►
From YouTube: 2021-03-11 - Node.js Release Working Group 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
So
we
are
live
with
the
node.js
release,
working
group
meeting
on
the
11th
of
march
2021
and
we
will
start
by
working
through
the
items
on
the
agenda,
which
is
in
the
node.js
release,
issue
651
I'll
go
ahead
and
share
my
screen
to
get
started,
but
while
I'm
doing
that
are
there
any
announcements,
people
would
like
to
make.
A
I
guess
one
thing
to
mention
is
node:
16
is
due
out
in
about,
I
think,
around
five
to
six
weeks
time,
so
we're
actually
starting
to
do
some
test.
Builds
of
that
just
to
check
infrastructure
and
things
are
running
smoothly.
A
For
14,
I
think
we're
still
trying
to
get
a
collaborative
effort
together
to
land
some
items
on
the
14
x
branch.
I
did
see
a
ping
on
the
on
local
yesterday,
where
someone
mentioned
that
there
was
a
bit
of
a
backlog
of
things
that
needed
to
land
on
the
14
release
line.
I
haven't
run
branched
if
for
a
while,
and
but
I'm
expecting
it
to
be
like
over
a
thousand,
if
not
2
000,
so
it
might
end
up
being
more
of
an
opt-in
rather
than
us
triaging.
The
whole
list.
B
Yeah
on
the
subject
of
14,
specifically
I'm
pairing
with
a
bank
bangkol
to
land
some
of
the
work
he
had
backlog
for
stack,
traces
and
source
maps,
so
I'm
probably
going
to
be
landing.
Some
commit
some,
the
backboarding
on
the
staging
branch.
A
Okay,
so
that
kind
of
lands
with
our
kind
of
opting
kind
of
stuff,
the
items
that
we've
that
have
explicitly
been
called
out
as
being
needed
to
land
on
the
branch
rather
than
obstructing
that
massive
list
yeah
sounds
good,
so
yeah,
I
guess
we'll
see
how
that
goes.
We
probably
need
to
bump
this
schedule
now
in
terms
of
release
candidate
time
frame.
It
looks
like
we
may
even
start
pushing
into
april.
A
If
we
want
to
give
the
full
three
weeks
and
that's
if
we
can
get
enough
landed
to
warrant
during
release
over
the
next
couple
of
weeks.
Any
concerns
there
particularly
or
are
we
still
going
to
aim
towards
doing
a
sum
for
minus
soon.
B
I
think
I
think
this
this
begs
the
question
that
we
want
to
maybe
change
the
policy
on
on
the
lts
to
an
opt-in
kind
of
thing
and
communicate
that
better
to
the
rest
of
the
collaborators.
If
that's
the
case.
A
So
like,
rather
than
saying,
we
will
triage
everything
that
lands
in
current.
We
will
say,
please
notify
the
release
team
at
the
lts
watch
label
for
anything,
you
believe,
should
land
on
the
14x
release
line.
A
C
Maybe
maybe
we
could
change
what
maintenance
means
or
just
call
it
something
else
like
lts
versus
active
lts,
or
something
like
that,
and
only
do
six
months
of
the
act
of
keeping
things
up
to
date
and
then
for
the
rest
of
the
lts.
It's
kind
of
that
hey
when
it
like
makes
sense,
and
when
it's
asked
for
kind
of
like
a
like
a
push
model
rather
than
a
pull
model
that
could
afford
us
a
bit
more
flexibility
in
the
maintenance
life
cycle
of
the
releases.
C
I
guess
it
like
in
theory
would
maybe
mean
that
we
could
potentially
have
more
churn
on
a
release
later
in
its
life
cycle,
but
I
think,
like
the
odds
of
that
happening,
are
pretty
low,
but
what
it
would
mean
would
be
like
maybe
we'd
have
more
flexibility
to
do
a
minor
if
we
had
to
or
more
flexibility
to
like
like,
for
example,
we
just
saw
this
fs
promises
thing
where,
like
there's
the
massive
like
500
times,
speed
improvements
that
have
been
noticed,
we'll
probably
just
decide
to
land
that
on
maintenance
anyways,
so
it
kind
of
doesn't
feel
like
that's
too
different.
D
So
even
if
you
were
to
say
six
months
of
you
know
actively
back
we're
not
doing
that
at
the
moment,
so
it's
yeah.
That
was
the
problem.
I
was
not
not
going
to
solve
the
problem.
We're
actually
seeing
it
right
at
this
moment
in
time
with
14.
D
And
yes,
we
have,
you
know,
changed
dates
and
things
before,
but
I
think
the
main
problem
we've
got
with
this.
One
is
just
time
that
people
devote
to
doing
it
and
obviously
the
longer
it
goes
on
before
we
do
the
minor
the
bigger
the
diff
gets
er
to
to
the
point
that
you
know
it
might,
it
might
have
to
be
selective
just
because
there's
just
so
much
that's
accumulated
since
october.
A
Yeah,
so
I
guess
we
would
have
aimed
to
do
like
in
the
q4
time
frame
like
one
minor,
but
that
got
pushed
out
for
various
reasons.
Security
releases
time
of
us,
particularly
what
I
find
is.
I
can
because
the
patch
releases
that
we
have
done
were
very
much
regression
fixes
and
opt-in
and
security
releases.
A
We
don't
have
such
lengthy
requirements
on
like
the
release
candidate
phase
for
those
for
most
of
those,
and
I
do
find
it
a
bit
of
a
struggle
to
kind
of
put
together
a
minor
release
wrong
in
mind
the
backlog
and
also
bearing
in
mind
the
massive
like
three
weeks,
like
that's
a
lot
long
period
of
time
to
have
something
on
my
list.
B
A
Part
of
the
reason
it's
been
pushed
out
and
we've
been
like
about
five
for
14,
because
I've
done
a
few
of
the
recent
ones
is
because
I
feel
like
I
don't
have
enough
time
to
get
a
good
enough
chunk
of
stuff
on
the
staging
branch
to
warrant
minor
release.
But
I
do
have
time
to
get
a
few
bits
on.
So
maybe
we're
happy
putting
out
some
for
minor
releases
out
where
there's
only
maybe
four
or
five
or
like
a
small
number
of
actual
feature
editions.
A
But
I
guess
because
we
only
do
it
once
per
quarter.
Mine
was
like.
I
really
want
to
dedicate
enough
time
to
get
everything
back
that
we
can
at
this
point,
because
if
we
commit
to
only
doing
one
per
quarter,
people
then
have
to
wait.
So
you
really
want
to
make
sure
you've
included
what
you
can,
but,
as
a
result,
we've
ended
up,
pushing
it
out
and
the
backlog's
got
bigger.
So
there's
a
lot
more
work
for
us,
so
not
sure
on
the
best
approach
to
go
forward
with
at
this
point.
C
Yet
so
so
richard
for
what
it's
worth
historically,
when
I
was
managing
two
lts
branches,
I
I
would
not
flow
back
through
lts's
so
like
it
would
land
on
both
lts's.
At
the
same
time,
right
it
was
like
when
I
was
doing,
I
guess
like
six
and
eight
and
eight
and
ten
so
for
for
what
it's
worth
well,
it
can
be
maybe
confusing
to
folks
if,
for
example,
12
has
something
that
14
doesn't.
C
I
don't,
I
think,
for
the
exact
reason
that
you
pointed
out,
it's
not
necessarily
very
pragmatic
to
have
it
have
to
like
waterfall
through
every
single
release.
Okay,.
A
I
guess
there's
also
the
consideration
that,
like
12's
in
maintenance
at
the
moment-
and
I
think
we
have
seen
this
for
14
and
12
at
the
moment-
we're
putting
out
a
new
feature
on
a
maintenance
release,
but
not
the
active
one.
The
optics
of
that
might
be
a
little
strange,
so
I
think
we'd
at
least
try
to
align
the
releases
roughly
at
the
same
time.
So
people
aren't
saying
hey.
Why
is
this
maintenance
release
got
a
new
feature
before
the
act
of
lts,
but
then
aligning
dates
across
releases.
A
So
I
guess
for
the
next
steps
on
14,
maybe
it's
worth
taking
a
look,
see
how
much
is
on
the
staging
branch
and
seeing
whether
we
can
say
yes,
there's
enough
to
just
maybe
create
a
proposal
and
what
we
land
in
that
proposal
on
a
given
date
goes
out,
even
if
it's
slightly
smaller
than
we
expect.
A
E
B
A
A
Sure,
thanks
for
landing
those
good
to
get
the
depths
updates
in
because
picking
up
the
bug
fixes
and
such
I
guess,
if
we
landed
all
of
these,
if
we
could,
if
they
all
passed,
etc,
that
would
be
another
10
well
about
seven
pr's,
but
probably
about
10
commits
or
so,
and
it
might
be
worth
looking
at.
How
much
has
the
label
lts
watch.
A
Yeah
just
to
try
and
get
a
miner
out,
not
many
another
eight,
so
there
would
be
maybe
30
40
commits.
A
Would
that
be
enough
to
warrant
putting
december
miner
out
just
to
get
one
out
for
the
features
that
we've
been
told
or
would
people
prefer
that
we
push
it
out
again
and
do
try
to
get
through
some
of
that?
Those
commits
the
650
or
so
or,
however
many
they
are
to
pull
some
more
items.
A
C
Okay,
I
was
just
gonna
say,
like
I,
don't
know
who's
volunteering
to
do
this,
but
if
someone's
volunteering,
maybe
they
could
just
try
to
get
as
much
as
they
can
get
done
and
just
call
a
date
and
like
make
it
somewhere
minor
so
that
they
could,
like.
I
personally
think
keeping
it
semverminer
makes
it
easier
to
do
the
back
ports
because
then
you're
not
like
having
to
not
land
certain
things
yeah
I
can
offer
to
pitch
in
for,
like
maybe
one
or
two
backboarding
sessions.
C
That's
what
goes
and
we
could
do
a
call
to
the
project
for
semverminers
and
if
folks
have
specific
things
that
they're
looking
for
they
can.
You
know,
ask
and
hopefully
help
with
the
backboard.
A
Yeah
sure
yeah,
I
can
certainly
commit
to
running
like
branch
diff
landing
all
I
can
async
and
I
could
possibly
commit
to
doing
the
release
once
we've
got
some
bits
together
unless
anyone
else
would
like
to
do
that,
release
as
an
lts
release
it.
The
main
thing
I
can't
commit
to
is
like
getting
through
that
whole
650
or
getting
through
a
large
amount
and
and
doing
the
release,
because
that
would
that
would
be
a
lot.
I.
A
Think,
where
would
be
the
best
place
to
do
that
cool
miles
for
december
miners?.
C
Maybe
we
could
post
something
on
the
like
core
team
so
like
we
know
that
everyone
gets
pinged
and
then
you
know
someone
can
get
grumpy
and
be
like
don't
message.
This
list
give
us
all
an
email
and
then
we
can
be
like.
That
was
the
point.
D
A
D
A
And
we
could
do
it
like
tbd
date
if
we
wanted
to
or
something
like
that,.
D
A
A
Yeah
is
anyone
particularly
interested
in
opening
that
draft
proposal
up
as
it's
a
draft,
I'm
sure
that's
not
committing
to
doing
the
release
in
full.
So
if
anyone
would
like
to
get
that
opened
as
a
kind
of
like
work
in
progress
interest,
particularly.
A
A
Okay,
so
we'll
go
with
that
for
now,
I
think
for
14
as
best
effort
to
try
and
get
the
minor
moving
forwards.
Where
are
we
in
terms
with
the
11th
of
march
today
right?
A
A
A
A
A
A
Okay,
12,
I
don't
think
the
state's
particularly
changed.
Oh,
maybe
aside
from
that
fs
promises
thing
that
was
mentioned.
D
Yeah,
it's
not
in
here
the
the
the
pr
that's
gone
into
master.
I
don't
think
it's
got.
I
don't
think
it's
gonna
end
current
yet,
but
the
question's
in
about
backporting
it
into
lts,
because
the
performance
gap
between
the
promises
version
of
the
fs
apis
and
the
non-promises
versions
is
quite
large,
so
miles
miles
has
got
the
code
into
15,
but
I
think
it
needs
manual
backwards.
14
and
12.
A
Yeah
yeah
same
so,
it
sounds
like
as
long
as
it's
labeled
like
lts
watch
or
back
or
requested,
or
and
a
back
port
pops
up
and
when
that's
there.
We
probably
have
the
discussion
about
when
to
ship
out,
because
I
think
we
do
have.
We
do
have
a
couple
of
things
on
the
12
branch
waiting
to
go
out
as
well.
So
yes.
A
D
Gradually
and
yeah
that,
back
to
the
earlier
discussion
about,
send
the
miners
going
out
in
12
that
haven't
gone
out
and
14.
Yet
like
there's
not
that
many.
D
A
Yeah
ready
to
go
yeah.
I
think
that
at
this
point
that
makes
sense,
let's
land
what
we
can.
Let's
not
hold
off
landing
miners
now,
because
it's
been
a
long
time
since
we've
done
feature
full
blinders
for
both.
So
let's
just
land
what
we
can
get
14
out
when
we
can-
and
it
probably
makes
sense
for
12
to
hold
off
until
at
least
the
promise
that
province's
back
ports
open
and
landed.
And
then
that
sounds
like
a
good
time
to
set
a
date
to
get
that
release
out.
A
Sure
thanks
richard
so
in
terms
of
10,
I
don't
think
there's
much
to
discuss.
Has
anyone
seen
anything
heard
anything
about
10,
if
not
for
a
while,
which
is.
A
E
A
D
A
D
D
I
mean
I
am
at
the
stage
with
10
now
that
unless
someone
really
pushes
for
things,
I'm
not
really
inclined
to
pull
anything
back
in,
and
the
only
thing
I
might
consider
is
if
it
was
something
fundamental
to
like
build
infrastructure
or
something
like
that.
But
again
there's
nothing
that
I'm
aware
of.
A
A
We
have
quite
a
exhaustive
policy
on
the
steps
we
must
follow
for
a
major
release
line.
For
example,
we
state
that
we
will
cut
the
branches
three
months
in
advance.
A
We
will
start
creating
the
proposal
two
months
in
advance
and
actually
from
what
I've
found
is
there's
not
much
benefit
from
doing
that
and
I
think
a
few
times
the
dates
have
slipped,
so
I'm
wondering
whether
it
makes
sense
to
open
the
pr
to
update
those
kind
of
like
exhaustive
requirements
and
maybe
loosen
them
a
bit
just
say
six
weeks
before
the
bill.
Six
weeks
before
the
release
we
start
test
builds
and
that
kind
of
assumes
that
we've
created
the
branches
and
proposals.
D
A
D
Not
not
the
only
things
that
I
disrupted,
but
in
terms
of
just
culture
and
yeah
updates,
tend
to
change
quite
a
lot
and
I
think
we're
still
waiting.
Aren't
we
for
the
next
v8
to
merge
next
week
or
something
for
16.,
so
we
can
open
them
early,
but
the
only
benefit
for
that
is,
if
we're
actively
running
and
monitoring
the
test
results
to
spot
things
that
might
need
to
be
addressed.
A
Yeah,
the
the
other
thing
is
before
this
december
major
cut
off.
It's
just
a
mirror
of
the
main
or
main
branch.
So
in
theory
we
we
should
catch
most.
Things
like
when
folks
are
on
sit
gym
on
the
main
branch
or
run
ci
on
the
main
branch
and
as
prs
go
in,
there
are
some
infrastructure
things.
It's
worth,
opening
them
like
the
16x
branch
to
check
things,
work
on
that
side.
D
Yeah,
actually,
that
is
a
good
point.
Yeah.
A
Yeah,
so
I
I
think
I
had
a
chat
with
ash
recently
and
on
the
releases
md
file.
We
kind
of
like
came
to
the
decision
that
we
should
probably
have
a
checklist
in
there
and
to
say
when
we're
creating
a
major
release.
Please
open
a
build
issue
with
these
tick
boxes,
because
I
don't
think
we
have
that
checklist.
Yet
they'd
like
build
in
for
a
major
release.
Checkbox
of
what
needs
to
happen
like
adding
the
drop
downs
and.
A
A
D
A
I
think
rod
might
have
opened
a
pr
to
mention
the
snap
stuff
needing
to
be
called
out.
So
maybe
maybe.
A
A
I
don't
think,
there's
ever
been
an
instance
of
us
saying
we're
not,
including
that
major
like
everything's
always
been
like.
Yes,
we're
happy
to
pull
that
in
there's,
never
been
any
objections
and
the
one
time
there
was
an
objection.
I
think
it
was
for
a
certain
deprecation.
We
actually
reverted
it
like.
We
opened
a
reaver
pr
for
that
one.
So
I
do
wonder
whether
do
we
still
need
december
major
cutoff
or
does
it
need
to
be
a
month?
A
Could
it
be
like
two
weeks
in
the
past,
I've
tried
to
freeze
the
the
code
on
like
the
exact
seven
days
before
so
in
this
case,
it'd
be
like
the
13th
and
just
so
that
the
change
node
can
be
finalized
and
like
no
one's
gonna,
be
up
at
night
the
day
before
the
release,
picking
things
in
so
I
don't
know
if
there
are
any
thoughts
on
that
about
the
value
of
december
major
cut
off
and
whether
people
have
seen
that
value.
I.
D
I
can't
remember
if
it
was
the
last
major
or
the
one
before
there
was
one
where
we
we
diverged,
va
to
have
forward
compatibility
patches,
so
they
landed
in
the
major
branch,
but
the
master
branch
just
had
the
v8
update,
as
was
so.
There
were
differences.
D
But
yeah,
I
can't
remember,
I
think
that
might
have
been
two
releases
ago.
It
was
one
where
we
had
some
plan
as
to
which
v8
versions
would
go
into
that
major
and
to
enable
that
we
had
compatibility
patches
to
take
that
v8
version.
That
was
there
at
the
moment
to
a
later
api.
A
A
A
My
my
thoughts
are
like
if
we're
not,
if
we
think
it's
going
to
be
too
disruptive
to
the
ecosystem
at
this
point
of
time,
what
what
is
the
benefit
of
landing
like
something
on
the
main
branch
before
the
ecosystem's
ready
to
kind
of
accept
it
like?
I
know
it's
not
going
to
get
extra
testing
aside
from
maybe
from
collaborators
and
people
building
head
themselves.
D
E
What
if
we
changed
the
policy
a
bit
and
removed
kind
of
this,
this
cutoff,
but
keep
opening
the
the
proposal,
like
you
did
at
least
one
month
in
advance
or
more
so
that
it's
clear
for
everyone.
What
are
going
to
be
the
several
major
changes
and
if
more
come
up
before
the
release
goes
out,
then
I
don't
know
we
put
something
in
the
in
the
policy
that
says
we
should
ping.
A
A
D
So
the
only
question
would
be
anything
landing
that
you
possibly
didn't
want
to
have
to
land,
but
then,
in
that
case,
we'd
probably
stick
a
blocked
or
waiting
label
or
something
so.
A
Yeah,
so
there
was
some
concern
about
like
we
don't
want
to
hold
up
development
on
like
the
head
branch
because
of
the
upcoming
major
release.
A
But
I
I
don't
think
we're
gonna
see
it
to
be
honest,
based
on
what
I've
seen
and
there's
never
been
any
objections
raised
and
if
they
have
been,
it's
been
completely
reverted
as
long
as
we
do
have
a
code
freeze
of
some
kind
a
week
or
end
days
in
advance,
so
that
there's
not
a
lot
of
last
minute.
Churn.
D
D
So
it
wasn't
like
the
it
wasn't
like
splitting
the
branches
and
having
the
thing
sort
of
prevented.
That.
E
But
for
for
v16,
when
are
you
going
to
stop
rebasing
on
master
and
diverging
the
branch.
A
I
guess
setting
the
code
freeze,
another
arbitrary
gate
that
might
have
the
same
incentive
just
a
couple
of
weeks
later
or
something
so.
A
Okay,
I
can
open
a
draft
pr
to
kind
of
suggest
that
to
see
what
the
kind
of
thoughts
are
from
the
wider
folks,
including
the
tfc,
I
think
it
would
just
save
us
having
to
like
reach
out,
say:
hey
you're,
happy
for
this
to
be
included
and
people
not
seeing
it
or.
A
Okay,
but
yeah
test
build.
I
have
kicked
off
the
test
build,
I
haven't
linked
to
it
yet,
but
I
think,
as
of
next
week,
probably
do
rc0
and
then
each
week
I
tend
to
just
mirror
from
the
main
branch
until
a
major
appears,
and
then
I
would
start
cherry
picking.
A
But
if
we
can
get
some
thoughts
and
feedback
on
scrapping
the
major
cut
off,
then
it
would
just
be
a
mirror
literally
each
week
this
branch
would
just
be
a
mirror
of
whatever
head
was
on
tuesday
and
we'd
turn
that
into
a
release
candidate,
build.
A
Sure
other
items
on
the
agenda,
I
realized
we
didn't
type
them
out
as
we
added
them.
What
was
next
was
it
npm,
7
and
node
14.
A
You
need
to
do
a
github
feature.
D
C
B
E
It's
risky
having
worked
with
npm
seven
for
a
few
months
now
I
I
know
that
there
are
many
cases
where
it
just
throws.
When
you
try
to
install
ins,
it
just
fails
because
there
are
issues
with
peer
dependencies
when
it
was
just
warning
in.
E
B
Okay,
sorry
yeah,
I
was
trying
to
say
I
synced
up
with
the
rest
of
the
team
yesterday
and
I
think
we
have
a
consensus
that
yeah
it's
too
risky
to
try
to
backboard
it
so
yeah.
I
think
we'd
rather
not
backport
it
to
the
node
14
or
previous
lts
releases.
For
now.
B
Yeah
it's
looking
like.
It
may
not
be
possible,
like
it's
just
too
risky
right.
There
are
some
breaking
changes
on
top
of
the
the
larger
peer
dependencies,
yeah,
so
yeah,
all
in
all,
I
think
it's
it
might
be
too
risky.
So
we
might
just
have
to
live
with
having
to
support
in
chem
6
for
a
little
longer
but
yeah.
The
pm6
is
basically
just
maintenance
mode
now,
so
we
will
only
really
land
security
patches
or.
A
A
I'm
certainly
that
was
where
my
kind
of
mindset
was
like.
I
did
think
it
was
slightly
too
risky
at
this
point
in
time.
Maybe
before
14
goes
into
maintenance,
we
could
have
another
discussion,
but
I
guess
my
gut
would
be
if
it
doesn't
happen
before
we
go
into
maintenance,
then
possibly
we'll
just
stick
with
six
yeah.
Okay.
Now,
that's
that's
good
comfortable
with
that
kind
of
so
is
anyone
can
respond
on
this
discussion?
Maybe
we
should
leave
it
to
npm
folks,
maybe
royal
miles.
B
A
A
A
Sounds
good
and
I
think
we
did
mention
one
other
thing
to
be
tagged
onto
the
agenda
but
again
didn't
write
it
down.
Can
anyone
remember.
D
E
B
Yeah,
I
think
there
is
already
a
band-aid,
a
patch
sent
by
colin
she
scrolled
down
yeah,
and
so
I
think
the
other
yeah
we
might
just
want
to
do
that
for.
A
A
E
D
No,
I
think
it's
just
making
the
thing
a
new
innumerable,
so
you
can
write
okay,.
A
D
A
A
D
I
mean
I'm
happy
give
given
what
that
says
there
I'm
happy
with
to
to
land
that
pl
that's
open
and
put
then
15.
yeah.
D
D
A
Okay
sounds
good.
Was
there
anything
further
to
go
through
today?
A
I
guess
I
saw
that
we
we
now
have
a
like
16x
tracker
for
failures
in
sitchin,
so
I
guess
I'll
try
and
keep
that
updated.
As
I
run
sit
gym
on
the
proposal.
A
Okay,
nothing
further
to
discuss
on
the
agenda.
I
guess
we'll
close
that
out
here
and
I
guess
speak
to
you
all
next
time.