►
From YouTube: Node.js Release Working Group Meeting - 2020-12-03
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
Nope,
okay,
so
I'll
go
ahead
and
share
my
screen
as
the
first
items
on
the
agenda
are
to
go
through
the
schedules
for
our
various
release
lines,
so
I
hope
open
up
those
now.
B
A
Cool
okay,
so
for
node
15
we
are
scheduled
up
until
the
new
year,
so
probably
all
good.
There.
A
We'll
check
we
haven't,
got
any
extra
participants
nope,
okay.
I
don't
think
we
need
to
plan
further
ahead
than
that
any
thoughts
I
don't
know
if
we
do
need.
A
Really
nope,
okay,
node
14.
This
is
one
where
I
think,
just
by
the
nature
of
having
a
security
release
last
time
and
then
having
the
lts
transition
release.
I
think
it's
been
about
six,
maybe
at
least
six
weeks
since
we've
had
like
a
feature
for
rizzy
or
a
patch
release
of
14
like
a
generic
patch
released,
it's
not
security
related.
A
So
I
am
hopeful.
I've
signed
my
name
up,
I'm
hopeful
to
get
one
out
in
december
sometime.
My
aim
would
be
to
try
and
get
a
proposal
up
this
week
and
then
maybe
we
can
agree
on
timings
after
that,
but
I
do
think
it
would
be
good
to
get
one
out
kind
of
this
side
of
the
holidays.
B
A
Plus
weeks
and
it
seems
like
the
trade-off
of
how
much
disruption
we
would
cause
by
doing
a
release
kind
of
a
few
days
before
the
holidays
and
making
people
wait
longer
versus
just
getting
out
when
we
can
aim
for
as
long
as
baking
period
as
we
can
reasonably
fit
into
the
time
we've
got
seems
it
seems
like
a
reasonable
trade-off.
This
time.
For
me,
but
fair
enough,
you'll
agree.
A
A
A
Yeah
yeah,
just
because
it
seems
like
for
a
minor,
we
probably
would
want
a
bit
more
time
so
yeah,
it's
fairly
in
the
most
reasonable,
so
I'll
just
see
where
I
can
get
to
hopefully
aim
us
by
the
end
of
this
week
to
have
it
open
and
then
we'll
decide
whether
to
do
next
week
or
the
following
week.
Probably
the
following
week,
tuesday.
B
A
So
I
I
landed
that
matteo's
used
internal
streams
pr
yesterday,
after
getting
a
green
ci
branch
and
there
there
are
some
subsequent
back
ports
that
what
prior
to
that
also
touching
streams.
So
I
need
to
go
in
and
figure
out
whether
I
can
just
cherry
pick.
The
15x
ask
the
person
to
patch
the
okay.
So
that's
the
that's
the
kind
of
hold
up
at
the
moment
before
I
can
run
branch
diff,
but
I
think
we'll
be
in
a
good
state
and
I'll
just
try
to
get
it.
A
Then
we've
got
a
minor
scheduled
for
january
january.
5Th
seems
ambitious,
but
I
guess
we'll
leave
it
there
if
we
have
to
push
it
out
by
week
or
so
so
be
it.
B
A
B
It
is,
was
it
you,
somebody
asked
about
whether
we
should
split
this
table
or
reorder
this
table.
A
I
did
it
for
14,
so
maybe
we
should
do
it
do
a
similar
thing.
I
like
hid
all
the
current
ones
under
a
twisty
just
because
made
it
easier
to
read
for
me.
B
Because
I
think
I
can't
remember
what
column
I
did.
I
added
a
column
to
this,
but
I
can't
remember
which
one,
what
was
it?
Maybe
it
was
14.
A
A
B
B
I
suppose
the
only
the
only
thing
is
we
don't
have
anyone
from
npm.
Here
there
was
a
point
patch
release
of
npm,
I'm
I'm
guessing
since
they
haven't
tried
to
pr
into
nodes
directly
that
it's
probably
not
urgent,
but
some
of
the
dependency
updates
did
mention
security
issues.
So
I'm
guessing
there's
a
possibility.
There
might
be
audit
warnings
or
something.
B
B
See,
I
don't
believe
I
don't
believe,
there's
anything
outstanding
that
anyone's
pushing
for
for
ten.
A
B
A
B
A
A
So
I
see
miles
has
just
added
there's
a
bunch
of
people
in
the
binary
summit.
I
I
think
it's
worth
starting
the
discussion
because
I
don't
think
we're
gonna
assault
like
it's
gonna,
be
a
long
running
thing.
So
if
we
can
start
it
and
maybe
get
some
action
items
kind
of
around
what
data
we
could
collect
as
danielle
mentioned
it's
worth,
starting
to
dig
into
that,
I
think
so
I
can.
I
guess
I
can
have
a
go
at
introducing
this
james
opened
a
proposal
to
revamp
the
lts
schedule.
A
It
talks
about
the
overlapping
releases
and
having
like
at
the
moment,
we
have
four
release
lines
to
maintain
and
when
you
encounter
security
issues
or
issues
across
all
release
lines,
and
it
can
be
quite
difficult
to
patch
those,
especially
where
things
the
same
patch
might
not
apply
to
all
of
the
release
lines,
and
he
he
gave
a
couple
of
approaches.
A
B
Yeah
somebody
here
there
we
are
12
12
months
of
active
support,
18
months
of
maintenance,
the
other
way
around
in
12
and
earlier
but
yeah.
At
the
moment.
It's
12.
12
months
of
active
maintenance
and
18
maintenance
and
james
was
proposing
drastically
cutting
maintenance
down
from
18
to
6.,
so
that's
losing
losing
the
entire
year
of
support.
A
So
if
we
looked
at
that
in
the
context
of
say,
node
12
node
12
would
be
end
of
life
in
april.
B
Given
that
we've
only
just
put
14
into
lts
yeah,
so
that
would
only
give
you
what
six
six
months
to
make
the
transition,
which
is.
A
One
thing
that'd
be
useful
when
I
know
we're
working
on
it
with
ash
is
getting
the
download
stats
and
trying
to
see
what
the
uptake
on
14
is
as
a
proportion
of
the
overall
downloads
at
the
moment,
just
to
try
and
see
whether
is
it
still
lingering
behind
12
in
terms
of
share,
or
is
it
surpassed
that
within
six
months?
That
would
be
interesting?
It
might
help
make
the
call.
A
It
might
be
worth
asking
daniel
you
mentioned
about
numbers,
and
you
could
get
some
your
side.
C
Yeah,
so
I
can
get
pull
numbers
from
heroku.
We
do
lock
the
version
on
our
build
packs,
at
whatever
the
I
guess.
The
active
lts
is
right.
Now
I
still
have
it
locked
at
12..
Just
I
think
that
was
it
just
this
week
that
14
became
active
lts,
I
don't
know
but
yeah,
so
it's
still
12
it'll
be
14.
C
Eventually,
I
think
I'd
like
to
pull
those
numbers
before
I
switch
it
to
14,
just
to
see
like
who,
just
from
the
builds
that
we're
running,
who
like
how
many
of
those
actually
switch
to
14.
That
means
that
they're
just
using
the
default
version
because
there's
different
ways
that
people
are
using
heroku,
you
know
spaces,
they're,
they're
running
builds
as
well
as
running
web
servers.
So
there's
like
those
factors
to
consider,
but
yeah
we
have.
I
can
pull
some
numbers
as
to
like
what
people
are
doing.
C
We
don't
have
a
lot
of
we
don't
have.
I
would
say
that
there
aren't
a
lot
of
people
that
are
using
deprecated
versions,
but
I
definitely
see
them
more
often
than
you
would
think.
That's
mostly
because
you
can
just
deploy
code
to
heroku
and
then
let
it
run
there
forever
and
never
touch
it
again
and
it'll
just
that
specific
version
of
the
application
that
will
just
run
forever.
So
there's
not
a
huge
advantage.
I
mean,
from
the
their
perspective,
to
upgrade.
A
Okay,
she'll
say
the
numbers
you,
you
could
potentially
pull
the
number
of
people
using
each
kind
of
version
as
a
proportion,
yeah,
okay,.
A
A
B
B
So
if
we
can
typically
patch
for
so,
for
example,
right
now,
if
we
can
patch
node
10,
node
12
is
somewhere
between
10
and
mar,
and
current
so
12
would
not
be
so
difficult
to
maintain
if
we
had
a
patch
for
10
or
a
patchwork
and
the
patch
were
current,
12
will
be
somewhere
in
the
middle,
and
I
don't
see
that
some
of
these
approach
that
the
second
approach
we're
always
going
to
have
the
oldest
release.
B
A
B
So
yeah
for
this.
For
this
second
option.
Yes,
we
would
have
less
release
lines
to
support,
but
we
would
still
have
the
problem
that
we
would
still
be
supporting
something.
That's
you
know
up
to
30
months
or
not
not
quite
maybe
29
months
old,
depending
on
where
it
is
in
its
life
cycle
and
the
gap
between
that
and
the
current,
which
is
the
technical
problem.
A
And
and
we're
gonna
have
a
gap
of
what
three
potentially
three
or
more
majors
yes.
So
I
would.
I
would
maybe
even
think
that
keeping
that
major
in
between
so
if
I'm
12
up
to
date
might
help,
because
you
know
right,
granular
path
between
the
code
bases,
rather
than
a
massive
jump
between
them
and
and
then
in
the
context
of
companies
like
enterprise
companies
that
tend
to
just
hop
from
lts
to
lts.
A
I
think
that
would
make
their
they're
going
to
have
a
bigger
jump
and
for
now
we
kind
of
say,
hey,
it'd,
be
a
good
idea
to
test
against
the
odd
versions
of
node
in
between
just
to
like
test
your
migration
path,
but
saying
to
someone,
oh
you're,
going
to
have
to
taste
these
two
versions
in
between
the
next
lts
for
your
migration
path.
I
don't
know
who
would
who
would
go
to
that
expense?
A
B
At
least
from
what
I've
seen,
there's
quite
a
few
companies
out
there
that
only
migrate
when
they
absolutely
have
to
so,
although
we
have
recommended
testing
on
current
in
in
the
meantime,
I
I
still
see
a
lot
of.
B
A
Yeah,
I
guess
I
was
quickly
skipping
through
option
option.
Three
was
a
radical
move
away
from
the
current
release
model,
which
was
we
have
a
canary
track
which
has
all
changes
landing
in
the
main
dev
branch,
with
a
release.
Every
few
weeks
fast
track
stable
and
selected
experimental
changes
graduating
within
a
month
after
a
month
a
slow
track
verified,
stable
changes.
B
A
B
I
think
part
of
the
problem
we've
had
over
the
last
year,
but
maybe
a
bit
more
than
that
was,
is
that
one
of
the
reasons
we
expanded
the
pool
of
releases
was
that
we
were
finding
it
difficult
to
schedule
releases,
which
meant
that
releases
started
slipping
and
it
meant
that
the
technical
debt
for
each
release
got
bigger
and
bigger,
which
made
it
harder
then
to
do
those
releases,
because
it
just
meant
more
things
to
shift
through
in
terms
of
evaluating
the
back
ports
and
content.
A
B
A
And
security
releases
will
apply
to
those
as
well
the
one,
the
one.
So
when
I
look
at
these
three
options
on
the
surface,
the
one
to
me
that
I
would
I
would
prefer,
if
I
had
to
choose
between
them,
would
be
two
only
because
when
explaining
the
node.js
release
cycle
people,
it's
not
easy
as
it
is,
it's
not
it's
not
100
clear,
but
at
least
like
the
odd
even
is
I
I
think
that's
the
closest
thing
to
having
something
we
can
reasonably
explain
like
saying.
A
Oh
every
other,
even
release
is
lts
in
a
sentence
just
to
help
people.
I
think
the
other
two
would
make
explaining
what
we
do
a
lot
more
complex
and
therefore
people
would
struggle
to
understand
what
to
use
when
a
little
bit
more.
But
even
so
I
don't
follow
you.
A
B
Yeah,
because
all
this
says
is
there's
an
ongoing
maintenance
burden,
especially
when
we
encounter
security
issues,
but
you
know
from
what
I've
seen
it's
not
been
the
number
of
branches
we
have,
but
the
actual
technical
difficulty
of
taking
something
from
current
and
taking
it
as
far
back
as
then.
B
But
maybe
you
know,
maybe
james
has
some
other
ideas,
but
definitely
as
far
as
I
can
see,
I
don't
see
the
problem
he's
stating
telling
up
with
the
solutions
being
proposed
and
the
other
data
point
I've
had
is
that
you
know
we
do
have
an
established
lts
policy,
but
I
am
aware
that
there's
quite
a
few
enterprise
products
and
things
that
use
node,
where
the
feeling
is
that
our
current
lts
periods
are
actually
shorter
than
they
would
like.
B
A
B
For
14.,
so
12
was
18
months,
followed
by
12
and
then
14
is
12
months,
followed
by
18.
I
think,
or
is
it
not
12
12?
Sorry
12
was
the
first
that
was
12
months,
followed
by
18.,
so
yeah.
A
I
guess
it
would
be
to
keep
an
eye
on
whether
that
makes
security
patches
or
other
patches
even
more
difficult,
because
I
think
that
was
that
could
happen
potentially,
if
we're
not
regularly
pulling
back
patches
because
the
delta
could
get
larger.
So
it
is
something
to
keep
an
eye
on
but
yeah.
I
I
feel
like
from
this
discussion
kind
of
introducing
it
and
the
takeaways
I
would
have
is:
let's
try
and
figure
out
the
problem
statement
a
bit
more
and
also
try
and
get
data
of
usage
across
versions
as
they
are
today.
A
B
And
I
don't
I
don't
know
if
there
is
a
particular
difference
between
the
regular
releases
that
we're
doing
and
the
security
releases
which
are
unique
in
that
there's.
A
much
smaller
pool
of
people
that
look
at
security
releases
for
obvious
sort
of
confidentiality
reasons,
and
maybe
part
of
the
problem
is
the
availability
of
people
to
actually
look
at
them.
Those
issues
you
know
being
more
restricted
right.
So
again,
this
comes
back
to
the.
What
is
the
actual
problem?
That's
trying
to
be
solved
here.
A
C
A
B
Yep
agreed
and
10
is
only
until
april,
so
after
april
it's
gone
so
it
may
be
a
very
short-term
problem
that
just.
A
B
A
B
So
my
my
position
would
be,
I
would
not
want
to
make
any
changes
to
the
existing
releases
that
are
out
there
at
the
moment.
I
am
open
to
trialing
a
different
approach
for
node
16,
but
I
don't
want
to
do
that
just
because
I
would
like
that
to
be
a
you
know.
We
have
reasonable
confidence
that
we
know
why
we've
made
some
changes
for
16..
This
is
why,
rather
than
some
speculative.
B
Adjustment
because
I'm
not
opposed
to
moving
the
plans
around,
but
we
have
tried
to
have
plans
and
I
don't
think
we've
really
kept
to
any
of
them.
We
probably
have,
but
we
you
know-
we've
been
filling
around
with
sort
of
maintenance
periods
and
pushing
putting
out
dates
and
things.
So
it
would
be
good
if
we
only
did
that
in
exceptional
circumstances
and
not
as
the
norm.
C
I
guess
different
release
plans,
maybe
probably
other
javascript
project
like
angular
or
ember,
because
you
have,
you
probably
have
some
of
the
same
users,
there's
probably
an
overlap
there,
but
it
may
be
seeing
like
how
you
know
how
quickly
they
see
people
actually
adapting
to
the
upgrades
or
if
they,
their
user
bases,
say.
Oh,
this
is
too
fast,
or
this
is
too
slow
or
whatever
I
don't.
I
think
this
is
kind
of
missing.
Also
from
that
proposal
is
some
examples
to
draw
from,
because
we
could
also
get
data
from
that
as
well.
A
Yeah
definitely-
and
we
should-
we
should
bear
some
of
these
projects
in
mind
as
well,
while
making
this
decision,
because
their
hands
may
be
tied
by
the
decisions
we
make
with
our
lts
policy
right.
B
And
one
thing
about
that
second
option
about
only
having
every
other
release
effectively
being
lts
is
that
would
probably
be
not
suited
to
those
people
that
want
to
try
newer,
javascript
features,
but
only
want
to
do
it
in
an
lts
release.
So,
for
example,
we
had
all
that
stuff
with
the
es
modules
and
the
reason
that
was
backported
to
12
was.
B
The
argument
was
that
there
was
the
argument
was
to
try
and
get
a
greater
adoption
amongst
people
in
an
lts
release,
rather
than
limited
limiting
it
to
current
at
the
time,
and
if
we
were
only
doing
every
other
release
as
an
lcs
release.
That
would
just
be
an
even
bigger
gap
between
when
a
feature
appears
in
current
and
actually
ending
up
in
an
lcs
release.
A
It
should
be
okay
to
share
those
because
we're
just
talking
about
previous
releases
and
previous
security
releases,
where
the
patches
are
already
out
there,
try
and
figure
out
what
data
would
be
useful
from
the
node.js
side,
as
well
as
external,
like
hiroku,
and
maybe
investigate
some
modules
and
lts
policies.
A
Maybe
it's
something
that
I
can
raise
on
the
package
maintenance
call.
It's
probably
worth
a
quick
discussion
over
there.
There's
a
few
module
maintainers
on
that
call
to
see
what
their
thoughts
are.
Just
point
them
in
the
discussion.
A
Okay,
one
other
thing
that
I
thought
might
be
useful
is
we've
got
the
schedule,
generator
thing
that
outputs
this
svg.
B
A
I'm
I
might
have
a
play
and
like
try
and
generate
one
with
some
of
these
numbers
in.
B
A
Yeah,
I
might
try
to
screenshot
it
and
add
it
to
the
discussion.
A
I
guess
rather
anyone
if
there's
anyone
watching
the
stream,
it's
not
just
it's,
not
a
decision.
That's
been
made.
Yet
it's
like
we're
discussing
we're,
exploring
we've
not
made
any
decisions,
so
don't
need
to
worry
about
it
being
changed
without
good
review
and
discussion.
B
A
Okay,
thanks
richard,
if
that's
all,
I
will
stop
the
poll
and
speak
to
you
all
next
time.