►
From YouTube: 2021-01-14 - Node.js Release Working Group Meeting
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
So
hi
everyone
and
welcome
to
the
node.js
release
working
group
meeting
for
the
1st
of
january
2021
and
we'll
be
working
from
the
agenda.
That's
in
the
notejs
release
issue,
which
is
node.js,
release,
issues
638
and
just
to
start,
are
there
any
announcements
anyone
would
like
to
make
today.
A
And
so
the
first
item
is
release
working
group
meetings
and
there
are
entries
in
the
node.js
or
calendar
now
and
for
now
I've
set
it
just
this
week
to
be
3pm
uk
time
for
free,
utc,
sorry
and
the
ones
going
forward
at
4
utc,
which
was
our
previous
time
at
two
week
intervals.
A
But
I
did
put
out
a
doodle
poll
and
it
seems
like
a
lot
of
people
have
responded,
saying
the
three
utc
time
is
okay
for
most
people
going
forward.
So
I'm
I'm
wondering
if
it's
worth
moving
to
that
time
and
seeing
how
it
goes
at
least,
until
savings
time
kind
of
changes
things.
I
don't
know
if
anyone
has
thoughts
on
that.
A
Yeah
sounds
good,
yeah,
okay,
so
I'll
probably
go
forward
and
move
them
all
to
three,
which
I
did
check
the
calendars
and
if
we're
three
utc
every
two
weeks,
we
shouldn't
clash
with
any
other
meeting
like
rotational
meetings
on
the
calendar,
so
looks
like
it's:
okay,
so
just
start
with
that
and
see
how
we
go
and
if
we
need
to
change
it
to
make
give
the
opportunity
for
more
people
to
attend
we'll
go
from
there.
A
But
if
anyone
else
in
release
or
anyone
else,
who'd
like
to
attend,
the
meetings
could
fill
in
that
doodle.
That
help
us
just
confirm
whether
that's
a
good
choice
and
after
that
item,
I
guess
it
makes
sense
to
move
on
to
the
back
porting
the
release
key
one
and
do
all
the
schedules
together
in
a
minute.
A
A
A
We
have
to
explicitly
go
and
land
them
on
the
lts
branches,
especially
when
the
releases
and
maintenance,
I
think
that's
something
we
should
do
and
we,
if
anyone's
doing
a
release,
but
I
guess
we
just
need
to
pr
somewhere
into
our
governance,
or
maybe
the
releases
md
file,
to
say
before,
producing
a
release
on
a
given
release
line,
ensure
your
key
is
available
on
that
branch.
I
don't
know
if
something
like
that
makes
sense.
B
Yeah,
I
I
think
I
think
we
currently
have
a
policy
that
the
key
needs
to
be
in
the
readme,
but
it
only
refers
to
the
current.
A
B
And
it
doesn't
talk
about
the
complication
about
the
lts
branches,
so
I
have
cherry-picked
the
commit
for
my
key
into
the
10th
staging
branch.
B
We
don't
actually
have
any
releases
planned
to
push
that
out,
but
at
least
it's
sitting
there
waiting
for
the
next
release
to
go
out,
but
obviously
anyone
else
who's
been
recently
added
won't
be
in
the
reading
either.
So
whether
that
restricts,
who
can
be
released
and
we're
not
we're
not
expecting
that
many
more
releases
on
10
but
yeah
at
the
moment
we
don't
have
the
full
set
of
release
keys
there.
A
My
kind
of
gut
feeling
is
the
easiest
thing
for
us
to
do
is
on
our
releases
on
onboarding
governance.
We
just
say
please
cherry
pick
your
like
once
it's
landed
on
the
main
branch,
please
cherry
picked
all
active
release,
lines
yep.
That
seems
the
easiest.
I
think,
if
we,
if
we
start
kind
of
complicating
it,
saying
oh
once
you're
entitled
to
do
an
lts
release
or
you
have
the
access
to
do
an
lts
release,
then
cherry
picker.
I
think
we
will
miss
it.
A
B
A
Yeah,
so
I
think
I
think,
I'm
not
sure
whether
that
needs
to
go
in
releases
md
in
the
adding
a
publicly
listed
gpg
key
or
in
the
governance,
or
maybe
both,
maybe
that's
a
suggestion.
We
need
to
kind
of
unify
some
of
that
content.
A
Okay,
I
don't
know
if
anyone
would
like
to
take
that
action
to
just
add
that
kind
of
sentence
in
you
know
I'll.
Take
that
awesome
thanks
richard
and
we
can
figure
out
any
unifying
of
docs
later
on,
but
sounds
like
a
good
way
to
make
sure
we
don't
forget
to
do
that
and
remember
that
it's
something
we
should
do
cool
thanks.
Next
few
are
to
run
through
the
release
schedules,
so
I
will
open
them
all
up.
A
D
It's
everything's
passing
now,
so
I'm
going
to
release
it
today.
Awesome
cool.
C
A
Yeah,
I
was
thinking
about
this
one,
but
I
don't
I
don't
know
I
don't
know
if
we
need
to
like
doing
a
release
in
between.
I
don't
think,
that's
a
big
concern
unless
you'd
prefer
to.
I
guess
your
release
would
be
slightly
smaller.
C
With
it
yeah,
if
you
want
to
just
stick
to
the
dates,
I
can
prepare
one
in
there.
Next
tuesday,
yep.
A
Yeah
yeah,
okay,
if
we
roughly
stick
to
like
one
every
couple
of
weeks,
I
guess,
if
maybe
the
week
after
works
better
in
terms
of
your
timing,
that
would
make
complete
sense,
but
I
guess,
without
and
michael
here
I
don't
really
want
to
push
his
so
feel
free
to
move
your
date
within
the
kind
of
two
weeks,
and
if
that
suits
you
better,
I
think
that's
probably
a
good
way
to
go.
I
think
this
is
just
draft
cadence
of
roughly
one
every
two
weeks.
A
A
We
did
have
a
aim
to
do
a
semver
minor,
but
that's
a
lot
of
work
and
we've
not
got
a
volunteer
to
do
that
just
yet.
We
probably
need
to
push
the
date
out,
but
without
anyone
to
put
their
name
down
straight
away.
I
I'd
probably
just
suggest
just
putting
like
february
x
and
just
see
how
that
goes.
A
I
guess
for
lts
miners
we
aim
cut
two
to
three
weeks
kind
of
bait
with
the
release
proposal
open.
A
So
with
that
being
the
case,
that's
kind
of
why
I
pushed
it
into
february,
because
even
if
we
opened
it
kind
of
today,
we
wouldn't
really
have
enough
time
to
give
it
that
free
three
weeks
so
I'll
push
it
to
there.
I
might,
I
might
be
able
to
pick
that
one
up
but
I'll
need
to
double
check
after
this
call
before
jotting
my
name
down.
A
Yeah,
okay
yeah:
I
was
just
double
checking
that
it
wasn't
april
because
I
know
it
used
to
be
april
time
frames
that
we
did
the
transition,
but
yep
we're
good.
A
So
follow
that
and
node
12
isn't
now
in
maintenance.
So
we
possibly
I'll
possibly
shrink
the
schedule
down
and
maybe
just
have
a.
A
B
Yeah,
the
npm
update
applies
to
14,
12
and
10.,
because
it's
a
it's
an
npm
six
uptake.
It's
just
I
I
believe
it's
just
a
minor
bump
to
the
some
of
the
dependencies,
but
sorry
a
patch
level
bump
to
from.
A
It's
like,
I
guess,
for
for
10.
I
know
we've
had
some
earlier
discussions
around
february
time
frame.
If
nothing
comes
sooner,
causing
us
to
do
a
release
a
little
bit
sooner.
We
will
aim
to
get
that
patched
in
february.
I
don't
know
if
it
makes
sense
to
do
that
consistently
for
12
and
also
that's
when
the
14x7
is
kind
of
due
as
well.
Maybe
just
timing
them
all
roughly
at
the
same
time
make
sense.
A
So
yeah,
I
guess
I
guess
the
call
to
make
is:
do
we
want
to
rush
out
some
patch
releases
for
14,
12
and
10
soon,
like
next
kind
of
two
to
three
weeks,
or
do
we
want
to
adjust
it
mark
february
for
when
those
will
go
out
and
the
main
factor
of
that
decision
is?
Will
anyone
have
time
to
prepare
those
in.
B
A
B
Yeah
yeah
that
14
release
is
going
to
be
tricky
because
we
haven't
had
december
miners
since
it
went
into
the
main
active
lts,
which
was
in
october.
So
it's
getting
under
three
months
of
potential
stuff.
To
that.
A
So
yeah
that's
going
to
take
a
lot
of
work
and
I
know
pushing
f
is
going
to
take
a
little
bit
more
work,
but
I
don't
I
don't
with
baking
time
in
the
amount
of
time
it's
going
to
take
to
put
that
together.
I
don't
think
we
can
target
any
earliest.
I
think
14
15.
A
I
think
I'll
add
the
security
releases
in
here
so
that
we
can.
A
A
Cool
okay,
so
possibly
we
will
aim
to
get
the
that
npm
update
out
january
kind
of
time
frame
in
terms
of
the
calendar.
A
As
you
say,
it
shouldn't
be
too
much
for
us
to
get
them
through.
I
can
certainly
do
one
of
them
if
it's
just
the
npm
update
and
maybe
any
other.
A
Maybe
if
there's
open
back
ports,
it
makes
sense
to
get
those
out
if
they've
been
waiting
a
long
time
if
they're
bug
fixes
but
maybe
not
doing
the
whole.
A
Possibly
make
sense
okay,
and
so
I
can
take
a
look
at
doing
14
minor
14,
the
patch
one.
I
can
probably
take
a
look
at
doing
that,
one
too
that
shouldn't
be
too
bad,
so
I
don't
know
if
we
have
volunteers
to
do
the
12
and
10
with
the
npm
patch.
A
I
guess
that's
kind
of
requiring
the
lts
bits
so
yeah
yeah.
Perhaps
in
the
minutes
I
will
write
our
plan
and
maybe
some
of
the
folks
that
aren't
here
will
volunteer
to
do
one
of
the
others.
But
if
not,
it
sounds
like.
C
A
That's
true
yeah,
if
you'd
like
to
pair
on
one
of
those
or
I'm
sure
yeah.
That
makes
sense
because
you've
been
you've
been
added
to
the
team.
Now
I
think
or
there's
an
issue
open
to
add
you
to
the
team
so
once
you're
added
and
your
key
is
on
that
branch
and
we
can
go
forward
and
start
preparing
yeah,
a
small
release
is
probably
good
to
start
before
cherry
picking
a
massive
cherry,
semper
miner.
C
Yeah,
I
think
it's
still
pending
the
the
issue,
but
yeah
then
the
three
of
us.
We
can
organize
and
get
the
security
releases
out.
A
A
A
Not
maybe
that's
the
okay,
I
I
wonder
if
it
probably
makes
sense,
while
we're
all
here
together
to
just
jot
names
down,
I'm
kind
of
thinking
richard
you've
been
dealing
with
10
ci's
quite
a
lot
recently,
so
I
wondered.
B
A
A
I'm
sure
we
may
get
a
few
comments.
Oh
I've
done
it
done
again.
A
C
A
A
Okay,
so
we've
got
those
going
out
and
probably
makes
sense
to
get
them
out
to
people
so
sounds
good,
so
call
on
volunteers
for
14
and
12
and
10
are
in
maintenance.
So
we
don't
need
to
plan
any
further
ahead.
For
those,
so
sounds
good,
and
I
think
that
was
all
on
our
list.
Is
there
anything
else?
That's
people
thought
about
to
talk
about
today.
D
A
Yeah,
I
think
it.
I
don't
think
we
have
any
good
dogs
that
go
through
it,
but
I
think
periodically.
We
try
to
like
run
a
sit
gym
and
mark
things
appropriately
like
if
something
some
modules
put
out
a
broken
release
or
a
release
where
their
tests
fail,
we
will
go
and
mark.
It
is
skip
until
that's
fixed,
but
it
takes
us.
A
So
it's
the
time
like
the
time
it
takes
us
to
do
that,
because
if
we
keep
doing
delta
runs
and
things
in
the
modules
are
changing
underneath
us,
we
won't.
We
may
not
actually
dig
into
those
results,
because
we
just
see.
Oh,
it's
occurring
on
the
previous
release.
It's
occurring
on
this
release,
so
we
don't
dig
into
it
as
part
of
the
release
process,
but
it
is
something
we
try
to
do
at
times.
Admittedly,
I
haven't
got
around
to
it
and
possibly
with
the
holidays
and
things
others
haven't.
A
A
D
A
Yeah,
I'm
not
sure
of
any
further
ideas
to
make
it
kind
of
the
process
of
that
easier
or
easier
to
understand
what
we
need
to
do
and
when
I
can
try
and
take
a
look
at
jim
to
see,
see
if
there's
any
obvious
module
failures
that
we
can
tidy
up
into
modules
themselves.
That
aren't
broken
because
of
our
release.
D
Yeah
I'll
try
to
go
back
and
look
as
well,
because
there's
definitely
a
couple
that
keep
coming
up
and
they're
the
same
one.
So
maybe
it's
time
to
go
through
and
mark
some
of
them.
It's
flaky
again,
yeah.
D
I
just
had
one
more
question
about,
even
I
so
I
updated
my
release
key
last
week
and
I
got
moved
to
master
and
then
or
merged
into
master,
and
then
I'm
running
my
release
this
week
and
I
think
I'm
I
just
want
to
make
sure
I
understand
how
the
release
key
is
being
used,
but
I'm
I
have
the
pr
that
I'm
I've
opened
with
my
proposal
also
contains
the
new
release.
Key.
A
Today,
I
don't
know
if
we
have
history
of
like
that
happening
before
okay,
but
I
guess
we're
doing
the
same
thing
and
richard
your
keys,
been
cherry,
picked
onto
the
10
branch.
B
B
D
Okay,
cool
yeah,
I
yeah,
I
thought
it
would
be
okay
and
then
I
don't
know
I
was
looking
at
it
yesterday
just
to
make
sure,
because
I
didn't
want
it.
It's
such
a
big
release
that
I
didn't
want
to
break
anything.
B
A
B
B
But
I've
seen
I've
seen
other
projects
that
have
been
doing
validation
of
the
keys,
and
I
only
know
about
them
because
I
was
tagged
because
they
were
not
picking
up
the
changes
that
we've
been
doing
on
on
main.
So
they
were
still
doing
checking
like
no
12
and
things,
but
they
weren't
picking
up
the
readme
from
maine,
so
weren't
weren't
getting
the
keys.
A
A
B
A
Know
maybe
that's
I
need
I'll,
go
searching
for
that
issue
and
maybe
tag
its
release
agenda
and
we
can
deep
dive
a
little
bit
more
into
it
next
time.