►
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
Okay,
so
we
are
live
with
the
node.js
release,
working
group
meeting
on
the
10th
of
september
2020..
We
will
start
working
for
the
agenda,
which
is
in
the
node.js
release,
github
repository
and
it's
issue
609
and
to
start
off.
Are
there
any
announcements
anyone
has
to
make.
B
A
Nope,
so
moving
on
to
the
first
item
on
the
agenda,
I
added
this
one
onto
the
agenda.
A
It's
doc
update
back
port
requirements
on
the
lts
release
lines,
so
this
kind
of
stemmed
from
a
pr
being
opened
back
port
pr
being
opened
for
a
feature
that
was
tagged
with
back
port
requested
v10.x
and
what's
kind
of
happened
here
is
we've
tagged
it
with
backport
requested
v10.x
back
when
10
was
inactive,
lts
and
the
the
label
hasn't
been
removed,
possibly
because
we
don't
have
a
process
in
place
to
do
that
when
something
transitions
from
active
into
maintenance,
so
pr
has
been
opened
and
then
immediately
kind
of
we've
kind
of
said:
we're
not
looking
to
add
new
features
to
node
10
as
it's
in
maintenance.
A
So
the
question
is:
should
we
update
documentation
to
say,
do
not
open
backcourt
prs
for
things
that
are
in
maintenance,
or
do
we
want
to
add
some
kind
of
process
to
audit?
What's
labeled
back
or
requested
for
a
particular
release
line
as
it
goes
between
active
and
maintenance?
C
So
I
think
that
there's
like
a
couple
options
here-
I
think
one
thing
that's
worth
kind
of
pointing
out
is
well.
This
is
like
a
sharp
edge
that
someone
has
run
into
we've
been
running
this
lts
program
for
years,
and
it's
the
first
time
that
it's
happened.
I
know
that
our
immediate
reaction
to
hitting
a
sharp
edge
is
to
create
processes
around
making
sure
it
doesn't
happen
again,
but
I
also
always
think
it's
good
to
step
back
and
ensure
hey
we're
not
like
creating
an
overly
large
amount
of
process.
C
I
think
historically,
there's
value
in
having
those
labels
and
like
continuing
to
know
like
what
things
have
not
landed
on
a
branch
is
not
is
not
totally
useless.
A
super
easy
way
to
clean
it
up.
If
we
don't
plan
to
ever
use,
those
labels
again
is
to
simply
delete
the
label,
and
then
that
removes
it
from
everything
or,
alternatively,
change
the
name
of
the
label.
C
If
we
want
to
keep
those
for
historical
purposes,
so
it's
possible
that,
like
a
very
simple
thing
that
we
could
do
here
would
be
to
at
the
point
that
a
release
moves
into
maintenance
that
we
change
the
name
of
the
label
from
back
port
requested
to
perhaps
not
backported,
to
or
like
you
know,
some
other
label
that
keeps
the
historic
like
labeling,
that
we
know
that
things
you
know
like
had
been
requested
and
didn't
land,
which
may
be
very
helpful.
C
If,
for
example,
we
have
like
a
security
thing
that
we're
trying
to
patch
and
that
helps
us
understand
like
what
landed
and
what
didn't
or
if
we
need
to
audit
the
branch,
like
those
labels,
are
still
helpful
without
giving
people
the
wrong
impression
that
we're
still
expecting
things
to
be
backported.
A
Agreed
one
of
my
first
instincts
was:
maybe
we
could
just
delete
the
label
as
well,
and
the
other
thing
is
that
maybe
in
the
back
port,
how
to
back
port
to
release
lines
guide,
we
just
add
a
small
note
that
says
kind
of
like
this.
Back
porting
guide
is
aimed
at
backboarding
to
a
release
line.
That's
in
an
active
state
if
it's
a
maintenance
check
with
the
lts
team
before
raising
a
back
port
or
something
like.
A
C
D
D
C
A
So
yeah
I
don't
run
branch
diff
or
anything
for
maintenance
release.
I
do
just
search
on
the
github
issue,
tracker
for
anything
labeled,
v10.x
and
land
anything
relevant
from
there.
I
think,
as
long
as
we
have
some
way,
I
can
imagine
there
could
be
a
regression
in
say
14
that
we
need
a
back
port
for
410
to
fix
a
relatively
severe
issue.
So
in
that
case
I
guess
we
could
just
label
it
with
lts
watch
v10.x
and
manually
ping,
the
people,
but
that's
a
rare
case.
We
normally
know
for
a
maintenance
release.
A
A
C
A
I'm
happy
to
write
that
in
the
minutes
and
happy
to
action
and
delete
the
label,
we'll
probably
need
to
loop
back
to
the
the
pr
that
was
opened
and
just
say:
hey
our
process
will
be
that
we
delete
the
label.
So
hopefully
this
shouldn't
happen
again
and
maybe
the
updates
to
the
release
guy
to
the
backboarding
guide
aren't
necessary.
Now
we've
got
that
process
in.
D
D
A
Have
one
for
current
lts,
so
we
could
just
change
that
heading
to
be
like
transitioning
and
then
have
it
under
the.
B
E
A
B
A
No
worries
and
that's
everything
that
was
actually
on
our
agenda
in
15
minutes.
So
any
is
there
anything
anyone
wants
to
talk
about
now
or,
if
not,
I
can
start
going
through
and
just
checking
our
schedules
for
the
upcoming
releases.
C
I
get,
I
guess
one
thing
I'd
add
and
I
had
totally
forgotten
about
mentioning
this
at
the
beginning.
I
think
when
you
called
for
announcements
december,
major
cutoff
date
is
coming
up
in
less
than
two
weeks.
C
So
if
I
recall-
and
you
could
tell
me
if
I'm
wrong-
it's
the
22nd-
which
is
the
tuesday
two
weeks
from
now
so
it's
about
like
12
days
away
and
so
good
for
folks
to
know
that
if
you're
looking
at
landing
send
for
major
changes
that
will
go
into
15,
you
know
get
them
in
before
that.
There's
still
an
opportunity
to
get
them
in
afterwards,
but
it
does
require
tfc
approval.
A
Yep
and
I
guess
to
add,
add
an
update
on
15,
so
I
there
is
a
proposal
open
and
a
couple
of
test
builds
just
to
kind
of
smoke
test
and
see
how
sick,
jim
and
things
are
faring.
At
the
moment
we
are
seeing
quite
a
lot
of
modules,
failing
their
test
suites
with
a
deprecation
warning,
which
is
the
umass
deprecation,
and
I
think,
unless
it's
been
fixed
recently
running,
npm
install
or
any
npm
command
also
shows
that
deprecation
warning.
A
A
Was
due
to
go
out
in
14,
but
we
opted
to
dock
deprecate
it
in
around
march
time
and
said
we
would
run
time
deprecate
it
for
15,
and
so
it's
kind
of
like
kicking
it
down
a
bit.
But
that
could
be
the
right
thing
to
do,
depending
on
how
the
ecosystem
can
handle
the
deprecation.
C
Beth
one
thing
that
might
be
worth
kind
of
requesting
to
core
and
we
can
see.
I
know
that
when
we
did
the
deprecation
warnings
for
buffer,
it
was
extremely
disruptive
and
I'd
be
lying.
C
If
I
told
you
that
I'm
not
getting
kind
of
like
waves
of
this
being
another
one
of
those
one
of
the
things
that
we
did
for
the
buffer
deprecation,
if
I
recall,
although
I
could
be
mistaken,
I
believe
at
one
point
we
made
it
so
that
the
error
that
the
warning
only
logged
if
the
warning
was
within
your
the
tree
of
your
application.
C
That's,
in
my
personal
opinion,
a
far
simpler
problem
to
deal
with.
C
Yeah
I
get,
I
guess
the
thing
that
that
would
make
sense
to
me
and-
and
maybe
this
is
we
need
to
open
an
issue
about
it
or
I
think
james
was
involved
in
like
that
original
fancy
way
of
handling
the
buffer
warnings.
I
kind
of
think
what
we
need
to
do
is
just
get
a
pull
request
open
to
implementing
this
as
soon
as
possible.
C
So
I
can
maybe
take
the
action
item
of
just
pinging
james
right
now
and
seeing,
if
there's
historic
code
on
that,
that
he'd
be
able
to
dig
up.
Otherwise,
I
can
do
some
spelunking
and
see
if
I
can
find
the
old
buffer
warning
commits
that
did
that.
A
A
So
yeah
the
and
just
to
finish
the
update
on
15,
the
pr
will
be
updated
every
kind
of
week
or
so
up
until
the
22nd
of
september.
It
will
just
be
a
copy
of
master
and
then,
after
that
point
we
will
only
be
cherry-picking
the
miners
and
the
patches
into
the
release
line
and
at
that
point
and
release
candidates
should
start
to
appear.
A
Cool
awesome,
any
other
new
topics
to
add.
On
the
end
before
we
review
the
schedules.
B
Now
the
only
thing
I'd
mention
for
anyone
looking
at
the
screen
but
hasn't
seen.
Otherwise
there
are
some
security
releases
coming
out
on
tuesday.
So
look
out
for
those.
A
A
I
guess
it's
worth
saying,
congrats
to
richard
for
preparing
and
promoting
your
first
release.
B
C
A
B
Yeah,
I
know
I
I
think
it
makes
sense
to
to
to
get
to
to
let
the
streams
folk
spend
a
little
bit
more
time,
eyeing
out
the
issues
with
that
that
commit
so
backing
out
and
perhaps
revisiting
it
later
date,
but
yeah,
it's
just
just
trying
to
get
to
a
stable
state
so
that
those
security
releases
on
tuesday.
C
B
B
Thing
with
this
is
originally,
it
was
sender,
major
and
then
ronag
opened
a
pr
to
back
port
it
to
14
and
took
it
to
the
tsc
to
get
approval
to
bring
it
back
in
as
december
minor.
C
B
Yes-
and
I
I
know
they're
working
through
some
looks
like
there
are
still
some
edge
cases
in
the
in
the
upstream
thing
on
on
master
working
through
so
yeah.
That's
the
only
sort
of
complication
into
the
whole
should
we
revert
it
or
not,
because
it's
obviously
breaking,
but
it
might
be
allowed
to
break
on
on
the
next
major.
B
You
need
more
input
from
streams.
I
think
to
make
that
call
as
to
whether
it
should
be
reverted
up
there
or
not.
C
A
Awesome:
okay,
thanks
richard
okay
cool
for
12.
I
think
yeah
we're
aiming
for
a
minor
before
it
goes
into
maintenance,
but
that's
based
on
a
release
for
availability.
B
I
think,
according
to
our
lts
rules,
slash
guidelines
that
I'm
only
eligible
to
do
an
lts
release.
Two
weeks
after
my
current
release.
B
So
that's
that's,
you
know
I
could
potentially
do
it,
but
might
be
at
least
for
another
two
weeks.
A
Yeah,
I
guess
I
guess
we
do
aim
to
have
a
little
bit
of
baking
time
at
the
moment
it
doesn't
seem,
we've
got
any
names
to
it,
so
feel
free
to
fiddle
with
the
dates
to
a
date
that
works
for
you,
okay
and
sign
up.
D
D
C
C
Like
I
guess,
the
one
thing
to
keep
in
mind
here
is
like
this
is
the
last
miner
before
maintenance.
So
I
I
I've
been
trying
to
find
time
and
have
not
found
time.
Unfortunately,
but
I
think
we
do
need
to
do
kind
of
like
a
full
audit
just
of
the
esm
stuff
to
try
to
get
the
12
esm
as
close
to
14
as
possible.
C
There's
things
we
won't
be
able
to
get,
for
example,
like
top
level
await,
but
I
think
it's
important
that
we
try
to
get
it
there
other
than
that,
like
I
had
a
partial
list
of
the
miners,
but
it
likely
would
be
a
good
idea
to
review
all
of
those
miners
if
we
can
find
time
so
that
we
can
ensure
there
aren't
like
specific
things
that
we
don't
want
to
land.
C
I
also
think
in
general,
it
might
be
worth
a
broader
conversation
here
about
the
timing
and
the
flips
that
we've
done
for
both
maintenance
and
active,
mostly
because
I'm
having
conflicting
feelings
on
one
hand,
I'm
glad
that
we're
not
going
to
continue
maintaining
it
because
it
takes
a
lot
of
time
and
effort
and
obviously,
I
think,
like
the
lack
of
getting
this.
This
specific
release
out
is
a
great
example
of
like
just
us
not
being
super
on
top
of
it.
C
But
at
the
same
time
it
also
feels
like
we're
missing
out
on
keeping
12
a
little
bit
more
up
to
date.
If
we
wanted
to
have
some
specific
targeted
things,
so
I
don't
think
that
we
benefit
by
like
making
new
phases
or
whatever.
But
it's
like
we,
we
had
12
months.
C
Where
we
have
the
flexibility
to
release
a
minor
release
or
a
flexibility
to
do
a
non-maintenance
based
release
might
be
helpful,
but
it's
also
possible
that
this
is
just
like
I'm
feeling
that
way
because
of
the
modules
changes.
How
do
people
feel
about
12
and
and
with
where
it's
at
right
now.
A
I
kind
of
feel
like
it
would
be
nice,
possibly
to
get
more
a
few
more
miners
from
14
back
into
it
if
possible,
and
that
I
probably
still
feel
that
way
over
the
next
two
or
three
months.
I
think
part
of
it
at
the
time
was
kind
of
our
small
group
of
releases
and
our
ability
to
backport
things
that
were
quite
heavily
conflicting.
A
C
Yeah,
I
I
would
agree
with
that,
and
I
think
I
think,
maybe
maybe
like
slightly
augmenting
it
for
14
might
make
sense.
I
guess,
like
the
only
only
thing
that
I'm
concerned
about
which
we
can
we
can
revisit
maybe
add
to
the
agenda,
would
be
continuing
to
augment
our
support
calendar
and
how
long
we
do
releases
and
then
like
if
we
have
12
with
something
completely
different
than
10,
and
also
something
completely
different
from
14.
A
I
guess
we
do
have
the
kind
of
escape
that
our
definition
of
maintenance
is
that
we
do
allow
sen
for
minors,
but
it's
got
to
be
at
the
discretion
of
the
lgs
team
to
believe
that
this
minor
is
necessary
for
migration
purposes,
up
to
later
release
lines
or
just
help.
The
ecosystem
in
general.
C
C
Yeah
and
and
for
what
it's
worth
like,
and
there's
a
flip
side
to
this,
that,
I
think,
is
worth
thinking
about
as
well.
It's
like
I
have
heard
feedback
from
more
than
one
party
and
when
I
say
party
I
mean
like
consumers,
like
both
people
who
are
running,
who
are
managing
runtimes
or
distribute
node,
that
being
like
debian
or
certain
cloud
providers,
that
the
fact
that
we
do
miners
on
lts
actually
is
is
hard
for
them,
because
keeping
up
in
knowing
what
they
can
support
is
hard.
C
There's
module
authors,
for
example,
who,
though,
even
though
we
are
putting
these
miners
into
12,
if
they
say
they
support
12,
will
support
like
the
lowest
miner
of
the
lts,
which
creates
these
kind
of
like
arbitrary
api
surfaces
that
they
end
up
supporting
so
like
we,
we
do
have
our
our
own
kind
of
support
story,
but
but
various
folks
are
not
able
to
100
match
that.
So
I
do
think
that
perhaps
there
has
been
a
benefit
to
us
limiting
how
much
we're
actively
landing
features
on
lts
that
some
people
may
appreciate.
C
A
C
It's
12
and
then
18..
So
I
I
think
one
of
the
things
that
I
was
suggesting
there,
which
could
be
splitting
it
and
making
it
15
and
15,
but
then,
and
actually
that
may
not
be
bad,
but
that
would
like
offset
the
move
to
maintenance
not
being
around
the
same
time
as
the
lts,
and
I
think
part
of
the
reason
we
flipped
it
was
that
we
would
only
have
one
act
of
release
at
the
same
time.
Whereas
if
we
made
it
15
and
15,
then
there
would
be
a
three
month
overlap
of
two
different
active.
D
Yeah
and
which
is
about
basically
the
fact
that
a
lot
of
library
authors
try
to
still
support
the
maintenance
releases
until
they
they
are
just
out
end
of
life,
and
that's
that
can
be
a
problem
because
they
will
never
use
the
new
features
until
they
they
disappear.
From
all
I
mean
until
they
are
available
in
all
node.js.
A
Yeah,
I
I
think
this
kind
of
suggested
that
maintenance
should
be
seen
as
a
something
you
should
start
moving
off
of
quite
quickly,
whereas
if
it
for
us
it's
18
months,
so
that
doesn't
really
apply
in
this
case,
because
we
of
the
length
of
time
something's
in
maintenance
people
have
additional
time
to
upgrade
and
they
can
they
have
to
upgrade
to
get
new
features.
C
C
But,
as
I
mentioned
with
like
cloud
providers
or
like
debian
or
like
these
other,
these
other
organizations,
there
are
organizations
that
actually
prefer
maintenance
lts
to
active
lts
because
they
don't
want
new
features.
C
They
want
to
ensure
that,
like
there
is
a
consistent
api
surface
throughout
that
life
cycle
and
to
them
that's
what
lts
means
and
in
fact,
in
in
many
other
projects,
what
we
call
maintenance
lts
is
far
closer
to
what
their
lts
programs
are
like,
and
it's
much
more
of
a
like
we're
going
to
fix,
bugs
and
we're
going
to
fix
security
vulnerabilities,
but
it's
stable
and
you
shouldn't
expect
too
many
things
to
change.
So
I
think
that
we
do
need
to
take
with
a
grain
of
salt
here,
but.
D
I
think
I
think
michael
would
agree
with
what
you
said
and
that
yeah
I
don't
want
to
to
interpret
too
much
what
he
said,
but
I
I
I
think
that
his
point
of
view
is
that
we
should
not
push
or
maybe
you
know
at
the
opposite.
We
should
push
library
authors
to
to
drop
all
node.js
versions
before
they
are
out
of
lts
as
soon
as
they
are
in
maintenance.
A
I'm
vaguely
recalling
I
had
an
action
on
this
one
to
take
to
the
package
maintenance
group
to
I
know,
they've
put
out
some
blogs
just
saying
which
versions
they
recommend
library
authors
test
against
and
at
the
moment
I
believe
it
includes
maintenance,
active
lts
and
maybe
additionally
current
if
people
want
to
check
their
migration
path
forwards.
A
Sorry
we're
already
trying
to
get
struggling
to
get
12
releases
out
so
would
extending
it
make
much
difference
in
terms
of
the
features
that
get
back
to
our
users
and
in
their
hands.
A
A
B
I
think
the
thing
is,
though
we
we're
on
boarding
more
releases,
and
so
you
know
I'm
I'm
I'm
more
or
less.
My
onboarding
is
more
or
less
done
other
than
the
small
way
to
do
the
lts
releases.
B
But
then
you
know
there
are
others
coming
on
board
and
we
don't
know
what
the
effect
that's
going
to
be
on
our
ability
to
maintain
branches.
Until
probably
a
couple
of
months
down
the
line
I
mean
it
might,
it
might
have
no
effect,
it
might
cause
more
things
to
you
know
so
that
we
have
less
debt
in
terms
of
things
landing
on
branches.
B
A
A
Okay,
is
there
anything
else
to
add
on
this
one
today.
A
No
should
I
just
just
clarify,
I
think
the
outcome
today
we're
going
to
keep
12,
as
is
we're
not
going
to
make
any
decisions
to
push
it
out
and
think
about
it.
A
A
E
A
I
know
we
get,
we
can
just
slot
an
additional
one
in.
You
should
probably
update
the
table
to
contain
the
new
release,
so
the
numbers
will
line
up
but
yeah
yeah.
I
think
previously,
a
couple
of
years
back.
We
did
release,
try
to
do
an
current
release
every
week
and
then
we
downgraded
it
to
two
weeks.
But
if
we
can
do
one
and
interim
one,
we
do
sure
cool
thanks.
B
If
there's
not
much
content,
you
know
it
doesn't
harm
since
it'll.
Be
your
first
release
for
you
to
do,
go
through
the
go
through
it
all
anyway,.
E
Yeah,
I
was
also
wondering
about
tuesday
called
we
want
to
go
over
the
security
patch
or
we
want
to
start
picking
up
commits
to
the
staging
branch
for
the
for
the
upcoming
release.
A
It
may
make
sense
to
use
that
time
to
promote
the
security
release,
so
we
can
try
and
time
it
at
the
same
time.
I
know
richard
and
I
are
doing
one
so
we
could
try
and
coordinate
timings,
hopefully
shouldn't
take
too
long.
There
shouldn't
be
too
many
problems,
I
hope
so
maybe
we
would
have
time
as
well
to
start
on
the
40
next
stuff.
B
A
A
Okay,
we've
gone
through
all
of
our
plans.
Any
additional
topics
to
talk
about
before
we
close.
A
A
No
okay,
if
not
I'll
end
the
call
there
and
speak
to
you
a
bit
later.