►
From YouTube: 2021-12-02 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
We
will
work
for
the
agenda,
which
is
in
the
issue,
as
always,
which
is
in
the
node.js
release
repository
and
it's
issue
713
and
before
we
start
are
there
any
announcements?
Anyone
would
like
to
make
today.
B
B
Also
so
node
18
is
april
next
year,
so
it's
a
while
well
a
while
away,
but
not
too
far
away.
I've
opened
an
issue
in
the
build
repository
about
planning
for
the
sort
of
minimum
sort
of
build
environments
and
supported
sort
of
tool,
chains
and
stuff.
B
We
know
we're
going
to
need
to
move
off
centos
7,
because
that
will
go
end
of
life
before
during
the
lifetime
of
node
18,
so
we're
going
to
move
anything
that's
center,
7
or
rail
7,
based
in
the
build
infrastructure
for
node
18
onto
something
else.
That's
that's
been
worked
through,
but
yeah
just
for
awareness.
There
are
discussions
going
on
about
node
18,
including
things
like
whether
to
move
the
minimum
minimum
deployment
target
for
mac
os
up
from.
B
I
think
it's
currently
10.13
what
whatever
version
of
mac
os
that
equates
to
in
terms
of
code
names,
nothing's
been
set
in
stone
yet,
but
the
discussions
are
starting
because,
ideally
with
anything
that
needs
to
happen
in
terms
of
adding
new
machines
or
things
to
the
build
ci.
That
sort
of
ideally
needs
to
happen.
In
january
february,
beginning
of
next
year,
ahead
of
the
april
release.
A
Yep
sounds
good.
What
I'll
do
from
the
agenda
from
the
agenda
items?
I
think
it
makes
sense
to
start
with
the
non
schedule
ones
then
we'll
go
through
the
schedules
last.
So
the
first
item
is
issue
711,
which
is
moved
to
monthly
release
working
group
meetings,
hopefully
not
too
controversial.
A
I
found
we
this
year,
we've
tended
to
cancel
almost
like
every
other
one
anyway,
so
just
wanted
to
raise
it
here.
Folks
are
happy
to
move
to
the
monthly
cadence.
I
propose
that
maybe
we
do
a
doodle
poll
over
the
rest
of
december
and
just
check
that
the
times
are
okay
to
go
monthly,
going
forward
from
january.
So
now
for
any
comments
or
plus
ones.
On
that.
C
Sure
maybe
we
should
ping
the
release
team
on
this
issue.
A
Oh,
have
we
no
okay,
yep.
A
Yeah,
like
the
sentiment,
was
kind
of
neutral.
I
found
like
no
one
was
going
to
stop
us
doing
it,
but
there
was
also
not
great.
Enthusiasm
have
folks
found
recently
that
an
email,
alias
would
have
been
useful.
B
A
A
I'll
see
I
see
if
we
get
response
on
the
issue
for
the
meeting
times
and
okay,
maybe
maybe
that
can
you
be
a
demonstrate
of
our
people
catching
these
things
or
not,
and
if
not,
maybe
we
could
explore
the
alias
again.
If
folks
would
like
that.
A
But
no
no
immediate
plans,
but
I
can
see
that
being
useful,
particularly
around
security
releases,
particularly
for
whoever's
trying
to
coordinate
a
security
release
to
say,
hey
at
releases.
Anyone
can
anyone
step
in
this
short
notice,
which
they
often
are,
and
I
figured
email
might
be
a
better
way
of
doing
that
than
notifications.
But
let's
see.
A
The
other
one
is
propose
renamed
citrium
team
to
release
automation.
I
remember
if
I
added
this.
Yes,
I
did
yeah
it's
quite
quite
old.
It's
something
we
said.
We'd
do
and
also,
I
think
it
would
result
in
some
changes
around
access
for
like
pushing
on
like
change,
not
make
a
branch
diff,
no
coil
utils.
If
the
whole
release
automation
team
was
automatically
in
there,
because
I
I
don't
know
exactly,
but
I
think
some
of
those
repos
might
be
like
added
on
an
individual
basis
or
using
an
old
team,
I'm
not
sure.
B
A
Yeah,
so
I
don't
know,
is
there
still
appetite
to
rename
it?
I
don't
know
if
it
would
simplify
or
just
scream
or
what.
A
B
I
think
in
general,
and
not
just
that
team,
it
would
be
useful
for
teams
to
actually
grant
access
to
things,
especially
right
access
to
things
to
be
reviewed
regularly.
Never
a
regular
whatever
regular
is.
B
B
B
B
A
Think
also
am
I,
in
my
opinion,
like
thinking
from
the
releases
team
as
well
having
a
long
list
of
folks
there,
so
not
reflecting
the
folks
that
are
maintaining
is
probably
not
a
good
idea,
just
in
a
sense
that
people
may
look
and
think.
Oh
there's
10
people
there.
Of
course
you
can
get
a
new
citroen
release
out
like
this
week,
like
it's
good
to
actually
have
an
indication
of
the
people
currently
maintaining
it
just
to
highlight.
If
we
need
more
maintainers.
B
Yeah,
let's,
let's
then
perhaps
review
that
list
we
can.
We
can
move
people
like
to
emeritus
status
or
something
and
and
sort
of
just
just
tidy
up
the
teams.
A
Yeah,
I
think
that'd
be
a
good
start
and
then
maybe
we
can
revisit
what
we
want
to
do
to
rename
after
that
point,
whether
it
makes
sense
to
rejig
the
teams,
because
let's
reflect
who's
in
these
teams
and
active
from
using
them
at
the
moment,
yeah
that
sounds
good.
A
And
now
I
need
to
find
the
pr
and
paste
it
in
the
chat
and
didn't
appear
on
the
agenda
for
some
reason.
Maybe
I
added
it
too
late,
but
it
was
the
simplifying
the
major
release,
preparation
which
is
in
the
node
core
repository.
I
did
put
kind
of
a
description
of
like
changes
in
rush
now.
The
three
key
points
were
at
present.
The
guidance
was
like
create
the
branch
three
months
prior,
but
we're
not
actually
doing
any
test
builds
until
six
weeks
prior.
A
So
I
feel
like
there's
no
added
benefit
for
that
extra
month
in
unless
the
build
team
needed
it.
But
then,
when
you
look
at
the
second
change,
which
is
to
mirror
the
master
branch
for
as
long
as
possible
and
that
kind
of
mitigates
any
impact
there
because
obviously
builder
be
testing
against
mastering
if
they're,
mostly
in
sync,
we
can
test
things
like
new
upgrades
and
such.
A
A
B
B
You
know.
Occasionally
we
bump
them
sort
of
probably
around
that
month
before
as
a
sort
of
last
minute
thing,
and
that's
one
of
the
reasons,
the
earlier
sort
of
announcement
of
the
platform
planning
for
note
18,
I
you
know
I've
started
that
now,
because
we
don't
want
to
be
doing
that
right
before
we
cut,
then
you
cut
cut
that
branch
so
yeah,
I
don't
have
any
real
concerns
about.
You
know
shortening
that
down
from
three
months
to
to
one.
A
Good,
I
guess
the
key
thing
that
I
proposed
to
changing
here
was
dropping
the
sun
for
major
cut
off.
I
found
we
very
rarely
actually
said:
no,
don't
land
that
and
when
we
have
said
no,
don't
land
that
we've
actually
reverted
it
on
master.
A
In
most
cases,
almost
all
cases,
I
think,
there's
maybe
one
exception,
and
then
the
fact
that
we
gave
all
majors
going
in
to
with
tfc
approvals,
I
figured
we
could
lighten
this
requirement
to
be,
rather
than
no
rejections
from
the
tfc.
Just
a
inform
the
tfc
of
all
the
majors
that
land
past
to
cut
off.
Because
then,
if
anyone
does
object
strongly,
they
could
open
a
reaper
or
something
like
that.
B
Yeah
I've
I've
slight
mixed
feelings
about
I
I
I
get
the
sort
of
it's
not
really
a
sort
of
hard
cut
off,
but
I
do
feel
we
need
some
sort
of
mechanism
to
try
and
try
and
slow
down
or
reduce
sort
of
the
sort
of
frequency
of
december
majors
landing
as
we
get
closer
to
release.
A
I
generally
haven't
seen
that
as
a
problem
and
to
be
honest:
okay,
it's
it's
actually
exhausting
like
having
to
try
and
like
get
20,
plus
ones
or
whatever,
or
make
sure
everyone's
seen
the
message
that
says:
hey
these
approvals-
I
don't
know
what
value
this
cutoff's
bringing
us
in
the
past
two
or
three
releases.
It's
not
obvious
to
me.
A
I
do
get
the
point
of
slowing
it
down
and
I
guess
coded
into
this
changes
a
week
before
we
have
a
proper,
like
code
cut
off
like
nothing
unless
it
was
like
gonna
break
the
release
not
having
this
extra
commit,
so
that
would
give
a
full
one
week
baking
time.
So
it's
really
three
weeks
before
that,
whether
we
think
anything's
necessary
to
slow
changes
down.
A
A
I
don't
actually
think
many
people
were
like
running
off
on
nightlys
or
running
on
the
cutting
edge
aside
from
the
core
developers
that
are
already
you
know,
building
node
regularly,
so
I
don't
know
why
it
actually
gains
us
having
like
a
major
sit
on
the
master
branch
for
six
months
between
maybe
the
start
of
april
and
end
of
october,
because
it's
not
it's
not
going
to
be
out
there,
particularly
to
the
people
that
would
realistically
pick
it
up
like
module
authors
and
such.
A
Yeah,
I
don't
know,
maybe
we
take
a
cautious
approach
for
this.
One
inform
tsc
of
all
december
majors,
quite
clearly,
yeah
gauge
the
numbers
general
trend
from
what
I've
seen
is
standard
majors
are
going
down
with
every
release
since
node
10,
so
the
numbers
tend
to
be
getting
smaller
and
smaller,
which
is
probably
a
good
thing.
A
So,
okay,
if
anyone
has
approvals
or
objections,
I
guess
just
point
them
at
the
pr
and
if,
if
there's
no
objections,
say
in
a
couple
of
weeks,
I'll,
probably
just
land
that
and
we'll
try
this
approach
for
node
18,
but
yeah,
we've
added
caution
just
to
keep
an
eye
on
the
numbers
and
check
that
this
doesn't
open
the
doors
to
like
10
majors
landing
a
week
or
something
just
before.
I
guess.
B
B
Sometimes
they
sort
of
hang
around
for
a
bit
and
it's
sort
of
it
concentrates
on
trying
to
get
reviews
and
things
landed.
I
guess
that's
that's
the
impression
I've
had
around
december
cut-offs.
B
A
B
B
Yeah,
typically,
isn't
it
some
of
the
v8s
occasionally
have
like
forward
compatibility
patches
is
that
is
that
right,
so
so,
like
the
the
v8
update,
lands
pretty
much
as
it
as
it
is
on
master,
but
then
for
the
december
for
the
new
symbol,
major
they
might
have
additional
patches
for
api
compatibility.
With
sort
of
you
know
a
couple
of
releases
in
mind,
so
it
won't
be
a
relaxed,
exact
sort
of
one-to-one,
but
probably
as
much
as
possible.
I
guess.
C
B
A
Okay,
it
seems
positive
well
among
other
group,
no
objections
so
we'll
I
will
leave
it
open
for
a
little
while
longer,
maybe
the
end
of
next
week,
I'll
close
off
and
land.
If
there
are
no
objections,
I'll
try
and
share
it
in
the
channel
as
well
just
fyi
again.
A
We've
got
node
17
schedule
and
I
can
see
danielle's
volunteered
to
do
one
in
a
couple
of
weeks.
That's
probably
quite
good
timing.
I
won't,
I
guess,
there's
probably
no
need
to
do
a
call
for
volunteers
for
the.
C
And
we
can
start
again
one
week
earlier
in
in
january.
A
That's
how
it
goes,
but
we're
here
mark
that
one
in
harley
jungle
we
don't
want
vested
releases
and
we
can
figure
out.
People
probably
don't
know
their
schedules
for
next
year.
Just
yet.
So
we
leave
that
one
as
it
is
note
16.
A
I
see
danielle's
volunteered
to
do
this.
Semver
minor
release
of
note
16
in
january.
So
that's
good,
we'll
probably
do
a
patch
the
following
month.
I
imagine
so
I
may
just
swap
that
in
with.
A
Placeholder
there
we
go
uncovered
on
my
base.
14,
we
are
hoping
to
do
minor
in
january
as
well.
Aren't
we.
B
Yeah
there
are
a
handful
of
pr's
marked
sort
of
backwards,
marks
and
vermin.
B
A
B
B
So
I
think
one
of
them
is
something
to
do
with.
It
was
either
esm
or
loaders.
It
might
have
been
loaders
there's
something
on
the
staging
branch
which
I
didn't
push
out
in
the
release,
because
it
was
the
original
pr
that
was
back
ported
with
simva
miner,
so
something
to
do
with
alexa.
I
think.
No!
No!
No
sorry!
That's
12.
pattern.
Trailers
yeah!
That's
the
one
pattern!
Trailers,
so
that
the
upstream
was
marked
december
miner.
B
So
it's
already
landed
on
stage
in
branch,
I'm
probably
okay
with
that,
going
out
on
maintenance,
but
there's
other
things
like,
I
think,
there's
a
backport
pr
for
call
pack
and
I'm
slightly
less
enthusiastic
about
that
one.
On
the
other
hand,
it
probably
won't
cause
too
much
problems,
but
I
don't
know
what
other
everyone
else
thinks
and
then
there's,
I
think,
there's
another
one
about
disabling
native
add-ons.
B
B
I
I
guess
I
think
there
will
be
stuff
for
a
minor,
I'm
just
not
convinced
that
everything
currently
open.
That's
marks
over
miner
would
land
in
it,
but
yeah.
B
There
was
one
about,
I
think,
changing
the
format
of
the
anchor
links
in
the
markdown
files
in
the
documentation
and
I'm
kind
of
leaning
towards
not
landing
that
so
yeah,
even
though
there
might
be
drift,
then
between
documentation
changes
that
get
back
ported.
That
should
be
a
small
number
of
you
know
we're
not
really
expecting
to
land
much
on
maintenance.
B
B
But
yeah,
okay,
I
I
think
it
makes
sense
to
keep
that
simba
miner
there
it's
just
a
question
about
what
is
actually
going
to
land
in
it.
There
is
some
stuff
that
will.
A
I
guess
maybe
to
make
life
easier,
as
if
anyone
has
objections
to
a
specific
pr
landing.
I
guess
indicating
as
such,
on
the
open
back
thought
pr
might
make
sense,
and
then
we
can
stop
them
jumping
through
same
with
the
approval.
If
we
are
okay
with
something
okay,
that
sounds
good.
I
know
I
suppose,
we'll
probably
target
like
third
or
fourth
week
of
january,
so
we
should
have
time
when
we
in
the
new
year
to
figure
out
the
release
date
for
that.
A
B
Yeah
and
we've
marked
it
for
this
year,
which
will
be
it's
possible.
I
guess
so.
There
is
a
cjs
lexa
update
sitting
on
the
12th
staging
branch
and
we
haven't
yet
backboard.
So
there
was
a
sierras
update
that
we
went
that
went
out
in
the
releases
this
week,
but
that's
not
landing
on
12
so
that
regression
to
do
with
the
c
names
with
underscores-
that's
still
regressed
in
12..
So
we
can.
I
can
potentially
drop
the
sierra's
back
port
and
drop
that
on
top
of
12
staging.
A
A
A
B
A
Yeah
yeah,
maybe
I'll,
play
miles
and
ask
just
because
if
that
did
come
out,
it
would
make
sense
to
update
it
on
12
and
then
it'd
be
good
to
just
be
the
112th
patch
released,
updates
that
and
pulls
in
those
other
small
changes.
At
the
same
time,.
B
Yeah,
I
I
agree,
the
less
the
less
12,
the
less
number
of
12
releases.
We
have
to
do.
B
B
I
think
it
wasn't
clear
whether
we
normally
do
that
that
brought
in
those,
because,
on
the
one
hand
they
could
be
argued
as
security
updates,
as
in
not
sort
of
immediately
fix
security
updates,
but
sort
of
keeping
a
current
set
of
root.
Certs
could
be
seen
as
good
practice.
I
guess
there's
a
not
not
zero
possibility
that
someone's
using
a
root
set.
That's
been
dropped
out
of
that
set,
so
that
could
be
a
breaking
change.
B
We
can
break
things
if
they're
security
related,
and
the
argument,
then,
is
how
how
much
how
much
breakage
would
we
tolerate
for
a
root,
cert
update-
and
I
I
don't
know
the
answer
that
so
I
I
wouldn't
object
to
updating
the
root
certs
outright,
but
then
I
wouldn't
say
it's
absolutely
necessary,
so
I'm
willing
to
take
guidance
from
other
people
if
other
people
have
opinions
on
on
whether
those
root
certs
should
be
updated
in
lts
releases
maintenance,
lts
releases
or
we
could
decide
not
to.
I
guess
I
think,
they're
quite
old.
B
B
Yeah
yeah
yeah,
I
held
them
out
of
this
14
patch
release,
given
that
we
had
a
14
miner
sort
of
penciled
in
just
to
leave
a
bit
of
a
more
time
for
discussion.
I
guess.
B
So,
yes,
it
could
be
breaking,
but
it's
very
hard
to
tell,
because
you'd
have
to
identify
the
certificates
that
people
are
using
on
servers
that
they
might
be
talking
to.
B
C
Get
errors
because.
B
They
don't
have
the
root
certificate
to
validate
the
chain,
yeah,
that
that
is
also
a
possibility,
so
yeah,
it
goes
either
way.
B
I
I
guess
I
guess
the
only
the
the
the
workaround
would
be
that
I
think
there
are
command
line
options
to
specify
where
the
route
certs
are
so
instead
of
using
the
built-in
ones
you
can
provide
them
separately
and
they,
I
think
they
override
the
entire
set.
A
B
A
A
A
I'll
try
and
dig
out
the
link
to
the
lgs
watch,
v12
and
paste
it
in
minutes
and
it'll
be
good.
I
think
I
will
try
and
go
through
them
and
unfortunately
we're
going
for
a
quieter
phase
with
releases
now,
so
I
might
have
time
to
go
through
some
of
them.
A
Okay,
so
I
think
that's
it.
I'm
gonna
leave
that
at
2021
until
I
I
will
ping
miles
and
see
if
he
has
any
indication
if
they
are
going
to
ship
a
mpm6,
maybe
we
could
squeeze
a
release
in
I'm
kind
of
hesitant
to
do
to
like
pencil
in
any
necessary
releases
before
after
say
the
18th
of
december.
I
think
keeping
the
last
two
weeks
of
december.
Pretty
free
releases
is
a
really
good
thing.
A
Cool
okay,
thanks
for
joining
everyone.