►
From YouTube: Node.js Release Working Group Meeting - 16 July 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
B
A
Awesome
Oh
sad
later
just
kind
of
announced
that
we've
got
three
new
collaborators
on
boarded
sedan,
no
projects
all
based
on
their
involvement
in
the
release
working
group.
So
we
welcome
Rory,
Danielle
and
Stuart
and
with
the
view
that,
hopefully
they
can
start
preparing
releases
and
get
more
involved
with
the
release
team.
Now
they
have
access
to
DC.
A
If
that
no
more
announcements
move
on
to
the
first
item
on
the
agenda,
which
is
to
basically
go
through
each
of
our
release,
plans
for
the
three
release
lines
so
for
node,
14
I,
know
Maya's,
you
just
kind
of
mentioned
the
one
that's
due
out
today
and
we're
scheduled
up
until
the
end
of
August,
and
that
includes
some
paired
releases.
Two
on
border
new
releases.
A
B
I
guess
I
guess
one
thing
I
can
offer
is
like
I
will
be
working
on
the
last
bits
of
getting
the
release
out
this
afternoon.
So
if
anyone
would
like
to
pair
with
me
on
that
feel
free
to
reach
out
on
diem
or
like
just
in
the
chat
here,
if
you
want
me
to
send
you
a
calendar
invites
so
we
could
do
it
together.
C
A
Guess,
Richard
you're
the
apartment
spirit
as
well.
You'll
probably
need
to
find
a
current
release
because
I
know
you've
already
prepared
10x
as
your
kind
of
paired
release,
but
the
first
release
I
think
we've
still
got
enrolled
at
the
first
release
we
have
to
do
is
a
current
to
get
the
GPT
he
kind
of
propagated.
B
Through
for
what
it's
worth,
I
would
say
that,
like
I'm
personally
comfortable
with
changing
that
to
saying
any
release,
if
anything
doing
an
LTS
releases,
more
work
than
a
current
release
and
I
think
it
would
be
silly
to
have
to
wait
longer.
I
think
the
pragmatic
thing
to
do
here
would
to
just
be
augment
the
the
governance
there.
Instead
of
making
making
Richard
do
another
release.
C
Sure,
okay
is
the
rule
about
that
about,
promoting
or
preparing
or
both
promote,
current
or
like
a
criminal
eats
before
LTS
release,
promote.
B
B
A
But
I
think
we've
even
got
the
governments
in
our
governance
stock
that
I
could
probably
open.
We
have
to
start
peering
to
like
the
keys
to
the
node
readme
and
they
need
to
be
there
a
couple
of
weeks
first
so,
depending
when
all
of
that
happens
and
we'll
determine
when
you
can
promote
your
first
release.
I
think
yes,.
D
In
that
which
there's
after
often
nominees
first
prepared
release
has
been
promoted.
So
for
me,
that
will
be
after
the
next
ten
release
goes
out
next
week
and
there's
all
those
steps
there
are,
that
being
added
to
various
teams
and
getting
the
GPG
key
into
the
readme
and
then
at
least
two.
It
says
they're
at
least
two
weeks
after
that,
before
you're
eligible
to
promote
your
own
release.
I
guess
that's
just
to
allow
the
key
to
propagate
sure.
E
D
B
D
C
A
Awesome
I
think
that
10
and
12
are
both
due
to
count
on
the
same
day,
which
is
nice.
Nice
timing,
which
is
good
and
I,
think
both
will
contain
the
NPM
update,
I'd,
leave
school
and
say
yeah
and
maybe
need
source
volunteers
for
the
August
OTS
release.
I
may
have
some
capacity
to
work
on
that
one.
So
me
drop
myself
down,
but
if
any
of
our
newer
releases
wants
to
pick
that
up
again,
that
could
be
a
paired
process.
A
And
for
no
ten,
no
tenants
now
in
maintenance!
So
don't
know
if
you
want
to
leave
this
issue
open
or
not
I
kind
of
think
having
here
so
people
having
a
venue
where
they
can
say:
hey
I'd
like
a
new
10
release,
because
I'm
being
blocked
by
this
bug
or
something
it
might
be
quite
nice
to
leave
it
open.
A
D
Think
there
were
still
quite
a
few
piles
where
we
that
the
backers
were
requested
for
ten.
So
if
they
don't
happen,
then
there's
nothing
to
release,
but
if
anyone
does
feel
strongly
about
ones
that
have
back
bought,
requested
and
actually
baffle
them,
then
they'll.
You
know
there
might
be
more
stuff
in
the
future
to
do
to
ten
releases.
A
Okay,
so
that's
it
for
our
release.
Plans
we're
looking
looking
good
for
the
next
couple
of
months
and
I
think.
Does
it
make
sense
to
talk
about
MT
m7
now,
we'll
continue
about
the
release.
Timings
probably
makes
sense
to
us
what
those
and
so
for
note
14
mama.
She
mentioned
the
VA
up.
There's
a
v8
update
jus
at
the
start
of
October
or
mid-october,
or
something
a
remnant,
I
believe.
B
It's
some
point
in
October.
To
be
frank,
I'd
have
to
go
through
and
review
what
the
release
timing
is.
I
think
this
is
probably
something
good
to
check
with
liked
Argos
and
the
team
that's
maintaining
v8
in
for
right
now,
as
well,
because
we're
getting
a
8.4
on
14
today,
which
is
great
and
I,
think
you
know
the
hope
would
be
that
we
can
continue
to
update.
B
We
also
in
the
past
have
landed
like
pre-releases
like,
like
v8,
has
the
time
words
in
beta
before
it
gets
promoted
to
stable,
and
we
have
in
the
past,
like
for
LTS
purposes
like
landed,
that
beta
version,
that's
like
a
really
really
late,
beta
and
just
like,
landed
the
patches
to
put
it
to
the
stable
version
in
like
the
first
couple
like
in
the
first
LTS
release
afterwards.
So
we
have
a
couple
different
options
about
how
we
can
handle
it.
B
Turbofan
ignition,
so
this
was
like
a
number
of
years
ago,
maybe
like
three
years
ago,
where
we
were
creative
I.
Think
like
one
of
the
biggest
things
selfishly
I
care
about
and
I
have
a
big
bias
is
stable.
Top-Level
await,
I,
don't
think,
there's
huge
changes
happening
in
v8,
but
I
think
like
it
should
be
targeting
one
of
the
upcoming
v8
releases.
I.
Think
another
thing
too,
is
to
just
maybe
go
through
and
figure
out
like
hey:
can
it
be
a
VI
compatible
B?
D
B
D
I'm
wondering
what
the
delay
would
be,
what
yeah?
What
would
the
justification
for
the
delay
be
because
one
of
the
things
has
always
been
complaints
about
our
dates
and
the
fact
that
people
don't
get
adequate
warning
updates,
so
I'm
not
versed
in
moving
it,
but
I
have
a
good
reason
to
do
it.
I
guess.
B
B
A
B
I
guess
one
more
thing
to
add
Richard
to
the
point
that
you
made
about
like
the
change
in
timing
like
it's
totally
valid,
and
it
has
really
annoyed
people
in
the
past.
I
think
one
of
the
important
bits
here
is
like
we're
in
July
right
now
and
that's
why
it's
like
now
is
the
right
time
to
be
talking
about
this
and
getting
people
like
many
months
of
the
heads
up,
which
is
why
I'm
bringing
it
up
now
just
so,
we
can
not
be
changing
it.
You
know
last-minute
for
folks.
Yes,.
A
E
E
If
we
were
to
go
with
the
ideal
strategy
from
NPM
side,
which
would
be
just
to
land,
seven
in
as
many
you
know,
healthiest
versions
as
possible
with
the
breaking
change
that
that
is
sort
of
personally
and
selfishly
the
strategy.
That
would
be
easiest
for
us
to
maintain
and
may
you
know,
may
actually
be
okay
with
the
community.
But
we
definitely
want
to
be
be
mindful
here
and
offer
up
other
other
source
strategies
to
go
forward.
And
if
that
means
maintaining
two
separate
releases
to
ensure
that
we
aren't
super
disruptive
and
that's
also
a
possibility.
B
Think
I
think
one
thing
to
point
out
is
like
we're
collecting
a
list
of
all
of
the
breaking
changes
and
right
now,
at
least
to
me
like
there's
like
some
changes
to
like
workflows,
but
the
biggest
kind
of
change
that
I
think
would
be
viewed
as
breaking
for
folks
is
the
one
related
to
pure
dependencies.
So
I
think
that
it
would
be
good
to
have
a
conversation
like
at
a
high
level.
B
So
I
think,
like
a
big
question
to
the
release
team,
although
this
may
actually
be
maybe
a
broader
question
to
the
TOC
or
node
core
would
be
you
what
level
over
a
liability
would
we
be
expecting
for
NPM
on
these
different
release
lines
and
what
would
be
considered
like
acceptable
changes
here?
As
far
as
the
output
is
concerned,
so
I'd
be
curious.
If
folks
had
opinions
there.
F
There's
one
more
one
more
of
the
breaking
changes
that
I
would
probably
put
side
by
side
with
peer
dependencies,
which
is
the
change
to
life
cycle
scripts
environment
variables,
like
there's
a
bunch
of
environment
variables.
There
change
they're
not
going
to
be
there
anymore,
so
I
think
that
one.
We
should
also
keep
a
close
eye
on
it
because
it
might
has
a
potential
to
be
disrupting
the
ecosystem,
so
I
will
bring
the
two
of
them
peer
dependencies
and
life
cycles.
Quick
changes,
I.
A
D
A
I
was
just
gonna
say,
guess
my
gut
is
that
we
might.
We
won't
know
what
to
what
will
be
acceptable
in
ten
or
twelve
until
we
get
some
kind
of
use
of
feedback
from
maybe
it
landing
in
14
or
15,
or
something
like
that,
so
it's
going
to
tell
I
imagine
this
is
the
update
in
10
and
12
is
gonna
tell
behind
by
a
couple
of
months
anyway,
just
power
our
process
is
that
the
expectation
I
mean.
B
F
B
Acceptable
in
those
versions
or
not,
and
that's
why
we're
potentially
looking
at
a
strategy
where
we
separate
some
of
those
more
breaking
changes
from
the
reliability
changes
to
make
it
easier
to
get
on
to
LTS.
But
I
guess
a
question
for
folks
like
12
is
going
into
maintenance
in
October
and
10
is
already
in
maintenance.
So
I
don't
think
we
were
ever
talking
about
targeting
10
with
these
changes,
but
I
think
that
we
would
be
looking
at
trying
to
get
it
into
12
prior
to
12
going
into
maintenance.
D
What
I
was
gonna
say
was
and
obviously
not
being
familiar
with
the
changes
that
are
coming,
but
I
do
know
that
we've
been
broken
in
the
past
when
I
think
with
no
GUI.
He
changed
location
on
disk
during
a
in
one
of
the
empty
inversions
and
that
broke
a
lot.
The
ecosystem,
which
was
assuming
that
was
in
a
specific
path.
D
D
B
One
strategy
we
talked
about
today,
and
it
doesn't
mean
that
we'll
do
this
was
also
maybe
cutting
both
a
seven
and
an
eight,
where
the
only
difference
between
seven
and
eight
would
be
flipping
the
bit
on
on
that
specific
change,
and
then
that
would
allow
us
to
land
seven
on
all
the
LTS
releases
and
then
land
eight
on
fifteen
with
that
change.
So
we
could
have
it
out
for
a
little
bit
and
then,
assuming
that
that
change
is
like
non-disruptive.
D
E
D
I'd
be
happy
to
revisit
whatever
decision
we
make
in
terms
of
if
we
actually
had
concrete
data
after
about
a
month
of
it
being
out
in
the
world.
You
know
if
it
was
a
month
and
people
said:
oh,
it's
not
too
bad.
You
know
when
I
go
with
it,
then
maybe
there
wouldn't
be
an
issue
with
just
dropping
it
back
into
twelve.
D
B
Yeah
I
think
this
becomes
like
one
of
those
interesting
questions
about
like
what
does
stability
mean
across
the
release
lines
because
there's
one
way
of
viewing
it
where,
like
stability
is
hey,
it
doesn't
change
from
the
way
it
worked
before,
but
the
other
is
like
hey.
It
works
consistently
across
release
lines,
and
so
I
like
I,
think
a
great
example.
B
That
would
be
something
like
napi,
although
an
API
is
arguably
like
always
like
forward
and
backwards
compatible,
but
we
are
like
doing
updates
to
napi,
even
in
maintenance,
because,
like
keeping
that
up
to
date
is
considered,
you
know
more
stable
from
an
ecosystem
perspective.
So
if
modules
are
being
released
and
are
expecting
this
new,
like
pure
dependency
resolution
strategy,
like
the
flip
side,
is
there's
actually
risk
to
the
older
versions
of
node,
not
respecting
that
and
the
modules
not
landing
in
a
way,
that's
expected,
and
then
you
know
dropping
support
for
older
versions.
B
D
B
D
If
you
could
toggle
it
in
seven
in
that
you
would
get
the
eight
behavior
by
adding
a
flag,
then
we
would
provide
a
mechanism
to
cope
with
the
scenario
where
some
more
dual
is
updated
to
be.
You
know
to
work
with
the
new,
whatever
changes,
but
it
we
find
it
breaks
in
twelve,
but
hey
you
can
click
this
flag
and
you
know
until
we
back
pull
over
you'll
still
be
able
to
to
work.
B
I
do
think,
though,
and
like
I
mean
perhaps
folks
have
have
a
different
opinion
that
the
breaking
changes
to
things
in
the
life
cycle,
especially
if
we're
talking
about
like
environment
variables
and
looking
at
environment
variables
well,
obviously
like
not
the
best
for
users
does
strike
me
as
the
kind
of
thing
that,
at
least,
if,
for
example,
we
could
land
this
in
14.
Well,
it's
still
current
and
it's
not
LTS.
Yet
is
a
little
bit
less
of
a
concern
to
me
personally
than
the
trees.
As
far
as
stability
is
concerned,
yeah.
F
Icon,
yeah,
yeah,
yeah
I,
don't
think
like
it
just
daddy.
It
is
quite
risky
like
because
it's
just
like
this
septal
detail
that
people
rely
on,
so
we
just
have
to
be
mindful
about
it
and
I
think
to
the
same
level
as
a
peer
dependence
is
because
people
are
using
scripts
for
everything.
So
if
you
write
them,
it
can
be
quite
disruptive.
D
The
other
thing
from
my
point
of
view
is:
if
you're
on
12,
you
could
always
install
NPM.
You
know
to
the
NPM
gee
install
NPM
to
upgrade
to
whatever
the
latest
is
at
that
time.
It
just
means
that
the
out-of-the-box
NPM,
if
we
don't
change
it
immediately,
will
be
the
behavior
you
know
we
would
guarantee
is
still
the
same,
because
we
haven't
changed
the
version
of
NPM.
D
So
you
know
if
we
find
that
the
more
the
ecosystem
shifts
to
the
new
behaviors
it,
we
can
still
direct
people
to
install
newer
versions
of
NPM
on
the
LTS
lines,
I'm,
not
sure
how
that
works
going
backwards.
So
if
you
forgot
that
we
put
NPM
by
8
or
7
into
LTS
and
then
find
that
that
doesn't
work
for
the
ecosystem,
how
easy
it
would
be
didn't
should've,
NPM,
install
backup,
you
know
an
earlier
level
version
of
NPM
to
restore
the
old
behavior
I'm,
just
talking
in
terms
of
mitigation.
F
B
We
think
that's
a
rough
estimate
but
like
when
looking
at
the
usage
of
the
latest
version
of
NPM
a
little
bit
ago,
it
was
about,
like
I,
think
5
to
6
percent,
and
it
was
absolutely
correlated
with
like
what
percentage
of
users
are
using
the
latest
version
of
14
and
so
I.
Don't
think
there
are
too
many
people
actively
doing
that.
No.
D
E
D
D
D
E
Mean
I
think
from
our
standpoint,
what
we
can
offer
is
where
we're
working
towards
aggressively
working
towards
getting
that
beta
and
that
all
that
will
help
with
us.
This
discussion
for
sure
so
expect
that
in
the
next
couple
weeks,
also
from
our
team,
specifically
I,
think
myself
and
potentially
cloudy
I
have
on
our
radar
next
Tuesday's
I
think
it's
next
Tuesday's
training
session
for
the
release
working
group
I've
been
coming
to
these
meetings
and
haven't
participated
in
a
more
substantial
way.
A
D
Think
the
only
other
thing
I'd
say
about
the
NPM
issue
is:
if
we
don't
already
have
long,
we
should
open
an
issue
somewhere
either
on
release
or
in
call
just
not
talking
about
this
doesn't
have
to
get
into
technical
things,
but
it
might
be
worth
just
I
mean
it
didn't
have
to
be
right
now.
Maybe
it
could
be
near
with
big
beta,
but
it's
somewhere
to
collect
all
the
information.
I
guess.
E
B
B
You
know
next
round
of
feedback
back
to
the
team,
just
to
kind
of
like
gut-check
what
we
were
thinking
about
doing
and
what
we've
been
discussing
and
like
kind
of
put
together
like
the
more
exact
kind
of
outline
of
like
what
those
breaking
changes
are,
what
we
think
the
issues
could
be,
what
strategies
were
thinking
about
as
far
as
like
how
we
could
land
it
or
how
we
could
alleviate
some
of
these
concerns.
That
folks
would
have,
and
maybe
like
a
more
robust
release
plan,
and
we
could
then
either
open
an
issue.
B
D
A
B
A
A
Cool
okay,
so
I'm,
probably
just
a
real
story,
is
really
good
to
have
some
new
faces
and
the
release
team
getting
up
to
scratch,
with
helping
out
with
getting
releases
out
and
shipping
them
out
and
feel
free.
If
anyone
else
knows
anyone,
that's
interested
to
point
them
to
the
this
session,
that
happens
on
Tuesday,
Sydney,
nodejs,
all
calendar
and
if
they
want
to
follow
our
process,
if
there's
nothing
else,
I
read
in
a
cool
head
and
say
thanks
everyone
and
speech
you
or
later.