►
From YouTube: Node.js Release Working Group Meeting - 27th Feb 2020
Description
A
Okay,
so
we
had
life
with
the
no
just
release
working
group
meeting
on
the
27th
of
February
2020
and
we'll
be
following
the
agenda
that
Sydney
noches
release,
issue
5
free
night
and
the
first
item
on
the
agenda
is
the
1216
post-mortem,
so
I
think
Myles
you
open
this
issue.
I,
don't
know
if
you
want
to
kick
it
off.
B
Yeah
sure
so,
a
couple
weeks
back,
we
had
a
release
for
12.16
targets
is
also
running,
could
maybe
chime
in
a
bit,
but
there
was
a
handful
of
different
bugs
I
think
there
was
six
in
total
that
we
identified
of
different
kinds
of
regressions
I've
landed
on
the
branch.
Some
of
them
would
maybe
be
have
been
avoidable.
Some
of
them
are
like
you
know
the
kind
of
things
we
don't
really
see
until
we
ship,
and
so,
if
we
kind
of
look
here,
we
ended.
B
We
ended
up
doing
a
last-minute
release
the
following
week
of
12.16,
one
to
kind
of
patch
these
problems,
so
the
first
one
that
we
ran
into
was
packaged
self
resolution,
not
behind
an
experimental
modules
flag.
You
have
me
personally
to
thank
for
this
particular
bug,
so
the
feature
originally
landed
with
its
own
flag
on
masteren
13
and
the
flag
was
then
removed.
B
But
the
experimental
conditional
exports
flag
was
still
in
front
of
it,
but
then
the
experimental
conditional
exports
flag
was
removed
on
13,
but
on
12
we
kept
the
entire
modules
implementation
behind
the
experimental
modules
flag
and
the
code
path
to
this
particular
feature
was
not
behind
that
flag.
It
got
missed
in
the
back
porting
that
was
just
unfortunate
mix.
Miss
there
was
no
specific
unit
tests
for
it
and
it
wasn't
until
the
release
went
out.
People
played
with
it
that
they
excuse
me.
He
wasn't
totally
released
when
out
that
people
actually
found
this
bug.
B
I
think
that
this
is
one
of
the
things
that
could
potentially
have
been
found.
If
we
had
had
more
people,
testing
DRC's
but
other
than
that
I'm,
you
know
not
really
a
hundred
percent
sure
how
we
could
have
avoided
it.
I
don't
know
if
other
people
have
anything
they
could
chime
in
with
on
this
one
I.
A
B
B
B
The
the
issue
is
fixed
on
master,
but
I
hadn't
landed
or
been
released
at
the
time
of
the
12
release.
The
Lord
large
pages
feature
was
back
ported
in
a
back
court
PR,
but
the
issues
that
it
created
were
not
linked
back
to
the
back
court
or
to
the
original
PR.
So
when
the
future
was
being
reviewed
and
eventually
landed,
we
have
we
did
not
have
any
clue
about
the
build
problems
and
the
there
were
no
tests
that
were
available
to
ensure
like
to
make
us
aware
of
those
build
problems.
B
I
think
that
you
know
some
of
the
stuff
that
was
listed
here
is
like
commenting
on
the
PR,
with
the
link
so
like.
Whenever
people
find
issues,
we
really
should
be
coming
back
and
documenting
those
on
the
PRS
that
introduced
them.
If
a
PR
is
not
going
to
be
reverted
on
on
master,
and
there
are
issues,
then
the
back
port
block
label
should
likely
to
be
added,
and
if
the
PR
is
reverted
on
master,
the
don't
land
label
should
be
added.
B
I,
think
one
additional
thing
here
and
folks
can
chime
in
if
they
agree
or
disagree,
you
know
the
the
back
port
PR
that
was
opened.
The
person
who
was
championing
this
feature,
or
whoever
is
championing
a
feature
should
likely
be.
You
know,
taking
the
work
and
making
the
effort
to
ensure
that
there
are
no
Russians
and
that
the
LTS
branches
are
aware
of
it.
B
B
That
was
a
change
that
got
introduced,
landed
in
December
and
13,
and
the
bug
was
only
reported
once
it
landed
in
12
and
12.
It
was
fixed
and
the
fix
was
fairly
trivial
and
backported.
This
is
one
of
the
ones
that
I
don't
know
that
we
really
could
have
done
much
more.
Similarly,
with
the
HTTP
response
listener,
the
bug
landed
for
these
two,
a
I
guess.
One
thing
that
that
is
worth
considering
here,
although
I
don't
know,
if
it's
huge
is
that,
like
the
the
changes
that
we're
talking
about
landed
in
like
late
December?
B
And
if
you
look
at
like
our
download
charts,
you
can
see
massive
dips
around
the
holiday,
so
we
may
want
to
consider
letting
things
bake
a
little
extra
longer
if
they
went
out
in
a
13
or
in
a
current
release
around
the
holidays,
and
that's
maybe
a
way
to
avoid
stuff
like
that.
But
these
kind
of
bugs
happen
and
I
think
those
two
bugs
in
particular
may
or
may
not
have
been
considered
sufficient
to.
B
You
know
cause
a
full
release,
but
with
all
the
other
things
that
were
getting
fixed,
they
got
bundled
in
and
the
last
one
that
we
found
was.
There
was
a
new
field
created
on
a
vent
emitter
that
was
enumerable
but
non
writable,
and
this
is
really
not
a
best
practice
for
us
to
do.
People
enumerated
across
our
objects
and
do
things
with
it.
There
is
a
popular
library
called
extend,
that's
used
for
writing
class
extensions.
B
A
B
And,
to
be
honest,
I'm,
not
sure
I,
a
hundred
percent
agree
with
this
I
think
that
there,
in
some
cases
it
might
make
sense,
but
a
really
good
example
of
where
I
think
this
could
be
problematic
would
be
like
the
large
changes.
The
large
pages
change
like
that
had
not
been
reverted
on
master
when
the
initial
problems
were
found
and
I
think
it
would
have
been
fairly
disruptive
for
us
to
have
put
to
try
to
revert
that
on
master
and
and
kind
of
waterfall.
B
Those
down
I
believe
that
Anna
and
I
have
a
slightly
different
mental
model
of
how
we're
thinking
about
this
I.
Don't
necessarily
think
either
of
us
are
right
or
wrong.
For
me.
You
know
we
add
things
to
the
LTS
branch
as
we
do
our
releases
and
if
we
add
things
that
are
problematic,
I
think
it's
very
reasonable
to
remove
them
until
they're,
not
I,
think
her
biggest
concerns
are
related
to
losing
track
of
those
changes
and
not
actually
eventually
getting
them
landed.
B
A
Think
aiming
to
repair
or
master
first
if
we
can
make
sense
and
then
cherry-picking
the
rebirth,
but
if
we're
trying
to
like
get
a
fixed
out,
yes,
release
out
as
soon
as
possible.
I
feel
like
it's
okay,
to
make
a
deviate
from
that.
As
long
as
we
try
and
again
to
post
on
the
original
PR
to
say:
hey,
I've,
just
loved
be
tender
excellently
twelve
dogs
because
it
was
causing
these
reported
issues.
At
least,
then
we
have
the
reference
back.
B
Yeah
I
guess
one
of
the
things
that
could
be
a
good
way
to
think
about.
This
is
like
I,
at
least
when
I
was
handling
the
12.16
dot.
One
release
there
were
kind
of
two
modes
I
was
in.
It
was
either
fine
to
fix
and
patch
it
or
revert
it,
but
maybe
it's
like.
We
need
to
have
a
in
our
toolbox
there,
which
is
revert
on
master
and
backcourt,
that
reversion.
B
Say
I
guess
like
the
thing,
the
one
thing
that
I
would
be
concerned
about
with
like
reverting
on
master
would
be
like
ensuring
that
those
reversions
also
then
in
turn
land
on
current.
But
that's
probably
not
a
massive
issue
would
probably
just
get
picked
up
but
for
features
I,
don't
know
how
I
feel
about
that.
But
but
maybe
it's
something
we
deal
with
on
a
case-by-case
basis
in
the
future.
B
C
B
B
Yeah
we,
why
don't
we
start,
then,
maybe
with
a
pull
request
against
this
repo
and
figure
out,
maybe
where
it
should
live.
There's
also
the
possibility
that
we
could
make
like
a
new
folder
within
the
repo
just
with
like
guides,
so
that
the
readme
doesn't
just
keep
kind
of
growing
and
becoming
this
huge
thing
to
digest,
especially
if
it's
something
that's,
maybe
not
a
general
interest
but
of
interest
to
the
people
who
are
doing
the
work.
Yep.
A
A
I,
don't
think,
there's
anything
else
to
add
there
I
also
added
to
the
agenda
the
10:19
one
release.
So
this
has
been
pushed
back
quite
a
lot.
Originally,
we
were
hoping
it
would
be
January
February,
but
with
the
security
releases,
it's
been
delayed,
and
this
was
actually
due
to
be
the
last
December
minor
of
no
10.
So
just
before
the
meeting
I
opened,
a
PR
I've
landed
some
open
back
courts
and
some
things
labeled
I'll
just
watch
on
to
the
stage
and
branch
and
created
a
draft
proposal
at
the
moment.
A
A
But
the
main
issue
is
that
there
are
a
hundred
and
twenty
seven
pr's
labeled
backcourt
requested
and,
to
be
honest,
I
have
no
we're
like
no
idea,
which
ones
worth
investing
the
effort
into
and
actually
go
through
and
fix
the
conflicts
and
back
port,
which
is
why
I
pin
the
PR
to
kind
of
everyone
and
say
hey.
If
there's
a
feature
in
this
list
that
you're
really
interested
in
maybe
take
his
tablet
back
courting
it.
A
B
One
thing
that's
worth
shining
in
here
is
like
ten
is
now
gonna,
be
the
last
release
line
that
will
continue
to
be
actively
supported
for
those
six
months
that
it's
in
right
now
that
we're
finding
to
be
particularly
difficult,
so
I
I
for
one
am
okay
and
open
to
you
know
we
could
potentially
even
just
China
in
on
the
contributors
a
discussion
board.
We
could
tweet
about
it.
Just
let
people
know
hey
like.
Are
you
still
using
ten?
Do
you
have
issues
with
ten?
B
B
A
A
A
Okay,
that
sounds
like
we
want
to
do
some
like
marketing
on
this
release,
to
try
and
get
some
people
to
try
minute.
I
have
tentatively
kind
of
said
mid-march,
but
I
can
imagine
that
be
pushed
back.
I,
don't
think
we
should
let
slip
into
April,
otherwise
we'd
be
doing.
We
would
be
doing
a
minor
release
in
the
month
that
turns
maintenance,
yeah.
B
B
D
B
I'm
not
bullish
on
trying
to
get
that
back
to
ten,
especially
if
the
feature
sets
that
we're
talking
about
are
not
really
like
the
functionality
of
the
repo
itself.
I
would
not
want
to
accidentally
introduced
into
any
sort
of
regressions
or
problems,
but
yeah.
So
there's
twenty
open
issues
that
are
labeled
ten.
B
A
Okay
and
never
know
if
anyone
is
trying
to
cherry-pick
something
onto
the
10x
staging
brunch
I've
had
lots
of
problems
running
CI
on
no
ten,
probably
because
it's
not
been
run
quite
well.
A
lot
of
flaky
tests
haven't
been
marked
on
10,
etc.
So
it's
not
fun.
Just
as
a
caveat.
If
you're
running
CI,
you
okay
seems
like
we
have
a
plan
there,
and
that
was
everything
on
the
agenda,
but
what
I
will
do
is
go
through
our
schedules,
for
you
should
releases
if
I
click
the
right
one.
A
E
B
So
the
idea
we
would
wait
until
March
for
the
next
release,
yeah
yeah,
I,
think
that
seems
reasonable
and
if
Shelley's
got
you
know,
I
guess
the
one
thing
I'm
looking
at
here,
just
looking
to
cut
a
calendar,
so
Shelly
you've
got
a
release
that
you're
responsible
for
next
week.
Already
right:
yes,
no
you're!
B
You've
got
something
that
week,
which
means
then
like
the
following
week:
you
can
work
on
the
back
porting
stuff
to
get
the
RC
out
by
the
17th.
That
already
seems
like
it's
a
lot
of
work
to
ask
of
you,
so
I
I
think
if
you
are
okay
with
that,
then
that
seems
reasonable.
I
think
asking
for
sooner
deadlines
on
that
is
unreasonable,
yeah.
E
B
B
B
Minor
might
be
good
to
actually
do
this
number
miner
sooner,
especially
because
we
had
like
the
long
large
pages
change
which
got
reverted
so
that
means
that,
like
it
will
be
back
out
in
a
reasonable
amount
of
time,
but
I'm
not
sure
if
people
want
to
see
another
semper
miner
come
out
so
soon,
but
anyone
have
thoughts
on
that.
I
think.
A
B
Also-
and
you
could
tell
me
if
I'm
wrong-
it
looks
like
we
have
a
release
candidate
date
and
then
the
actual
release
date
is
a
week
later.
That's
not
really
giving
a
lot
of
time
for
the
RC.
It
seems
like
in
general.
We
only
have
a
week
on
here.
I
know
that
we
briefly
talked
about
that
before,
but
in
the
past
we
had
been
doing
two
week,
our
C's
for
the
for
December
patches
and
three
week,
our
C's
for
December
miners.
So
I
don't
know
what
like
do.
B
A
B
C
C
D
B
That
is
something
that
the
the
team
has
been
discussing.
That's
gonna
creep
up
on
us,
but
there's
still
a
few
other
pieces
of
work
that
we're
doing
including
kind
of
like
negotiating
and
discussing
timelines.
So
I
would
say.
Probably
in
the
next
two
weeks
the
team
will
have
a
more
solidified
idea
of
what
that
timeline
is
going
to
look
like.
A
A
A
4
p.m.
UTC,
I
believe
and
we've
we've
still
got
a
few
attendees
it's
down
to
one
or
two,
but
there's
two:
a
couple
of
people
go
into
that
one
see
if
anyone
was
interested
in
joining
along
I,
usually
just
use
the
time
to
like
prepare
released.
It's
on
the
cards,
but
I
was
announcing
that
circle
thing
on
the
agenda.
So
if
there's
nothing,
anyone
wants
to
worry
so
please
to
pull
up.