►
From YouTube: Node.js Release Working Group Meeting - 7th May 2020
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
So
I
see,
we've
got
pretty
much
people
scheduled
up
to
mid
June
and
the
relief
14
to
run
out
on
Tuesday,
so
I
guess
surely
you've
signed
up
for
one
in
two
weeks
time,
so
we've
set
two-week
cadence
for
our
14x
releases
and
but
I
guess.
If
there's
any
interim
critical
bunks,
we
will
patch
those
as
some
when
we
have
time
to
create
the
patch
releases
or
any
comments
or
thoughts
on
our
14x
release.
Schedule.
B
A
Thing
is
probably
worth
raising
is
on
14,
1
and
14.
There
was
a
commit
that
seems
to
break
some
downstream
modules,
like
just
I,
think
its
into
an
intermittent
breakage,
and
it
only
shows
up
on
the
releases
that
we
bailed
so
people
if
they
build
with
Visual
Studio
2017
locally,
and
they
won't
ever
hit
the
issue.
So
it's
quite
difficult
for
people
to
bisect
I
know,
Micah's
also
went
and
did
a
price
act
on
our
release
builds
so
like
manually,
inputted.
A
A
A
A
C
So
the
I've
done
this
update
once
before,
but
honestly
I'd
need
to
get
myself
back
up
to
date
with
it,
we
could
dig
up
and
see
what
we
did
last
time.
I
believe
I
documented
it,
but
I
could
be.
It
could
be
wrong,
I
hope
I
did,
but
updating
the
TZ
data
does
not
involve
updating.
Icu
itself
is
just
kind
of
like
its
own
file
and
those
need
to
be
updated.
C
Anytime
time
zones
around
the
world
change
their
information,
or
we
will
essentially
give
people
the
wrong
time
zone
data
in
our
ICU
data,
so
this
needs
to
be
updated
on
all
lines.
I
think
that
where
this
becomes
an
interesting
question
is
like
is
this
the
kind
of
thing
that
should
create
a
release
on
maintenance
release
lines
or
not?
I
think
we
should
kind
of
probably
have
a
consistent
policy
around
that
I.
C
Think
that
there's
an
argument
that
could
be
made
that
having
the
incorrect
time
zone
data
is
something
that
is
like
a
like
a
correctness
issue
and
potentially
breaks
people
setups.
But
you
know
I,
don't
know
if
that's
something
that
should
justify
its
own
release
on
like
ten,
for
example,
at
the
very
least
we
should
patch
10
and
put
upon
it
staging.
We
should
patch
12
past
13
patch
14
and
get
them
out
in
in
upcoming
releases.
C
A
Thoughts
are
kind
of
like.
Would
it
be
more
disruptive
if
10
was
returning
at
different
time
saying
to
12
and
it's
almost
like,
we
coordinated
all
the
releases
kind
of
go
out
at
roughly
the
same
time
of.
Why
is
there
gonna
not
have
the
same
time?
I
can
imagine
people
testing
again
it's
multiple
versions
of
note
getting
weird
test
results.
If
the
time
same
thing
is
correct
in
one
case,
and
not
the
other
yeah.
C
C
We
want
to
minimize
the
number
of
updates
that
we
do
so
you
know
like
something:
I
could
see,
for
example,
is
like
having
that
time
zone
update
on
staging,
but
just
waiting
until
there's
a
couple
more
things
so,
like
napi
updates,
I
know
we're
also
in
the
pipeline.
It
would
be
a
shame
to
do
like
a
release
for
the
time
zone
data
and
a
release
for
the
nati
updates.
In
my
personal
opinion,
I
think
we
should
roll
this
all
together
as
much
as
possible
right.
C
A
C
C
C
C
D
C
10
is
60
4.2,
so
we're
looking
at
three
different
versions
of
ICU,
although
I
would
say
the
next
12
that's
coming
out
is
December
minor,
so
I
would
say
we
should
probably
be
able
to
use
the
same
patch
against
master
14,
13
and
12.
The
1
to
12
would
include
the
update
to
260
6.1,
although
12
will
probably
require
a
different
patch
than
14,
because
14
uses
full
ICU
and
12
uses
ICU
small.
C
C
That
would
be
awesome
in
the
issue.
That's
open,
there's
also
a
link
to
an
RSS
feed,
that's
updated
whenever
that
the
timezone
data
is
updated,
so
I
think
that
there
is
the
possibility
that
we
could
kind
of
automate
the
whole
pipeline
of
creating
the
pull
requests
when,
when
there
are,
are
updates,
yeah.
D
C
So
we
have
right
now,
I
mean
this
isn't
like
kind
of
like
part
of
the
official
build
teams
in
distress
sure,
but
no
jayadev
is
running
in
a
Google
cloud
project
that
I've
gotten
some
credits
for
so
we
could
experiment
in
there
if
you
just
want
access
to
cloud.
Infrareds
like
paid
I
know
that
the
build
team
does
have
a
number
of
different
machines,
some
of
which
could
potentially
host
some
of
this
infrastructure.
I
would
say
for
prototyping,
it's
kind
of
fun
to
throw
wherever
but
like
once.
C
C
Let's
see
I
personally
see
like
I'll
put
it
another
way
like
there's.
No
reason
why
you
can't
set
up
your
own
animations
on
your
own
hardware,
that
openko
requests.
There's
no
rules
against
that.
You
know
so
I
think
it
makes
a
ton
of
sense
to
just
you
know:
do
it
on
whatever
infrastructure
you're
most
comfortable
with
and
have
access
to,
and
then,
if
we
have
a
prototype
and
we're
thinking
about,
you
know,
production
izing
it
and
what
the
Foundation's
taint
like
the
our
projects
team
to
maintain
it,
then
we
can
kind
of
do
an
evaluation.
A
C
A
E
Guess
that's
a
question
if
people
are
using
full
ICU
is
that
gonna
I
don't
know
after
this?
Does
that
get
updated
with
the
latest
time
zone
data?
Could
anyone
using
for
lie
to
you
would
not
be
using
the
ICU
built
into
that
node.
C
C
E
You
use
ten,
that's
compared
with
small
ICU,
but
you
can
work
full
ICU
and
peer
module
to
get
the
full
Weiss
view.
Data
I
think
yeah,
that's
that's
where
this
issue
started
coming
in
is
that
if
people
had
done
that
and
then
we
updated
ICU,
then
obviously
the
the
standalone
module
was
at
the
wrong
version
and
wouldn't
automatically
update.
Unless
you
went
in
and
did
it
yourself.
C
Necessarily
have
ever
liked
any
of
them.
Yeah
I,
believe
that
could
be
wrong,
that
the
trans
own
data
released
cadence
is
separate
from
the
release
cadence
of
ICU
itself.
So
well,
it's
possible
that,
if
someone's
using
full
ICU
and
using
like
a
newer
version
or
a
different
version
than
what
is
in
core,
that
they
could
have
I,
guess
a
more
updated
version
of
the
TZ
data,
but
I
think.
E
I'm
thinking
more
about
the
people
using
the
module,
the
module,
so
it
will
be
the
same
version
of
ICU
in
theory,
but
using
the
data
files
that
are
in
the
module
rather
than
the
ones
that
shipped
with
node,
because
we
only
ship
small
I,
see
you
on
everything,
12
and
10.
Isn't
it.
It
was
only
14
that
we've
got
the
force
you
built
in.
C
C
A
F
F
F
F
C
A
A
F
B
This
is
definitely
a
huge
improvement
over
whatever
we
had
before
and
I
know,
like
especially
the
top
part
is
probably
the
most
important
and
it's
the
most
difficult
to
get
and
I
guess.
We
need
to
have
the
public
s
open
for
a
while
to
get
all
the
information
together
so
that
other
people
could
also
contribute
some
examples,
as
we
did
here,
and
so
maybe
we
should
try
to
open
our
draft
just
a
little
bit
earlier
in
the
future.
Yeah.
E
I'm
wondering
if
there's
a
way
to
easily
capture
the
text
that's
going
in
here.
If,
for
example,
we
would
then
pull
that
particularly
changed
to
another
release
line
where
there
will
be
easy
to
find
this
text
or
whether
we'd
have
to
go,
find
the
other
release
that
that
landed
in
and
copy
it
copy
it
out
of
it,
because
at
the
moment
that's
not
going
to
be
associated
with
the
particular
pull
request.
Is
it
it's
only
going
to
be
in
this
release
proposal?
E
A
Guess
right,
respectively,
adding
the
notable
changed
label
to
any
of
the
PRS
here.
May
you
remind
us
to
go
looking
to
see?
Oh,
it
was
listed
as
really
notable
change
and
then
you
can
find
like
go
back
and
see
which
release
it
was
pulled
into
and
see
where
it's
written
about
there,
maybe
mine.
If
that,
would
it's
not
the
easiest
train
of
thought
to
follow,
but
like,
for
example,
this
would
have
the
notable
change?
Oh
it
already
does,
but.
C
A
A
F
Yeah
I
think
that's
a
good
thing
to
formalize.
It
does
one
thing
that
I'm
not
really
sure
about
its
how
we
should
transfer
this
to
the
commit
message,
because,
with
the
previous
format,
it
was
quite
easy
to
do,
but
now
I
don't
think
it's
really
a
good
idea
to
copy/paste
this
huge
text
to
the
commit
message
yeah,
so
that
would
need
to
be
defined.
How
we,
how
we
do
it.
C
So
could
you
quickly
show
what
the
with
the
change
log
itself
looks
like
with
all
of
us.
F
A
Cool
okay,
so
I
guess
we're,
try
and
keep
up
I.
Don't
know
necessarily
need
to
sign
someone
up
for
writing,
formalizing
this
and
releases
MD
that
if
anyone
does
have
time
to
do
it,
I'll
add
some
links
in
this
issue
actually
and
didn't
you
the
new
layout
that
Michaels
kind
of
proposed
it
sounds
good.
Definitely,
improvement.
A
A
A
Does
anyone
have
time
to
volunteer
that
one
or
once
the
peels
are
open
I
may
be
able
to
complete
them?
All
I
may
be
able
to
do
as
well.
Oh,
okay,
I
guess.
Would
you
see
how
long
have
we
got
before
maintenance
7th
right
in
ten
days,
yeah
feel
free
to
ping
on
the
issue
a
little
bit
closer?
If
you
have
time.
A
I
guess
the
last
thing
this
was
tagged,
release
agenda,
but
it
didn't
seem
to
automatically
add
itself
to
the
issue
and
but
with
the
release
tags
and
when
we
cherry
pick
to
master
and
it's
just
making
sure
we
we
provide
the
array
of
versions
that
the
feature
was
added
in
so
you're.
Typically,
NEC
conflicts
when
you're
preparing
an
LTS
release,
it's
just
kind
of
a
reminder
to
add
the
whole
array
of
new
versions.
I
didn't
realize
that
I
thought
we
just
over
overwrite
them
originally,
but.
A
C
A
Twelve
signed
up
for
a
while
tenors
and
maintenance,
and
so
I
guess
the
maintenance.
Lts
releases
are
kind
of
less
interesting
because
they're
just
a
few
patches
and
there's
not
like
the
thing,
the
PRS
that
were
open,
we
tend
to
just
merge
them
all
in
because
they're
opened
during
maintenance
for
a
reason.
A
D
A
Yeah
I
kind
of
feel
the
same
because
nowadays
we
kind
of
get
for
everything
we
want
to
discuss
in
the
like
in
Greek
rules,
unless
there
was
I
dedicated,
like
automation,
focus
or
maybe
a
sick
Jim
figures,
but
for
the
regular
kind
of
policy
stuff
I
think
the
working
group
meetings
kind
of
cover,
those
so
I,
don't
think
we
need
an
additional
time
right.
Don't
if
anyone
had
any
other
ideas
for
like
a
dedicated
session
on
a
particular
topic
or
something
I.
C
I
think
I
agree
with
that
assessment
to
be
completely
honest
and
the
fact
that
we
also
have
like
the
mentoring
sessions
once
every
two
weeks
to
like
I
think
that
it's
at
least
in
my
opinion,
others
may
disagree.
I.
Think
that
we're
in
a
position
where
we
can
leave
the
time
for
the
summit
for
other
teams
that
need
to
build
more
collaborators
and
stuff
feels
like
we
have
like
a
good
amount
of
of
momentum.
C
A
D
B
A
E
Popped
into
the
build
work
group
meeting
this
week
to
talk
about
stuff
had
been
talking
about
in
package
maintenance
where
they
had
a
similar
thing
about
having
words
for
to
describe
releases,
and
that
was
from
the
point
of
view
of
trying
to
get
version
managers
to
adopt
it.
So
so
there's
some
common
terminology
about
long-term
support
releases
and
whether
they
were
in
maintenance
mode
or
not,
but
it
was
kind
of
pre
news
for
everyone
in
build.
He
just
popped
in
and
then
there
yeah
there's
been
some
discussion.
E
The
package
lady
was
working
group
and
I've
not
really
been
attending
those.
So
I,
don't
really
know
the
context
around
that,
but,
for
example,
they
we
thought
he
was
talking
about.
There's
some
tooling
pkgs,
that
scrapes
things
like
the
schedule
and
the
index
JSON
files
to
try
and
come
up
with
whether
a
particular
point
in
time.
A
release
line
is
in
maintenance
or
not,
but
yeah.
It
all
ties
in
with
that
sort
of
consistent
terminology.
A
A
E
E
Guess
and
Mars:
well
you
hear
it's
a
down
and
put
you
into
the
spot,
but
I
was
just
thinking
they're
the
dropping
of
the
flag
for
experiment
for
ESN
modules
on
12.
Is
there
any
danger
that
anyone
that
doesn't
opt
that
isn't
opting
in
to
ascend
might
be
affected?
So,
for
example,
if
you
were
including
another
module,
could
you
suddenly
start
seeing
a
difference
in
behavior
because
that
flag
is
no
longer
required?
E
C
The
the
potential
behavior
change
here
and
I
think
that
it
needs
to
be
taken
with
a
grain
of
salt,
but
you
know
if
the
release
team
has
a
problem
here,
it's
a
very
good
time
to
voice
it.
Unflagging
ESM
also
essentially
unflagged
package
exports
on
on
twelve,
and
so
the
like
observable
change
for
people
would
be.
If
you
were
using
packages
that
shipped
with
both
a
main
entry
and
a
package
exports
entry
yeah,
you
will
start
getting
the
package
exports
entry
point
instead
of
main
now.
C
The
I
think
that
there's
two
different
ways
to
consider
this,
where
I'm
landing
on
it
right
now
and
I,
recognize
that
it's
it
is
a
shift
is
the
packages
that
are
introducing.
Exports
tend
to
be
kind
of
bleeding
edge
packages
and
experts
can
be
introduced
in
a
way
that
are
cember
minor.
They
can
be
done
in
a
way
that
don't
have
backwards
like
don't
have
breaking
changes,
and
the
breaking
change
of
the
exports
is
more
of
a
breaking
change
to
the
interface
of
the
module,
not
to
note
itself.
C
So
with
that
in
mind,
you
know
like
if
people
have
projects
that
are
using
exports
and
that
breaks
people
on
twelve
and
they
get
issues.
It's
pretty
straightforward
to
make
small
augmentations
to
the
package,
exports
to
fix
whatever
broke
in
December
patch
or,
alternatively,
revert
it
and
introduce
the
exports
in
December.
Major
I
know
that
this
isn't
perfect
and
I
know
that
it's
a
little
it's
a
little
wavy,
but
it
yeah
I,
don't
think
that
it's
any
different
than
introducing
any
other
new
feature
or
API.
So,
like
you,
we're
back
boarding.
My
other
api's
yeah.
E
I'm
I'm
not
entirely
sure
there,
because
my
worry
from
an
LTS
point
of
view
is
you
have
something
installed
that
works
a
certain
way
and
then
you
upgrade
node
and
it
works.
You
know
it
might
it's
all
theoretical
right,
because
unless
we
actually
go
in
and
its
value
a
every
single
module
out
there,
we
don't
know.
But
the
point
is:
if
you
suddenly
get
a
chip
in
behavior,
then
what
we're
saying
what
that,
if
you're,
if
you've,
got
one
of
these
dependencies
that
has
got
a
broken
exports
for
some
reason.
E
C
E
E
C
E
No
I
I'm
just
being
ultra
cautious
in
it
because
you
know
like
I
said
this
is
if
this
is
an
LTS
now
you
know
it's
not
like
this
will
become
L
fear,
it's
easy
now,
sugar
and
basically
we're
going
to
shift
the
behavior
on
people
without
the
option
of
going
back
to
the
behavior
they
had
before.
So
there
is
the
potential
here
that
we
are
going
to
cause
breakage,
whether
that's
on
us
to
fix
or
the
actual
modular
roof
is
to
fix.
E
E
But
if
not,
then
the
only
thing
I
could
suggest
would
be
to
either
introduce
another
flag
or
have
something
come
beyond
that.
It
that
experiments
motor
spike
to
just
say
well,
the
default
is
to
enable
ESN,
but
you
know
we
provide
you
with
an
escape
hatch
to
disable
it
so
that
you
it's
back
to
how
it
was.
If
you
didn't
specify
it,
you
know
if
you
were
on
the
older
release
line
and
you
weren't
supposed
to
find
experimental
modules,
but
I
guess
that'd
be
a
baby.
C
E
E
F
C
I
guess
really
what
we'd
want
to
be
honest,
yeah
here,
because
it
actually
has
nothing
to
do
with
ESM
its
exports
right
is
what
you're
asking
for
is
a
like
disabled
exports
flag.
If.
C
So
so
I
mean
for
what
it's
worth
and
I
think.
Maybe
this
is
even
something
to
consider
proposing
to
the
modules
team
as
a
whole
kind
of
like
thinking
of
this
allowed
yep
disabled
exports
seems
like,
depending
on
how
gross
it
is
to
put
into
the
source
text.
Maybe
it's
something
you
should
consider
just
having.
F
C
I
guess
it
goes
in
two
directions
like
on
one:
I
can
imagine
anything
around
disabling
exports
being
like
a
bunch
of
checks
and
the
result
which
is
gross,
and
we
probably
wouldn't
want
to
maintain
that
so
I
could
see
a
reason
to
have
that
target.
I
could
see
how
you
have
the
target
just
be
12
rather
than
having
to
like
maintain
this
flag
forever,
but
I
can
also
see
people
being
like
annoyed.
C
E
C
E
And
yeah,
if
it's
yeah,
it
doesn't
have
to
be
the
whole
of
ESN.
But
if
it's
the
observable
change
is
the
package
exports,
then
you
know
I'm
not
opposed
to
having
their
on
by
default
as
a
change.
But
the
worry
is
that
if
that
does
cause
people
problems,
we
have
no
way
of
switching
that
off.
So
you
know,
if
you
happen
to
be
affected
by
that
your
options
are
either
to
roll
back
to
an
earlier
version
of
12
or
to
wait
for
a
you
know:
a
module
update
from.
C
E
I'm
honestly
I've
seen
a
lot
of
we
have
this
problem
window
geoip,
where
it's
hard
to
convince
people
that
it's
a
problem
with
the
modules
they're
using
and
not
because
because,
as
far
as
the
PIAT
person
encountering
the
problem
is
concerned,
the
only
thing
that
changed
is
the
version
of
node
the
fact
that
they
have
a
latent
bug
in
one
of
their
dependencies.
That
is
only
surfaced
because
we
changed
something
they
don't
really
care
about,
that
they
just
care
about.
I,
had
something
working
and
now
I've
change,
something
it's
broken.
Yeah.
C
We're
like
4g
RPC
builds
got
broken
because
of
a
change
to
streams
which
seems
to
have
unearthed
the
latent
bug
in
needle-like,
so
I
guess
Richard.
My
thoughts
here
and
I
can
be
flexible.
I'm
not
trying
to
be
stubborn.
I
think
that
we
should
push
this
out.
I
think
that,
yes,
there
is
room
for
breakages,
but
I
think
that
the
majority
of
this
breakages
are
actually
rather
easy
to
fix
and
we've
seen
folks
who
introduce
experts
in
a
way
that
break
people
quickly
revert
them
in
the
ecosystem.
C
Already
such
as
the
is
promise
circumstances
that
happen,
I,
don't
think
that
we're
going
to
be
seeing
people
kind
of
massively
doing
this
in
breaking
ways,
because
it
would
already
be
broken
on
other
release
lines.
I
I
am
hesitant
to
introduce
a
flag
to
either
turn
off
modules
or
turn
off
exports
because
I
it's
gross.
It
creates
a
pattern
that
I,
don't
think
is
great
and
it
creates
an
inconsistency
between
the
LTS
versions
that
have
these
features.
C
That
I
just
think,
is
going
to
be
confusing
for
folks
with
that
being
said,
I
would
be
willing
if
we
released
this,
and
there
are
massive
breakages
and
people
can't
adopt
it
in
tons
of
issues.
I
think
we
have
a
clear
path
forward
of
adding
a
flag
to
disable
exports,
but
I
would
like
that
to
be
our
fallback,
not
our
default.
Is
that
something
you
think
you
could
get
behind?
Yeah.
E
Like
I,
don't
know
enough
about
more
jaws
in
order
to
say
how
much
of
a
problem,
it's
always
the
reticle
problem,
it
might
be
that
no
one
has
any
issues.
It's
just
yeah.
It's
just
the
clear
that,
because
this
is
LTS,
it's
the
you
know
what.
If
the
worst
happens,
what
are
we
going
to
do
and
if
it
is
that
we
would
then
have
to
push
out
another
release?
E
C
Yeah,
it's
been
discussed,
I
I.
Think
personally,
I
am
okay
with
the
risk.
I
know
that
it
does
risk
us
burning
some
of
our
credibility,
and
you
know
that's
why
we
should
have
buying
across
this
whole
team
about
doing
it
and
thank
you
for
bringing
it
up.
Yeah
I
think
that
the
risk
is
tolerable
personally
and
it
feels
like
we
have
a
clear
plan
to
mitigate
that
to
mitigate
it,
if
it
does
prove
to
be
an
ecosystem
problem
and
the
solution
is
not
overly
complex.