►
From YouTube: 2023-02-09 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
All
right,
yeah,
we
should
be
live
on.
Youtube
now
welcome
everyone.
This
is
the
release.
Working
group
meeting
and
yeah
today
is
the
9th
February
and
we're
here
to
talk
about
other
release.
Things
going
on.
We
have
a
quick
agenda
here,
but
before
we
get
to
that,
to
anyone
has
any
announcements
anything
they
would
like
to
bring
up.
B
Yes,
we
have
some
security
releases
announced
for
next
Tuesday
Valentine's
Day,
so
you
go
to
the
node
website.
There's
a
little
Banner
that
sort
of
gives
a
little
heads
up
more
details
that
we
announced
will
be
posted
on
that
page
when
we,
the
releases,
are
done
but
yeah
we're
currently
preparing
those.
If
you're
a
collaborator,
the
Ci's
been
locked
locked
down
restricted
to
people
working
on
the
release.
So
that's
that's
ongoing.
C
Oh
I
have
something
also
to
share
since
it's
not
your
agenda.
I
just
made
a
pull
request.
I
sent
in
the
chat.
I
was
talking
with
that
with
that
about
it,
basically
including
an
option
to
the
git
node
release
to
prepare
a
proposal
for
security
release
as
well
so
I
as
you
can
see
in
the
pre-request.
There
is
a
log.
Currently
it
is
not
totally
automated.
It
will
stop
to
let
you
to
to
amend
commits,
but
after
that
I
think.
C
That's
good
I
have
made
the
proposal
for
16
for
19.6.1
using
that
that
script
and
it
seems
to
work
I
still
think
that
we
might
might
want
to
update
a
few
things
like
the
git
commit,
and
the
change
log
is
not
totally
accurate,
but
I
think
it's
ongoing
work
I've
been
doing
that
I
I
would
do
I
work
in
that
in
the
next
month.
C
Firstly,
to
make
git
node
land
on
private
Heap
works
and
then
a
month
to
that
to
that
script
and
after
that
is
to
work
in
the
other
side
like
how
to
generate
the
next
security
issue
with
all
the
steps
automated.
Hopefully
it
will
be
a
good
thing
for
us,
but
yeah.
We
have
something
ready.
A
That
looks
great
yeah
and
what
is
the
workflow
you?
You
were
kind
of
thinking
for
for
the
for
the
git
command
you,
you
kind
of
like
share
it
pick
the
commits
first
or.
C
Do
that,
basically,
if
you,
if
you
look
to
the
the
request,
you'll
see
that
there
is
a
log
if
you
click
there.
Basically,
if
you
call
node
release,
that's
that
secret
that
that's
Dash
prepare,
it
will
create
the
branch.
C
Basically,
it
will
ask
you
to
go
to
the
dot
X
Branch
instead
of
staging
that's
the
river
or
workflow
for
secret
ones,
and
then,
if
you
create
the
branch
and
wait
you
to
chart
pick
the
comments
manually
in
another
in
another
terminal,
that's
kind
of
hacky
but
I
think
that's
that's
way,
it's
more!
For
than
like
having
a
step
and
go
direct
to
this
step.
This
will
be.
This
will
make
the
request
more
complex
away
and
I.
Stop
it
there.
C
So,
for
instance,
where
all
the
patches
that
chart
picket
with
no,
it
will
say
a
warning.
Okay,
go
to
another
terminal
and
chair
pick
all
the
comments
and
then,
when
you
press
yes,
it
will
follow
the
regular
workflow
like
updating
the
node
version,
updating
the
replacement
change
log
and
then
create
the
commit.
A
Right
now
it
might
yeah
it
might
be
a
personal
preference.
We
might
follow
up
in
the
pr
here,
but
I
would
prefer,
like
maybe
break
into
two
commands
right
like
like
a
one
like
start
that
will
you
know,
do
the
check
and
bring
open
the
proposal
branch
and
then
have
like
a
finish
or
or
a
change
log
right
like
command
that
those
the
rest
of
the
stuff
right
so
that
you
kind
of
could
have
that
other
logic
in
the
same
terminal,
right,
yeah,.
C
It
would
need
to
to
change
the
the
not
just
the
pull
requests
a
lot,
but
the
the
this
comment
a
lot,
because
currently
this
is
the
workflow
for
regular
release.
It
won't
stop
to
let
you
do
because
it
does
it
everything
automatically.
C
B
No
I
was
just
gonna,
say,
I
think
there
is
I
think
in
the
normal
Landing
workflow,
when
you
when
it
asks
you
whether
you
want
to
amend
the
commit
message.
There
is
some
some
way
of
interrupting
like
the
workflow,
where
it
waits
for
you
to
do
something,
and
then
you
basically
run
the
same
command
with
like
dash
dash
continue,
and
it
continues
the
steps
from
where
it
is.
So
that
would
be
a
way
if
you
didn't
want
to
do
a
sort
of
you're
halfway
through
then
you're
on
another
terminal.
B
You
know
effectively
some
way
of
saying
like
a
yes,
no
question,
you
say
yes
or
no,
whatever
the
correct
answer
is
and
then
it
sort
of
stops,
you
continue
what
you
do
and
then
at
some
point
you
you
know
do
run
the
same
thing
with
a
continuing.
It
picks
up
where
you
left
off,
but
I.
Don't
remember
enough
of
how
no
call
utilities
works,
I,
think
there's
like
a
session
class
or
something
that
holds
the
state,
but
it
is
possible
I.
B
Think
to
do
that
where
you
sort
of
you
start
something
you
get
a
yes,
no
question.
You
answer
a
particular
way,
then
it
basically
stops
until
you
then
rerun
the
thing
with
continue.
So
I,
don't
think,
is
it
possible
it?
Might
it
may
be
something
that
maybe
whatever
whatever
we
land
is
the
the
first
step
that
could
be
like
a
future
enhancement
or
something
called
you
know
the
does
it?
Okay,
let's
discuss
it
in
the
in
the
pr.
A
Ize,
okay,
then,
let's
get
on
with
the
regular
agenda
here
we
do
have
a
first
item
here,
oh
yeah,
which
is
a
new
item
here
that
was
brought
up
by
one
of
the
club
warriors
confusion
around
sember
minor
commits
so
yeah
I
saw
that
Richard
you
you
both
commented
on
it
already.
Do
you
wanna
kinda,.
D
Yeah,
that
would
that
was
some
confusion
and
a
couple
of
PRS
around
just
how
we
approached
some
of
the
miners
and
our
notable
changes
and
I
think
amongst
releases
and
our
tooling.
We
kind
of
agree
that
by
default
all
seven
for
miners
get
marked
as
notable
changes
unless
it
happens
to
be
an
exception
where
it's
really
not
end
user-facing,
we
shouldn't
call
it
out
so
I
think
what
we
would
need
to
do
from
our
side
as
a
releaseer
is
just
be
clear
that
that's
what
we
do.
D
We
default
to
marking
all
seven
for
miners,
as
so
notable
unless
there's
an
ask
from
another
collaborator
or
the
author
to
indicate
otherwise
right,
like
that's
our
position
today,
maybe
we
should
document
that
and
then
revisit
the
conversation
of
whether
we
should
change
our
position
at
a
later
time
or
maybe
on
a
different
PR.
B
And
I
think
there
was
a
little
bit.
There
was
a
comment
as
well
about
the
actual
label,
the
notable
change
label
and
whether
that
was
misleading
or
confusing
I
guess:
I.
B
So,
instead
of
like
a
one-line
change,
log
entry,
you
know
our
our
default
would
be
for
say:
December
miners
would
be
to
just
list
the
commit
commit
titles
and
commit
hashes,
but
I
think
you
know.
Our
idea
of
the
notable
change
thing
would
be
that
you
know
we
would
actually
want
more
words
in
the
changelogs
for
those
but
I
think
some.
B
There
was
some
suggestion
that
you
know
things
without
the
notable
change,
weren't
notable
which
again
maybe
this
comes
back
to,
like
you
know,
explaining
all
Clarity
or
even
if
it
you
know,
could
come
up,
come
up
with
a
different
different
set
of
words
for
that
label,
but
yeah
and
then
I,
don't
know
if
it
was
on
the
agenda.
But
Beth
you
had
a
suggestion
about
automating
notable
changes.
D
Yeah
just
the
idea
of
like
when
someone
adds
the
label
the
boppings,
it
says:
hey,
you
added
a
label.
Do
you
want
to
supply
some
more
info
and
then
give
them
a
field
to
add
that
info?
So
we
can
just
copy
it
a
list
of
the
benefits
in
the
pr.
D
You
know
it
means
it's
consistent
between
versions
and
it
might
help
us
crowdsource
it
a
bit
more,
but
I
guess
we'd
need
to
handle
still
the
default
where,
if
someone
doesn't
Supply
anything
in
that
box,
it
still
should
be
in
the
notable
changes,
but
just
with
the
commit
title
as
as
normal
as
it
is
today,
yeah
just
an
idea.
We
need
to
work
on
it
and
implement
it.
I'm
sure
it
should
be
possible.
A
Right,
yeah
and
I
haven't
I,
haven't
I
mean
I,
haven't
done
too
much
reading
to
what
was
going
on
with
the
specific
PR
that
was
brought
up
there,
but
I'm
just
kind
of
like
afraid
that
these
labels
might
like
just
have
a
charge,
meaning
for
for
some
other
people.
I
can
avoid.
You
know
having
discussions
about.
Oh,
whether.
A
D
That
might
be
an
addition
to
our
clarification
as
well,
and
we
might
need
to
say
all
seven
for
miners
are
notable
unless
either
the
releaser
or
the
another
contributor
has
stated
that
it
it
should
be
demoted,
and
it's
not
interesting
enough
to
be
well
interesting,
is
not
the
correct
word.
It's
a
not
something.
An
end
user
needs
highlighted
at
the
top
of
the
change.
Look
yeah.
C
Yeah
the
explanation
is
I
mean
if
I
see
a
pull
request
with
just
someone
included,
they
add
a
notable
chain
or
notable
change
label
without
explaining
why
that's
notable,
if
that's
not
a
simple
reminder,
I'm
tempted
to
just
remove
it.
You
know.
D
B
Think
I
think
that's
the
appeal
of
the
the
automation.
You
were
suggesting
that
if
there
is
a
set
thing
that
we're
expecting
that
we
get
people
used
to
bullying
and
then
when
people
ask
well
what
why
why
hasn't
this
shown
up
and
point
them
and
say
well,
there's
a
box
here:
you'd
fill
that
in
you
would
have
got
it
automatically
or
something
yeah
it
won't.
If
we
get
that
Tooling
in
place.
A
A
The
last
item
before
the
release
plans-
let's
talk
about
the
npm
9
I
noticed
there
were
some
activity
this
week.
Apparently
there
was
some
sort
of
breaking
change
that
was
disturbing
people
workflow,
so
did
any.
What
did
anyone
here?
Follow
that
with
this
conversation
that
wanna
to
add
anything
about
it.
B
I
haven't
followed
it
that
much
I
did
see
that
there's
been
a
patch
release
of
npm
to
revert
a
default
default
value
for
one
of
the
the
options
I
don't
know.
If
that's
all
the
issues
that
were
that
people
were
fine,
I
I,
think
I've
seen
two
and
I
can't
remember.
If
the
other
one
was
folded
into
this
one
but
yeah
it's.
A
B
The
interesting
thing
about
this
one
was:
we
were
a
bit
cautious
with
npm9
in
that
we
didn't
drop
it
straight
into
18
and
and
yet
this
particular
issue
hadn't
been
flagged
until
the
point
we
dropped
this
into
the
LTS
release,
so
that
was
unfortunate.
B
Somebody
did
open
another
issue
in
the
release
repay,
which
I,
don't
think
is
on
the
agenda,
which
is
trying
to
talk
about
more
generic,
dropping
npm
updates
into
the
LTS
branches
and
yeah
I,
guess
that
needs
to
that
needs
to
be
looked
at
at
some
point.
It's
it's
a
fundamental
disconnect
where
you
know
we
bundle
this
thing
in
this
case
the
the
package
manager
and
they
don't
actually
have
the
same
sort
of
LTS
policies
that
we've
got
the
node
releases.
D
I
think
the
way
they
would
we
were
trying
to
mitigate
that
was
getting
the
agreement
with
mpm
and
node
to
say
this
is
what
we
believe
is
breaking
in
the
context
of
being
bundled
in
mode.
So
I
wonder
if
we'd
need
to
take
that
a
step
further
and
have
tests
in
node
core
that
represent
all
of
those
cases
that
you
know.
We
say
these
are
the
things
that
we
class
as
a
breakage
in
npm
in
the
context
of
node,
and
they
need
to
be
tasked
within
our,
maybe
not
within
our
repo,
but
at
least
run.
B
And
I
think
that's
the
challenge,
isn't
it
it's
getting
those
cases
and
having
the
test
for
all
them
in
a
way
that
we
can
run
ideally
like
in
an
automated
test
Suite,
whether
that's
part
of
the
regular
flows
or
whether
that's
certain
or
some
other
testing
tool,
but
I
think
the
challenge
is
identifying
those
cases
and
having
to
test
for
them,
because,
whatever
we've
been
running
currently
and
whatever
npm
has
been
running
on
their
side,
hasn't
caught
this
or
hasn't
flagged
it,
at
least
as
as
you
know,
breaking
for
the
situations
that
this
particular
whoever
reported.
B
The
issues
against
18
ran
into
yeah.
D
I
guess
yes,
if
we
get
to
the
point
where
we
can
agree
on
what
those
are,
we
can
then
start
adding
regression
tests
and
hopefully
getting
better
over
time
kind
of
thing.
But
I
don't
know
it
feels
like
that's
the
inevitable
path,
because
the
only
alternative
is
to
try
and
get
agreement
on
major
version
support
for
three
years,
but
I
don't
think
it
sounds
like
that's
going
to
fit
with
their
LTS
policy.
A
There
is
also
there
yeah
that
possibility,
but
yeah
no
I
can
definitely
stopped
by
one
of
one
of
their
calls
one
day,
one
of
these
weeks
and
no
way
I
can
let
them
know
it
would
be
nice
to
have
you
know
either
miles
or
someone
from
the
mcli
team
joining
the
next
meeting
and
like
talking
about
that
I
kind
of
yeah,
I
kind
of
like
see
like
it
would
be
ideal
to
at
least
try
the
time.
A
Banner
right,
like
I,
think
this
this
time
it
was
kind
of,
unfortunately
like
very
disconnected
from
our
but
yes
and
from
our
schedule,
right,
like
in
general,
yeah.
D
I
think
the
issue
this
time
I
think
we
shipped
a
new
major
version
of
node
and
then
a
few
weeks
later
or
within
that
small
window,
the
new
version
of
npm
came
out.
So
if
there
was
a
way
for
the
npm
released
to
happen
in
enough
time
for
it
to
be
shipped
in
the
October
or
April
note,
release
I
think
that
would
be
it'd
be
better
if
they
were
one
month
earlier
than
us
than
oh.
A
B
That
still
doesn't
answer
the
issue
about
upgrading
in
the
middle
of
an
LTS.
A
A
Like
because
the
insta
was
definitely
like
part
of
the
API
that
we
agreed,
that
npm
couldn't
break
right
like
and
and
they're
reverting
it
right
like
we're,
gonna
ship,
the
fix
and
like
that's,
okay,
right,
like
from
a
from
a
standard
point
of
view.
I
guess
like
so.
If
some
anything
breaks
in
npn
install
like
that's,
that's
kind
of
an
API
that
we
shouldn't
be
breaking
in
LCS.
A
Okay
but
yeah:
let's
continue
that
conversation
then
about
the
issues
and
following
up
meetings.
A
C
Thing
to
mention
here
is
that
there
is
a
release
plan
for
for
Targus
for
the
same
date
as
the
secret
release.
So
it
should
be,
it
probably
will
be
postponed
one
week.
I
guess.
E
A
C
Yeah
so
I
I
need
I,
mean
I,
won't
be
able
to
perform
release
between
21
and
April
30,
because
I'll
be
I'll,
be
traveling,
so
and
and
my
machine.
The
the
sign
machine
is
not
the
same
one
as
a
I
think
bring
to
their
to
their
conference
and.
D
C
Okay,
yeah
so
yeah
April.
Seven,
it's
good
to
me.
B
A
A
A
Probably
review
this
later,
it's
hard
to
type
and
share
a
screen
present
at
the
same
time,
but
it
looks
good.
We
have
someone
planned
that
well,
if
yeah
with
all
that
said
like,
if
anyone
wants
to
volunteer
for
21
and
April
4.,
we
have
those
both
of
these
dates.
C
C
F
C
Okay,
at
March,
21
right.
A
C
A
E
A
A
A
A
C
Is
it
breaking
when
you,
when
you
mean
braking,
is
just
the
npm
CLI
or
something
that
is
is
bumped
inside
node.js?
Is
the
npm
calls
like
ndpm
installer
npm,
something
right.
D
Yeah,
that
option
would
be
do
we
make
a
rare
case
exception
to
bundle
it
in
with
the
security
release
and
just
say:
look,
this
is
stopping
people
adopting
it.
We've
made
this
decision,
it's
not
normally
what
we
do,
but
you
know
if
it's
going
to
inhibit
people
getting
the
security
features
and
it's
such
a
known
problem,
then
I
don't
know.
A
D
E
B
F
E
E
D
E
E
E
A
F
F
C
Honestly,
I
think
that
yeah,
if
we,
if
we
include
the
npm
reward
in
that
patch,
it
will
still
be
a
kind
of
breaking
change
for
users
that
already
adopted
the
new
way
of
ndpm
9
right.
So
I
I
see
that
in
another
minor
proposal
is
that.
A
A
B
Mean
the
other
thing
about
dropping
it
into
18
is
our
usual
policy
is
to
drop
things
into
currently.
First,
this,
the
npm
update,
will
not
be
in
the
current
release.
Okay,
yeah.
A
E
B
The
next
current,
so
I'm
I'm,
okay,
making
an
exception
for
that
Brighton.
If
it's
you
know,
has
broken
people
but
yeah.
It's
something
to
consider
as
well
that
we
will
not
have
had
any
any
sort
of
on
the
field
field,
testing
of
a
node
release
with
that
that
version
of
npm
in
it.
A
Yeah,
okay,
I'll
I'll,
leave
it
open
for
now
we
we
can
wait
to
see
if
we
actually
get
anyone
to
volunteer
for
the
the
28
release
right
like
we
don't
have
anyone
right
now
and
I.
Just
yeah
I
just
realized
I
can
commit
to
anything
this
month.
So
I
I
was
throwing
the
idea.
Maybe
I
can
help
with
Logics,
but
no
I
cannot.
So
that's
not
gonna
be
very
helpful.
So
we
kind
of
need
someone
for
the
end
of
the
month
already.
So
there.
C
B
A
F
Miles
did
a
great
job
in
the
previous
18th
release,
lucky
board
and
thanks
to
18.
and
I
think
land
completely.
You
know,
at
least
for
me
as
the
release
it
I
don't
have
any
problems
without
any
commits
that
just
mind
and
word,
but
some
the
people,
that's
that's
it.
B
All
we
we
might
push
that
out
to
March.
If
there's
a
security
release.
Okay,
I
I,
don't
know,
I
mean
16's
Enlightenment,
so
it's
kind
of
like
whenever
we
think
we
have
enough
things
to
I.
Think
there
is
a
back
port.
A
couple
of
Backpages
did
open.
So
particularly
for
that
time
we
could
do
one,
but
given
that
we
do
have
the
security
release
I'm
doing
the
security
release
for
16
and
14,
so
yeah
might
space
in
that
a
bit
yeah.
A
B
Yes,
I
mean
the
main
thing
I
had
for
14
lined
up
was
the
mpm6
update
but
yeah
that
that
that's,
that
is
been
been
taken,
care
of
and
anyone
else,
who've
gotten
14,
probably
not
much
I.
Think
so
again,
that's
probably
in
a
similar
situation
to
the
16
release.
Where
might
try
and
do
one
in
March
as
a
sort
of
last
14
release
before
it
goes
into
life
in
April
right.
A
B
Yeah,
let's
put
a
placeholder
in
for
March.
It
may
or
may
not
happen
depending
on
what
what
we've
got
lined
up
to
go
in
there
yeah
we'll
we'll
see
I
kind
of
half
expect
that
we'll
do
maybe
one
last
release
before
it
goes
in
life,
but
but
we'll
see
yeah.
Probably
things
like
like
updating
the
roots
certificates
and
stuff,
but
yeah
I
I
see
that
yeah
deciding
over
the
time.
B
I
think
we
I
think
we
still
have
a
you
know:
an
action
to
check
what
which
keys
are
in
the
key
ring
in
that
repo,
so
that
repo
has
keys
in
there.
But
it
also
has
a
key
ring
and
I'm
I
can't
remember.
The
keyring
was
updated.
B
The
last
time
we
added
keys
there,
so
that
that
might
be
something
to
check,
because
I
think
some
some
reports
were
that
they
were
using
the
trying
to
use
the
keyring
to
validate
the
release
it
releases
on
and
if
keys
are
not
in
the
key
ring,
then
people
using
the
key
ring
to
validate
the
keys
won't
be
either
so
yeah.
A
Okay,
yeah,
no,
and
the
last
issue
here
is
just
it's
just
a
note
about
the
the
npm
issue
that
needs
to
land
the
end
game.
Update
needs
to
land
on
14.
B
A
F
A
F
I'm
not
sure
I
followed
the
question
so,
oh,
if
it
is
okay
to
generate
those
keys
and
this
current
computer.
This
is
the
notes
or
computer,
but
they
are
going
to
give
me
another
one.
F
A
C
A
B
You
know
if
you
do
upload
it
to
one
password
or
whatever,
to
move
to
machine.
So
that's,
probably
okay.
As
long
as
you're,
aware
of
you
know
where,
where
your
key
has
been,
and
if,
if
one
password,
for
example,
ever
gets
security
breach,
then
you
know
we're
relying
on
you
to
to
take
appropriate
steps
to
keep
that
key
secured.
So
you
know
if
it's
there
temporary
or
permanently.
If,
if
there's
ever
a
suspicion,
it
may
get
compromised,
then
we're
relying
on
each
releaser
to
a
bit
like
you
did
one.
B
You
know
when
your
laptop
got
stolen
to
notify
the
rest
of
the
team
so
that
we
can
take
steps
to
to
you
know
appropriate
steps.
So
so
that's
all
I
say
is:
you
know,
use
your
own
judgment
but
try
and
keep
the
keys
as
secure
as
possible
that
yeah
it
doesn't
preclude
you
remove
them
between
machines,
but
it
is
then
your
responsibility
to
to
keep
those
keys.
Yeah,
secure,
yeah.