►
From YouTube: 2023-01-12 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
Okay,
welcome
everyone
to
the
release
working
group
meeting
so
we're
here.
We
have
an
agenda
here
to
follow,
but
before
we
get
started
to
anyone
else,
have
any
announcement
they'd
like
to
share
anything
want
to
bring
it.
A
B
Yes,
I
opened
that
we
do
have
scheduled
meetings,
but
I
think
there's
still
an
open
questions
to
the
frequency
as
to
whether
we
want
them
once
a
month
or
every
four
weeks,
which
is
what
we
had
before.
Beth
has
pointed
out
that
having
them
every
four
weeks
means
that
we
avoid
clashing
with
a
security
working
group.
B
Was
it
security
with
another
meeting
so
having
the
once
a
month
means
that
we
would
eventually
run
into
clashes
whereas
having
them
every
four
weeks,
so
I
believe
that
there
is
a
calendar,
Michael
Craig's.
The
calendar
thing
which
is?
B
Is
that
going
out
once
a
month,
so
we
probably
just
need
to
resolve
the
frequency
and
then
or
the
this
Zoom
link
had
expired,
but
Beth
has
extended
that
so,
hopefully
that
that
has
been
resolved
as
well,
although
might
need
to
get
that
added
to
the
calendar,
invite
but
yeah
yeah.
That
issue
is:
is
there
I,
I
open?
It
will
disappear
by
the
time
of
my
next
meeting
and
we'll
never
resolve
yeah
issues.
C
B
B
With
every
four
weeks.
A
Yeah,
yeah
and
I
think
there
is
no
opposition
to
it.
It's
just
that
when
I,
when
I
went
to
reach
out
to
to
Michael
Dawson
I
just
had
in
the
top
of
my.
A
Like
and
yeah.
C
Yeah
good,
it's
pretty
much
done.
I
I
had
to
log
into
Zoom
to
re-enable
the
webinar,
but
that's
all
done,
though,
and
not
a
problem.
Hopefully
until
next
year,.
C
So
there
is
a
process
for
getting
access
to
the
calendar.
You
get
added,
I,
think
you'll
get
added
to
a
Gmail
group
or
something
which
grants
you
access.
As
someone
hosting
a
meeting
I
think
at
least
at
the
time
when
I
started
hosting
meetings,
I
was
told,
apply
for
the
calendar
access,
so
you
can
add
it
to
the
calendar.
So
it
might
be
worth
us
going
through
that
and
getting
you
added.
C
A
Right
makes
sense,
makes
sense.
Yeah,
okay,
I,
see
Raphael
doing
you
promote
the
panelists.
A
A
And
okay,
let
me
skip
here
to
the
third
issue
in
the
agenda:
let's
leave
the
release
plans
out
to
the
end,
so
there
is
a
npm
9..
It's
still
hearing
the
agenda
and
I
wanted
to
confirm
with
you
all.
It
is
just
following
the
schedule
we
had
agreed
before
right.
It's
good
to
have
it
land
in
the
18
staging
Branch
now
and
have
the
npm
9
go
out
in
the
31st
January
release
right
I
mean
there's
just
no
opposition
to
that
right
like
it's
what
we
agreed
before.
A
C
It
sounds
like
what
you
at
least
might
want
to
act
or
ping
to
say
this
is
happening,
maybe
tag
it
for
TSC
agenda
I,
don't
know
we
might
want
to
surface
this
a
bit
more
broadly,
if
someone's
here
real
issue
with
it,
so
they
don't
get
hit
by
it
again.
A
A
Yeah
now
I
can
speak
up
to
the
to
that
particular
point.
I
think
I
saw
the
the
comment
there.
It
was
just
the
login
method
to
npm
that
it
changed
the
default.
So
I
think
it
was
the
old
TP
that
now
is
defaulting
to
go
to
the
website
and
and
do
the
whole
OTP
dance
in
the
browser
instead
of
having
it
in
the
command
line
and
yeah
and
then
basically
Jordan
was
just
saying:
yeah.
Well,
it
kinda.
It
is
not.
A
My
workflow
I
was
expecting
it
to
have
the
the
same
workflow
as
before
OTP
and
the
command
line
and
dope.
But
there
were
well
I
mean
there.
Is
that
list
of
Breaking
Chains
I'm,
not
sure
I'm,
not
100,
sure
that
was
outlined
in
the
list
of
Breaking
changes
that
went
out
with
the
change
level
right,
but
it
sounds
like
the
kind
of
breaking
chain
that
they
were
planning
for,
and
it's
not
something
like
that
that
prevents
anyone
from
just
using
the
the
npm
CLI
or
the
origin.
You
know
the
anything
with
node.js.
D
A
A
Yeah
no
I,
remember
yeah,
they
do
have
it
I,
don't
know.
If
it's
publicly
available,
though
that's
a
good
point
but
yeah
but
I
know
it
tends
to
go
over
very
aligned
with
the
node.js
releases
that
the
the
CLI
landed
in
right.
So
it
will
probably
align
with
the
adoption
of
the
19
version
right.
D
B
A
D
A
Yeah,
no
and
I
think
it
it's
only
when
you're
trying
to
log
in
or
publish
yeah
without
providing
the
OTP
I
think
like
if
you
still
provide
the
OTP
flag,
I
think
it
still
behaves
the
same
as
before.
I
think
it's
just
the
default
mechanism.
I.
E
Do
do
we
ship
npm
9
in
the
19
release
right
yeah,
so
we
might
we
I,
don't
know
if
we
have
data,
but
we
can
just
Loop
to
the
to
how
many
downloads
do
we
have
on
windows.
At
least
that
comes
with
the
with
the
npm
binary
directly
and
Chuck.
If
I
don't
know,
I'm
looking
to
the
issues
and
we
apparently
we
don't
have
anything
on
on
the
web
or
even
in
the
GitHub.
Regarding
that
so
I
think
we
are
safe.
A
D
E
Who
did
be
decays
of
a
knight,
build
or
something
like
that?
Like
a
release
candidate
for
18,
just
with
the
npm
9
just
before
I,
don't
know
for
maintainers
only
or
something
like
that
just
to
check
before
landing
it
directly.
C
For
the
value
maybe,
and
if
maintained
I
guess
if
maintainers
want
to
try
out,
they
could
mpm
upgrade
locally
and
the
main
I
think
like
Michael
was
saying.
E
D
Yeah
and
I
I
think
practically.
There
are
much
less
people
who
you
who
try
RCS
than
the
current
release.
A
D
B
Only
time
I've
ever
seen,
feedback
from
release
candidates
is,
if
someone
has
has,
has
a
specific
issue
that
we've
fixed
in
a
release
and
have
said
this
is
fixing
this
release.
Candidate
and
they've
verified
that
their
particular
issue
has
been
fixed
but
not
I,
I,
don't
recall
ever
seeing
General
feedback
on
a
release
candidate,
it's
usually
quite
highly
targeted,
as
at
a
you
know,
a
particular
fix
that
someone
was
interested
in
and
wanted
in
in
a
in
an
LTS
sort
of
current.
It's
normally
LTS,
because
we
don't
normally
do
release
candidates
recurrent.
E
Yeah
so
well,
I
think
one
thing
that
I
don't
know
if
that's
valuable
though,
but
I
I
know
that
most
of
CIS
use
their
setup
node
and
we
can
I
don't
know,
maybe
talk
with
them
and
create
a
branch
for
with
with
any
PM9
by
defu.
So
maintenance
can
just
use
the
specific
version
that
that
contains
the
npm
9
and
see
if
the
CI
breaks
or
not
but
yeah.
It
also
might
be
too
much
work
for
a
low
value,
so
yeah
I
think
we
are
good.
C
B
C
C
A
C
If
we
can
open
that
PR
and
we
have
confidence
earlier-
that's
okay,
but
you
know,
let's
see
how
the
runs
go.
I
think
because
I
think
the
next
is
the
next
19,
not
until
the
like,
almost
February
anyway.
So
I
think
I'm
not
sure
we'll
review
our
schedules,
but.
C
D
A
A
A
C
A
It
is
a
statement
in
which
yeah
we
want
to
validate
that
there
is
no
potential
CI,
but
regarding
that
issue
with
the
OTP
right,
like
changing
that
default
value
right,
could
that
somehow
impact
CI
environments?
I,
don't
think
so,
but
maybe
I
don't
know.
Okay,
I
think
something
we
want
to
validate
right.
C
C
D
A
A
C
I
I
can't
I
can't
remember
last
time,
I,
skimmed,
City
and
I
was
like
100
plus
failures.
So
I
don't
know,
I,
don't
know
how
much
is
hidden
in
that
noise
of
red.
So
maybe
we
want
to
join
get
that
in
a
healthier
state,
so
we
can
get
more
feedback
from
it.
I
don't
know.
A
A
B
B
I
think
that
was
finding
people
to
to
actually
do
the
release.
The
major
releases
so
I
guess
we're
now.
Looking
at
node,
20.,
yeah
yeah.
E
Well,
I
was
talking
internally
at
near
Foreman
for
the
night
for
the
20
I
can
handle
it
too,
but
yeah
I
think
the
description
is
also
worth
it.
Regardless
of
we
have
some
1
to
20
or
not.
C
Yeah
I
think
we
I
think
we
discussed
this
and
came
to
a
resolution
that
there
was
no
point
trying
to
plan
it
like
months
and
months
in
advance,
and
we
would
just
say
three
or
three
or
four
months
before
the
release.
We
need
to
come
to
it
like
start
trying
to
find
a
volunteer
or
volunteers
for
for
the
upcoming
release.
C
It
sounds
like
we
might
have
just
done
that,
so
we
might
be
good
for
this
time,
but
we
probably
need
to
update
our
documentation
somewhere
to
say
it's,
probably
in
the
digest
release,
documentation
to
say
three
or
four
months
before
the
release.
We.
D
E
I
I
think
we
can
also
just
I,
don't
know,
go
to
to
our
it's
like
Channel,
node.js,
Dash
release
and
asked
to
to
remind
us
every
six
months
to
about
like
who
will
be
the
next
secret
major
secret
to
really
major
releaser
and
just
just
to
not
forget
you
know,
because
now
I'm
pretty
sure
bats
will
never
forget
it.
But
I
I,
don't
know
about
me.
I
always
forget
things
so.
E
B
C
A
Okay,
I'll
leave
a
comment
here
in
the
issue
saying
that
these
are
actually
the
things
that
we
are
waiting
to
take
and
then
can
probably
close
this
issue,
but
yeah
so
just
make
sure
we
update
the
detox,
and
maybe
someone
can
create
some
type
of
automation
to
make
that
call
every
six
months.
Yeah
calling
for
releasers.
E
A
I
need
a
calendar,
otherwise
I
can
tell
when
they're
your
next
one.
So.
A
Okay
and
I
think
that's
good
for
painting
feel
free
to
jump
in
put
your
name
there.
If
you
want
to
plan
something
for
the
future,
but
it's
looking
good,
it's
already
mid-February
there.
So,
let's
yeah,
let's
take
a
look
at
the
other
ones,
so
18,
which
has
the
yeah
the
release
date.
We
were
mentioning
before
right
end
of
the
month.
I
saw
one
is
already
signed
up
here.
A
A
E
D
Since
we're
talking
about
release
Keys,
someone
opened
an
issue
that
there
was
the
last
release
was
apparently
signed
with
a
key.
That's
not
in
the
key
ring.
E
E
B
Yeah,
we
probably
didn't
update
the
key
ring
in
this
repo
I
think
we
updated
the
keys,
but
not
the
key
ring,
oh
okay,
it
might
be
it
and
if
so,
I
would
have
expected
Daniel's
key
to
be
in
there.
But
if
it's
talking
about
the
release
before
that,
which
was
once
then
you
and
but
one
where
the
most
recent
key
editions
I
think
so
it.
B
D
They,
if
the
we
definitely
have
PR
stuff,
they
posted
a
key
like
here
Exodus
version
of
a
key
in
in
the
issue,
and
it
doesn't
exist
in
the
readme.
D
For
the
six
one
FC,
yes,.
E
Okay,
it's
ruin
keys,
so
it
shouldn't
be.
It
should
be
failing
because
we
removed
that
key.
B
A
B
B
C
E
C
D
Yeah,
maybe
we
should
try
to
run
the
same
command
as
the
person
who
opened
the
issue,
see
if
it.
B
I
I
suspect
this
is
going
back
to
I
I.
Don't
think
the
key
ring
has
all
the
keys
in
it.
So
so
this
repository
has
keys,
but
it
also
has
a
key
ring
and
I.
Don't
think.
E
E
On
this
issue,
no
I
I
have
one
thing
to
comment,
but
we
have
we
finished
the
list.
The
the
agenda
well.
E
Okay,
let
me
share
an
issue:
I
think
you
won't
know
about
it,
but
it's
worth
to
to
mention.
We
have
yeah.
A
B
E
14Th
there
is
the
security
one
I
think
we
need
to
bring
it
we,
it
is
also
in
the
agenda.
Actually,
if
you
look
to
the
there
is
a
dependency
vulnerability
assessment
we
have
a
CV
to
fix,
so
probably
would
be
great
to
to
perform
a
regular
release
on
14
to
include
that
back
part.
B
Yes,
yeah,
yeah
and
I
suppose
the
other
question
there
is
there
are
CVS
being
addressed,
but
is
there
an
assertion
that
these
are
not
actual
security
issues
for
npn
I
guess
the
question
is:
are
we,
how
are
we
comfortable,
releasing
the
npm
update
in
a
non-security
release,
or
would
we
be
marking
the
no
14
release
as
a
security
release,
No.
E
Actually
we
we
assessed
that
and
well
it
doesn't
affect
node.js
directly,
so
it
might
land
in
a
regular
release.
So
well
that
that's
the
the
point,
even
though
the
the
pull
requests-
and
this
issue
is
public,
so
really
I-
don't
think
that
we
need
a
secret
release
for
that.
Okay,.
B
A
Yeah
I'm
kind
of
yeah
kind
of
been
waiting
for
that,
but
yeah
oh
yeah
I'll
try
to
follow
up
in
actually
schedules
at
some
point
for
that
that
working
really
easier,
so
okay,
yeah
I,
think
that's
all
I'll
probably
update
the
release
working
here
later,
but
yeah
Rafael.
If
you
wanna,
go
ahead.
E
E
We
all
know
how
how
difficult
is
to
perform
our
time
consuming
is
to
perform
a
secret
release,
and
my
intention
is
I
know
that
I
can't
automate
everything,
but
I'm
really
I'm,
pretty
sure
that
we
can
automate
like
very
basic
stuff
like
open
an
issue
to
the
build
repo
or
sending
emails
to
to
the
to
the
Google
Mail
list,
I,
guess
and
well.
My
intention
is
to
reduce
that
those
42
steps
to
at
least
20
and
I'm.
E
The
next
one,
but
I
will
I
will
answer
you
all
I'm,
also
looking
at,
we
probably
might
need
to
to
to
generate
the
cves
from
from
that
about
automation
too
I'm,
just
not
sure
about
how
how
it
can
work
and
also
I
had
an
account
this
week
with
a
product
owner
from
GitHub,
and
she
told
me
about
the
the
how
to
report
a
security
vulnerability
on
directly
on
on
on
GitHub
and
like
I,
have
suggested
also
that
whenever
someone
opened
an
issue
that
might
be
a
vulnerability
that
should
be
reported
on
hacker
one.
E
We
transfer
it
to
that
platform.
That
would
be
a
good
thing,
but
probably
I
think
we
we
might
need
to
discuss
at
some
point
if
how
useful
would
would
be
to
us
to
to
to
generate
the
CV
instead
of
hacker
one
but
directly
on
on
GitHub,
and
then
we
can
automate
it
way
better
for
this
script,
but
yeah,
just
a
heads
up
that
I
will
be
working
on
that
probably
next
month
and
soon
as
I
have
something
I
will
share
with
you
all.
Then.
E
Yes,
if,
if
you
have
any
thoughts
on
that,
please
sharing
the
issue.
I
will
try
to
answer
as
soon
as
possible,
but
that's
it
yeah.
B
My
my
main
comment
in
the
issue
was
I
think
you
said
there
was
a
suggestion
about
a
note,
called
util
function
to
do
Automation,
and
my
point
was
there
already
is
one
for
releases
and
then
I
think
Beth,
fixed
band
is
saying
that
there
are
potential
things
it
could
be
doing.
B
In
addition
to
what's
already
doing-
and
my
point
was
just
there's
automation
for
security
releases
for
the
actual
releases,
but
then
there's
also
the
Automotion,
which
is
more
of
what
you
were
talking
about
in
the
issue
about
for
the
stewards,
so
the
the
person
overseeing
the
security
release,
who
would
then
be
the
one
who
is
opening
sort
of
issues
in
in
build,
or
you
know,
fire
filing
the
CVS
and
stuff,
so
I
believe
that
automation
is
worth
doing.
B
It
is
I,
think
separate
from
automation
or
the
releases,
so
the
actual
people
doing
the
the
actual
mechanics
of
you
know
the
actual
19
or
20
or
whatever
release
it
is
so
I.
Don't
necessarily
think
that
that
that's
the
same
I
think
both
automations
worth
doing
it's
just
it's
not
the
same
person
or
come.
A
C
Think
there
might
be
some
overlap,
though,
because
Mateo's
recent
suggestion,
which
was
hey-
if
we
can,
you
know
when
we
file
a
cve.
Let's
do
it
in
PR
form
in
a
structured
format
that
then
either
you
copy
in
or
we
use
automation
to
generate
it.
If
that
existed,
and
it
had
the
cve
title
and
the
severity
and
description,
then
that
might
actually
satisfy
the
need
in
the
change
law
and
the
change
from
generation
tooling,
so
yeah
we
could
actually
just
pull
that
information,
so
the
same
solution
might
actually
benefit
both
places,
but.
B
E
Yeah,
actually,
yes,
the
the
first
step
I
mean
the
first
iteration
would
be
just
simple
things
like
open
the
issue.
Automatically
get
I,
don't
know
list
all
the
the
pull
requests
opened,
approved
and
add
as
a
description
of
the
of
the
next
secret
release
issue
and
do
the
the
requests
for
the
release
announcements
in
private.
You
know
all
the
all
the
list,
the
steps
that
we
have
and
then
probably
in
a
second
iteration.
E
We
can
do
those
I
think
this
is
a
bit
more
sensitive,
so
yeah
once
we
have
the
foundation
I
think
we
can
think
about
generating
cve
or
even
performing
the
the
secrets
release
automatically
I,
don't
know.
B
And
in
terms
of
the
features
in
GitHub,
they
didn't
exist
when
a
lot
of
the
process
was
put
together.
So
I
guess
there
might
be
some
scope
for
adapting
or
or
changing
the
process,
but
I
mean
the
process
is
in
place
way
before
way
before
GitHub
was
doing
security,
vulnerability
reports
and
things
so
and
I
think
in
terms
of
cve,
raising
I
think
we
were
raising
cves
before
we
moved
to
hacker.
B
One
I
think
we
did
have
like
I
can't
remember
like
what
it's
called
we
did
have
whatever
it
was
that
allowed
us
to
open
cves,
but
we
stopped
doing
that
when
we
moved
to
hacker
one
yeah
without
moving
back
again,
because
I
think
part
of
the
process
is
we
do
open.
We
do
end
up
creating
Json
files,
don't
we
for
the
cbes,
but
that's
a
post
thing
rather
than
a
pre-think.
E
Anyway,
no
okay,
yeah,
so
I'll
keep
you
all
posted
sounds.
C
A
If
not,
I'll
just
go
ahead
and
stop
the
meeting.