►
From YouTube: 2021-11-04 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
We
will
work
from
the
agenda,
which
is
in
the
node.js
release
issue
as
issue
709
and
to
start
off,
I
think,
we'll
ask:
are
there
any
announcements?
Anyone
would
like
to
make.
A
Okay?
Okay,
I
guess
I'll
move
on
to
sharing
our
schedules
and
we
will
talk
through
those.
A
So
the
first
one
is
node.js
17,
which
we've
tended
to
stick
with
a
two
week:
release
cadence.
I
think
we
might
have
had
a
delay
recently.
B
Yes,
so
the
ci
has
been
in
a
really
bad
state
recently,
due
to
a
combination
of
I
was
going
to
say
due
to
accommodation,
so
there
was
there
was
at
least
one
platform
down
for
maintenance,
but
I
think
the
majority
of
the
flakiness
has
been
sort
of
tests,
so
we
are
seeing
a
lot
of
test
failures
recently
and
they
kind
of
need
to
be
looked
at.
There's
various
issues
opened.
B
I
think
windows
has
been
particularly
bad.
There's
been
lots
of
test
timeouts
and
we're
not
quite
sure
yet
why
that
is,
but
yeah
michael
couldn't
get
a
sort
of
confidence
that
we
we
could
get
clean.
Ci
runs
on
things
that
needed
to
be
landed
or
even
a
release
proposal.
So
I
think
that's
been
postponed.
A
Yeah,
fair
enough,
so
the
next
one
we're
looking
at.
I
think
I
guess
that
dates
already
passed,
so
we
should
edit
that
one
out,
I
guess,
leave
it
blank.
If
not
our
next
scheduled
one
will
be
the
16th,
which
is
probably
okay.
A
A
C
So
I'm
actually
here
on
datadog's
behalf,
my
new
employer,
we're
trying
to
figure
out
if
we
should
join
the
release
team.
I
don't
think
we
could
onboard
in
that
amount
of
time,
but
we
do
have
a
little
bit
of
bandwidth
for
anything.
After
that
I
mean
for.
A
Now
I'm
just
going
to
say
that
sounds
really
good
and
just
to
mention
that
we
were
thinking
of
starting
up
the
like
onboarding
sessions
again.
So
hopefully
we
would
be
able
to
tie
that
in
and
bring
some
of
your
votes
onto
the
onboarding
sessions
to
get
people
up
to
speed.
C
D
So
I
was
going
to
say
like
if
folks
are
wanting
to
get
involved.
That
is
like
one
of
the
things
where
we
could
you
know.
Maybe
you
could
audit
folks
who
are
doing
the
work
or
whoever
wanted
to
get
involved.
Can
you
know
help
out
with
that
stuff,
but
it
like,
I
don't
know
what
we've
done
for
the
most
recent
onboarded
release
managers,
but
usually
that
process
takes
like
a
number
of
weeks
and
over
a
month
to
kind
of
get
to
the
point
where
you
could
be
leading
your
own
release.
A
We
take
an
item
on
to
like
the
end
of
the
agenda,
to
talk
about
how
we're
gonna
proceed
and
with
these
onboarding
sessions,
maybe
set
an
action
or
something
for
a
doodle
poll.
A
But
either
way
I'm
gonna
leave
this
at
the
16th
we'll
see
when
michael
is
around
and
see
if
he
can
pick
up
the
next
one
and
just
see
which
date
that
lies
on.
But
if
not
the
following
release
is
16,
so
we
should
be
okay
there.
A
As
for
16,
I
guess
we
haven't
scheduled
them
yet.
Typically,
we've
gone
for
a
monthly
cadence.
Do
you
think
we
should
stick
to
that?
Maybe
we
should
expand
this
a
little
bit
here.
A
B
Yeah,
possibly
I
I'm
not
exactly
sure
what
landed
in
17
that
hasn't
made
it
into
16
that
isn't
similar
major,
because,
obviously
now
it's
in
maine
now
now
now
we're
in
lts.
We
sort
of
expect
things
to
be
in
current,
so
we
haven't
had
a
current
for
a
little
while.
Well
current
current
was
the
note
17
release
and
1701,
which
was
the
sort
of
quick,
quick
fix
up
so
yeah.
It's.
B
A
30Th
of
november
is
a
tuesday
so
that
works
yeah.
I
think
that
makes
sense.
I
may
be
able
to
volunteer
with
that.
I'm
just
going
to
check
some
holiday
dates
I
have
coming
up,
but
I
should
be
able
to
volunteer
for
the
16
release.
A
B
Release
but
yeah.
A
B
Think
can
anyone
remember
what
we
usually
do
with
miners
in
lts.
B
Okay,
does
that
exclude
this
quarter
then,
given
that
that's
when
we
did
the
lts
transition,
or
would
we
want
to
do
one.
A
I
would
actually
say
if
we're
doing
one
in
january,
that
should
be
the
one
that's
the
minor
and
maybe
patch
releases
I
feel
like
that,
would
work
okay.
It
gives
us
time
to
build
up
the
features
and
audit
them
okay,
so
this
would
be
16,
31
and,
of
course,
some
other
other
things
may
edit
our
plans.
If
there's
a
major
issue,
we
may
need
to
do
some
interim
releases,
but
we
can
address
those
if
they
pop
up.
A
B
D
A
Find
a
release
candidate
phase
difficult
to
meet
and
it
means
timings
are
more
difficult
to
me.
I
guess
we
can
discuss
that
another
time.
Maybe
if
we
raise
an
issue.
B
Mean
this
cautious
is
that
the
word
I
maybe
it
doesn't
even
need
to
be
the
release
camera,
but
it's
almost
like.
B
Ideally,
the
release
proposal
should
be
opened
for
a
bit
for
the
miner.
Just
so
people
can
object
to
all
yeah.
I.
B
Them
too
often,
I
mean
the
candidate's
good
to
actually
get
if
people
are
willing
to
help
test,
but
it's
more
of
a
kind
of
chance
for
people
to
speak
up
and
say
things
like.
Oh
this
shouldn't
land.
Without
this
other
thing
or.
A
Yeah
yeah,
perhaps
we
should
add
that
in
I
my
gut
is
like
a
week
minimum
for
a
minor,
but
two
weeks
would
be
ideal
kind
of
that's
the
kind
of
ballpark.
I
was
thinking.
D
B
A
Yeah
editing
it
now
live
will
be
a
bit
pain,
I'll
save
this,
because
I
think
those
dates
look
good,
and
that
means
our
14
release
should
have
enough
content
in
it
by
january.
A
So
it
looks
good
node
14.
Where
are
we
here?
I
guess
14
18
went
out.
14
is
now
in
maintenance,
so
I
guess
it's
just
ad
hoc
as
we
need
so
does
anyone
know
anything
pressing.
B
I'm
not,
I
don't
know
if
there's
anything
pressing,
I
have
seen
things
being
landed.
I
have
a
pr
that
hasn't
landed
to
backport
the
python
3.10
support.
B
So
at
the
moment
the
windows
ci
fails
on
node
14
without
the
310,
the
python
310
patches,
but
it's
complicated
because
I'm
seeing
other
windows
tests
fail
for
similar
reasons
that
seven
you
know,
1617
master
were
failing.
So
I
am
seeing
some
timeouts
and
windows
tests
that
are
not
related
to
the
python
support,
but
then,
without
the
python
support
the
tests,
the
compilation
flows
and
we
don't
get
to
tests
so
yeah
14
at
the
moment
is
yeah.
A
B
A
A
Okay,
if
it
was
a
minor,
I'm
not
so
sure
I
think
maybe
we
deferred
a
minor
to
january
to
give
us
time
to
decide
what
to
be
included
and
what
not
to
be
okay,
so
I
might
just
drop
that
in
it
should
be
a
small
release,
though
so,
hopefully
it's
not
going
to
be
too
intensive
to
okay
on
the
wrong
column
again
haven't
I.
A
Well,
I
think
that
I
think
that's
a
good
aim.
We
can
get
any
lingering
patches
in
in
good
time
before
the
holidays,
and
then
I
I
would
suggest
if
we
were
considering
doing
a
minor
during
maintenance.
We
aim
for
january.
Likewise
with
the
16.
A
Did
I
add
the
minor
end,
just
as
a
yeah,
probably
just
just
sort
of
heads
up?
If
people
are
considering
asking
for
a
minor
to
go
into
14,
then
this
is
time
frame
they
can
kind
of
expect
it.
A
Right,
I
suspect,
after
that
our
miners
will
be
even
fewer.
Let's
hope,
with
things
going
into
this
yeah.
C
A
I'm
good
okay,
that's
14
12.!
I
guess
we
likely
mentioned
12
earlier.
It's
very
much.
A
maintenance
goes
end
of
life
in
april.
B
B
I
think
there
were
some
other
psm
related
things
that
guy
wanted
to
backport.
There's
are
those
those.
D
Yeah,
I
can,
I
can
talk
to
these,
so
I
I
feel
like
the
esm.
Lexer
stuff
is
pretty
straightforward.
Personally,
the
you
know,
I
think,
similar
to
napi.
This
is
kind
of
like
a
tool
that
we
embed
most
of
the
changes
that
come
to
it
are
for
consistency
and
fixing
edge
cases
so
like
even
if
there's
you
know
like
sember
miners
or
some
of
our
majors
in
the
lecture.
D
You
know.
I
don't
think
that
that
that
is
more
about
like
the
interface
we
use
and
not
so
much
the
experience
for
our
customers.
So
I
think
that's
fine,
the
other
one
there
is
the
is
the
bigger
challenge,
the
the
december
minor
change
that
was
there
for
12..
Okay,
I
don't
think
it's
been.
It
was
backported
and
I
I
kind
of
talked
to
a
guy.
D
He
didn't
realize
about
what
was
like
just
kind
of
like
the
policy
and
we
don't
usually
back
with
reminders
until
we're
ready
to
do
a
minor,
and
so,
if
we
take
a
look
here,
yeah
pattern,
trailers,
backboard,
so
that's
the
one
that
is
I'm
on
the
fence
about
whether
or
not
we
should
do,
and
I
would
like
to
defer
to
the
team
because,
like
12,
is
practically
in
maintenance
now
now.
D
This
is
like
an
additional
feature
to
the
export
maps,
feature
of
node
that
that
adds
you
know
some
syntax
to
support
edge
cases
and
the
general
like
idea
here
of
why
they
want
it
to
be
backboarded,
so
that,
like
package
maintainers,
can
adopt
these
tools
sooner,
since
it
will
take
some
people
to
get
off
of
off
of
node
12..
D
I
am
uncomfortable
with
landing
a
semver
minor
like
this
on
12,
so
close
to
end
of
life,
especially
if,
like
you
know
our
general
support
stories,
we
don't
support
past
end
of
life
and
our
advice
to
maintainers
is,
you
know,
like
don't
support
these
old
versions.
Well,
it
does
create
a
little
bit
longer
of
a
timeline,
possibly
for
adoption
of
this
feature,
I'm
not
convinced
that
we
should
kind
of
be
like
bending
the
rules
like,
even
if
it
was
like
early
in
maintenance.
D
I'd
be
skittish
about
doing
this,
let
alone
like
right
before
we
land,
I'm
not
sure
about
that
fixed,
regular
expression
to
detect,
slash
and
slash
that
does
to
me
seem
like
it
might
be,
just
like
a
full-on
bug
fix
which
in
which
case
is
probably
fine.
Yes,
this
was
a
bug.
D
C
Speak
a
little
bit
on
my
own
about
the
other
one
with
the
patterns.
The
only
real
concern
that
I
would
have
is
people
may
update
their
packages.
We
saw
this
with
people
doing
usage
of
exports
and
expect
things
to
work
but,
like
miles
said
we're
so
close
to
end
of
life.
I
don't
think
there's
much
need
for
us
to
do
it.
I
do
think
if
it
was
near
the
beginning
of
maintenance,
there
would
be
a
stronger
argument.
C
A
C
So
I
don't
think
it.
I
don't
think
we
need
to
worry
about
it,
because
it's
so
close
to
end
of
life.
The
only
thing
that
we
would
get,
I
think,
personally,
of
real
life
value
in
maintenance
mode
not
like
to
give
features,
is
the
ability
to
write
something
that
works
in
12
and
14
and
doesn't
give
an
error
right.
I
think
we're
so
close
to
the
end
of
life
that
that's
true
for
a
lot
of
features.
We're
not
gonna
likely
want
to
make
an
exception.
Just
for
this
has
this.
C
Yeah
so
pattern
trailers
work
in
14,
yes,
okay,
but
there's
a
previous
feature
where,
instead
of
a
pattern
which
is
the
asterisk,
if
you
had
a
trailing
slash,
it
acted
like
what
the
pattern
does
for
slash
asterisk.
C
So
in
14
you
get
a
warning.
If
you
do
just
the
trailing
slash.
C
B
A
A
I'll
craft
it
in
the
notes
which
I
wrote
respectively
and
then
so
we
have
it
to
point
to
say:
hey
we
discussed
this
here.
Our
gut
feeling
is
this,
but
we
can
continue
the
discussion
like
it's
not
a
flat
note.
It's
like
I
got
fields.
This
probably
wouldn't
be
worth
it
at
this
point
in
time.
I
I'd
also
back
to
the
like
release
plan
for
12..
My
gut
would
be
to
add
an
entry
for
a
following
patch
release,
but
not
following
sun
vermin.
B
It's
probably
not
super
urgent,
but
I
did
land
a
sierra's
update
on
master
a
couple
of
days
ago,
which
we
could
potentially
put
back
to
12
because
one
of
the
security
releases
we
did
which
updated
outdated
sierra's.
B
There
was
a
small
regression
to
do
with
resolving
server
names
with
underscores
in
yeah.
So
ideally,
we
just
follow
the
normal
landing.
Current
first
make
sure
there's
no
major
regressions
found,
and
then
you
know,
if
it
all
seems
okay
after
a
couple
of
weeks,
potentially
back
put
that
into
a
12
release.
If
one
is
lined
up
for
other
reasons,.
A
Yeah
yeah,
based
on
that,
I
think
not
setting
us
at
like
a
november
date
for
this
12
release
makes
sense.
It
can
give
us
some
more
time.
We've
only
like
looking
at
the
station
branch
just
now,
we've
got
one
commit
there.
Another
commit
open
that
we
plan
to
land,
so
it
probably
makes
sense
to
hold
off
and
see
what
happens.
There.
Maybe
talk
about
it
in
a
couple
of
weeks.
B
B
A
Yeah
sure
sounds
good.
It's
definitely
worth
doing
at
least
a
patch
release.
I
think
this
year,
especially
just
because,
if
we
do
hit
any
security
releases,
just
having
all
the
freshest
bug
fixes
on
there
makes
sense
and
makes
our
life
easier,
particularly
if
there's.
B
Ci
problems,
I
think
12
is
okay,
so
12
is
the
only
release
that
other
than
master
that
we
are
doing
daily
builds
for
so
the
daily
bills
of
12
have
actually
been
quite
good
they're,
mostly
passing
okay,
there's
just
the
old
flake.
That's
that's
fine,
but
generally
12.
The
crb12
has
actually
been
quite
good.
So
I
I'm
not
at
this
point
in
time
concerned
about
12..
It
doesn't
suffer
the
python
issue
because
we
never
backported
the
python
3
support
to
12..
B
So
no
12
still
requires
python
2
to
build
and
doesn't
even
attempt
to
build
a
python
3..
So
you
know
want
to
build
a
python
3
move
to
a
different
release,
but
yeah
12.,
it's
been
a
while,
I
think
the
last
non-security
release
according
to
that
was
back
in
july.
But,
to
be
honest,
I
I'm
not
saying
a
huge
amount
of
things
that
we
want
at
that
point,
which.
A
Is
a
good
thing:
it's
nice
to
have
it
tailing
off
a
bit
before
okay,
sometimes
of
our
schedules,
I
think
we're
good,
so
we're
hoping
to
have
a
patch
release
of
16
in
the
end
of
november
14,
a
patch
release
same
similar
time
frame-
and
I
guess
12
with
tbd,
but
hopefully
this
year,
and
I
might
chat
to
michael
about
when
he
thinks
he'll
get
time
to
prepare
the
next
17
and
whether
we
should
swap
swap
him
out
and
switch
things
around
slightly.
A
Okay.
That
sounds
good
and
I
guess
the
only
other
topic
that
we've
touched
upon
is
the
onboarding
new
releases
I
did
put
out.
A
I
think
it
was
on
the
collaborators
discussion
and
ask
for
folks
saying
who's
interested
from
the
collaborator
base,
who
would
like
to
contribute
to
the
release
working
group
and
maybe
be
on
board
as
a
releaser,
how
we've
done
that
before
was
we
set
up?
Some
doodles
found
a
good
time
for
the
folks
that
were
interested
and
then
had
hour-long
kind
of
sessions
where
I
would
go
to
that
session
and
actually
prepare
a
release.
I
think
richard
you
did
it
as
well.
A
You
prepared
a
release,
kind
of
like
shadowing
sessions
and
once
folks
have
gone
through
a
couple
of
those
next
step
is
for
them
to
prepare
a
release
which
you
can
do
with
the
access
like
just
public
access
to
node,
but
that
first
release
would
be
signed
by
a
member
of
the
releases
team
and
that's
kind
of
like
the
onboarding
release,
like
you
prepare
one
with
a
release
assigning
it,
and
then,
after
that,
it's
just
the
actual
steps
of
onboarding
onto
the
release
working
group
releases
group,
which
involves
like
generating
the
keys
getting
your
signing
key
added
where
it
needs
to
be
and
getting
the
access
you
need.
A
So
it
does
sound
like
there
is
a
lot
of
interest
from
quite
a
few
different
places.
So
I
guess
the
actions
on
me
to
try
and
set
up
doodle
with
some
context
to
say:
hey
we're
looking
at
starting
these
sessions
again
here
are
some
documents
that
you
can
look
at
to
see
what
the
process
entails
up
front.
But
if
you,
if
you
do
have
interest,
please
submit
your
availability
and
we're
trying
to
get
some
pairing
sessions
set
up.
B
B
A
B
I
helping
you
along
mainly
because
you're
not
sure
what
might
go
wrong
or
what.
A
B
A
A
I
don't
think
you
could
just
read
it
and
pick
it
up
and
run
with
it,
because
there's
a
lot
of
things
that
could
go
wrong,
as
you
say,
and
there's
some
things
that
are
a
bit
open
to
interpretation.
So.
B
B
Yeah
well,
it's
I.
I
think
we
still
need
people
to
do
a
current
release
before
an
lts
special
keys
yeah.
I
suppose
that
might
be
something
to
discuss
once
we've
to
attack
on
to
the
end
of
this
with
the
key
server
stuff,
because
I
think
we've
still
got
an
open
issue
in
the
core
repo
about
updating
the
signing
verification
steps,
because
it's
still
pointing
at
the
decommissioned
sk
sks
key
servers.
B
A
Yeah,
I
kind
of
kind
of
my
gut
feeling
now
is.
We
should
just
get
that
pr
landed.
Saying,
hey
it'd,
be
great
if
you
could
verify
if
you
haven't
already,
but
I
think
we
should
just
land
this
main.
The
reason
why
I
think
that
would
be
okay
is
because
the
folks
that
have
not
verified
their
keys
are
folks
that
are
not
doing
releases
in
the
past
like
a
few
months.
A
So
if
people
are
trying
to
verify
a
release,
I
I
suspect
they
will
be
verifying
a
recent
release
which
is
likely
to
work
because
it
will
be
done
by
the
folks
that
are
most
active
at
the
moment.
A
So
I
think
it
should
be
okay,
with
the
caveat
that,
like
we
should
still
try
and
get
those
folks
to
verify
if
they're
still
on
the
release
group
yep,
I'm
I'm
okay
with
that,
okay,
yeah
I'll,
try
and
post
a
comment
to
that
effect
and
say
we
should
just
land
this
get
things
working
if
there's
a
problem
with
an
old
key
verifying
an
old
release,
I
think
that's
better
than
the
majority
case
where
we
are
at
the
moment
where
they
all
don't
work.
So.
B
Yeah
yeah,
I
don't
know
what
to
do
with
that
one.
We
used
to
release
free,
bsd
binaries.
I
can't
remember
if
it
was
node,
8
or
no
10.
I
can't
remember
if
we
dropped
through
his
free
bsd
in
note
10
or
whether
it
was
no
12.,
but
we
used
to
release
the
binaries.
But
then
we
had
issues
on
the
ci
and
not
enough
expertise
and
build
to
keep
the
platform
running
and
I
don't
think
anything's
changed
in
the
meantime.
So
there
was
an
issue
in
build
a
belt.
B
So
at
the
moment
freebsd
is
tier
three,
which
means
we
don't
produce
binaries
for
it.
But
there
was
an
issue
opening
build
to
try
and
get
to
discuss
what
needed
to
happen
to
get
freebsd
promoted
up
again
to
like
tier
two,
but
I'm
not
aware
that
anything's
changed
in
the
meantime
and
that's
kind
of
stalled
out
and
was
also
closed
and
by
the
stellbot
so
yeah
I
I
guess
it
depends
who's
asking,
but
then
also
who
would
have
available
in
the
community
to
help.
A
A
B
A
What
was
the
stupid,
actually
sourcing
machines?
Was
it
because
didn't
join
us
to
freight
their
sd
machines.
A
A
A
Sure,
I
guess
you
don't
that
one
might
stay
in
limbo
for
a
little
bit
longer
see
if
anyone
comes
back
expressing
desire
or
interest.
A
Okay,
any
other
things
to
discuss.
A
Nope,
so
I
try
and
get
the
notes
written
up
with
those
actions,
and
they
do
include
commenting
on
the
back
port
setting
up
those
men
shadowing
mentorship
sessions
and
such
so
try
and
get
those
written
up.
Thanks
for
joining
everyone
and.