►
From YouTube: 2022-05-05 - 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,
so
welcome
to
the
node.js
release
working
group
meeting
for
the
5th
of
may
20
20
22,
and
we
will
work
through
all
of
the
items
that
have
been
labeled
with
release
agenda.
So
I
will
start
with
the.
I
will
start
with
the
ones
that
aren't
the
schedules
and
then
we'll
go
for
the
schedules
towards
the
end
of
the
meeting.
I
guess
first,
it
makes
sense
to
ask:
are
there
any
announcements
anyone
would
like
to
make.
A
Okay,
so
the
the
first
item-
that
is
not
a
schedule
that
I
felt
we
should
talk
about
today
is
there
is
a
issue
in
our
repo
called
automate
time
zone
updates.
I
will
ping
the
link
to
it.
I
just
added
it
to
the
agenda,
because
I
think
we
should
just
move
this
to
the
node.js
core
repository,
because
that's
where
the
automation
will
probably
have
to
run
and
also
if
we
tag
it
with
good
first
issue
or
something
like
that,
I
think
someone
may
actually
pick
it
up
and
write
the
automation.
A
I
feel
that
it's
a
bit
lost
in
the
release.
Repo
sounds
good
to
me.
A
I
guess
it's
worth
asking:
are
there
any
objections
to
the
automation
existing
and
I
assume
the
answer
is
no,
but
just
give
people
the
opportunity
to
say
that.
A
The
next
item
I
did
add
to
the
agenda
mostly
because
the
issue
was
opened
in
2018
and
I
think
they
said
it
would
be
a
problem
in
a
like
in
around
five
years
time
and
that's
the
our
code
names
for
our
releases,
we're
for
following
periodic
table
elements
and
there
is
no
element
starting
with
j,
and
that
will
be
a
problem.
We
need
to
work
around
in
an
upcoming
long-term
support
release
and
so
there's
lots
of
suggestions
in
the
thread.
A
A
A
No
okay,
well
I'll,
try
and
collate
all
of
the
suggestions
that
I
can
see
in
the
thread
and
maybe
ask
and
just
ping
any
further
suggestions.
Otherwise
these
are
the
ones
we'll
use
for
the
poll.
Then.
Maybe
in
our
next
release
working
group
meeting,
we
can
look
at
all
the
proposed
ones
and
say:
yes,
we
wouldn't
object
to
any
of
these
being
in
the
poll
and
then
from
that
just
have
a
simple
vote
and
just
pr
into
the
repository.
So
we
can
make
a
decision.
A
B
Yeah
sure
so
I've
opened
an
issue
over
the
tfc
repo,
mainly
because
we
brought
it
up
yesterday
in
the
tsc
meeting.
It's
technically,
I
guess
a
release
working
group
decision,
but
it's
got
it.
Its
effects
are
going
to
be
a
more
sort
of
wide
rangings.
B
I
think
we
want
buying
from
as
many
as
much
of
the
sort
of
collaborator
base
as
we
can
get,
but
the
problem
is
that
we
originally
were
hoping
that
we
could
release
openness
or
sorry
release
node.js
16
with
openssl
3,
but
the
openness
of
three,
the
sort
of
release
date
for
that
kept
moving.
So
in
the
end
it
wasn't
out
by
the
time
we
did
cut
note
16,
so
node
16
went
out
with
openness,
so
1.1.1.
B
The
issue
we
have
is
that
openness
of
1.1.1
will
cease
to
get
any
further
updates
after
september
2023,
which
is
seven
months
before
the
end
of
node.js
16.,
so
there's
sort
of
a
seven
month
period
on
the
current
planned
node.js
16
lifecycle,
where
it
you
know.
Potentially,
if
there
are
vulnerabilities,
they
won't
be
being
patched
in
the
base
open.
B
B
That
is
what
we
did
for
node.js
eight,
where
we
brought
forward
the
end
of
life
of
node.js
eight
to
coincide
with
the
end
of
support
for
ignis
cell
102..
So
we
have.
We
have
precedent
there
on
an
earlier
lts
release,
although
I
think
for
no
date,
we
we
were
aware
of
it
before
we
ga
so
before
we
released
no
date,
so
we
had
a
consistent
message
and
didn't
have
to
readjust
the
schedule
after
we'd
already
released.
B
So
for
note
16,
I
think
if
we
there's
been
sort
of
broad
support
to
bring
bringing
the
date
forwards,
but
if
we
do
that,
we
do
need
to
communicate
that
early
to
allow
people
to
plan.
For
that.
B
B
I'm
a
little
bit
hesitant
right
now,
because
we
know
there
are
some
issues.
People
have
raised
against
node,
17
and
18,
where
we've
moved
to
optimism,
free
in
terms
of
compatibility,
especially
around
native
add-ons
that
are
doing
openssl
calls
themselves.
B
So
I
think,
there's
too
much
of
a
question
mark
right
now
as
to
whether
it
would
be
feasible
to
do
an
in-place
update
without
introducing
some
form
of
break,
and
my
thinking
is
if
we,
if
we
were
to
introduce
a
break,
we
might
as
well
push
people
onto
node
18,
breaking
change
so
september.
2023
will
be
a
year
into
node,
18's,
long-term
support
or
coming
up
to
a
year,
so
no
daytime
will
become
lts
in
20
october
2022,
so
it
will
be
sort
of
about
11
months
into
its
lifespan.
D
I
just
had
a
question:
what
about
node
14?
Does
it
make.
B
Node
14
goes
end
of
life
in
april
before
openness
of
1.1
goes
out
of
support,
so
14
is
fine.
14
will
be
out
for
support
before
opening.
So
it's
only
node,
16.
node
18
is
on
openness
of
three,
so
yeah
yeah,
it's
just
bro.
Just
for
awareness.
I've
opened
that
issue.
People
have
been
commenting
so
far.
Most
people
will
seem
to
be
in
agreement
with
bringing
the
date
forward.
It's
probably
the
simplest
thing
we
can
do,
and
it's
just
the
case
of
the
end
of
communication.
B
I
am
open
to
having
my
mind
swayed
otherwise,
but
sort
of
you
know
if
we
were
making
a
decision
right
now.
That's
the
one
I've
got
for.
A
Yeah
from
from
seeing
the
disruption
of
people
upgrading
between
16
and
18,
my
gut
feel
was
like
the
main
problem
was
the
openness
of
self
reupgrade
or
the
most
visible
problem
that
I
saw
so
if
they're
going
to
go
to
the
expense
of
having
to
you
know,
update
new
open
ssl
in
node
16,
they
may
as
well
move
to
node
18
and
get
the
longer
life
from
doing
that
jump
anyway.
So
I
I
no
objections
to
shortening
and
we
have
prior
art
there.
So
I
think
I
think,
just
making
sure
the
release
team's
aware.
A
There
are
no
objections
from
our
team
and
then
seeing
if
we
can
get
more
of
the
tsc
to
kind
of
plus
one
to
it.
And
if
that's
the
case,
then
it's
just
a
case
of
writing
the
blog
pr
in
the
shorting
of
blogs,
shortening
of
dates
and
updating
the
charts
and
obviously
the
sooner
we
do
that.
The
better-
and
I
do
think,
like
almost
18
months
of
notice
or
just
shy
of,
is
ample
amount
of
time.
You
know
we've
done,
we've
done
the
best
we
can.
I
think
there.
B
When
we,
when
we
were
trying
to
plan
for
the
openness
for
openness
3
before
we
knew
what
openssl
3
would
look
like,
the
hope
was
that
we
would
be
able
to
switch
without
too
much
disruption.
But
I
believe
what
we've
seen
suggests
that
that's
probably
not
going
to
be
feasible.
There
will
be
some
disruption
involved
with
the
switch
so,
like
you
said,
people
going
from
node
16
to
either
17
or
18,
not
everyone,
but
enough
people
that
I
wouldn't
want
to
do
that
during
the
lifetime
of
an
lcs
release.
A
A
A
Yes,
so
one
thing
to
bear
in
mind
when
we're
reviewing
these
schedules
is
there
was
an
open,
ssl
update.
That's
come
out,
it's
public,
so
we
can
talk
about
it
here.
I
think
there
are
some
very
low
severity
things
that
would
be
worth
fixing,
so
we
will
want
releases
on
all
release
lines.
Does.
B
A
Yes,
if,
if
the
releases
go
out
in
may,
I
think
just
we
should
include
17
that
17
release
can
just
be
the
open
ssl
commit
so
hopefully
not
too
intensive
having
to
do
an
extra
release.
So
with
that
in
mind,
actually
I'm
gonna
remove
this
new
releaser
hold
for
the
current
release
because
we
managed
to
find
another
release
with
them
today.
A
So
we
we
do
need
a
node
18
release
is
I
I
feel
like
the
17th
of
may
is
reasonable
to
aim
for.
So
I'm
like
any
objections
to
leaving
that
date
in
the
schedule.
B
B
A
Meeting,
I
think
wishful
thinking
there,
but
I
can
add
it
in
so
raphael
is
interested
in
being
on
board
as
a
releaser
and
to
do
that,
he
he
will
need
to
prepare
a
a
current
release.
So
I
figured
actually
the
node
17
release
would
be
a
good
candidate
for
that,
because
it's
just
the
one
commit
we
can
go
through
the
process
and
it
is
a
security
related
change
that
we're,
including
in
that
and
that's
the
kind
of
work.
A
I
think
he
plans
to
do
in
the
project
so
that
all
aligns
nicely.
So
I
propose
that
we
aim
for
a
17
release
on
the
same
day
and
I'm
happy
to
pair
on
that
one
with
raphael.
I
will
double
check
with
him,
because
I
don't
think
he's
here
so
I
can.
I
can
put
my
name
in
that
and
I
think
keeping
it
the
same
day
as
18
makes
sense.
A
We
have
just
done
one,
but
I
didn't
want
to
you
know
derail
that
release.
While
we
still
were
waiting
on
prs
and
things,
so
we
should
probably
schedule
one
of
those
for
may
as
well.
B
B
A
That's
hopefully
low
effort
to
bring
those
in
so
I
don't
know
if
anyone
has
any
capacity
to
pick
one
up
I
mean
it'd
be
nice
to
do
that
around
the
17th,
but
it
doesn't
need
to
be
exact
because
all
these
things
are
public
and
they're
low.
It's
just
when
we
can
get
them
into
releases.
C
A
A
So
does
any,
would
anyone
like
to
prepare
that
one?
I
guess
in
terms
of
coordinating
timings,
if
rich
is
doing
14
I'm
doing
17?
Perhaps
I
could
pick
up
16,
so
we
can
get
the
kind
of
those
bunch
out
together
and
if
18
follows
at
a
different
time.
That's
that's
okay,
too,
so
I
I
could
probably
pick
this
one
up.
There's.
B
No
there's
no
real
reason
to
have
to
so.
I'm
not
sure
how
much
I
can
do.
The
the
vulnerabilities
have
been
discussed
privately
abide
by
the
you
know
by
people
on
the
the
team,
triaging
security
issues
in
node.
So
at
the
moment
there's
I
don't
think
we've
published
our
assessment
of
the
vulnerabilities,
but
it
the
fact
that
we're
discussing
them
here
openly
in
the
call
they're
not
being
deemed
as
high
highly
you
know,
urgent,
must
fix
everything
I
mean
they're
only.
B
I
think
they're
moderate
for
open,
ssl
and
there's
nothing
that
we've
found
so
far.
That
would
indicate
there
will
be
a
higher
severity
for
node
users,
so
I
don't
think
we
need
to
necessarily
to
coordinate
them
all
on
the
same
day,
but
given
that
we
try
to
go
for
tuesday
releases
yeah,
it's
it's
not
here.
A
A
However,
we
were
waiting
to
ship
these
and
releases
by
the
end
of
may,
and
if
we,
if
in
this
session
we
can
say,
yeah
end
of
may
seems
reasonable
and
we
can
go
back
to
the
security
steward
and
say
yeah
put
the
post
out
and
we
should
be
able
to
fit
that
and
considering
it's
just
16
with
a
question
mark,
I'm
pretty
confident.
We
should
be
able
to
do
that
with
our
regular
schedule.
B
A
Okay,
so
I
think
that's
all,
if
we're
all
confident
we
can
probably
ship
them
releases
out,
we
have
volunteers
for
most
of
them
18.
We
tend
to
pick
up
volunteers
quite
quickly
for
those,
so
we'll
just
keep
an
eye
on
that
and
if
not
it'll
only
be
the
following
week.
Also,
there's
no
concerns
there.
B
I
believe
the
I
believe
rafael's
already
opened
the
prs
against
the
releases,
yes
to
update
openness
for
18
and
17
we'd,
be
cherry
picking
the
commit
from
master.
Yes,.
A
A
B
A
Yep
yeah,
I
think
at
least
one
or
two
of
them
have
passed.
Ci
so
looks,
looks
good,
no
big
concerns.
Okay,
I
can
go
back
to
michael.
The
security
steward
and
just
say,
hey
end
of
may
seems
reasonable.
We've
got
things
scheduled
in
pretty
much
until
then
anyway,
so
the
releases
should
just
pick
up
those
open,
ssl
updates.
A
And
I
guess
I
guess
that's
all
on
the
agenda
I
went.
I
went
through
everything
that
was
labeled
release
of
gender.
I
guess
one
one
thing
would
be
we're
continuing
to
do
some
onboarding,
and
so
we
have
stuart,
juan
and
hopefully
soon
raphael
will
be
preparing
and
being
on
boarded
so
working
through
those
steps.
B
No,
I
have
added
the
releases
team
to
the
maintainers
for
change
log
maker
and
branch
death,
so
we
had
an
issue
open
for
a
while.
There
were
no
objections
and
one
positive
thumbs
up
so
bought
by
a
existing
maintainer.
So
we
should
be
able
to
merge
things
into
branch
dip
and
change
look
maker.
Now.
I
believe
those
repositories
are
set
up
to
auto
release
in
that.
B
If
we
merge
call
requests
in,
they
should
automatically
create
releases
so
including
publishing
to
npm,
I
think,
but
if
it
doesn't,
we
can
revisit
whether
we
need
to
be
added
specifically
to
the
npm
project
and
stuff,
but
I
have
also
opened
issues
on
node,
core
utils
and
citrium
and
they're
mainly
formalities.
I
don't
think
anyone's
really
going
to
object,
but
I've
opened
those
so
yeah
just
just
to
try
and
give
us
the
ability
to
maintain
the
tools
we're
using
to
do
the
releases.
A
A
D
I
do
have
a
question:
I'd
like
to
bring
up,
is
there
any
because
maybe
someone
here
will
know,
maybe
richard
will
know,
I
don't
know.
Is
there
any.
D
Or
group
of
people
working
on,
I
wouldn't
say,
fix
but
at
least
improving
the
state
of
sitkin
like
right
now.
B
I'm
not
aware
of
a
concerted
effort,
but
there
are
definitely
people
that
every
now
and
then
take
it
upon
themselves
to
at
least
investigate
the
state
and
then
dive
into.
I
guess
the
things
that
look
fixable
or
even
if
they
turn
out
to
be
more
complicated
than
initially
seemed.
So
I
mean
this
might
introduce
you
in
interest.
Euro
mpm
tests
in
sichu
have
been
read
for
a
long
time.
D
B
B
A
Yeah
and
failed
to
do
that
so
far
I
thought
just
applying
like
tap
color
zero
or
something
like
that
would
work,
but
nope
so
a
bit
a
bit
to
debug
there.
I
think
someone
from
npm
just
commented
on
the
issue
I
opened
for
that
one
saying
they
had
tried,
but
it
might
be
more
of
a
problem
than.
B
Michael
said
about
filtering
the
output
and
section,
but
I
thought
we
already
did
filter
the
output.
Maybe
unless
it's
flagged,
maybe
we
have
to
flag
to
try
and
filter
the
output.
As
in
I
I'm
pretty
certain.
We
have
sort
of
like
an
ansi
regex
dependency
in
sit
gym
and
the
idea
was
to
try
and
strip
out
fancy
codes
or
better
transform
them
into
colors
and
jenkins.
D
Right
yeah,
but
I
ask
more
for
when
I
do
have
more
capacity
like
something
I
yeah,
I
kind
of
love
to
help
a
little
bit.
I.
B
Think
traditionally,
what's
happened
is
someone's
opened
an
issue
and
said,
gym
and
said
here's
the
current
state
of
you
know
here
are
the
things
that
we
know
are
failing
consistently
and
then
basically
checklisting
it
and
then
trying
to
sort
of
work
through
that
list
and
say
I've
been
yeah.
I've
investigated
this.
It
looks
like
this
or
I've
investigated
this,
and
I
still
can't
work
out.
B
Right,
I
have
released
a
new
minor
represent
gym
today
to
pick
up
the
current
changes
on
on
the
main
branch
so
including,
including
that
just
restoration
of
no
longer
testing
with
the
master
but
mainly
yeah,
the
head
branch
just
was,
and
I
think
it
adds
there's
one
or
two
new
modules
that
been
introduced,
which
hopefully
might
make
things
worse.
They
were,
they
were
passing
when
they
were
added,
so
you
know
hopefully
they're
still
passing.