►
From YouTube: 2021-05-20 - 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
A
Make
so
the
first
kind
of
items
on
the
agenda
to
quickly
review
our
schedules
so
I'll
go
ahead
and
share
my
screen
and
open
up
the
various
release
schedules.
A
So
we
have
the
node.js
16
release
line
schedule
and
we
are
scheduled
all
the
way
up
until
the
end
of
june.
So
all
seems
good
any
folks
for
the
later
ones
when
they
know
their
availability
feel
free
to
volunteer
any
other
comments
on
this.
One
all
looks
good.
A
I'll
try
and
go
back
and
populate
some
of
the
versions
for
node
14.
I
guess
we
did
have
the
big
node
14
release,
so
thanks
danielle,
michael
and
everyone
who
put
effort
into
getting
that
one
out,
because
that
was
a
lot
of
work
long
time
coming,
but
a
lot
of
work
and
really
good
to
see
them
go
out.
A
A
Yeah
and
actually
a
patch
in
july,
another
minor
in
august
and
then
september,
some
patch
releases
before
the
next
before
16,
goes
long-term
support.
That
actually
probably
will
work
quite
nicely.
A
It
seems
like
we
can
just
leave
it
as
is
and
populate
dates
as
and
when
the
particular
volunteer
has
time.
I
think
that's
probably
a
better
way
of
working
it
if
we
just
say
which
month
folks
are
aiming
for
and
then
it
can
fit
the
dates
to
align
with
what
they
can
do.
A
Yeah,
okay,
I
guess
we
can
always
recap
in
a
couple
of
weeks
and
look
how
it's
going.
That's
it
we,
I
guess,
15
nothing
needing
critical
to
go
out
on
15
and
it
will
go
end
of
life.
Let's
start.
A
A
Okay
next
topic
was
the
transfer
of
the
keys
from
canterbury
node.js
keys
to
node
richard.
Would
you
like
to
just
summarize
what's
happening
here?
If
you
can.
B
Yeah
so,
as
you
can
see
on
the
screen,
this
has
been
open
for
quite
a
long
time
and
it
came
out
of
a
discussion
that
there
was
some
compromise
on
the
key
servers
that
most
of
the
keys
get
uploaded
to.
So
there
was
a
proposal
that,
instead
of
sort
of
relying
on
an
external
set
of
network
of
servers,
that
we
don't
really
have
control
over
that
you
know
we
had
somewhere
that
we
could
actually
have
our
keys
actually
downloadable
from.
B
B
Canterbury
set
up
a
repository
demonstrating
how
this
would
work
and
then
the
proposal
was
to
transfer
it
into
the
node.js
organization
and
it's
kind
of
just
sat
in
the
admin
repo
since
september
2019..
I
believe
we
have
discussed
this
before.
I
can't
remember
exactly
when,
but
I
believe,
we've
sort
of
had
the
agreement
that
this
did
seem
worth
pursuing,
especially
since
we
did
have
issues
before
with
distributing
keys,
especially
when
we
onboarded
new
releases,
because
we
sort
of
pushed
them
up
into
the
key
server
cloud.
But
then
it
would
sort
of
take.
B
You
know
a
couple
of
weeks
for
it
to
hopefully
get
distributed
amongst
all
the
servers,
because
it's
all
decentralized,
so
there
isn't
sort
of
a
master.
You
point
your
gpg
information
at
this
server
and
you
will
guarantee
to
get
the
key
it's.
It
was
a.
We
hoped
that
the
key
would
have
percolated
its
way
over
to
the
particular
server
you
got
connected
to,
and
I
know
in
the
past,
we've
had
people
trying
to
use,
say
the
ubuntu
key
servers
which
is
in
that
network.
B
A
B
It
will
be
something
that
would
be
under
our
control
so
that
you
know
when
we
have
a
new
releaser.
We
can
add
the
keys
into
say
this
repo,
and
you
know
that
that
would
be
yeah
our
source
of
truth
and-
and
there
are
then
additional
comments
about
this
reaper
about
who
should
have
access,
and
I
think
the
general
agreement
is,
it
will
be
the
release
team
or
you
know,
particularly
the
releases,
so
so
the
only
people
that
would
have
right
access
to
this
repository.
B
I
I
guess
the
organization
owners
would
as
well
just
because
the
hub
works,
but
the
idea
would
be
that
it
would
be
extremely
limited
in
terms
of
who
could
write
to
this,
so
that
the
idea
would
be
that
it's
very
controlled
as
to
when
the
keys
are
updated,
because,
obviously,
if
your
key
is
in
here,
you
can
sign
a
release
effectively,
or
at
least
you
can
validate.
You
know
someone
could
validate.
That
release
was
signed
by
the
key
okay
that
was
in
here.
B
I
think
I
don't
think
anyone's
going
to
object
to
the
release
team
having
ownership
of
it.
Certainly
I
don't
think
build.
B
I
think
this
is
originally
sent
to
the
build
team,
but
I
mean
the
build
team:
don't
really
touch
the
gpg
keys
because
it's
all
done
on
the
releases
machines
as
they
come
at
the
release
so
yeah.
I
think
it's
just
from
our
point
of
view
just
resurfacing
that
we
we.
We
think
this
is
a
good
idea
yeah.
We
still
think
it's
a
good
idea
and
and
that
I
guess,
feeding
back
to
the
admin
issue
that
you
know.
B
Yes,
we
would
still
like
to
transfer
it
over
and
take
ownership
of
it
and
there's
a
bit
of
bike
shedding
over
the
repository
name,
and
I
think
I
I
personally
don't
have
an
objection
to
calling
the
repository
release
keys
over
the
generic
keys,
because
I
agree
with
your
your
last
comment.
There
beth
that
I
don't
think
we
should
mix
the
release
keys
with
any
other
gpg
keys.
We
might
have
in
the
org.
B
So
yeah,
I
think
from
our
point
of
view,
it
was
just
a
reaffirmation
that
you
know.
No
one
thinks
this
is
a
bad
idea
and
yeah
just
try
and
then
work
with.
I
guess
the
owners.
I
guess
yourself,
beth,
that's
one
of
them
to
try
and
you
know,
get
that
transferred
over
and
get
the
appropriate
permission
set
up,
and
then
I
I
believe,
we'll
need
to
check
that
the
keys
are
still
current.
B
B
A
Yeah
yeah,
so
I
guess
on
this
call:
does
anyone
object
to
the.
A
Yep,
okay,
so
yeah.
If
we
give
our
thumbs
up
and
just
say
no
concerns
from
release
side
of
moving
the
repository
and
naming
it
no
just
release
keys
and
we
can
probably
get
moving,
perhaps
between
one
of
our
admins,
we
can
just
get
moved
over
and
figure
out
where
to
go
from
there
in
our
next
couple
of
sessions.
A
B
Raise
where
are
we
with
the
releases
email
alias?
Is
that,
quite
as
is
that
just
waiting
on
more
people
to
respond.
A
Yeah
and
I
I
yeah-
I
see
miles's
comment
around
the
discussion
board
only
releases.
Can
you
see
that
discussion
board?
Is
that
right?
Any
members.
B
Yes,
no,
I
think
anyone
in
the
world
could
see
the
teams.
Oh
okay,
but
I
don't
know
you
might
be
able
to
you.
You
may
be
able
to
say
I
think
when
you
post
to
it,
you
can
choose
whether
your
post
is
public
or.
A
Oh
only
two
members
of
the
team
yeah
I've
seen
that
setting
so
the
the
the
main
intention
for
this
alias
was
like
when
there's
a
security
release
that
needs
a
volunteer
releaser.
They
don't
need
to
find
one
of
us
who
then
has
to
go.
Ask
everyone
else
kind
of
like
what
their
availability
is.
They
could
just
either
send
an
email
to
one
place
or
post
something
in
one
place
where
we
would
see
it
and
be
able
to
volunteer.
B
A
A
Yeah
but
yeah,
we
I
think
we
did
have
like
for
one
of
the
previous
security
releases.
Like
folks,
didn't
even
know
we
needed
volunteers,
possibly
because
we
had
like
such
a
massive
notifications
and
some
effects
have
more
than
others.
So
it's
not
always
possible
to
keep
up.
A
A
There's
it
didn't
seem
to
be
a
massive
desire
for
or
massive
like
against,
between
our
groups.
So
that's
why
it's
not
kind
of
moved.
I
don't
know
what
effects
have
more
stronger
opinions
or
better
ways
we
could
handle
that
situation
just
to
bring
it
like
raise
the
urgency
of
these.
C
Releases,
maybe
we
could
name
the
alias
so
that
it's
more
specific
to
what
the
like
the
appropriate
topics
are
so
that
people
are
more.
You
know
when
they're
typing
it
in
it's
like
clear
what
they're
using
it
for,
I
don't
know
like
if
it
was
called
node.js
security
release
or
something.
A
B
Yeah,
that's
correct.
I
think
that
I
think
there
is.
I
think
it
is
called
some
like
security
releases,
something.
A
Yeah,
okay,
maybe
maybe
that
would
make
sense,
then
creating
a
less
specifically
called
security
release
and
yeah,
and
then
that
would
kind
of
enforce.
A
That
sounds
good.
I
can.
I
can
add
that
to
minutes
as
a
proposal
and
then
hopefully
like
point
it
out
in
the
pr
to
match
the
minutes
and
then,
if
folks
have
any
objections
there,
they
can
raise
them
and
then,
if
that
lands
and
people
like
plus
one
spot
it,
then
I
think
go
forward
and
open
the
pr
to
create
that
alias
the
security
release.
One
and
update
the
security
release
documentation
to
email
that
I
think
that
seems
like
a
reasonable
approach.
A
A
I
guess
there's
the
trim
active
releases
list
for
that
one
I
think
all
that's
left
to
do
is
someone
to
go
in
and
wipe
all
of
the
keys
and
then
populate
them
with
the
keys
we
mentioned
in
here.
But
I
guess
that's
like
something
people
would
be
conscious
of
doing,
because
you
don't
want
to
just
go
in
and
wipe
when
you
don't
necessarily
know
what
every
key
was
for.
A
A
Yeah
there's
a
question
there.
So
okay
that'd
be
good.
B
Yeah
no
yeah
mike
was
just
posted
in
the
chat
that
there's
a
number
of
keys
without
label,
which
I
I
think
I
think
does
tie
in
what
I've
seen
before
yeah
yeah.
At
worst,
we
can
probably
save
it
away
in
the
ssh
directory
with
the
sort
of.
A
B
Yeah,
well
I
mean
these
are
these.
This
is
specifically
the
ssh
keys,
not
the
not
the
gpgs.