►
From YouTube: Node.js Release Working Group Meeting - 26 March 2020
Description
A
So
we
are
live
with
the
nodejs
release,
working
group
meeting
on
the
26th
of
march
2020
and
we'll
be
following
the
agenda,
which
is
in
issue
554
in
nature's
release.
Repo
and
I
will
start
sharing
my
screen
I,
don't
know
how
many
not
okay,
I
will
skip
so
my
screen,
because
I
have
some
permissions
problems
and
but
going
back
to
the
agenda.
The
first
item
on
e-type
for
the
agenda
is
the
release
cadence,
due
to
the
curve
at
19:00
panda
ik
there's
been
some
suggestions
that
we
maybe
take
a
different
approach
more.
A
B
B
So
there's
a
handful
of
kind
of
different
things
for
us
to
discuss
and
consider
here.
I
want
to
point
at
the
chrome
project,
as
well
as
the
electron
projects
as
examples
here
so
I
think
that
there's
a
question
regarding
kind
of
like
stability
and
release
cadence,
while
we're
in
the
midst
of
feeling
out
hearing
out
what
life
looks
like
for
the
next
couple
months
or
a
year.
B
Yeah
I,
don't
know
about
yourselves,
but
you
know,
like
my
life,
is
a
little
bit
differently:
I'm
now
working
from
home,
a
hundred
percent
remote
and
and
have
a
bunch
of
extra
work
streams
around
kovat
response
on
my
plate
that
I
didn't
have
before
so
in
some
ways,
I
actually
have
more
time
to
spend
on
releases,
but
in
other
ways
at
times,
I
have
less
that
it.
That
is
one
place
where
this
is
important,
but
it's
also
important
for
our
downstream
consumers.
B
I
think
it's
more
important
than
ever
for
us
to
have
a
stable
platform,
not
that
that
is
not
something
we
don't
take
seriously
all
the
time,
but
I
can
point
at
I
think
it
was
12
.
13
and
some
of
the
recent
13
releases
as
examples
of
like
releases
that
that
broke
things
unexpectedly
like
we
did
not
see
them
coming
and
I.
B
But
I
thought
it
would
be
prudent
for
us
to
at
least
discuss
this
to
kind
of
think
through
what
would
be
the
best
balance
between
you
know,
keeping
people
downstream
stable,
but
also
keeping
our
upstream
work
not
getting
too
much
of
a
backlog
for,
like
you
know,
if
we
stop
doing
releases
on
12,
for
example,
for
an
extended
period
of
time,
the
backlog
of
commits
could
get
so
large
that
we
kind
of
can't
keep
updating
12.
This
is
something
that
we
kind
of
see
happening
on
our
other.
Various
releases.
B
12
only
has
active
support
until
October,
so
one
thing
that
we
may
want
to
do,
for
example,
is
sit
back
and
rethink
the
release
cadence
and
when
we
plan
a
December
minor,
but
in
general
I
think
it
would
be
reasonable
for
us
to
kind
of
re-evaluate
the
cadence
of
our
release
branches.
With
that
being
said,
I
I
think
it
is
still
reasonable
for
to
move
forward
with
14
and
to
keep
the
cadence
that
we
have
on
current.
B
That
would
at
least
allow
us
to
avoid
stopping
velocity
on
on
the
project
itself,
which
I
think
would
be
unfortunate,
especially
since
many
people
with
extra
free
time.
This
may
be
a
great
way
for
them
to
blow
off
some
steam.
So
I,
don't
really
want
to
have
any
sort
of
project
wide
feature,
freeze
or
anything
like
that,
but
anyways
I
don't
know.
If
anyone
else
has
any
feelings
or
support
there
or
thoughts,
then
just
as
a
thing
it
looks
like
Darcy
joined,
it
needs
to
be
promoted.
A
And
based
on
the
options,
you
kind
of
listed
up
some
suggestions
and
the
issue
and
the
one
I
think
a
few
people
have
kind
of
+1
Don
and
the
issue
itself
was
for
the
LGS
releases,
kind
of
adopting
a
maintenance,
only
kind
of
approach,
but
also,
if
those
features
that
people
really
want
one
in
there's
a
pull
on
specific
features.
We
would
allow
those
to
go
in
as
well.
My
guess
out.
Yes,
it's
already
at
the
1:7
for
minor
every
three
months.
So
that's
probably
not
too
disruptive
I.
B
Guess
the
problem
that
I
have
with
that
and
I'll
use
the
large
pages
on
twelve.
As
an
example,
there
was,
like
large
pages
on
twelve,
was
a
feature
that
was
requested
that
had,
like
you
know,
support
from
a
TSE
member.
It
wasn't
just
like
no
one
liked,
it
wasn't
someone
who
doesn't
understand
node
and
we
had
somewhat
major
regressions
due
to
that
and
ended
up
having
to
revert
it
pretty
quickly.
B
B
Maybe
we
even
just
pushed
that
off
by
a
month
and
maybe
move
to
like
like
once
every
four
months,
instead
of
once
every
three
months,
or
maybe
even
just
kind
of
play
it
by
ear
or
seeing
how
things
are
at
the
very
least,
I
think
with
the
kind
of
way
things
are
right
now
it
may
be
prudent
to
push
off
the
semver
minor
by
another
month
and
10
has
December
minor,
Beth
and
correct
me
if
I'm
wrong.
There's
a
summer
minor,
that's
prep!
That's
about
ready
to
go
correct,
yeah.
B
A
Guess
one
other
thing
we
could
consider
is
at
the
moment
we
say
a
change
needs
to
be
on
current
for
two
weeks
before
it
can
go
into
LTS.
If
we
doubled
that
to
like
four
weeks,
we've
got
more
baking
time
and
subsequently
like
more
time
to
catch
problems,
and
that
should
slow
down
the
LTS
releases
as
one.
B
B
A
A
C
B
Is
anyone
able
to
take
on
the
action
item
of
that
I
would
but
I
am
in
equity,
executive
committee
committee
meetings
today
and
tomorrow
and
I'm
chairing
tc39
all
of
next
week
remotely
so
I
won't
have
been
with
for
at
least
a
week
and
a
half.
So
if
anyone
can
volunteer
to
draft
the
comms,
I
can
definitely
review
it,
but
I
don't
have
the
bandwidth
to
to
lead
it
right
now.
A
B
B
A
A
D
D
B
Would
say:
yes,
the
answer
that
I
don't
think
that
these
permissions
need
to
necessarily
be
mutually
exclusive,
so
I
agree
with
like
the
nude,
with
changelog
maker
and
branched,
if
definitely
being
like
under
the
purview
of
this
team.
I.
Guess
like
the
thing
that
I'm
saying
to
take
it
a
step
further
is
like
if
we
can
get
like
Joey
in
the
general
maintainer,
zuv
node
core
util,
for
example,
to
agree
that
this
team
should
have
like
right
permissions
to
that
repo
I.
B
Don't
think
that
that
means
that
this
team
is
the
only
owners
of
it
or
the
only
people
that
have
permissions
just
that
they
have
permissions
and
will
still
be
responsible
to
adhere
to.
You
know
the
governance
of
that
repo,
so
so
I
guess
I
just
may
be
frame
it
slightly
differently.
Event
we'd
be
talking
about
giving
this
group
permissions
for
that,
but
not
necessarily
ownership.
A
E
B
I
also
particularly
like
with
these
changes,
and
maybe
there's
other
changes
that
we
can
make
to
do
this,
but
I
think
as
we
brought
in
scope
here,
we
increase
the
people
who
may
be
interested
in
working
on
it.
So
like
I,
really
like
the
idea
of
broadening
it
and
potentially
broadening
the
group
of
people
that
will
participate.
A
A
A
We
also
had
an
action
last
time
say
we
should
create
essentially
create
a
policy
and
what
to
do
when
something
goes
wrong
with
the
release.
So,
like
our
action
plan
of
how
to
handle
a
broken
release
and
that
could
include
communications,
etc.
I,
don't
think
we
have
an
issue
on
the
backlog
for
that,
so
we
should
probably
create
an
issue,
and
if
there
were
any
volunteers
to
write
out
kind
of
plan
for
when
something
goes
wrong.
A
The
last
item
that
was
added
that
Richard
mentioned
was
the
publish
a
debug
version
when
making
a
new
release.
So
there
was
kind
of
a
request
on
certain
bill
builds.
We
would
publish
the
debug
version.
Rod
I
think
has
chimed
in
in
the
issue,
I
think.
In
one
case
it
was
over
a
gig
per
built,
so
I'm
not
sure
if
that
kind
of
just
blocks
us
from
considering
this,
because
it
will
just
take
up
too
much
space
and
but
I
guess
that's
a
build
working,
great
position
to
make
models.
B
Beth
like
specifically-
and
this
was
something
that
was
raised-
there
would
be
that
this
would
significantly
increase
potentially
the
size
of
distribution,
the
other
thing
that
it
would-
and
I
don't
know
if
it
was
discussed
there,
but
it
could
also
create
additional
complexity
in
the
build
itself.
So
you
know
when
the
disks
get
full
that
blocks
our
ability
to
promote
builds.
B
If
this
slows
down
the
or
makes
the
process
of
building
the
assets
substantially
slower,
then
that
is
yet
again
like
another
thing
that
that
can
hurt
our
velocity,
so
I
do
think
that
it's
reasonable
for
us
to
like
assess
what
additional
commitments
this
would
make.
Also
the
debug
builds.
Will
we
now
be
responsible
for
checking
that
the
debug
builds
actually
work,
and
now
all
of
our
releasers
need
to
do
that?
B
Think
it
was
like
build
extras
or
node
release
extras
I
forget
like
the
the
name
of
the
project
that
they
did,
but
it
was
like
extra
builds
for
platforms
and
resources
that
aren't
kind
of
official
and
I
personally
actually
really
liked
the
idea
of
it
living
there
rather
than
as
part
of
the
official
builds,
especially
since
this
is
something
that
is
complementary
and
kind
of
only
likely
useful
to
a
subset
of
people
who
are
specifically
looking
at
doing
debug.
So
I
would
love
to
see
this
be
part
of
unofficial,
build
rather
than
official.
Personally.
B
D
Yep
I'm
in
favor
of
that
just
one
thing
about
the
unofficial
builds
project.
It's
basically
a
thing
that
exists
and
is
requesting
contributors
to
contribute
to
it.
So
it's
not
like
it.
It
isn't
actually
actively
run,
which
is
why
it's
unofficial.
But
the
whole
point
is
that
people
can
submit
their
own
conflict
into
that
project
and
they
will
be
built
after
a
releases
made
or
attempted
to
be
built
after
a
release
is
made
but
yeah
the
advantage
for
us
is,
it
doesn't
block
any,
but
it
doesn't
block
any
of
our
release
process.
D
B
I
think
with
that
as
well,
it
means
that
like
if
it
lives
there
and
it's
if
it's
successful
and
useful
and
people
ask
for
it,
then
we
can
consider
promoting
it
into
like
an
official
build,
but
I
think
it
makes
sense
to
kind
of
start
there,
because
at
least
the
assets
would
be
available.
I,
don't
know
Richard
if
you're
actively
involved
in
the
unofficial,
build
team,
but
one
thing
that
I
can't
offer
and
look
into
is
like
resource
for,
like
free
credits
from
Google
cloud
for
storage.
B
D
You
probably
have
to
talk
to
rod
about
storage,
I,
don't
know
if
the
storage
is
shared
with
the
actual
official
builds
like
I
said
there
isn't
an
actual
team
for
unofficial
bills.
It's
something
that
rod
set
up
as
an
experiment,
so
things
have
been
contributed
to
it.
But
this
this
sounds
like
the
ideal
kind
of
thing
that
someone
could
write,
something
for
that's
what
they
wanted.
D
It
was
mainly
set
up
because
we
in
build,
we
demoted
some
platforms
to
experimental,
so
I
think
32-bit
Linux
is
experimental,
so
that
now
lives
in
unofficial
builds
in
that
if
the
build
will
happen,
but
it's
not
part
of
the
official
releases
and
it's
just
kind
of
sitting
there
ticking
over
but,
like
I,
said,
there's
no
actual
active
team.
Looking
after
it.
A
A
A
B
F
We
just
I
just
realized
yesterday,
I
think
it
is
still
shipped
in
the
in
the
tar
poll
from
the
NPM
resolution.
So
I
put
a
I
already
raised
the
team
that
we
need
to
definitely
fix
it,
but
not
on
note.
We
like
that
the
PR
doesn't
have
them,
so
it
should
be
alright
for
for
the
for
the
PR
to
be
marred,
but
I
think
they
still
slip
into
the
tar
bowl.
We
are
distributing
in
the
registry.
Okay,.
B
Cool
Targo
see
I
think
you
may
have
been
the
one
who
noticed
the
artifacts
in
the
last
NPM
release.
At
the
very
least,
you
are
aware
of
that.
Do
you
I
just
dropped
the
pr
into
the
chat?
Do
you
have
like
two
or
three
minutes
to
just
review
it
and
make
sure
the
files
aren't
there
and
then
maybe
+1
on
the
fast
track
for
it?
Yeah.
B
A
So
for
the
10
release
that
currently
has
the
previous
version
of
NPM
in
it,
and
it's
built
and
prepared
I'm,
not
sure
when
to
promote
it,
because
at
the
moment,
so
we're
kind
of
skipping
the
rule
of
how
long
something
needs
to
be
in
current
in
a
current
release.
First,
because
the
NPM
fix
for
the
vulnerability
warning,
we
deem
that
kind
of
important
enough
to
kind
of
skip
that
rule,
but
there's
also
an
open
SSO
update
in
there.
A
B
I
do
believe,
but
I
could
be
wrong.
One
thing
that
got
raised
was
like
there
was
an
internal
change
to
the
way
in
which,
like
an
internal
API
is
used,
that's
breaking
some
people
that
are
consumers.
My
understanding
from
talking
to
Sam
is
that
like
we
should
be
unaffected
by
that,
but
it
might
be
prudent
for
us
to
get
this
out
and
wait
a
little
bit
before
pushing
it
to
LTS.
B
So
it's
so
to
be
explicit.
I
think
what
I'm,
proposing
and
I'd
have
to
get
the
calendar
in
front
of
me,
but
would
be
pushing
the
release
date
of
I
think
both
the
ten
and
the
twelve
releases
to
the
7th
of
April
and
then
pushing
out
them
in
state
of
of
10
by
a
month
and
scheduling
one
more
patch
release
between
now
and
then
and
then
likely
pushing
out
the
release
date
of
the
following
summer,
minor
four
twelve
by
at
least
a
month
as
well.
E
B
A
B
Agree
and
that's
why
I
think
we
should
consider
pushing
the
maintenance
date,
so
we
can
have
an
additional
release
in
between
and
I
think
by
our
maintenance
contract.
We
have
enough
time
right
now
to
do
that
and
I
think,
as
we
were
talking
before
about
copy.
If
we
can
get
something
together
right
now,
I
think
we
can
include
all
this
information
in
there,
but
that
I
defer
to
you.
If
you
think
that
maybe
we
should
not
do
that,
you
know
I'm
flexible
on
this.
A
B
A
F
F
B
B
E
B
B
B
B
B
A
B
B
B
B
B
D
B
D
B
I
I
guess,
like
the
big
difference,
would
be
that,
like
in
theory,
although
this
is
not
always
the
case
that,
with
maintenance,
we're
really
only
supposed
to
be
landing
patches
for
kind
of
experience,
breaking
bugs
not
like
smaller
regressions.
So
it
gives
us
the
ability
to
have
like
a
slightly
broader
responsively.
This
would
be
like
in
theory
and
maintenance.
We
shouldn't
be
like
updating
NPM
if
we
don't
need
to,
or
we
shouldn't
be
updating,
like
assembler
patch
version
of
libuv,
but
that
gives
us
the
flexibility
of
doing
that.
If
we
need
to
yeah.
F
I
just
wanted
to
add
that
I
think
there's
also
a
human
component
like
more
important
in
this,
the
technical
aspect,
but
like
right
now,
it
really
is
like
something
very
extraordinary
right.
So
if
you
can
just
like,
because
some
corporations,
some
companies
might
you
know,
might
have
strict
policies
and
like
might
require
their
employees
to
be
on
top
of
these,
and
you
can
give
them
more
time,
I
think
it
definitely
provides
a
human
service.
B
B
D
Yeah
I'm.
Okay,
with
that
now
it's
the
only
thing
about
the
data.
It's
not
it's
not
like
when
we
transition
to
OTS,
where
we
do
a
release
on
on
that
date
to
say
this
is
now
change
status.
It's
basically
a
sort
of
line
in
the
sand
that
says
releases
happen
before
this
date
can
have
these
things
and
releases
happening
after
this
date,
com.
D
B
And
for
what
it's
worth,
like
part
of
the
reason
why
I
at
least
myself
and
being
somewhat
conservative
here,
is
because
and
I'm
totally
forgetting
the
exact
scenario
if
it
was
the
date
that
we
made
the
LTS
or
if
it
was
the
date
that
we
moved
it
to
maintenance.
But
in
the
past
we
had
done
so
without
one
of
these
changes.
B
Without
a
lot
of
warning
to
the
community
and
like
we
actually
had
a
handful
of
folks
come
in
and
let
us
know
like
hey,
you
know
like
we
were
planning
to
drop
support
for
X
release
of
node
when
it
went
into
this
particular
mode,
and
we
really
did
not
appreciate
you
kind
of
changing
those
dates
on
us.
So
I
just
think
being
really
clear
here
and
like
especially
since
April
first
is
kind
of
coming
up.
B
Next
Wednesday
I
think
we
and
we
also
have
those
rules
around
like
how
much
notice
we
want
to
give
people
before
changing
stuff.
I
think
it
would
be
kind
of
you
know,
kind
and
fair
of
us
to
put
this
out
prior
to
April
first
and
just
have
like
a
full
plan
across
all
the
release
lines,
including
if
we're
not
going
to
change
the
maintenance
date,
but
I
just
think,
based
on
prior
feedback
that
we'd
have
would
be.
It
would
be
good
to
kind
of
get
that
out.