►
From YouTube: Node.js Release Working Group Meeting - 2020-11-5
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
A
Awesome:
okay,
that's
better
cool!
So
for
note,
15!
We
are
scheduled
up
until
december.
So
probably
don't
need
to
talk
much
about
that.
I
know
michael
put
a
release
out
yesterday,
so
thanks,
michael
and
we'll
probably
have
15
to
next
week
with
danielle,
and
I
think
that
will
be
the
first
release
you
promote.
A
I
don't
know
if
we
need
to
schedule
any
further
in
advance
to
be
honest
on
there.
Node
14
release
plan
see
where
we
are
so
we're
hoping
to
have
a
release
in
november,
but
we
don't
appear
to
have
a
date
just
yet.
I
should
probably
take
an
action
after
this
meeting
to
build
up
the
table
now
that
14's
gone
from
current
to
active
lts
and
build
it
up,
probably
aiming
for
the
same
kind
of
one
release
per
month
that
we
normally
go
for
for
active
lts.
A
A
C
C
C
D
So
I
opened
the
rc
for
that
on
tuesday
there's
a
little
bit
of
work
to
still
be
done.
I
think
people
pointed
out
one
or
two
commits
that
they'd
like
to
see
brought
in,
and
I
think
it
would
also
be
a
good
idea
in
general
to
do
a
broader
call.
I
guess
one
thing
we
need
to
do
is
update
that,
because
I
wanted
to
push
it
off
to
three
weeks,
just
to
give
a
little
bit
more
time
for
some
of
the
module
stuff
to
bake.
D
E
D
Holidays
on
the
26th
and
like,
in
my
personal
opinion,
it's
not
like
people
need
to
update
we're,
not
doing
a
security
release,
we're
not
fixing
major
bugs.
This
is
assembler
miner
release.
I
don't
think
it's
worth
pushing
a
week
for
that.
If
it
was
a
security
release
or
something
that
required
people
to
update,
then
I
would
agree
with
that,
but
otherwise
I
think
it's
fine
cool.
A
D
Cool-
and
I
guess
one
one
note
in
there
is-
I
had
gone
through-
I'm
going
to
do
one
more
check
before
like
in
the
next
week,
but
this
should
get
the
modules
implementation
inside
of
12
to
be
more
or
less
neck
and
neck
with.
What's
in
14
and
15,
I
think,
like
the
only
really
big
difference
at
this
point
will
be.
We
won't
be
stabilizing
it
in
12
and
it
doesn't
have
top
level
weight
because
it
doesn't
have
the
version
of
v8
that
supports
that.
A
B
B
A
A
Agreed
in
terms
of
open
issues,
just
as
we've
not
used
up
much
time,
is
there
anything
that
stands
out
to
anyone
that
we
should
talk
about,
particularly,
I
guess
the
change
dog
changes.
That's
kind
of
I
saw
the
15
pr
that
went
out
yesterday.
We
kind
of
broke
the
changelog
down
into
test
doc
changes,
etc.
D
I
guess,
like
my
only
request,
and
I
don't
think
that
this
would
be
a
huge
deal
but
like
if
we
were
if
we
did
want
to
start
like
more
consistently
breaking
it
up.
That
way,
I'd
want
to
work
that
into
node
core
utils
so
that
we
could
automate
it,
which
I
I
think
should
be
possible,
especially
since
we
have
like
the
subsystems,
but
if
we're
going
to
codify
it,
I'd
very
much
like
it
to
be
automated.
Instead
of
creating
like
more
manual
work.
A
A
And
there's
a
lot
of
it,
I
don't.
We
still
have
not
renamed
the
sichum
team,
I
don't
think
to
release
automation,
but
I
think
I
think
we're
considering
doing
like
an
audit
of
members.
So
I
wonder
if
it's
worth
spinning
up
an
issue
for
that
to
order
all
the
members
of
release
because
of
the
access
that
comes
with
release.
Maybe
it's
a
good
time
to
say
to
some.
I
don't
think,
there's
many
people
that
are
not
active
in
the
release
working
group,
but
it
might
be
something
we
should
check
routinely.
D
I
think
with
this,
and
we
talked
about
it
briefly
like
I
think
it's
good
to
go
through
an
audit
of
the
whole
team
structure,
because,
to
be
honest,
I
was
looking
at
it
recently
and
it
doesn't
make
a
lot
of
sense,
which
I
think
is
part
of
what
like
the
proposal
there
was,
but
like
there's
like
the
release
team,
then
there's
the
sikkim
team,
then
there's
the
lts
team.
There's
the
backquarters
team.
D
It's
not
really
like
necessarily
super
clear
who
owns
what
decisions
anymore
and
then
there's
a
bunch
of
people
that
have
been
coming
to
this
meeting.
So
we
don't
really
have
like
a
working
group
anymore
like
that's
there.
That's
just
like
a
clear
list
of
the
people
that
are
in
the
working
group,
so
it
might
be
worth
coming
through
and
like
kind
of
rethinking
the
structure
of
the
team
as
a
whole.
A
D
D
A
D
Yeah
and
we've
given
anna
the
ability
to
land
on
that
branch.
I
I
guess
like
one
of
the
the
examples
and
then
the
flip
side
would
be
like
ryan
daniella
are
still
like
ramping
up
and
don't
necessarily
do
back
porting
yet,
but
that
shouldn't
that
shouldn't
like
stop
them
from
being
able
to
do
the
release.
If
other
people
are
backporting.
B
D
G
yeah
and
I
I
guess
like
getting
into
the
weeds
of
it
for
what
it's
worth
like.
If
you
were
doing
the
release
and
you
found
that
something
needed
to
be
pulled
out
or
landed,
I
think
that
that's
like
a
little
bit
of
a
distinct
case
from
the
like
going
through
and
auditing
like
300
commits,
but
perhaps
that's
a
distinction
that
we
don't
need
to
make.
D
A
I'm
just
not
sure
how
we
can
make
that
distinction
where,
like
anyone,
can
land
anything
on
the
branch
and
we
take
the
assumption
that
once
something's
landed
on
the
even
staging
branches
that
has
been
audited
and
it
should
kind
of
live
there
unless
it
trips
up
tests
or
anything
how
you
would
I
I
don't
know
how
you
can
make
the
distinction,
because
if
the
releases
have
permission
to
push
to
these
branches
anyway,
you're
not
gonna,
probably
look
for
and
say
who
landed.
This.
B
So
I
guess
the
question
is:
is
really
just
about
the
expanded
people
outside
of
release
that
would
be
allowed
to
backport
and
there's
not
too
many
at
the
moment,
and
I
guess
that's
just
a
trust
question.
I
guess
we
don't
really
have
like
an
onboarding
for
back
forces.
I
guess
other
than
what's
in
the
one
of
the
guides
in
core
does
talk
about
back
porting,
because
I
know
somebody
made
some
changes
recently
to
try
and
clarify
things
like
you.
B
D
I
guess
like
maybe
we
could
just
move
forward
with,
like
you
know,
to
your
point,
the
people
who
have
released
permissions,
who,
who
honestly
at
this
point,
it's
like,
I
think
it's
danielle
and
roy,
who
are
the
two
that
are
releasers-
that
haven't
really
done
lts
releases
right
not
to
just
like
directly
call.
You
well,
and
I
guess,
like
targos,
hasn't
really.
D
C
A
I
don't
think
we
need
to,
but
I
know
before
we've
said
you
must
do
so
many
currents
before
that
you
kind
of
get
on
board
to
lts,
but
I
don't
think
we
particularly
need
to
do
that,
especially
with
what
richard
says
we're
going
to
be
reviewing
these
the
mentoring
that
we
do
now
says
to
ask
for
help
and
etc.
I
I
think
we
would
catch
anything.
B
Yeah,
I
mean
to
be
honest.
I
think
that
we
have
more
trouble
with
the
back
porch
inside
of
just
trying
to
understand,
like
might
say
what
what
relies
on
what
and
and
some
of
them
things
like,
for
example,
streams
and
modules.
We
are
heavily
reliant
on
the
teams
looking
after
those
areas
to
advise
when
things
should
and
shouldn't
land.