►
From YouTube: Node.js Release Working Group 2019-01-17
Description
A
B
A
Yeah
I
guess
there's
like
a
couple
different
things
on
this.
Let
me
just
get
it
in
front
of
me,
so
we
do
have
it
in
maintenance
mode
right
now,
but
there
was
our
request
and
Dawson
can
chime
in
about
this
for
TS
FN
support
for
napi
leave.
It
open
pull
request
number
2500
for
that
T
Neeson
had
also
been
making
some
requests
for
crypto
related
features,
and
we
also
have
the
open
pull
request
for
namespaces,
which
may
or
may
not
resolve
that
one
may
not
land
there's
a
bit
of
a
backlog
as
well.
A
C
Basically,
TFS
n
is
thread
safe
functionality
in
an
API,
and
it's
and
one
of
the
things
that
it
does
is
it
lets
modules.
It
reduces
the
number
of
modules
that
would
need
to
use
libuv
directly
and
if
you
use
would
levy
directly,
you
don't
get
the
benefits
of
n
API.
So
it's
important,
you
know
it's
it's
basically,
you
know
an
area
we
found
that
we
had
a
gap
in
terms
of
adoption
and
Gabriel
did
a
lot
of
good
work.
C
To
put
that
together,
it's
been
validated
in
that
you
know,
FS
events
module
the
main
painter
used
it
and
basically
said
yeah.
Okay,
this
actually
solves
the
problem.
I
don't
need
to
use,
it'll,
be
viewing
it
anymore,
and
it
said
you
know
it's
important
to
them
for
this
to
actually
be
available
o'clock
across
the
LTS
version,
so
that
they
can,
you
know,
release
a
new
version
that
depends
on
that.
They
have
a
lot
of
users.
Even
some
of
their
users
are
chiming.
C
In
saying
this
would
really
you
know,
remove
a
lot
of
pain,
so
I
think
we
have.
You
know
a
combination
of
factors
that
say
you
know
one
is
good
for
any
P
I'd
option
which
we
want
to
you
know
promote
to.
We
have
actual
users
telling
us
that
it's
important
that
it
gets
in
and
three
you
know,
I
I
think
it's
you
know
on
the
risk
side,
there's
very
little
risk
to
any
anybody,
not
using
an
API.
And
it's
you
know
it's
it's
additive
versus
you
know
invasive
changes
or
anything
like
that.
C
A
A
couple
questions
on
this
really
quickly:
there's
a
bit
of
a
pattern,
just
not
a
bad
thing,
just
like
something
that
I'm
noticing,
where,
like
the
value
of
n
API,
really
relies
on
things
like
this
being
consistent
against.
You
know,
versions
that
are
out
in
the
wild
yeah,
and
so
it
seems
to
me,
like
some
of
the
policies
and
process
that
we
have
are
around
LTS
releases,
don't
necessarily
align
a
hundred
percent
with
the
needs
for
n
api-related
releases
and
so
I'm
curious.
C
That
makes
sense
to
me
in
terms
of
you
know:
I'm
hopeful,
I'm,
hoping
we
don't
have
a
you
know
a
stream
of
cember
miners,
but
I
do
it
is
important
that
things
that
you
know
say
bugs
and
stuff
that
we
find
are
back
ported
across
the
releases.
So
you
know
just
in
that
context,
I
think
that
would
make
sense.
Mm-Hmm.
A
Like
even
if
it
was
just
something
like
quarterly
during
maintenance,
but
it's
like
I
feel
like
I'm
mr.
grumpy,
showing
up
and
like
there's
something
like
this
having
to
say
hey,
you
know
this
is
not
an
interline
with
our
process
and
it's
mostly
because
if
we
keep
having
one
off
then
it
becomes
merely
to
say
no
to
other
things,
but
I
think
that
might
be
something
we're
diving
into
as
a
policy
change.
What.
A
Vulnerabilities
we've
been
putting
on
to
staging
things
that
are
like
doc,
fixes
or
test
fixes
or
like
minor
regressions
with
known
fixes,
but
generally
we
have
not
been
doing
releases
of
this,
so
I
think
like
even
right
now,
for
example,
if
you
were
to
go
and
check
out
six
decks
staging
it's
not
a
ton
of
commits,
but
there's
like
a
JIP
fix-it
build
fix
a
tool
fix
something
fixing
bootstrapping
on
VSD,
some
documentation
fixes
some
more
build
tests
and
a
test
fix.
These
are
really
really
minor.
A
A
The
idea
of
like
why
we
continue
to
land
those
things
but
yeah
I
think
I
think
there.
There
was
a
concern
partially
around
like
availability,
but
also
just
around
like
the
contract
itself,
and
you
know
like
once
something's
moving
into
maintenance.
I,
don't
think
people
are
expecting
it
to
really
move
around
a
lot.
C
No,
but
it's
sort
of
like
yeah,
so
yeah
so
like
in
that
context.
I
could
certainly
see
that,
like
the
the
quarterly
opportunity
or
something
for
for
napi
would
make
sense,
because
it
is
important
that
the
consistency
is
there
which
may
push
things
that
you
know
you
might
not
do.
Otherwise,
if
it's
a
consistency
thing
like
I
I,
still
want
to
minimize
as
much
as
possible.
What
has
to
go
back
right
like
just
because
we
make
we
change,
certainly
just
because
something
changes
in
an
epi,
it
doesn't
mean
it
has
to
go
back.
C
C
C
C
Maybe
maybe
I
should
write
it
up
as
we
have
this,
this
I
guess
like
it's,
it's
the
it's.
It's
kind
of
like
the
same
thing
as
the
the
security
releases
side
of
things
where
we're
talking
about
like
try
to
have
planned
releases
or
what
some
things
may
may
come
up
where
it's
like.
Oh,
this
is
just
so
important
to
backport.
We
should
do
it
sooner
than
later.
Other.
D
C
C
So
I
could
write
it
up
as
like,
not
an
epi
specific,
but
that
you
know
we're
planning
in
a
potential
slot
for
a
release
and
things
that
we
believe
are
important
in
it
and
basically
agreed
as
important
by
the
release
team
would
go
into
that
particular
candidate.
Not
necessarily
everything
like
I
still
think.
If
people
aren't
pushing
for
things,
we
don't
necessarily
have
to
include
them
right.
Yeah.
A
B
A
A
And
I
realize
and
I'm
happy
about
that.
I
didn't
that
wasn't
meant
as
a
grumpy,
but
like
yeah,
I
I
have
extreme
reservations
about
doing
regular
security
releases,
especially
when
we're
talking
about
LTS
when
we
have
any
sort
of
cadence,
because
we
don't
have
that
much
acquaintance
of
releases
to
begin
with.
So
ad-hoc
security
releases
make
far
more
sense
to
me.
The
flip
side
of
that
maintenance
releases
do
not
make
sense
to
me
to
be
ad
hoc
and
in
fact,
having
ad
hoc
releases
for
maintenance
makes
me
uncomfortable.
A
I
would
much
rather
have
an
explicit
contract,
and
even
if
it's
only
two
commits
or
three
commits
like
we
just
pushed
the
release,
I
would
rather
us
have
a
explicit
contract
of
how
like
four
LTS
of
how
often
people
should
expect
releases
exactly
when
they
should
respect
to
expect
releases.
Who
should
be
adhering
to
that
contract
as
much
as
possible.
A
C
Only
the
only
thing
is
some
of
those
don't
need
to
go
out.
So,
for
example,
if
we
get
three
low
priority
vulnerabilities
and
we
immediately
patch
each
of
those
three
you'll
have
to
do
three
releases
versus.
If
you
said
well,
we've
got
one
plan
for
three
months
from
now.
These
don't
warrant
an
immediate
patch,
so
let's
Bund
them
all
into
that
one.
So,
just
in
terms
of
the
total
work,
it
might
end
up
with
less
work.
I'm.
A
C
Yeah,
that's
I
mean
that's
a
different
way
to
go.
So
if
that's,
if
that
works
out-
or
we
think
that's
okay,
then
you
know
maybe
that's
an
alternate,
but
it
that
the
conversation
was
certainly
around
like
immediate,
immediate
subvert
security,
one
like
high
severity
ones,
I
think
everybody
would
still
agree.
Those
need
to
go
out
immediately,
ad
hoc
yeah.
It
was
just
that
if,
if,
if
we
for
the
ones
who
aren't
in
that
category,
can
we
do
something
more
planned
like
let's
give
ourselves
the
like?
C
You
said
it's
better
to
have
it
sort
of
structured
and
say
if
it's
not
if
it
doesn't
have
to
be
ad
hoc,
let's
have
a
plan
for
how
we
say
we
manage
that
and
make
the
high
severity
ones
an
exception
or
evolved
exceptional
case,
hopefully,
and
then
the
other
ones.
It's
like
yeah,
okay,
at
the
end
of
the
three
months
you
take
all
of
them.
C
You
put
them
out
and
that's
safety
time
if
they're,
if
they
can
be
handled
some
other
way,
I'm
I,
guess
I'm,
not
I,
don't
understand
well
enough
how
that
would
work
or
whatever,
but
if,
if
we
can
come
up
with
something
else,
that
also
means
that
those
ones
don't
need
their
own
releases.
That's
a
good
thing
too.
C
C
Right
I
just
thought
from
from
the
napi,
so
I
would
be
good
to
get
the
feedback
from
Gabriel,
because
there's
there's
the
one
that
he
has
there,
but
there's
another
one
to
take
it
out
of
experimental
and
and
based
on
not
wanting
to
do
too
many
releases.
It
sounds
like
we
should
get
that
one
in
there
as
well.
If
we
can
I
know
I
know,
there's
some
complications
on
that
front,
but
we
should
get
Gabriel
talking
to
commenting
on
that
side.
B
A
Might
make
sense,
I
think
that
the
like
I
talked
about
maybe
doing
this
release
around
the
end
of
the
quarter
like
before.
Six
goes
end-of-life,
wasn't
more
time
sensitive
for
like
because
I
was
just
imagining
like
if
we're.
If
we're
trying
to
get
this
out
there,
it
shouldn't
be
so
time-sensitive
if
people
are
also
having
to
support
six
right
now,
III.
C
B
B
B
So
I
can
so
10:15.
One
is
due
to
go
out
on
the
29th
I
think
that's
a
week
later
than
we
originally
planned
just
so
that
we
can
get
a
few
more
commits
in
there
and
then,
from
there
onwards,
February
12th
will
be
1015
to
being
released
on
the
26th
of
verb
and
then
the
semver
minor
will
be
1016
now
and
that
will
be
on
March
12th.
So
we've
got
that
all
in
the
issue.
B
A
A
One
of
the
things
on
this
timing-wise
and
this
overlaps
with
the
next
11x
release
Shelly,
has
not
yet
promoted
a
current
release,
so
may
not
be
able
to
promote
the
the
release
that
they
have
right
now.
So,
if
I
look
at
the
current
release
schedule,
there's
one
plan
for
the
22nd,
which
is
next
week,
which
is
tar,
goes
there
was
one
planned
for
last
week
Reuben
how
many.
E
A
D
A
D
And
not
really
I
mean
doesn't
really
make
a
lot
of
sense.
So
Jordan
asked
about
making
patch
release
and
I
actually
checked
how
difficult
it
is
to
do
a
patch
release
instead
and
I
have
a
branch
which
is
11.6
on
one
instead
of
11.7
point
zero
as
I
did
and
initially
so
we
could
do
that.
Instead,
we
could
release
the
minor
penalties
right
now.
The.
B
A
So
for
context
for
people
who
don't
know
when
we
landed
NPM
I
guess
it's
6.5,
it
still
had
a
RC
tag
inside
of
it,
so
it
wasn't
updated
to
the
full
stable
released
before
we
landed.
It.
That's
on
me,
sorry
about
that,
but
it
went
out
in
the
release,
and
so
the
release
does
not
have
a
standard
version
of
NPM,
so
the
requester
in
Jordan
cos
he
means,
and
the
M
was
whether
or
not
we
could
do
a
patch
released
to
fix
that.
A
So
the
11.6
line
is
you
know
how
the
tip
of
that
line
is
not
problematic.
I
had
mixed
feelings
on
it,
because
we
don't
really
have
a
support
contract
like
that
for
current
and
I.
Don't
necessarily
want
to
start
a
habit
of
pushing
off
semver
minor
releases
to
make
patch
releases,
because
we
don't
really
support
those
the
flip
side
of
it.
It
seems
to
be
good
timing.
A
A
So
I'd
be
willing
to
say
we
can
do
the
patch
this
week
in
the
minor
next
week,
so
that
Shelley
can
promote
the
LTS
release.
The
alternative
would
be
like
I
get
I
guess,
like
the
other
question
too
on.
This
is
like
that
rule
about
having
to
promote
a
current
release
before
promoting
a
a
LTS
release
was
something
that
was
introduced
as
part
of
like
a
refactoring
of
the
rules,
I'm,
not
even
a
hundred
percent
sure
if
that
had
landed
yet.
A
B
A
A
C
A
C
A
Assets
right,
okay,
now
with
that
being
said,
like
we
already
have
a
rule
where
your
key
needs
to
be
added
two
weeks
before
you
even
do
a
release
right,
it's
just
kind
of
like
another
security
gate
and
I,
don't
think
it
is,
for
you
know
any
problems
that
we've
actually
had
the
problems
that
we've
had
before
were
a
new
release
or
get
a
release
like
within
a
day
or
two
or
the
keys
being
added,
so
they
hadn't,
really
propagated.
Sure
I
mean.
C
A
Now,
the
flip
side
of
that
we
could,
we
could
and
I
think
what's
reasonable
here.
If
we
want
is
perhaps,
as
a
group,
we
decide
not
to
obey
the
rule
this
time
because
it
hasn't
landed,
see
if
there's
any
problem
and
then
iterate,
it's
also
very
reasonable
to
assume
that
we're
not
gonna
be
onboarding.
You
know
like
three
or
four
releases
at
the
same
time
in
the
future.
Yes,
so
this
rule
may
make
a
lot
more
sense
when
we're
not
in
the
exact
situation
we're
in
today,
yeah.
C
C
C
A
Think,
like
this
spirit
of
the
rule,
isn't
like
so
we
start
creating
new
releases,
so
people
can
sign
things,
although
I
don't
think
like
in
a
reality
that
actually
like.
If
we
want
to
have
that
safety
check,
that's
the
way
for
us
to
do
it
and
I.
Think
you
like
Beth
the
point
we
were
talking
about
from
like
a
precedent,
standpoint
I
think
we
can
stand
behind
the
precedents
say
no.
We
only
did
this
release
like
from
a
security
and
reliability
standpoint
to
like
make
sure
that
the
keys
were
going
out,
but
I.
A
A
B
B
D
That's
like
the
main
issue
was
just
that
there
were
so
many
conflicts
who
didn't
make
a
lot
of
sense
anymore,
to
fake
bolting,
further
things-
and
this
is
probably
also
the
main
issue
about
having
like
a
static
time
schedule
at
a
moment
for
really
signs.
If
we
hit
too
many
conflicts,
we
should
make
sure
to
resolve
all
those
conflicts
before
releasing
a
new
version.
A
So
there
was
an
adoption
of
staging
and
that
actually
made
the
releases
for
11
dot
X
be
able
to
go
away
faster.
It
allowed
people
to
do
work
in
between
and
I
think
one
of
the
things
and
Ruben.
We
talked
about
this
I
guess
it
was
last
year
in
Berlin
when
a
lot
of
the
people
who
are
now
releasers
were
kind
of
first
nominated
to
start
doing
this
and
if
anyone's
listening,
it
gives
you
a
good
context
of
how
long
it
takes
to
get
on
board
it
for
this
stuff.
A
But
we
were
talking
about
how
to
how
to
solve
these
conflicts
and
how
to
manage
back
ports
and
I'm,
forgetting
who
initially
came
up
with
the
idea.
It
was
not
myself,
but
the
idea
of
not
actually
closing
pr's
until
they
have
been
back
ported
or
triage,
and
you
know
I
think
the
current.
The
the
recent
experience
that
happened
on
current.
There
is
good
evidence
that
you
know
is
not
only
the
LTS
branches
that
are
affected
by
this
they're,
just
more
likely
to
be
affected
by
it.
A
So
like
right
now,
for
example,
the
staging
branches
are
locked
to
the
release
teams,
but
if
we
expanded
that
I
made
it
so
that
anyone
could
land
on
any
of
the
staging
branches,
we
in
theory
could
you
know,
be
building
the
release
out
of
that.
Staging
branch
it'll
be
a
little
bit
more
work
for
us
from
a
staging
perspective,
but
it
would
shift
where
the
work
is
happening,
so
it
might
be
better.
I
know
if
Shelley
has
a
lot
of
ideas
about
this
as
well
Wow.
So
we
spoke.
D
About
that
in
Berlin
we
spoke
about
a
bit
and
Vancouver,
and
there
were
a
couple
of
different
ideas
about
it.
I
still,
personally
think
we
need
more
automation
here
and
not
the
big
process
change,
so
it
was
actually
pretty
straightforward
to
land
two
things
after,
like
three
and
more
difficult
things:
land
that
that
blocked
the
following
commits
you
know,
so
it's
mainly
to
to
push
for
a
few
specific
back
ports
and
that
they
have
to
be
done.
Otherwise,
we
cannot
release
the
new
version.
C
A
A
C
D
C
D
All
the
time,
because
it's
often
already
confusing
for
them
in
general,
the
process
merged
and
they
say
anyway,
did
you
close
the
PR
and
so
on,
and
then,
when
we
say
okay
would
we
landed
and
why
is
it
still
open?
So
these
things
are
confusing
for
people
not
knowing
the
process
as
closely
as
we
do
I
think
that's
fine.
A
Like
I'm
not
trying
to
be
on
empathy
about
it,
but
it's
like
if
we
clearly
communicate
to
people
I,
think
that
that's
fine
having
done
this
for
like
going
on
almost
four
years
now.
The
fact
that
the
PRS
are
closed,
that
they're
read
that
we
need
to
use
metadata
to
grep
and
find
the
ones
that
need
to
land
is
a
source
of
a
ton
of
extra
work
and
the
fact
that
PR
is
closed
when,
especially
when
collaborators
are
done
with
them,
and
there's
no
intention
for
people
to
chip
in
and
help
on.
A
That
essentially
means
that
people
walk
away
from
the
things
that
they
work
on.
They
forget
the
context
of
them
and
by
the
time
we
get
to
them,
they
don't
necessarily
have
the
time
or
motivation
to
help
get
it
over.
So
we
can
even
get
in
to
a
release,
and
that
ends
up
with
situations
that
we're
talking
about
we're
like
we're,
blocked
and
even
doing
a
current
release.
So
I
don't
know
what
the
answer
is,
but
I
don't
think
that
what
we
have
is
yeah.
C
D
It
was
one
more
thing
that
I
thought
about
and
I
would
like
to
more
often
big
part
major
commits
and
because
we
could
just
have
a
follow-up
commit
often
that
actually
makes
the
Samburu
interesting
to
I'd
areas
and
where
mine
are
my
pitch.
Often,
the
actual
breaking
change
is
a
tiny
code
change
and
we
would
reduce
our
return
by
actually
back
porting
Zimmerman,
some
at
least
sounds
and
by
major
commits.
C
D
If
it
is
in
this
version,
well
do
a
and
if
it
is
version
to
be
that
could
have
been
done
and
hurt
the
honor,
for
example.
That
way
we
wouldn't
have
haven't,
had
to
do
anything
in
that
PR,
but
back
courting
it's
straightforward
and
a
lot
of
the
artists
were
relying
on
her
change
their
because
there
was
a
lot
of
different
changes
as
well
in
that
committee.
A
D
D
C
E
B
B
D
A
A
And
for
what
it's
worth
kind
of
as
a
follow-up
to
that
I
added
it
as
a
bi-weekly
right
now
into
the
calendar
for
this
time
we
have
it
set
up
in
the
zoom
for
a
scheduled
conference
call
at
this
time
and
then
all
the
details
for
the
zoom
are
in
there
so
other
than
just
saying:
hey
we're
moving
forward
with
this
time.
I,
don't
think
that
there's
any
action
items
right
now.
A
A
Well,
I
mean
one
thing
that
I
think
is
worth
bringing
up
again.
I
had
you
know
kind
of
said
that
I
would
be
stepping
down
from
releases
a
couple
months
back
and
I
think
that,
after
doing
December
minor
for
ten
at
the
end
of
March,
it
might
be
time
for
me
to
move
to
emeritus
on
release.
Do
people
feel
comfortable
with
that
I
wouldn't
be
stepping
down
from
helping
with
backports
I.
Just
you
know
would
not
be
actively
releasing
stuff
anymore.
A
Yeah
cuz,
then
it's
one
release
per
person
per
quarter,
which
is
like
super
manageable.
With
that
being
said,
you
know,
perhaps
we
can
make
a
concerted
effort
to
try
to
onboard
more
people.
I
think
this
is
one
thing
to
consider
as
well.
So
like
right
now
for
current,
we
have,
you
know
like
Reuben
and
tar
goes,
who
have
been.
You
know
actively
doing
it.
A
A
Do
you
think
it's
something
where
we
should
be
going
and
recruiting,
or
should
we
be
doing
an
open
thing
where
people
can
submit
Shelley
and
Beth
I'd
be
very
interested
and
Reuben
your
perspectives
on
this,
as
people
who
are
just
on
boarded
and
have
an
idea
of
like
how
much
context
and
work
you
need
to
do
to
be
ready
to
start
releasing
like?
How
do
you
think
we
can?
We
should
go
about
doing
that.
I.
E
Sort
of
spreading
out
and
emphasizing
the
fact
that
the
type
of
backward
parrots
have
a
lot
of
value
and
just
sort
of
seeing
if
we
can
increase
the
discoverability
of
like
hey,
like
you
know,
if
you
would
like
to
help
out
node
and
not
necessarily
just
like
open
PRS
to
master
them
like
this
is
another
great
way
you
can
contribute,
potentially
I,
think
sort
of
sort
of
emphasizing
those
things
is
another
great
potentially
to
see
who
may
be
interested
in
doing
this
kind
of
work.
Yeah.
B
I
agree:
Shelly
I
know
one
of
them
one
of
my
colleagues.
Actually
they
just
got
their
first
couple
of
PRS
into
node
and
they're
like
what
do
I
do
next
and
actually
one
of
the
slightly
easier
things
if
they're
not
confident
enough
to
add
a
new
feature
or
something
like
that
back
porting,
someone
else
has
changed
its
maybe
stalled,
while
waiting
for
back
copia
is
actually
quite
a
nice
way
for
them
to.
You
know,
still
contribute
to
the
project
without
actually
having
to
work
out.
How
to
add
a
new
feature.
B
A
Yeah,
like
that
sounds
really
interesting,
like
we
almost
could
do
like
a
smaller
code
and
learn
just
around
back
recording
which
is
or
like
have
the
back
ports
as
a
good
second
commit
right,
you're
getting
into
like
kind
of
deeper
stuff
and
more
complex
stuff.
But
at
the
very
least
you
don't
have
to
write
the
patches
yourself,
which
is
kind
of
like
a
nice
compromise.
Yep.