►
From YouTube: 2022-06-16 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
we're
live
with
the
node.js
release,
working
group
for
this
meeting
on
the
16th
of
june
2022
and
we're
gonna
work
through
the
issue
that
has
the
agenda
on
it
and
the
node.js
release
repository
and
it's
issue
754
this
time
and
to
start
just
ask:
are
there
any
announcements
anyone
would
like
to
make.
B
Probably
just
just
for
awareness,
I
hope
other
you've
seen
it
through
other
valve
news.
We
have
just
renamed
them
the
main,
the
primary
branch
of
the
node
core
repo,
so
it's
no
longer
called
master.
It's
now
called
main.
I
have
got
a
pr
open
to
update
the
release
instructions
in
in
the
call
repo,
but
yeah
just
bear
that
in
mind,
because
muscle
memory
is
a
thing
and
I'm
sure
I'm
sure
someone's
going
to
accidentally
try
and
push
the
master,
but
there
are
branch
protection
rules.
C
There
was
just
a
new
release
of
node
18
10
minutes
ago.
C
C
It's
fine,
no
problem,
thanks
for
taking
care
of
that.
Okay,
you're
welcome.
A
Cool
and
with
that,
I
guess
we
should
move
on
to
the
regular
agenda.
I
think
I
do
what
we
typically
do
and
go
through
the
schedules
last,
because
that
involves
sharing
screens
and
such
so.
Instead,
I
will
drop
to
the
other
thing.
Tagged
for
the
agenda,
which
is
the
periodic
table,
does
not
have
an
element
starting
with
j
or
q
or
w.
So
I
think
I
maybe
added
this,
because
j
is
not
too
far
away.
It's
like
a
couple
of
years
away
now,
so
making
a
decision
might
be
worthwhile.
A
No
22
and
no
24.,
no
no
22
in
2024,
that's
the
one
right,
so
there
have
been
some
suggestions
in
the
thread
for
a
while.
Quite
a
few,
I
don't
know
what
route
we
want
to
take
here.
I
think
at
one
point
I
proposed
having
like
a
poll
with
some
of
the
options,
so
do
folks
want
to
go
down
that
route,
although,
on
the
other
hand,
john
seems
to
have
quite
a
lot
of
support.
To
be
honest,
so
I'm
curious
what
peop,
what
route
people
would
like
to
take.
A
A
Yeah
I
mean
if
we
want
to
go
the
polling
route
we
could
just
like
after
this
or
in
the
minutes.
I
could
just
pull
out
each
of
the
options
and
then
asked
releases
if
any
additional
options
need
to
be
pulled
in
and
take
approval
on
the
minutes
to
be.
You
know,
these
are
the
pull
options
or
maybe
maybe
we
should
do
that
in
the
issue
itself.
Actually
just
come
up
with
and
ask
for
thumbs
up
to
say:
are
you
okay
with
these
polling
options.
B
In
terms
of
actual
polls,
github
has
polls
now
but
they're
only
in
discussions
not
on
issues
just
as
an
fyi.
B
B
Which,
I
guess
is
slightly
more
slightly
more
readable
than
like
just
a
bunch
of
reactions.
A
B
A
Yep,
okay,
so
yeah,
I
it's
not
massively
urgent,
so
I
can
probably
take
like
the
action
from
this
set
of
minutes
to
say
list
out
the
options.
These
options
we're
going
to
pull
on
and
then
let
people
walk.
I
think
it'd
be
quite
nice
to
let
people
poll
and
like
feel
like
they
have
a
say
in
these
things.
You
know.
B
A
Yeah,
I
just
write
down
the
thread
and
I
think,
like
I'm,
going
to
pronounce
half
of
these
wrong,
so
jabronium
jumbonium,
I
don't
think
jav
jarvium
is
a
serious
one,
but.
A
D
A
Enough
enough
to
do
that,
and
in
related
news
we
did
have
a
pr
opened
by
a
new
person
to
rename
node.js
18
from
hydrogen
to
half
name,
and
I
think
that's
based
on
the
previous
releases
or
having
like
the
iams
at
the
end.
So
the
same
suffix.
B
A
B
So
you
know
if
we
didn't
already
have
a
name,
it
seems
like
a
reasonable
suggestion,
but
we
do
have
a
name.
So
I
don't
feel
that
the
reasons
given
for
changing
it
are
compelling
enough
to
make
a
change.
A
B
Because
that
pr
is
editing
an
existing
list
of
names
and
the
reason
that
list
exists
is
because,
in
the
beginning
we
used
to
have
quite
a
lot
of
debate
as
to
what
the
names
should
be
and
it
got
very
like
yeah
bike,
sharing
sort
of
kept
going
around
in
circles
and
didn't
go
anywhere.
So
in
the
end
we
came
up
with
the
list
and
it
saved
quite
a
bit
of
headaches
over.
B
You
know
around
releases.
It's
we
kind
of
know
where
we're
going.
So
you
know
we're
open
to
changes
to
future
things
on
the
list,
but
I
think
it
would
have
to
have
a
better
reason
than
it's
just
an
alternate
name.
A
Yep
sure
I
can
write
an
action,
I
can
say
we
discussed
it
and.
B
Yeah,
unless
anyone
knows
otherwise,
I
don't
see
a
reason
not
to
use
the
word
hydrogen
and
if
we've
already
put
it
in
communications
like
release,
notes
like
I
think
maybe
was
it,
the
node
18
either
the
press
release
or
the
release.
Note
then
yeah.
It
doesn't
really
feel
like
something
we
should
change
unless
there
really
is
a
compelling
reason-
and
I
don't
see
one
at
the
moment.
A
A
Okay,
I'll
just
note
that
down
action
to
comment
and
the
one
issue
I
was
going
to
tag
on
just
to
try
and
unblock
and
move
things
forward,
is
from
the
release
keys
repository.
A
So
I
think
richard
you
opened
an
issue
a
long
while
back
around
linear
history
in
that
room,
because
I
think
you
noticed,
like
it
had
the
opposite
settings
enabled
to
what
we
typically
have.
I.
B
Did
notice
it
and
I
opened
the
question
because
the
default
positions,
I
think
a
default
position
should
be
sort
of
consistency
across
the
org.
Now
the
one
thing
is.
B
There
were
opinion
reasons
put
forth
as
to
why
the
setting
that's
currently
in
place
with
merges
is
the
reason
that
was
chosen.
So
it
was
a
conscious
decision
to
go
that
way
and
I
am
a
bit
swayed
to
actually
just
try
that,
because
the
repository
is
already
set
up
in
that
in
that
manner.
B
So,
even
if
we,
you
know,
even
if
we
made
it
to
zoom
now
that
we
did
want
linear
history,
we
don't
actually
have
linear
history
in
that
repository
unless
we
actually
did
go
and
rewrite
the
entire
branch
history
and
then
force
pushed
which
I
don't.
I
particularly
want
to
do
so.
So
one
of
the
one
of
the
arguments
was,
for
example,
if
someone
pr's
their
key,
you
know
if
a
release
appears
their
key
into
that
repository
and
signs
it
with
their
own
key.
B
Then
merging
the
pull
request
with
the
sort
of
merge
and
allowing
merge
commits
means
that
the
commit
remains
signed
with
the
original
signing
key,
whereas
if
we
were
to
do
our
regular
flow,
whoever
sort
of
pushes
the
commit
would
then
probably
end
up
signing
it.
So
you'd
end
up
being
signed
by
someone
else
and
if
I
it's
probably
not
too
bad
in
that,
it's
only
really
releases
that
you'll
be
allowed
to
push
to
that
repo.
B
But
it
is,
I
don't
know
how
to
it's.
It's
kind
of
like
you
know.
If,
if
a
releaser
assigned
a
commit,
then
why
would
we
have
it
that
another
release
pushes
an
equivalent
commit
sure?
To
be
honest,
I'm
happy
either
way,
but
given
that,
given
that
the
status
quo,
if
we
don't
touch
that
repo
is
as
it
is
set
up
at
the
moment,
I'd
probably
just
go
with
it
for
a
while
and
see
if
it
causes
any
issues.
A
B
So
I
think
we
can
merge,
merge
those
open,
pull,
requests,
I'll,
try
and
find
time
to.
We
need
to
regenerate
the
pre-populated
keying,
which
there
are
instructions
in
the
repository
on
how
to
do
that.
There's
a
shell
script.
I
think,
but
I
mean
that
regenerating
the
key
ring
shouldn't
hold
up
merging
the
keys
okay,
but
we
should
do
it
up
for
consistency
but
yeah.
We
should
merge
the
keys
first,
as
is.
A
If
yeah,
if,
if
there's
no
like
strong
strong
preference
towards
you,
know
swapping
the
history
changing
the
settings,
then
I
think
it's
just
on
us
to
merge
those
two
pr's
when.
B
I,
when
I,
when
I
opened
it,
I
just
noticed
it
was
different
and
I
didn't
know
why
it
was
different
and
and
sort
of
you
know
in
the
absence
of
a
reason,
then
it's
in
well.
We
should
just
be
consistent
with
everything
else,
but
the
reasons
given
seem
reasonable
enough
that
I'm
willing
to
give
it
a
go
and
see
if
we
run
into
any.
A
Okay
and
then
it's
just
a
case
of
regen
generating
the
keychain.
To
be
honest,
even
though
that's
the
last
step
of
the
onboarding,
I
don't
think
that
needs
like
we
haven't
got
any
conditional
requirements
that
say
like
it
needed
to
be
merged
for
two
weeks
before
you
can
do
a
release
or
anything,
and
I'm
not
sure
how
many
people
were
using
that
repo
as
the
source
of
truth.
Yet
probably.
B
So
yeah
I
I
agree,
though
I
mean,
I
think,
even
if
we
didn't
merge
the
pull
requests,
it
shouldn't
block
them,
people
being
able
to
do
releases
yeah,
it's
nice
to.
B
It
off
and
have
them
all
ticked
off,
though
we
can
change
our
minds
once
we
that
does
become
the
source
of
truth
and
we're
telling
people
that's
the
source
of
truth,
but
right
now
we're
we're
still
in
a
kind
of
setup
phase.
And
yes,
it
probably
would
be
better
to
try
and
get
a
move
on
and
trying
to
get
that
to
be
the
source
of
truth,
but
yeah
right
now.
Right
now,
I
don't
think
that
should
block
either
raphael
or
juan
from
being
able
to.
A
Okay,
it's
probably
the
case
that,
once
those
two
emerged,
I'll
just
double
check
check
the
onboarding
issues
that
raphael
and
one
are
completely
on
board
and
ready
to
be
welcomed
into
the
release
group
and
do
releases.
A
And
yeah,
I
know
I've
offered
to
pair
on
a
16
release
because
they're
going
to
be
quite
chunky,
the
next
16
release
with
one.
So,
oh,
okay,
that's
probably
a
good
time
to
segue
into
our
release
schedules,
because
that's
the
next
thing
on
the
list.
Okay-
and
I
will
share.
B
While
you're
digging
those
up
just
as
a
word
of
warning,
the
open
ssl
group
has
announced
there
are
going
to
be
some
open,
sl
releases
next
week
until
they
do
the
releases
we'll
have
no
idea.
B
The
impact
on
node
so
may
or
may
not
require
us
to
do
releases,
but
that'll
be
sometime
after
next
week,
well
at
either
at
the
end
of
next
week,
or
probably
going
to
into
the
week
after,
depending
on
the
severity
of
the
open
school
issues.
But
just
as
a
heads
up
there
might
be
a
need
to
do
releases.
A
B
A
Yeah
and
I
think
the
students
like
offered
to
review
the
content
and
see
like
help
us
make
that
call
on
applicability
and
things.
So
we
should
know
next
week,
cool
so
node
18,
so
1840
just
got
shipped
yay
thanks
daniel
and
then
the
next
one's,
not
due
until
towards
the
end
of
the
month.
No
volunteers
as
yet.
C
C
Oh
sorry,
I
didn't
realize
she
signed
up.
First
again,
no
worries,
but
if
you
all
want
to
do
that,
then
I
can
just
take
because
they're
on
the
same
day,
which
I
don't
don't
know
if
I
want
to
do
but
yeah,
but
I
can
do
one
or
the
other,
whatever,
whatever
y'all
don't
want
to
do.
Yeah.
B
A
Time
out
anyway,
so
what's
whatever's
easiest
to
be
honest,
does
it
make
sense
to
jump
straight
to
a
minor
from
oh.
C
B
One
thing
I'll
mention
to
16
is:
there
was
the
npm
release
that
went
into
the
last
16
that's
right
has
there
was
a
deprecation
of
the
minus
g
flag,
which
has
been
reverted
in
a
subsequent
npm
release,
so
we
do
want
to
get
the
updated
npm
that
I
think
right.
I
think
apm
was
updated
in
the
18
releases.
It's
just
gone
out,
so
we
probably
want
to
get
that
version
of
npm
into
the
next
16
release
when
the
next
16,
when
this
happens.
B
Is
it
amanda,
I
mean
the
mpm,
I
don't
know.
B
Well,
it's
it's
it's!
It's
reverting
a
thing
that
wasn't
meant
to,
but
basically
the
thing
that
went
in
16
is
actually
cause
warnings
in
people's
console
workflows.
So
the
reversion
is
basically
I'm
deprecating
it
so
that
it
no
longer
throws
warnings
when
you
use
the
minus
g
flag.
So.
C
C
B
But
in
terms
of
whether
the
next
16
really
should
be
minor
or
patch,
it
would
be
good
to
get
the
npm
release
out
in
the
next
16.
So
if
that
being
a
patch
makes
it
easier
to
do
the
next
16
release.
A
Yeah
yeah.
With
that
in
mind,
I
I
wonder
whether
we
should
defer
the
miner
so
that,
because
we're
going
to
have
the
open,
ssl
thing
that
we'll
probably
want
to
ship
sooner
rather
than
later,
anyway,
even
even
if
it's
not
like
directly
impactful
and
also
fix
that
npm
thing.
So
I'm
wondering
about
bumping
the
miner
to
july
I'm
leaving
that
there
okay.
I
think
I
think
that
makes
sense,
because
getting
a
route
requires
longer
rc
phase
and
we've
only
got
two
weeks
until
that
date
anyway.
A
So
juan,
are
you
still
interested
in
working
on
a
release?
Absolutely
yeah.
Do
you
want
to
do
the
next
18,
which
is
on
the
same
day,
should
be
slightly
easier
to
prepare.
E
B
I
have
no
idea
if
there's
anything
pending
on
14.
well
other
than
potentially
any
open
sl.
I
I
don't
know
if
there's
any
back
ports
open
or
anything
for
14,
so.
B
14,
this
still
has
npm
six.
So
there
was,
it
sometimes
gets
warnings
right.
There
was
a
release.
I
think
it
went
into
14.
A
B
Oh,
did
they
not
I'm
trying
to
remember
I
I
remember
roy
did
an
mpm6
release
and
I
think
that
went
into
note
14..
B
Oh
1419
too,
so
the
one
before
the
last
one
that
that
had
an
npm
bump.
So,
okay,
I
don't
know-
I
I
suspect
there
isn't
a
newer
npm,
six
to
put
into
sure
note
14
yeah.
These
have
been
all
around
mpm8.
So.
A
Yeah
I
just
looked
up
like
open
back
ports
and
there's
just
one
open
back
port.
That's
been
open
for
like
a
long
time,
so
I'm
not
sure
it's
never
gonna
ship.
Maybe
it's
still
needs
rebasing
or
something
which
one
is
it.
A
Source
use
correct,
outer
context
for
micro
task
queue.
I
will
paste
a
link.
Was
that
anna's?
Yes,
it's
anna's.
Yes,
I.
A
A
B
A
There's
also
a
stream
don't
emit
pre-finish
after
error
or
close,
which
was
opened
a
while
back
and
I
it
doesn't
run
cleanly.
I'm
not
convinced
this
is
a
change
we
would
make
in
maintenance,
because.
B
Yeah,
I'm
a
little
bit
hesitant
to
land
some
extreme
related
unless
we're
absolutely
sure
there
are
no
no
associated
risks,
because
I
have
seen
various
issues
where
people
have
been
moving
between
node
releases
and
running
into
stream
issues.
So
yeah
I'd
be
a
little
bit,
hesitant
to
just
land
a
stream
change
in
maintenance
without
a
good
reason.
A
Okay,
with
that
mind,
going
back
to
the
node
14
release
plan,
it
sounds
like
because
it's
ad
hoc-
and
we
did
one
in
may-
we
probably
don't
need
to
schedule
one.
So
I
might
just
I
might
just
put
a
placeholder
for
the
next
patch
without
like
a
concrete
date,
just
20
22.
A
B
Okay,
I
mean
there
is,
we
will
probably
update
for
the
new
cell
release,
regardless
of
whatever,
whatever
the
evaluation
is
of
the
spirit.
So
the
evaluation
of
the
severity
of
the
issue
has
been
fixed
for
node.
That
will
dictate
how
urgent
the
release
is
to
get
out,
but
eventually
we
would
put
out
a
release
with
that
cool.
A
A
No
okay,
I
had
a
couple
of
actions.
I
will
close
out
the
call
and
speak
to
you
some
other
time.
Thanks
for
joining
everyone.