►
From YouTube: 2021-10-06-Node.js Technical Steering Committee meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Okay,
so
welcome
to
the
node.js
technical
steering
committee
meeting
for
october
6
2021.
we'll
follow
the
agenda
based
on
the
issue
that
was
posted
in
the
issue
in
the
cc
repo.
Before
we
get
started,
does
anybody
have
any
general
announcements
they'd
like
to
share.
A
A
C
A
Okay,
lots
going
on
this
month,
okay
on
the
cpc
and
board
meeting
updates.
So
I
think
there's
no
no
board
meeting
update
this
week,
rich
anything
on
the
cpc
front.
I
didn't
make
the
meeting
so
I'm
not
sure.
A
A
B
Meeting
next
week
and
yeah-
I
don't
I
I
looked
for
stuff
to
bring
here
but
didn't
see
anything
that
needed
to
be
brought
to
this
meeting.
A
Sounds
good
okay,
so,
let's
move
on
to
the
issues
that
were
tagged
for
the
agenda,
so
one
of
the
things
we
were
we've
discussed
doing
is
getting
some
more
input
on
issue
number
30697,
which
is
migration
of
core
modules
to
primordials,
and
today
we
have
bradley
ferris
to
contribute
to
that
so
bradley.
You
want
to
take
take
that
away.
D
Sure
so
the
basic
premise
I
think,
has
been
covered
a
few
times.
I
don't
think
we
need
to
cover
that
there
are
different
arguments
on
what
path
should
be
taken
going
forward
and
different
arguments
about
kind
of
even
the
purpose
of
primordials.
D
My
stance
is
generally
that
primordials
themselves
aren't
the
goal.
Primordials
are
a
mechanism
to
make
parts
of
node
core
robust
against
various
tampering.
I
don't
think
personally,
we
need
to
make
all
of
node's
core
robust
if
you
go
and
you
tamper
with
some
things
like
mutate,
prototypes
and
browsers
in
other
environments.
D
Other
languages,
if
you
replace
essentially
implementations
with
custom
ones,
there's
no
guarantees
that
they
work,
but
in
general,
for
most
environments,
browsers
power,
shell,
all
sorts
of
languages,
the
loading
mechanism,
the
thing
that
actually
puts
code
into
executable
space
is
protected
from
tampering
in
various
ways.
D
I
think
the
the
need
for
node
to
be
robust
is
purely
about
the
initial
execution
and
further
loading
of
code
into
executable
space.
It
is
not
about
the
behavior
of
the
code
itself,
it's
just
about
knowing
that
when
you
load
a
file
off
disk
people
aren't
going
to
tamper
with
that
file.
If
you
use
the
proper
security
mechanisms,
so
in
general,
I
think
primordials
make
contributions
to
core
extremely
difficult.
D
I
think
core
effectively
doesn't
write
javascript
due
to
primordials
the
way
you
write
for
nodes
core
is
very
different
than
how
you
would
write
any
other
javascript
that
you'd
do
in
open
source
in
other
places.
Stuff
like
that,
since
we're
already
effectively
writing
a
different
language.
D
I
think
it'll
be
easier
if
we
ported
parts
of
core
off
this
weird
dialect
and
determine
what
parts
of
core
we
want
to
port
to
some
language
that
doesn't
suffer
these
kind
of
pollution
attacks.
D
I
don't
really
care
what
we
port
it
to.
I
used
to
put
stuff
in
c
plus
plus,
because
I
didn't
have
to
worry
about
this
stuff.
People
repeatedly
wanted
me
to
move
it
to
javascript.
Sometimes
they
would
take
the
c
plus
parts
and
move
it
to
javascript
and
every
time
they
did
that
for
important
parts.
We
started
it
using
before
primordials.
This
thing
called
safe,
globals
and
then
people
wanted
olive
core
to
be
robust
and
it
kind
of,
I
think,
has
spiraled
out
of
control.
D
I
have
zero
care
about
performance
on
this.
If
you
don't
want
to
feel
safe
about
running
any
application
in
node
I
mean
we
could
go
for
performance,
but
I
think
there
has
to
be
some
minimum
level
of.
If
you
give
node
some
stream
of
bytes
to
load
as
executable,
it
should
load
that
stream
of
bytes
it
shouldn't.
Really.
I
personally
don't
think
performance.
There
is
going
to
be
good.
D
C
Okay
thanks.
I
have
one
question
on
this
on
this
regard,
so
why
do
you
think
that
loading
things
is
can
be
slow?
The
startup
sequence
can
be
slow
like
there's
been.
D
It
I
don't
know
what
you
mean
by
the
word
can
be
slow.
It
is
slow.
C
Yeah,
I
know,
but
you
know
you
were
it's
low
now,
okay,
you
it
can.
I
there's
a
lot
of
attention
on
making
it
run
faster.
I
don't
know
you
know
it's
there's
a
lot
of
attention.
A
lot
of
question
on
boot
on
the
bootsy
on
the
startup,
see
the
cold
start
the
startup
sequence,
like
those
things.
So
you
are,
you
know
it's
it's
already
slow.
It
is
going
to
make
it
slower
you.
You
know
from
my.
C
D
C
D
But
yes,
performance,
really
the
slow
part
is
going
to
be
the
integrity
checks.
It's
not
really
about
the
language
itself.
It's
about
actually.
C
C
C
A
Yeah,
if
it's
opt-in,
that
seems
to
be
like,
we
may
have
different
use
users
like
some
users
who
will
really
care
about
the
fast
startup,
absolutely
over
everything
else,
other
ones
who
may
want
to
turn
this
on
and
as
long
as
it's
like
an
opt-in,
and
that
seems
like
a
way
to
satisfy
both
is
there?
Is
there
challenges
in
doing
that.
D
So
when
we're
using
javascript
primordials,
we
can't
easily
make
two
paths
a
slow
path
and
a
fast
path,
so
we
could
completely
copy
a
fast
path
out
and
maintain
two
different
loaders.
For
example,
I
don't
think
that's
practical,
given
the
low
number
of
people
working
on
them,
I
mean,
if
you
had
somebody
hired
full-time
to
do
it.
Maybe,
but
I
don't
think
it's
realistic.
D
D
There
are
existing
public
repos
from
chrome
on
github.
If
you
want
to
look
up
what
they
tried
to
do
with
some
transforms,
I
think
it
was
part
of
the
get
originals
proposal,
but
yeah
the
dynamic
lookups,
especially
of
symbols
and
syntax
operations,
is
just
makes
it
so
it
devolves
into
not
being
robust,
so
they
all
abandoned
it.
Firefox
actually
has
self-hosted
javascript,
they
don't
do
transpilation,
although
they
looked
into
it.
They
actually
have
a
very
specific
subset
and
dialect
of
javascript
that
they
write
kind
of
like
what
we
do
with
primordials.
D
He
wants
to
talk
to
me
because
I'm
not
paying
attention
to
her.
My
recommendation
is
really
we
move
parts
of
core
off
javascript
and
just
declare
those
the
defensible
parts
and
the
rest
of
it.
We
move
back
to
normal,
looking
javascript.
D
If,
if
we
aren't
trying
to
actively
prevent
users
from
you
know,
instrumenting
things
monkey
patching
things
doing
whatever
they
want.
The
cost
of
primordials
is
basically
maintainers
burden.
There's
there's
very
little
reward
in
it.
From
my
knowledge,
there's
no,
like
security
model
reason
we're
doing
it,
we're
just
doing
it
so
that
node
doesn't
crash.
If
you
do
something
weird,
but
I
mean,
if
you
do
something
weird,
you
can
always
just
make
your
application
fail
anyway.
I
don't.
I
don't,
have
a
strong
opinion
on
that.
D
It
really
depends
on
how
much
code
loading
we
want
to
do.
We
could
state
that
only
common
js
is
defensible.
Only
esm
is
defensible.
D
If
we're
going
for
all
of
the
code
loading,
we
basically
wouldn't
be
wanting
to
use
most
the
javascript
internal
binding
apis
anyway,
so
you
would
effectively
just
be
calling
out
to
lib
uv
directly
or
some
other
thing,
so
you
would
have
none
of
core
really
affected,
except
the
defensive
parts.
It
would
just
be
a
strong
barrier
between
them,
like
ipc.
D
The
common
js
loader
is
probably
forever
kind
of
tainted
due
to
history,
so
I
wouldn't
actually
say
it's
as
defensible
as
the
esm
loader,
but
that
would
be
just
the
common
js
loader,
not
the
file
system,
parts
of
it,
not
the
path,
look
up,
parts
of
it
and
then
the
esm
loader,
which
is
already
pretty
robust
against
file
system,
tampering
and
stuff
the
policy
mechanism
as
well.
D
C
Yeah,
that's
fine
yeah,
if
you,
if
you
run
it
on
the
on
a
separate
thread
and
so
on.
Yes,
so,
but
not
using
primordials.
What
I
mean
is
it's
having
to
rewrite
that
completely
like
part
of
the
massive,
the
part
of
the
more
important
performance
penalties
of
using
primordials
everywhere
are
inside
those
things,
especially
on
all
those
things
that
operates:
use,
arrays,
okay,.
D
I
wouldn't
say
we
port
it
to
c
I
I
have
no
preference,
it
could
be
c
plus
plus
it
could
be
rust
and
wasm.
It
could
be
on
a
different
thread,
just
isolate
it.
Okay
make
it.
So
it's
not
temperable.
A
D
B
G
Maybe
another
question
is,
I
think,
there's
a
new
proposal
that
is
going
to
be
presented
to
the
tc39
the
bind
operator
so
just
wanted
to
throw
it
out
there.
I
don't
I
don't.
I
don't
know
if
that
changes
something
for
our
4ks
here
but
yeah.
Maybe
another
solution
would
be
to
change
javascript
for
a.
D
A
Okay,
well,
thank
thank
you
bradley
for
your
time
and
and
the
discussion
that
was
great.
We
will
flip
back
to
the
next
agenda
item,
which
was
a
number
four
zero,
two
three
five,
which
is
add
initial
list
of
technical
priorities.
A
I
added
this
to
the
agenda
because
I
wanted
to
make
sure
you
know
all
the
tse
members
were
aware,
and
could
you
know?
Hopefully
you
know
review
comment
it's
intended
to
capture.
You
know
what
we
think
is
important
to
ensure
success
for
node
going
forward,
and
you
know
I
think,
that
technical
steering
committee
members
will
all
have
an
opinion
on
that.
It's
based
on
work
from
the
next
10
working
group
who's
done
some
brainstorming.
A
We
had
a
mini
summit
and
this
is
our
attempt
at
the
very
highest
level
to
highlight
you
know
it
doesn't
go
into
details
of
what
we
should
do,
but
it's
intended
to
capture
the
like
for
this
year.
These
are
the
things
we
think
are
most
important
and
then
we
could
dive
into
each
one
of
them.
Some
of
them.
I
think
we've
got
covered.
You
know
like
if
we
look
at
new
language
features,
keeping
up
with
new
javascript
language
features.
A
Michael
zaso
already
does
a
great
job
of
keeping
us
up
to
date
with
v8,
so
we
get
all
those,
so
some
of
them
will
be.
You
know
we
we
can
just
say
yep
check,
we're
doing
a
good
job
on
those
other
ones
might
be
well.
Actually
we're
not
actually
doing
anything.
So
since
we
think
they're
important,
maybe
you
know
let's
get
together
and
figure
out
what
we
should
be
doing.
A
A
Okay,
if
not,
the
next
issue
is
replace
openssl
1.1.1
with
openssl
3.0.0.
A
You
know,
we've
been
tracking
the
work
in
openssl
for
quite
a
while
that
actually
went
ga
in
september,
and
this
discussion
is
about
pulling
it
into
17..
Most
of
the
people
who've
chimed
in
are
like
yes,
we
should
pull
into
17
so
that
we
get
earlier
sort
of
feedback
from
you
know,
users
in
in
the
odd
release
versus
the
next
even
release
based
on
release
schedules.
A
We
would
pretty
much
have
to
pull
it
into
18,
because
the
end
of
life
for
1.1.1
is
actually
before
the
end
of
lts.
18
would
be-
and
I
think
actually
we
may-
we
may
even
be
in
I-
I
can't
remember
specifically,
but
I
think
that
might
even
be
the
case
for
16,
but
anyway
for
18.
We
would
definitely
want
to
do
it,
but
the
consensus
seems
to
be
if
people
chimed
in
that
we
should
do
it
for
17..
A
H
G
Yeah,
so
it's
going
to
be
discussed
in
the
next
loader
working
group
meeting,
which
is
next
tuesday,
so
we're
still
looking
for.
What's
the
best
technical
approach
to
add,
support
for
importer
sessions
with
regard
to
loaders.
A
Okay,
is
there
anything
like
that,
we
need,
you
know,
input
or
opinion
from
the
tse
or
or
you
know,
is
it
progressing.
G
Yeah,
if
the
meetings
goes
well,
we
shouldn't
need
the
input
from
tsc.
So
maybe
we
can
remove
the
delay
more.
A
F
H
A
A
A
Rename
default
branch
for
master
domain
a
couple
more
have
been
flipped
over
still
working
on
some
of
the
others,
but
we
are
getting
down
to
you
know
some
discussion
about
when
we
get
to
the
node
core
repo.
We
might
need
to
treat
that
kind
of
like
we
do
for
a
security
lease
where
we
lock
things
down
for
some
period
of
time.
A
A
A
Okay,
so,
okay,
so
we're
not
quite
there
yet
the
the
other
issue,
which
is
under
the
tc
repo,
which
is
to
be
or
not
to
be
in
core,
that's
one:
zero.
Four
one.
B
Yeah,
so
I
opened
the
pull
request
to
last
week.
I
last
week
in
the
meeting
I
agreed
to
try
to
consolidate
the
information
from
the
discussion
that
so
there's
this
tsc
issue.
Then
there's
the
node.js
repo
discussion
related
to
it
and
at
the
meeting
to
tsc
me
last
week
I
agreed
to
try
to
consolidate
the
information
from
the
discussion
into
a
single
document
which
I
have
done
in
node.js
pull
request.
40338
brian
white
and
benjamin
groombaum
have
already
asked
questions.
Slash
left
comments,
matteo
agreed
with
a
comment
from
benjamin.
B
I
would
encourage
people
to
look
at
that
document.
My
issue
number
again
just
so
that
I
can
get
it
into
the
notes.
The
pull
request
is
40338.
I
will
paste
the
link
into
the
chat
right
now
there
it
is
and
the
approach
here
was.
You
know
there
were
kind
of
two
conversations
going
on
there's.
What
are
the
considerations
for
including
a
module
in
core
versus
not
including
a
modular
core?
So
should
we
have
fashion
course?
Should
we
have
my
mid-course?
Should
we
have
x
and
core
you.
I
B
And
then
these,
then
the
secondary
con
or
not
secondary,
but
additional
conversations.
If
it's
in
core
does,
should
it
be
in
the
court
repo?
Should
it
be
it's
on
repo
and
we
vendor
it
in?
Should
it
be,
you
know,
there's
there's.
B
Of
course,
that
doesn't
answer
the
question
of.
Do
we
want
that
functionality
in
core,
which
is
a
different
question
anyway?
So
this
document
is
pretty
simple
and
short
and
probably
needs
a
bunch
of
additions
and
edits,
but
I
figured
something
imperfect
that
we
could
look
at
react
to
discuss
was
better
than
just
having
the
move
along
without
you
know,
going
over
the
same
things
over
and
over
again,
without
actually
creating
an
artifact.
So
here
we
are.
A
B
Starting
point
yeah
once
the
and
once
we
have,
if
we
have
consensus
on
on
on
you
know,
if
we
can
reach
consensus
on
what
things
are,
you
know
strong
indicators
that
something
should
or
shouldn't
be
in
court.
If
we
can
reach
consensus
on
that,
then
we
can
document
that
and
move
on
to
the
next
conversation,
which
is
when
we
put
when
we
move
external
things
into
core.
How
do
we
do
it
you
know?
And
but,
but
I
think
I
think
I
think
there's
no
point
in
having
that
conversation.
B
If
we
can't
agree
on
this
first
so-
and
I
don't
know
if
we
need
to
talk
about
it
in
this
meeting
I'm
happy
to,
but
I
think
that
you
know
I
just
opened
it
in
the
last
16
hours.
I
think
we
can
probably
let
the
conversation
happen
on
github
for
a
week
before
picking
this
up
again
and
just
as
a
preemptive
measure,
I'm
going
to
add
the
tsc
agenda
label
to
that
pull,
request
and
yeah.
That's
good
and
yeah.
B
Yeah,
that's
that's
that's
worth
considering
and
thinking
about
maybe.
C
I
yeah
I,
I
would
frame
it
like
that,
and
I
I
understood
it
was
this
way.
Okay,
it's
functionality.
Now
we
can
decide
to
include
a
module,
add
a
dependency.
We
can
decide
to
include
something
and
just
leave
the
code
and
adapt
it
and
fork
it
within
our
tree.
There
might
be
a
lot
of
different
options:
okay
on
the
table,
so
I'm
not
you
know
I
I
don't
want
to
to
limit
ourselves
to
some
extent.
Okay,
so
two,
including
third-party
modules,
like
only
third-party
modules.
A
A
A
A
I'm
just
looking
at
the
things
we
have
so
antoine
core
promise
apis
anything
to.
H
A
G
A
A
I
think
that
would
be
good,
like
you
know,
status
of
the
core
promise
apis.
If
you
put
that
table
in
there
and
then
have
the
link
in
this
dock,
that
would
be
a
handful,
a
handful,
a
useful
sort
of
reference.
We
can
look
at
when
we're
wondering
where
we're
at
okay.
Thank
you
very
much,
and
then
the
other
one
that
we
have
somebody
here
today
is
a
v8
currency.
So,
michael,
I
noticed
you
just
joined,
I
don't
know
if
you
have
an
update
on
that.
I
I
A
I
A
I
I
A
Okay,
so
unless
there's
any
other
questions
on
that,
I
think
we've
covered
strategic
initiatives
and
I
see
that
jordan
and
I'm
trying
to
promote
jordan
has
joined.
So
we
can
flip
back
to
discussion
of
primordials.
A
J
Thanks
thanks
for
being
flexible
with
the
schedule,
so
essentially
my
viewpoint
is
that
philosophically
and
like
as
a
user,
it
is
insert
adjective
here
if
the
platform
I'm
using
is
trivial
for
me
to
break
like
if
I
could
type
something
into
the
browser
console
that
would
make
web
pages
stop
working
or
the
web
page.
J
I'm
on
stop
working
like
that
would
be
weird
like
it's,
as
opposed
to
like
it's
fine,
that
I
can
break
user
code,
but,
like
I
shouldn't,
be
able
to
break
how
like
ajax
works
or
something
because
I
mess
with
something
unrelated
and
so
in
node,
in
the
rebel
or
in
a
program.
J
If
I
delete
built-ins,
there
are
lots
of
parts
of
node
that
just
fall
apart
and
of
course
that's
of
doing
so
is
a
bad
practice
and,
of
course
like
it
is
a
defensible
argument
that
a
program
doing
that
isn't
something
we
need
to
worry
about.
But
it
just
feels
very
kind
of
strange
to
me
that
the
platform
is
is
brittle
in
this
way,
and
so
it
would
be.
J
You
know-
and
I
personally
discovered
this
a
number
of
years
ago,
when
I
was
trying
to
test
polyfills
by
deleting
the
built-in
and
all
of
a
sudden.
I
got
you
know
a
screen
full
of
errors,
and
this
happened
to
be
in
the
rebel
but
like
it
just
it
sort
of
that.
That's
when
I
started
looking
into
the
it
being
an
issue,
so
the
more
concrete
topic
is
the
mechanism
by
which
node
makes
itself
robust
against
modifying
of
built-ins
the
current
approach,
because
of
there's
no
solution
for
this
in
the
javascript
language.
J
Hopefully,
yet
the
current
approach
is
not
ergonomic
and
v8
doesn't
optimize
for
for
it.
Well,
it
seems
so
it's
not
performance,
but
it
is
correct
and
or
like
it
ensures
correctness.
So
I
don't
have
any
attachment
to
the
current
approach.
I
just
don't
really
know
of
a
better
one.
Yet
there's
language
proposals
right
now
that
the
bind
operator
in
particular
would
allow
us
to
avoid
binding
all
of
the
almost
all
of
these
built-in
methods,
and
that
would
likely
avoid
the
performance
cliffs
that
we're
currently
seeing
in
some
cases.
J
But
you
know
it's
I
that
these
aren't
going
to
be
silver
bullets.
Obviously,
so
the
the
questions
we've
talked
about
in
the
calls
we've
had
about
primordials
are
kind
of
like
how
far
do
we
want
to
go?
Do
we
want
to
just
stop
trying
to
make
robust
in
this
way?
Do
we
want
to,
you
know,
make
everything
robust
at
all
costs,
even
at
performance,
there's
plenty
of
arguments
in
the
middle
for
let's,
like
avoid.
J
You
know,
let's
like
change
everything
over
but
like,
let's
be
very
careful
about
hot
pads,
and
things
like
that.
There's
been
some
perspectives
that
the
only
parts
of
node
that
need
to
be
robust,
robust,
like
this-
are
the
module
loading
system
and
not
all
the
rest
of
the
runtime,
but
because
the
module
loading
system
heavily
reuses
random
things
from
all
over
node.
J
J
Oh
my
proposal
is
to
continue
hardening
node
against
prototype
or
built-in
modification
and,
to
certainly
case
by
case,
as
problems
arise
where
I
assume
problems
are
going
to
be
primarily
performance
cliffs,
that
those
can
be
reworked,
and
I
think
that
there's
many
cases
where
we
can
preserve
the
robustness
and
the
performance
without
using
primordials,
and
if,
whenever
that's
the
case,
we
should
do
that
and
it'd
be
fine
to
not
use
primordials
in
those
cases
you
know
to
avoid
the
performance
cliff,
but
then
we
like
by
the
time
we're
finished,
we'll
have
a
few
of
these
cases,
annotated
and
that
can
be
pursued.
J
You
know
by
anyone,
who's
interested
in
ensuring
robustness
and
also
keeping
performance
right.
So
so,
essentially,
the
proposal
is
not
that
we
sacrifice
performance
for
robustness,
it's
that
we
prioritize
robustness
and
then
compromise
for
performance
whenever
it's
necessary.
C
C
Is
doing
stuff
so
that
it
it
does
not
work
in
certain
cases
because
it
overrides
all
of
our
primordials,
so
it
has
its
own
primordials
and
then,
for
example,
tracks,
like
instance
of
promise
or
instance
of
error
that
do
not
work
anymore.
C
C
Is
this
something
in
certain
cases?
Yes,
so
inside,
if
you're
doing
inside,
if
you
have
an
error
that
is
generated,
for
example,
from
the
short
module
and
or
our
assert
internal
module,
and
it
throws
okay
and
it
throws,
and
you
throw
that
that
error,
if
you
do
a
check
on
instance,
of
error,
which
is
very
common,
especially
in
a
sync
await
code,
it's
it's
not
going
to
work,
because
that
library
is
not
not
because
we
don't
need
to
do
something
because
of
just.
C
I
am
saying
that
there
are
libraries
in
the
ecosystem
that
relies
on
the
fact
that
they
can
change
all
of
those
all
the
primordials
to
run
okay,
and
by
removing
that
functionality
we
will
cause
them
to
break
or
significantly
change
how
they
work.
I
might
be
okay
with
that.
It's
just
a
fact
to
the
site
about
it.
J
Yeah,
I
would
love
to
hear
more
about
that
offline.
I
think
that
if
you're,
using
instance
of
because
of
the
existence
of
vm
and
iframes
you've
already
your
code's
already
broken,
so
I'm
not
worried
about
it.
C
J
I
I
D
D
So
there
are
a
well-known
set
of
things
that,
even
if
you
replace
the
globals,
it
doesn't
matter
for
a
lot
of
javascript's
language
features.
It
doesn't
use
the
globus.
These
are
called
the
undeniables
when
we
talk
in
tc39
so
trying
to
state
that
it's
safe
ever
to
replace
the
globals
is
not
agreed
by
tc39
they're
things
that
are
simply
undeniable,
and
one
of
those,
for
example,
is
you
can
always
get
to
the
function
prototype
from
a
function.
Literal.
J
I
I
guess,
maybe
if
I
implied
that
that
was
that
there
was
safety
in
there,
then
I
I
didn't
mean
to
the
the
issue
here
is
that
node
wants
node
core
should
have
everything
be
undeniable
to
itself,
but
only
the
subset
that
you've
just
described
bradley
are,
in
fact
undeniable.
D
Fairly
large,
if
you
do
weird
things
you
can
talk
to
agorik,
they
have
like
an
actual
list
somewhere
of
this.
J
B
We
are
about
about
five
minutes
from
the
top
of
the
bar,
so
I
think
we
probably
need
to
yeah
good.
B
Put
it
yeah
come
back
to
this,
but
I
I
found
this
really
helpful
today,
so
thank
you
bradley
and
jordan.
So
much.
A
Yeah,
thank
you
very
much
and
we'll
we'll
now
move
on
to
a
private
session.
So
if
you
bradley
and
jordan,
you
can
drop
off.
Thank
you
very
much
for
coming
and
providing
that
input.