►
From YouTube: 2022-09-07-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
A
A
It
is
meant
for
for
people
who
are,
you
know
part
of
the
project,
and
so
it
won't
necessarily
be
like
a
lot
of
introductory
stuff,
but
I
still
think
it's
it's
a
good
place
for
people
who
to
come
and
absorb
the
discussions
and
would
be
very
interesting
so
if
you're
in
that
area
or
can
make
it
that's
something
of
interest
to
keep
in
mind
and
I'll
paste.
The
link
to
the
the
tweet
that
announces
that
later
on.
A
If
there's
no
other
announcements,
then
we
can
move
on
to
the
issues
which
were
tagged
for
the
agenda.
We
have
a
fairly
light
agenda,
but
let's
get
into
them
so
the
first
one
is
inspector
introduce
inspector
promises
api.
This
is
number
44254.
B
A
A
Right
right,
okay,
that
does
swap
it
back
in
a
bit.
For
me,
I
think
it's
like
it's
were
the
the
you
know.
I
think
it
was
colin
commented
that,
like
he
thought,
we'd
decided
on
the
last
vote
that
we
were
going
to
use
the
the
node
colon,
but
then
other
people
pointed
out
they
thought
it
only
was
for
that
one
time
and
so
we're
back
to
discussing
whether
in
this
case
it
should
be
used
or
not
used.
Is
that
what
you
remember.
C
And
I
see
antoine's
here
as
well
and
he's
pretty
active
in
that
conversation
I
do
I
do.
I
do
want
to
just
insert
that
it
would
be
really
great
if
we
could,
once
and
for
all,
come
to
a
decision
on
this,
and
it
seems
like
every
time,
there's
a
new
module.
We
have
this
conversation
all
over
again
and
we're
always
caught
flat-footed
and
unprepared
and
stretches
over
five
meetings,
and
it's
just
really
annoying
for
everybody
involved
us
and
everybody
else
trying
to
get
stuff
done.
A
B
B
C
It
looks
like
jeffrey
had
looks
like
jeffrey
has
something
he
wants
to
say
unmuted,
and
I
think-
and
I
know
that
michael
mentioned
colin
I'd-
encourage
us
to
use
the
raise
england
function
for
this
conversation
because
we
might
actually
have
a
lot
of
stuff.
They
want
to
say.
D
B
E
I
think
it's
gonna
say
I
I
wouldn't
consider
it
new
like
if
it's
a
sub
path
but
an
existing
module,
then
no,
it's
not
a
new
top
level.
I.
C
D
D
I
was
thinking
that
this
wasn't
a
new
top-level
model
and
that
we
could
just
add
the
slash
promises
and
yeah
in
the
very
extreme,
obscure
case
that
someone
has
their
own
node
modules,
slash
inspector
folder
package
and
happens
to
have
a
promising
subfolder
of
that
we're
overriding
them
or
something
you
know,
but
like
that's
such
an
obscure
edge
case
that
I
wouldn't
really
consider
that
a
reasonable
december
major
breaking
change
that
this
should
be
safe
to
assuming
that
there's
nothing
else
that
I'm
not.
Thinking
of
that.
C
D
E
E
Whether
or
not
it's
a
breaking
change
yeah.
I
can
see
the
argument
technically
it
is
or
it
it
there
isn't
a
non-zero
chance.
However
unlikely
somebody
has
that
module.
So
technically,
yes,
it
is
a
breaking
change
there.
So
I
think
an
argument
can
be
made
to
treat
a
december
major.
D
C
So
in
terms
of
what
gets
into
a
relief
that's
up
to
the
releasers,
that's
not
up
to
the
tsc,
I
mean
in
in
theory.
We
have
delegated
that
to
releasers
they
they
are
responsible
for
determining
what
goes
into
what
release
and
what?
What
is
some
for
major
and
what
is
not,
or
even
choosing
to
incorporate
when
there's
a
compelling
reason,
some
ver
a
breaking
change
into
a
non-somber
major
release.
C
However,
as
we
all
know
in
practice,
they
they
look
to
us,
and
but
I
would
be
comfortable
just
letting
the
releasers
decide.
If
this
is
a
a
big
issue
or
not,
and-
and
I
mean
sure
december
major
technically,
that
means
it
has
to
wait
until
october.
That's
only
like
right,
that's
only
like
six
months.
D
Maybe
we
merge
it
in
with
december
major.
We
don't
bother
with
shenanigans
of
backboarding
it,
but
only
the
prefix
or
something
like
that.
It's
just
merchant
december
major,
we
can
maybe
make
a
statement
on
the
thread
that,
like
hey
releases,
there's
a
a
non-zero
edge
case
that
this
could
be
argue
december
major,
but
we're
also,
okay
with
it.
C
Basically,
just
put
it
in
a
summer
major
yeah
and
then
just
and
then
just
and
then
yeah
leave
it
and
then,
if,
if
releasers
decide
that
actually
we
would
like
this
to
be
an
lt.
You
know
in
in
18
or
whatever
fine,
but
but
unless
the
releasers
want
it,
I
mean
I
don't
know
that
it's
necessarily
huge.
I
don't
know,
I
don't
know
it's
usually
important
that
it
get
back
ported.
May
I
mean
I
guess
people
who
want
to
use
the
feature
in
older
versions.
D
E
C
And
danielle
just
put
and
for
the
purposes
of
people
watching
on
the
stream
danielle
just
put
in
the
chat,
I
think,
add
december
major
and
then
back
port.
If
requested,
slashes
and
a
disruptive
breaking
change,
I
mean
that
makes
sense
like
we
know
we
can
add
a
sem
for
major
and
then
you
know
like
we
are
not
back
porting
it
right
now.
But
if
we,
but
if
someone
if
we
change
our
minds
three
weeks
from
now
inside
the
back
port,
we
backboard
it
then
and
that's
okay
and
yeah.
A
C
B
Yeah,
I
would
just
like
to
add
that
I
think
it
would
be
a
mistake
to
land
it
in
lts,
even
like
I
think
current
would
be.
Okay,
lts
would
be
too
far
because
it's
really
not
worth
it.
I
think
james
proposal
to
just
that
that
promises
it
sounds
very
minor,
so
we
can
always
use
that.
A
So
it
sounds
sounds
like
we
have
consensus
and
we
can
put
that
in
for
this
specific
issue.
I
think
it
also
makes
sense
for
us
to
ought
to
document
this
somewhere
and
I'm
happy
to
volunteer
to
like
write
a
little
doc
or
something
because
we
should
basically
say
somewhere
like
a
new
module,
we'll
use
the
node
colon
prefix.
A
If
and
then
you
know
this
other
specific
case,
if
you're
adding
slash
promises
to
an
existing
module,
that's
okay!
You
don't
have
to
put
under
node
but
markets
december,
major
right
just
so
that
we've
got
that
written
down
somewhere
and
we
don't
next
time
this
comes
up.
There's!
No!
We
don't
need
to
discuss
it
unless
it
doesn't
fit
into
one.
C
A
C
A
A
A
E
C
B
Also
make
a
decision
today
if
we
want
for
new
core
modules
to
have
the
prefix
so.
A
Yeah,
that's
what
I
was
thinking
like
if
I
pr
that
into
the
collaborator
doc
like
it
sounds
like
here,
everybody
thought
we'd
already
agreed
that
through
the
last
boat.
So
if
we
actually
pr
it
in,
and
anybody
get
planes
we
can
say-
oh
well,
maybe
we'd
have
to
have
a
vote
right
on
to
confirm
that
or
something.
A
A
Okay,
so
I'll
paste
that
that's
good,
so
the
next
issue,
then
this
is
one
that
you
added
rich.
C
Yeah
so
the
node.js
security,
external
team
and
the
node.js
dash
private
security,
external
team
are
supposed
to
be
supposed
to
have
the
same
people.
I
don't
know
I.
I
don't
look
at
audit
logs
to
see
how
this
happened,
but
they
don't,
and
I
would
like
to
fix
that,
and
unless
somebody
wants
to
actually
dig
into
this
themselves,
I'm
just
going
to
go.
Do
it,
which
probably
involves
talking
to
you,
michael
or
somebody
else,
who's
aware
of
our
one
thing
to
sort
out
is
there
are
two
things
to
sort
out.
C
One
is
is
a
trial
of
bits
who
who
from
trouble
bits
if
anyone
should
be
on
that
list,
sure
and
the
other
thing
to
sort
out
is
of
the
non-trail
of
bits,
people
which
there
are
four
four
on
one
team
and
two
on
the
other.
You
know
what
to
do
with
all
of
them
and
that's
that
second
part,
I'm
comfortable
just
sort
of
like
looking
through
the
history
of
when
people
were
added
and
figuring
out.
C
What's
going
on,
and
then
just
telling
the
tsc
and
telling
the
security
triage
teams
what
I've
done
and
then
you
can
do
whatever.
But
the
trail
of
bits-
part-
I
don't
know,
I
don't
know
who's
involved.
C
If
anyone
at
this
point
it's
been
a
while,
since
we've
used
trailer
bits
for
something
yeah,
I
think
we
have
a
contract
with
them
through
the
foundation,
though,
and
I
think
for
another
x
number
of
months-
I
don't
know.
C
B
A
C
Okay,
well,
you
and
I
can
talk
about
this
offline,
but
I
just
want.
I
wanted
to
make
it
clear
to
everybody
else,
my
plan
to
just
sort
of
like
do
this
and
if
somebody
wants
me
to
not
just
do
it
and
wants
more
involvement
and
checking,
and
everything
else
tell
me
because
I
will
happily
include
anybody
who
wants
to
be
included.
Otherwise
I
will
fix
it
and
you
will
never
know
so.
C
A
Just
just
ping
me
and
I'll
find
the
name,
I'm
just
terrible
at
remembering
them,
so
I
don't
remember
off
the
top.
I
had
that
takes
us
to
strategic
initiatives,
then
so
chenzon
and
right,
yeah,
chenzong
added
an
update
on
the
shadow
result
on
the
shadow
realm.
A
A
couple
of
the
pr's
have
landed
and
he's
looking
at
rebasing
another
one
of
the
prs
to
just
saying
distangle
the
base
object
with
the
environment,
so
he's
just
pushing
that
hand
in
terms
of
the
next
10
effort.
We
did
have
a
meeting
today.
We're
planning
a
session
a
couple
sessions.
Actually
at
the
collaborator
summit
one
we
made
a
submission
for
the
one
at
the
collaboration.
A
Some
that's
going
to
be
about
sort
of
doing
the
whiteboard
brainstorm
in
terms
of
technical
priorities
and
then
wrapping
that
back
to
our
existing
ones,
seeing
if
things
are
changed
and
and
basically
you
know
validating
that,
we've
got
a
good
set
and
the
ones
we're
working
on
still
make
sense.
A
Let
me
look
at
the
other
ones.
Just
give
me.
A
Guys,
james
anything
on
http,
quick.
E
Yeah
I
went
and
refreshed
the
pr
there's
a
brand
new
pr
there,
the
previous
one,
after
about
two
and
a
half
years
bit
rotted
quite
badly
needed
to
be
touched
up.
There
are
some
build
issues,
some
test
issues
that
I'm
still
working
through,
but
I'm
just
waiting
for
people
to
start
reviewing
it.
It's
been
sitting
there
for
about
two
weeks
now,
maybe
longer
and
as
far
as
I
know,
no
one's
taking
a
look
at
it.
Yet
it
is
rather
large.
E
There's
lots
of
documentation
in
there
to
help
folks
go
through
it.
I'm
happy
to
jump
on
a
call
and
walk
people
through
it
to
help
kind
of
you
know,
get
get
oriented
for
for
doing
a
good
review.
E
One
key
thing
it
does
is:
it
does
not
expose
the
public
api.
We
talked
about
this
at
the
last
collaborator
summit,
yeah
that
we
wanted
to
get
the
internal
implementation
there
and
give
us
more
time
to
talk
about
what
the
public
api
for
hp3
is
going
to
be
and
and
that
kind
of
thing
there
is
a
javascript
api
there,
but
it's
an
internal
api.
It
would
not
be
it's
not
really
what
I
would
expect
to
expose
it
is
there.
There
is
no
specific
http
3
api
there.
E
E
E
E
One
thing
I
will
say,
like
I
said,
I'm
kind
of
concerned
that
there's
been
overviews
on
it
in
the
previous
one
for
so
long,
I'm
I'm
not
planning
on.
If,
if
folks
aren't
interested
in
reviewing
it
and
don't
take
the
time
to
review
it,
and
it
starts
a
bit
wrong,
I'm
not
gonna
update
it
again,
because
it's
a
hell
of
a
lot
of
work.
It
took
me
like
two
weeks
to
do.
E
I've
just
come
pretty
much
non-stop
working
on
it
to
get
it
updated,
and
you
know
so
I
I
would
really
appreciate
folks
taking
a
look
at
it,
so
we
can
get
this
thing
landed.
I
I
will
be
spending
some
time
next
week
going
through
the
remaining
kind
of
you
know,
tests
and
build
failures
that
are
there
and
kind
of
I'm
getting
those
figuring
those
out,
and
I
would
like
to
be
able
to
do
address
code
review
comments.
At
the
same
time,.
D
Do
you
want
to
maybe
you've
already
done
this,
but
you
want
to
ping
some
of
the
relevant
teams
and
trying
to
encourage
them
to
review
and
maybe
go
on
the
open,
js
black
and.
E
D
E
A
So
I
guess
the
question
two
is
is
like,
as
you
said,
it's
probably
quite
big.
It's
like
it
doesn't
expose
apis,
like
you
know,
pulling
in
the
existing
an
existing
c
dependency.
Like
all
that
code.
There's
no
point,
I
don't
think
us
looking
at
that
part
right.
So
it's
like
how
do
we?
How
do
you,
what
are
the
important
parts
to
look
at
and
how
do
you
kind
of
quickly
narrow
in
on
that,
in
terms
of
doing
something
that
might
add
value
as
a
review.
E
So
it
is
split
up
into
several
commits,
and
one
of
the
commits
does
update
the
ng
tcp
2
and
your
hp
3
that
can
be
ignored
right,
just
kind
of
stamps.
The
the
large
commit
that
actually
adds
implementation.
There
there's
so
there's
a
whole
new
set
of
c
plus
classes
that
are
there
the
the
oper
the
protocol
implementation
is
entirely
at
the
c
plus
level.
E
The
javascript
side
is
really
just
kind
of
superficial
to
kind
of
make
interacting
with
it
a
little
easier
to
perform,
like
type
validation
and
and
and
that
kind
of
thing
the
entire
protocol
operates
at
that
c
plus
level.
If
you
look
in
that
pr,
there
is
an
extensive
readme
there
that
kind
of
walks,
through
the
overall
approach
to
the
code
kind
of
how
it's
structured,
how
it
relates
to
quick.
E
It
even
gives
a
very
a
very
quick
introduction
to
quick,
so
folks
can
start
getting
oriented
and
then
there's
extensive
code
documentation
throughout
and
yeah
they're
out
there
to
to
help.
I
would
start
by
just
going
through
the
readme,
like
you
know,
you
know,
get
oriented
that
way
and
there
are
a
handful
of
tests.
E
Nowhere
near
complete
that's
one
of
the
things
that
I
that
I'll
also
be
working
on,
but
since
we're
not
exposing
a
public
api,
it's
also
something
we
can
do
incrementally.
E
But
but
the
one
thing
for
absolute
certain
you're
going
to
want
to
review
you're
going
to
want
to
read
the
quick
spec
get
familiar
with
that
in
order
to
because
otherwise
you
won't
be
able
to
know
if
the
implementation
is
actually
correct
or
not.
E
E
Like
I
said,
I'm
happy
to
jump
on
a
call
and
walk
people
through
it.
I
did
that
once
with
rich
and-
and
you
know
on
the
previous
one-
won't
shouldn't
take
too
long
to
do
just
reach
out
and,
and
let
me
know,
and
we
can
set
up
a
call
to
go
through
it.
E
A
Okay-
let's
see
sorry
just
looking
at
any
of
the
other
strategic
initiatives
that
we
have
from,
I
think
that
takes
us
to
the
end
of
the
list.
F
We
probably
don't
need
to
talk
about
it
here,
but
just
in
case
anyone
hasn't
seen
miles
opened
an
issue
in
the
release
repository
about
updating
to
npm
9
in
node
18.,
but
that
will
have
breaking
changes
which.
F
I
guess
needs
discussion,
it
doesn't
have
to
be
here,
but
if
you
haven't
seen
it,
I
encourage
you
to
read
through
he's
summarized
the
list
of
changes
that
are
being
proposed
for
mpm9
and
is
really
asking
for
an
exception
because,
like
we've
touched
on
earlier,
you
know
we
we
don't
drop,
but
the
release
team
does
not
drop
breaking
changes
into
a
lts
release
line.
So
he's
really
asking
for
an
exception
to
that.
F
So
the
release
team
will
make
a
decision,
but
obviously
the
tfc
will
also
have
input
and
any
anyone
else.
That's
like
viewing
this.
You
know
if
you
go
and
have
a
look
at
that
and
really
read
the
proposed
changes
and
and
sort
of
flag
up
anything
that
looks
like
a
sort
of
a
big
red
flag.
F
I
I
think
separately.
We
do
need
to
have
a
discussion
with
the
mdm
team
about
trying
to
align
releases,
because
this
isn't
the
first
time
this
has
happened
and
we
really
need
to
be
dropping
major
npm
releases
into
the
gas
of
the
major
releases
of
node
and
not
not
just
before
it
transitions
to
lts.
That's
that's
not
a
point
to
be
dropping
breaking
changes
in
denial.
A
Okay,
anything
else
that
people
want
to
mention
before
we
close
up
for
today.