►
From YouTube: Node.js Release Working Group Meeting 2020-08-13
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
Live
on
youtube
with
the
august
13th
edition
of
the
node.js
release
working
group
beth:
do
you
want
to
take
it
away.
B
Yep
sure
so
we
will
be
following
the
agenda,
which
is
in
the
node.js
release,
issue
number
599.
I'll
just
start
with.
Are
there
any
announcements
that
anyone
has
and
would
like
to
make.
A
I
have
an
announcement,
it's
very
short,
but
node
14.8.0
went
out
on
tuesday
and
with
it
came
top
level
await
being
unflagged,
which
I'm
extremely
excited
about.
B
Awesome:
okay,
we'll
move
on
to
the
first
item
on
the
agenda.
I
know
richard
you
added
this
one,
this
one's
from
a
discussion
over
in
node.js
node,
which
is
the
special
treatment
for
package
json
resolution
richard.
I
don't
know
if
you
want
to
start
that
discussion
as
you
added
it.
C
I
can't
remember
the
version
of
the
top
of
my
head,
but
we
did
discuss
prior
to
unflagging
if
there
were
risks
to
the
ecosystem
and
we
did
discuss
various
scenarios
that
could
occur
and
what
we
said
was
that
we'd
go
out,
we'd
see
what
the
fallout
is
and
if
needs
be,
we
could
add
a
flag
back
in
now,
I'm
not
suggesting
that
we
have
to
add
a
flag
back
in,
but
there
has
definitely
been
feedback
in
this
issue
as
to
the
change
affecting
the
ecosystem,
it's
a
bit
hard
to
gauge
how
widespread,
but
you
know
at
least
someone
has
felt
strongly
enough
about
it
to
start
questioning
whether
the
risks
were
assessed
before
unflagging,
and
I
think
you
know
we
can
say
that
we
did
assess
the
risks.
C
I
guess
the
question
to
discuss
here
is:
was
there
anything
else
we
could
have
done
or
you
know
are.
We
are
we
happy
with
the
state
of
things
at
the
moment?
You
know
it's
a
tricky
one,
because
obviously
there's
the
module
side
of
things
and
then
there's
also
the
node
side
of
things.
But
ultimately
it
is
an
observable
changing
behavior.
A
A
I
I
I
struggle
to
to
see
it
as
the
at
the
scale
that
it
was
being
presented.
Personally,
although
I
do
recognize
and
empathize
with
the
frustration
of
having
things
break
and
losing
time
to
having
to
figure
it
out,
you
know
that
that
is
definitely
less
than
ideal.
A
So
like
the
problem
was,
they
were
using
a
beta
version
of
fetch,
I
believe,
and
the
beta
version
of
fetch
had
a
broken
implementation
of
imports,
because
they
didn't
include
the
package
json
and
a
later
beta
like
included
it,
and
then
it
was
fine.
I
think
there
was
like
another
tool
from
jest
or
facebook
that
was
expecting
pakistan's
to
live
in
a
certain
way
that
there
was
also
an
upstream
change
landing
to
fix
that
problem.
A
So
you
know
like
I
guess
one
of
the
things
that
I
think
is
most
important
there
to
take
from
richard.
That
you
were
mentioning
is
the
like.
Is
there
more
that
we
could
have
done
or
is
there
something
different?
We
could
have
done
to
educate
people
on
this,
and
I
guess
like
at
the
core.
For
me:
it's
like
we
add
new
features
to
lts
all
the
time
we
have
change
logs.
A
We
have
blogs,
we
discussed
it,
we
have
documentation,
we
did
get,
we
did
get
feedback
when
we
unflagged
it
about
some
of
the
documentation
around
exports
not
being
sufficient
in
describing
the
ways
that
it
could
break
and
we
wrote
extensive
documentation
to
to
help.
You
know
improve
that.
I
I
think
that.
C
A
So
it's
like
it's
one
of
the
things
that
I
struggle
with
here.
A
little
bit
is
that,
like
people,
don't
always
read
the
docs
people,
don't
read
every
single
piece
of
information
that
we
put
out
there
so
one
way
that
we've
tried
to
be
improving
this,
as
well
as
having
better
error
messages,
and
I
think
that's
honestly
one
of
the
best
ways
in
which
we
can
improve
these
things.
Oh,
do
I
need
to
promote
someone?
Apologies
hi,
darcy.
A
I
think
in
the
case
of
this
feature-
and
it
was
something
that
I
was
mentioning.
I
think
it
would
be
far
more
disruptive
to
to
bring
the
flag
back
at
this
point
than
remove
the
flag.
I
think
that
for
our
ecosystem
long
term,
having
modules
on
12
like
significantly
outweighs
the
breakages
that
folks
may
have
experienced,
but
I
think
it
would
be
naive
to
say
that,
like
you
know,
some
folks
were
like
not.
Everyone
was
enthusiastic
about
us
deciding
to
to
do
this,
but,
but
I
think
like
and
I
stand
by
it.
B
A
So
it's
like
also
finding
a
balance
there
of,
like
you
know
the
feedback
versus
the
positivity
around
it,
I
think,
is
important,
because
more
folks,
like
folks
who
are
broken,
are
more
likely
to
show
up
and
like
talk
about
what
problems
they've
run
into
than
people
who
everything's
working
fine
for,
because
you
know,
arguably,
all
of
the
other
apps
on
12
that
didn't
break
no
one's
coming
by
and
saying
hey.
You
know
it
didn't
break.
A
Yeah-
and
I
think
that
was
like
kind
of
the
key
and
to
me
to
me
the
biggest
takeaway
that
I
think
I
would
love
to
have
from
this
and
richard-
please
let
me
know
you
know
if
I,
if
you
agree
or
if
you
want
to
collaborate
on
this,
is
like,
I
think
it
would
be
good
to
follow
back
up
with
the
person
who
opened
this
issue
and
like
try
to
work
with
them
to
figure
out
like
okay.
How
could
like
are
there
things
that
we
could
have
done?
A
Can
you
can
you
enumerate
them
for
us
like
what
are
things
we
like?
How
could
we
have
done
a
better
job
of
letting
folks
know
this
stuff,
because
there's
also
like
a
point
of
diminishing
returns
in
in
communications
and
like
not
everyone
reads
everything,
so
it
would
be
good
to
really
get
to
the
bottom
of
like?
Is
there
actually
like
a
really
distinct
actionable
thing
that
we
could
have
done
differently?
Aside
from
just
like
not
adopting
this
change
altogether.
C
It
seemed
that
they
had
quite
a
strong
view
on
this,
so
just
to
make
sure
that
we
at
least
consider
an
address,
and
by
address
you
know
it
could
be,
like
you
say,
going
back
and
initiating
dialogue
as
to
you
know
what
they
think
we,
what
concrete
things
we
could
have
done
better,
not
rather
nebulous
you
know,
consider
the
risks,
because
we
did
consider
the
risks,
and
you
know
that
the
conclusion
was
that
we
felt
that
it
was
acceptable
to
to
to
go
ahead
with
the
removal
of
the
flag
removal,
so
yeah
it
yeah.
C
A
Would
you
like
to
take
the
action
item
of
following
up
with
the
with
the
person
who
opened
the
issue,
or
would
you
like
me
to
do
that?
No.
A
A
A
So
for
anyone
who's,
just
you
know,
listening
just
being
clear
like
I
think
my
bias
here
is
is
super
obvious,
but
like
with
that
bias
aside,
like
I'm
doing
my
best
to
make
sure
this
is
getting
escalated
to
the
right
people
and
folks
are
hearing
about
it
and
we're
taking
it
seriously,
and
you
know
just
because
I
may
disagree
with
something
doesn't
mean
that
it
doesn't
deserve
a
discussion.
C
About
yeah,
I
don't
think
I
was
in
the
tse
meeting
tonight.
I
do
remember
reading
the
minutes,
because
in
in
the
issue
I
did
when
when
when
it
was
mentioned
in
the
issue
that
the
the
risks
weren't
considered,
I
did
quote
both
the
release
working
group
minutes
and
the
tfc
where
it
was.
It
was
brought
to
the
attention
of
the
two
groups
that
there
was
a
risk
involved
in
unflagging
and
we
still
decided
to
go
ahead.
So
it
wasn't
that
we
didn't
consider
it.
A
A
You
know
like
the
conversation
is
aware
and
traditionally
like
what
I've
seen
end
up
happening
from
the
tfc
is
that
they
don't
really
get
too
involved
in
the
module
stuff
because,
like
it
is
turtles
all
the
way
down
to
say
it
nice,
but,
like
you
know,
one
thing
that's
worth
mentioning
is
like
we
had
the
collapse
on
it
in
december
and
whether
or
not
we
should
unflag
an
lts
was
actually
like
an
extensive
conversation
that
was
held
between
myself
and
a
number
of
tsc
members
and
release
working
group
members
beth,
I'm
not
100,
but
I
think
maybe
you
participated
in
some
of
those
conversations.
A
B
With
sure,
okay,
I
guess
we
got
an
action
on
that
one
just
to
figure
out
how
maybe
we
could
have
communicated
better
or,
if
there's
something
specific
we
could
have
done,
but
no
plans
to
revert
the
unflagging.
B
So
I
think
we
can
move
on
to
the
next
one,
which
is
in
the
node
release
repo.
It's
the
current
should
include
12
13.,
so
I
opened
the
pr
yesterday
was
it
yesterday.
I
think
it
was
yesterday
to
update
the
dates
for
node
16,
because
I
realized
we
only
had
the
dates
for
15
and
with
15
coming
out
in
a
couple
of
months.
B
We
should
probably
look
ahead
a
little
bit
further
to
arrange
the
dates,
so
I've
opened
that
pr-
and
while
I
opened
it,
I
was
looking
at
the
timings
first
realized
that
the
major
release
was
set
for
a
wednesday
instead
of
a
tuesday
which
isn't
something
we've
done
before.
So
I
changed
that
back
to
a
tuesday
and
but
we've
had
this
ongoing
kind
of
discussion
about
whether
the
transition
for
14,
so
the
even
numbered
release
should
happen
before
15
comes
out
or
the
old
numbered
release
comes
out
or
after
both
ways.
B
So
in
the
case
where
15
is
released
before
14
becomes
lts,
we
end
up
in
a
situation
where,
where
we
have
multiple
current
releases
and
if
we
do
it
the
other
way,
we
end
up
with
no
current
release.
The
reason
this
kind
of
appeared
in
the
first
place
is
because,
at
the
time
the
node.js
or
website
didn't
really
handle
this
situation.
The
small
window,
where
these
things
aren't
necessarily
in
the
order
you'd
expect
them
to
be,
and
it
wasn't
showing.
B
I
think
it
either
was
showing
the
same
version
or
was
showing
the
wrong
version
or
something
like
that.
But
we
we
fixed
that,
so
it
should
be
able
to
determine
correctly.
I
think
what
it
does
at
the
moment
is
it
hides
the
current
release
when
we
don't
have
a
current
release
but
yeah?
The
question
is:
do
we
think
it's
better
to
have
a
time
frame
where
we
have
multiple
current
releases
or
a
time
frame
where
there's
no
current.
B
B
A
So
I
guess,
if
I
had
to
pick
one,
I
think
that
having
two
currents
at
the
same
time
is
fine
truthfully.
So
like
cutting
the
current
first,
then
promoting
14
to
lts
afterwards
seems
like
a
fairly
reasonable
order
of
operations.
It
just
makes
it
like
a
little
bit
easier
to
like
wrap
your
head
around.
I
I
do.
I
do
think
that,
while
it's
good
to
be
thoughtful
and
consistent
about
the
order
that
we
do
here
like,
I
do
think
that
we
should
just
like
not
spend
too
much
time
debating
it.
A
Not
not
like
I
mean
not
that
we
don't
have
time
to
debate
it
today,
but
more
just
like
yeah.
I
think
that
it's
very
semantic
heavy
and
like
it
really
only
matters
for
a
week
and
really
only
truly
matters.
In
my
personal
opinion,
in
the
context
of
like
the
rendering
of
the
website,
I
I
think
that,
like
you
know,
the
labels
of
current
and
lts
mean
a
lot
more
to
me
about
like
what
is
the
release
strategy
of
the
thing,
and
I
don't
think
like.
A
A
If
and
I
think
the
situation
that
we
found
ourselves
in
before
that
was
weird
where
it
was
like.
We
cut
the
lts
before
we
cut
the
current
so
like
I
think
it
was
like
version
like
12.7
was
current,
but
version
12.8
was
lts
and
that
just
like
looked
weird
and
feels
weird
yep
so
like
to
avoid
that
situation,
where
the
latest
current
release
is
actually
behind
the
latest
lts
release.
B
Okay,
so
in
terms
of
the
impact
on
the
schedule,
it
does
mean
that
the
transition
for
node
14
to
active
lts,
it
will
likely
be
pushed
back
to
around
the
27th
27th
of
october,
and
the
15x
release
will
be
around
the
20th
of.
B
B
Okay
sure
I
can
update
so
the
pr
I
have
open.
I
will
update
directly
after
this
meeting
to
account
for
that,
and
now
it's
probably
a
good
time.
It
was
the
next
thing
on
our
agenda.
I
think,
to
quickly
review
the
schedules.
B
B
So
the
next
one
in
the
pipeline
is
going
to
be
by
danielle
pairing
with
me.
So
I'm
I've
just
got
an
action
there
to
reach
out
and
find
a
time
to
start
building
up.
That
release
looks
like
afterwards.
We
don't
actually
have
anyone
scheduled,
so
people
have
time
for
free,
but
what
I
will
do
is
I
will
bump
the
40
next
date
to
the
correct
new
date,
which
will
be
the
27th
of
october.
B
B
C
B
C
A
C
A
C
And
so
I'm,
okay
with
that,
as
long
as
yeah,
the
rest
of
us
are
okay,
that
that
that
six
six
of
october
release
the
one
immediately
before
that
that
will
be
the
last
sort
of
normal
current
release.
Where
changes
go
in
and
then
the
lts
release.
C
A
Yeah,
so
I
I
guess
what
I
was
going
to
say
is:
I
don't
see
those
two
things
as
mutually
like
as
mutually
exclusive,
like
specifically
that
like,
if
1027
is
when
we're
talking
about
transitioning
to
lts,
I
think
the
big
question
is
like
well.
It
is
current
before
that.
Are
we
saying
that,
like
we
specifically
want
to
have
like
a
two-week
period
where
we're
not
allowing
anything
to
land?
If
we're
not
saying
that,
then,
like
in
theory,
we
could
land
stuff
and
do
10.x
releases
up
until
the
day
before
1027.
A
If
there's
things
that
we
want
to
do
because
current
releases
don't
have
like
like
we
do
it
every
week
or
every
other
week,
just
to
kind
of
like
have
a
cadence.
That
makes
sense,
but
that's
not
actually
like
a
commitment
of
that
release
line.
We
can
do
releases
whenever
we
want
the
other
thing
that.
C
B
A
So
one
thing
that
we
could
potentially
do
with
this
and
thinking
about
it
so
like
if
1006
is
the
last
non-lts
release
and
then
what
was
the
date
for
15?
It
was
like.
A
The
20th
yeah,
so
let
me
see
here,
hold
on
so
8
11
was
yesterday
and
then
two
weeks
and
then
two
weeks.
So
if
15
comes
out
on
the
20th
that
gives
us
like,
I
guess
the
challenge
there
is.
That
creates
like
a
two
week
gap
where,
like
we
don't
have
anything
going
out
but
like
we
do
have
15
then
going
out.
A
That
could
go
out
like
a
week
after
the
the
the
27th
and
aim
to
basically
have
a
release
of
10
going
out
two
weeks
after
the
release
of
14,
but
make
that
a
like
a
simver
miner,
like
the
december
patch
release.
A
Because
that
could
minimize
like
because
I
guess
theoretically,
right
like
we
want
14
to
now
start
transitioning
and
being
lts.
That
gives
enough
time
for,
like
things
to
be
on
15
for
two
weeks
before
they
would
land
on
14
and
stops
it
from,
like.
You
know,
get
like
having
like
two
full
months
between
releases.
B
Yeah
I
do.
I
do
quite
like
the
buffer
that
that
gives
us
in
terms
of
making
the
15
release
a
bit
more
seamless,
but.
B
Let's
hop
through
so
there
was
a
12
release
plan.
There's
one
plan
for
august,
a
minor
but
we've
not
had
anyone's
the
release.
Candidate
was
due
this
week,
but
people
have
limited
time
so
we've
not
got
to
it
yet.
B
A
So
that
was
supposed
to
what
have
I
guess?
Okay,
maybe
what
we
could
do
is
our
next
release
meeting
is
in
two
weeks.
A
A
A
Yeah,
it
seems
reasonable
and
then
the
one
I
guess
the
one
thing
that's
worth
mentioning
is:
I
am
moving
that
week,
the
week
of
the
24th
so
I'll
be
able
to
make
the
release
meeting,
but
I
may
need
like
some
help
with
like
getting
this
over
the
finish
line,
so
I
can
help
like
this
week
and
next
week,
but
maybe
I
don't
know
richard,
would
you
have
bandwidth
to
like
pair
on
this
yeah.
B
A
I
think
the
amount
of
traction
that
we're
seeing
on
like
maintaining
this
branch
really
reflects
that
it's
a
good
thing.
We
made
that
change,
but
I
also
think
something
that's
rather
interesting
here
is
that,
at
least
for
me
personally,
14
is
like
one
of
the
more
exciting
new
release
lines
that
we've
had
in
a
while,
since,
like
kind
of
eight,
so
I
think
it'll
be
really
interesting.
B
C
But
yeah
he's
still
having
problems.
B
A
A
Okay,
it
would
be
better
to
just
like,
if
you're
reading
files
or
something
to
just
use
like
a
non-stream
based.
I
I
can
look
at
the
code
again,
I
think,
like
I
looked
and
gave
a
review
and
there's
like
like
when
you
return
the
the
function
will
will
like
shut
down.
So
you
need
to
make
sure
that,
like
all
your
work
is
done
before
you
like
return.
B
Oh
yeah,
we
managed
to
get
past
that
point.
Okay,
it's
now
it
now
runs.
It
generates
the
file,
so
the
stream
seems
like
the
whole
stream
transforms
and
stuff
seem
to
be
working.
Absolutely
fine.
It's
just
after
an
undetermined
amount
of
time.
Things
will
start
to
error
and
it's
hard
for
us
to
even
diagnose
what
part
of
the
stream
was
broken.
B
A
Yeah,
it
might-
and
I
maybe
we
can
just
have
a
pairing
session
here,
and
I
can
also
try
to
grab
someone
from
the
google
team.
It
might
make
sense
to
maybe
move
this
service
either
to
app
engine
or
to
cloud
run,
and
I
believe
cloud
run
can
subscribe
to
the
same
events.
A
I
could
be
mistaken,
but
at
the
very
least,
there's
like
a
pub
sub
thing
that
we
could
set
up
like
so
you
could
have
the
function
just
serve
as
like
a
proxy
for
kicking
off
a
pub
sub,
and
the
pub
sub
could
then
trigger
a
different
job.
But
cloud
run
has
a
lot
more
granularity
as
far
as
like
controlling
the
life
cycle,
the
size
of
the
job.
A
A
B
Cool
yep
I
will
yeah
I'll
reach
out
to
that,
sounds
really
good
and
we
can
help
out
with
the
build
team
and
try
and
get
that
because
it
will
in
turn,
help
us
get
some
insights
into
the
release
lines.
B
B
And
let
me
hop
back
to
we've
reviewed
the
schedules.
I
guess
the
last
thing
is:
is
there
anything
anyone
would
like
to
add
or
announce
regarding
the
npm
7
beta.
D
I
don't
think
at
this
time,
there's
anything
to
really
add
other
than
we're.
Looking
for
feedback
and
usage
over
the
next
about
two
three
weeks
for
sure,
we
still
have
a
lot
of
work
to
do
to
essentially
get
our
test
coverage
up.
So
that'll
give
us
a
bit
more
sanity
before
we
land
this,
so
still
a
lot
of
work
on
our
end.
To
do.
A
Yeah
one
thing
that
I
would
add
that
I
think
is
like
good
to
know
is,
like
we've
been
starting
to
use
sitkim
and
the
node
infrastructure
to
test
the
integration
of
this
version
of
npm
in
with
node
14.
and
we're
finding
all
sorts
of
fun
bugs
like
one
does
with
canary
in
the
gold
mine.
A
Although
we
are
getting
some
good
insight
into
like
which
tools
or
which
workflows
would
be
broken
by
this
and
we're
slowly
kind
of
chipping
away
at
the
odd
bugs
that
we're
finding
and
I'm
pretty
confident
that
in
a
short
order,
you
know
things
will
be
in
a
place
where,
where
we
can
start
thinking
about
what
general
availability
looks
like
and
promoting
this
out
of
beta,
I
think
there's
just
a
little
bit
more
work
that
we
want
to
do
before.
We
open
a
pull
request
to
bring
this
into
master.
A
Just
to
make
sure
like
that,
you
know
we
have
like
a
baseline
of
stability,
but
we're
getting
close,
which
is
exciting.
D
B
No
okay!
Well,
if
it
does
not,
I
guess
thanks
for
joining
everyone
and
speak
to
you
all
a
bit
later.