►
From YouTube: 2022-09-22 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
A
So
let
me
just
make
sure
to
share
the
meeting
notes
with
the
participants
here,
so
everybody
can
add
themselves
and
taking
notes
and
following
a
bit
but
yeah.
The
first
item
here
is
the
plans
for
npm
9..
B
I
can
try
based
on
what
I
know
and
people
can
correct
any
mistake
right.
So
Miles
opened
an
issue
they're
planning
to
cut
npm
9
in
October,
and
that
was
an
Ask
to
try
and
get
into
node
18
and
to
be
honest
by
the
sounds
of
it,
based
on
lifetimes
and
life
cycles,
we're
probably
gonna
have
to
land
npm
9
in
node
18,
just
so
that
it's
support.
We
have
something
that
can
be
supported
for
the
lifetime
of
LTS,
just
based
on
what
they
can
commit
to
and
I.
B
Think
most
of
the
discussion
is
about
how
and
when
we
land
the
npm
9
update.
We
know
it's
going
to
be
shipped
in
October.
October
is
the
same
month
that
node
18
goes
LTS
so,
depending
on
the
date,
it
might
be
difficult
to
get
into
the
and
I
guess.
Another
thread
in
in
that
issue
was
sharing
all
the
breaking
changes
and
I
think
from
at
least
From
npm's
perspective.
Many
of
the
breaking
changes
shouldn't
shouldn't
really
break
people.
B
You
know
based
on
how
they
expect
to
interact
with
a
typical
app
it's
more
around
CIS
and
Publishing,
and
that
kind
of
stuff
and
authentication
I
think
so
there
is
an
ask
to
try
and
minimize
the
number
of
breaking
changes
and
review
them
in
advance.
I,
don't
I
think
some
of
us
have
gone
through
them
and
Mateo
offered
a
list
of
ones
that
you
know
would
be
deal
breakers
and
would
not
be
and
I
think
the
discussion
kind
of
rounded
off
there.
We
had
a
list
of
breaking
changes.
B
We
think
some
of
them
shouldn't
be
too
impactful.
We
still
need
to
I
think
we
still
need
to
decide
how
and
when
we
land
it
do
we
land
it
in
19,
first
and
then
back
Port
it
after
some
period
of
time,
or
do
we
try
and
rush
and
squeeze
in
I
guess
part
of
the
main
factor
of
that
is
we
don't
actually
know
the
exact
date
and
be
released.
A
Yeah
I
believe
I
noted
there
in
the
discussion.
The
initially
I
was
thinking.
It
was
better
to
get
it.
The
update
before
LTS,
but
Beth
had
some
good
arguments
there
too,
why?
It
would
be
not
not
not
the
worst
thing
right
to
land
before
o19
and
there
is
kind
of
the
expectation
that
it
wouldn't
break,
even
if
it's
the
current
and
it
hasn't
been
promoted
to
LCS.
Yet,
which
was
a
very
good
point
that
I
kind
of
was
missing
when
I
first
kind
of
proposed
that
that
we
tried
to
get
it
in
before
LTS.
B
Yeah,
my
motivation,
for
that
is,
if
we
ship
it
in
19-
and
you
know,
when
a
new
release
comes
out,
a
lot
of
people
like
to
get
hold
of
it
and
try
it
out
I'm,
hoping
that
any
of
the
it's
not
only
the
breaking
changes.
It's
when
you
do
such
a
significant
code
upgrade
and
change.
So
many
things
there's
going
to
be
unexpected
side
effects.
B
That's
you
know
just
what
happens
and
I
I
just
kind
of
think
it
would
be
better
to
catch
those
in
current,
where
we
can
fix
them
very
quickly,
like
every
month,
every
week
or
every
two
weeks
and
get
hopefully
that
would
allow
npm
9
to
stabilize
fairly
quickly
in
current,
and
then
we
can
get
to
a
point.
We
can
Backpage
it
when
we've
caught
all
of
the
small.
B
You
know
small
side
effects
and
also
if
there
are
any
breaking
changes
at
that
point,
we
would
know
what
people
have
hit
most
and
we
can
actually
write
in
the
change
and
okay.
Some
users
have
reported
issues
with
this
specific
thing
here
is
the
work
around
here's.
How
you
go
back,
you
know,
turn
the
option
off
or
something
like
that.
A
Yeah
and
from
a
technical
point
of
view,
I
think,
like
the
the
breaking
changes
are
minimal
and
one
good
thing
that
I
I
know
they're
trying
to
do
from
the
npm
side
is
providing
like
trying
to
limit
all
the
breaking
changes
like
into
providing
configuration
to
kind
of
like
switch
back
to
the
old
behavior
in
case
of
breaking
a
new
one,
so
that
could
be
also
a
good
having
a
a
way
to
basically
reward
functionality.
That
is
not
working
or
breaking
some
workflow.
That
I
think
that's
also
very
good.
At
another.
B
Good
Factor:
well,
it's
it's
not
really
a
technical
factor,
it's
just
like
if
mpm
9
is
being
shipped
in
October
at
the
same
time
as
node
19.
Maybe
there's
an
opportunity
there
to
invite
the
mpm
team.
You
know
to
Craft
part
of
the
release
proposal
to
highlight
what
they
want
to
highlight
and
there's
some
joint
efforts
there
to
say:
hey,
look
node's
gone
out
with
no
19
includes
mpm
9.
Here's
all
the
cool
features
in
npm
9
or
changes.
A
Yeah
I'm
pretty
sure
the
conversation
will
continue
on
the
pr
specifically
on
on
the
braking
changes
on
the
specific
specifics
of
each
braking
change.
I
know
there's
some
conversation
still
going
on,
but
I
guess
with
that.
Maybe
we
can
take
this
item
out
of
the
agenda.
I,
don't
think,
there's
nothing
too
productive
really
to
be,
or
do
anyone
agree
or
disagree.
Maybe
we
should
still
be
tracking
this
item.
A
B
I
think
if
there,
if
there
is
consensus
on
that
and
we've
given
people
time
to
object,
then
it
might
be
worth
just
adding
that
statement
to
the
notes
or
in
the
issue
just
just
to
know
what
to
expect
and
that
might
take
some
pressure
off
of
like
you
know,
maybe
even
the
mm
team
trying
to
get
the
release
out
in
time
before
LTS
and
things
like
that,
it
nice
to
clarify.
You
know
this
is
the
path
we
plan
to
take.
A
Yeah
I
can
I
can
comment
there
after
the
meeting
here.
I
can
comment.
We
discussed
it
here
and
we
have
consensus
on
Landing.
First
on
19.
A
A
C
Comments
on
it,
the
date's
gone
so
I
I
think
the
PR's
landed
on
master
I.
Don't
think,
we've
back
voted
it
yet
to.
C
I
mean
we
haven't,
had
a
14
release
for
a
16
release,
so
I
think
we
can
drop
the
we
can
carry
pick
the
pr
as
is
into
16,
because
I
think
that
has
the
same
version
of
ICU
now
as
as
current
14
would
probably
need
a
backboard,
but
I'd
have
to
check
I
can't
remember
what
version
of
ICU
note
14
is
running
on,
but
yeah
I
guess
the
we
could
probably
take
it
off
off
the
agenda.
C
Now
there
is
a
workaround
if
anyone
needs
the
updated
time
zone
stuff
before
it
lands
in
a
nug
release.
Otherwise,
I
guess
we
just
try
and
roll
them
out.
B
I'm
curious,
as
this
is
no
longer
like
dependent
on
release
scheduling
it's
just.
We
need
the
pr
I
wonder
if
we
could
consider
moving
the
issue
to
node.js
node,
maybe
with
an
explicit
ask
to
say
you
know
good
first
issue:
can
someone
back
for
you
know
time
zone
update
to
node
14..
It
seemed
quite
effective
when
we
moved
the
you
know
time
zone
automation,
one
over
there
and
tagged
it.
Someone
stepped
up
and
did
it
so
Maybe.
C
C
Yeah
I,
don't
think,
there's
much
else
to
say
about
this
now,
because
there's
no
urgent
Rush
to
get
that
out,
given
that
the
date
the
the
date
has
already
passed,
that
the
the
changes
came
into
effect.
A
A
Thank
you
so,
okay,
so
next
item
here
is
the
remove
limitation
on
frequency
of
some
verb,
minor
LTS
releases.
So
I
know
we
had
a
discussion
on
that.
I
guess:
I
had
one
question
for
the
more
experienced
folks
from
the
group
that
came
up
in
the
last
comments
in
that
threat,
which
is
when
working
when
putting
together
proposal
for
an
LTS.
A
A
B
I
think
in
the
past,
like
we
always
tend
to
cherry
pick
from
current
and
that's
what
we
used
against
our
Branch
diff,
whatever
the
current
releases
into
the
16
LTS
Branch,
when
we
had
the
two-week
baking
time
requirement
and
for
LTS,
sometimes
folks
would
manually
work
out
when
you
know
a
commit
was
less
than
two
weeks
and
stop
it,
but
an
easier
way
of
doing
it
is
using
the
tag
because
you
can
look
at
you
know
the
last
tagged
released
that
was
two
weeks
ago.
Was
this
specific
tag?
B
A
C
Depending
on
when
the
when,
depending
it'll
be
the
tag
of
the
current
release,
that's
at
least
two
weeks
old
yep.
So
if
the
current
release
has
been
in
the
last
week,
you
wouldn't
pick
that
one
you'd
pick
an
earlier
one
right
right:
okay,.
B
B
D
Just
gonna
I
think
also
at
least
when
I
was
starting
releases.
I
found
myself
like
not
I,
couldn't
find
the
two-week
rule.
If
it's
in
the
docs,
it's
not
easily
discoverable,
so
I
kept
having
to
kind
of
go
back,
or
maybe
even
asking
someone
and
and
thinking
okay
where's.
This
like
two-week
rule
coming
from
like
when
did
I
when
do
I,
apply
it
and
what
type
of
releases,
and
so
maybe
having
that
explicitly
in
the
somewhere
that
it's
a
little
more
more
easily
discoverable
might
be
helpful
too.
C
B
Yeah,
it
seems
to
be
buried
at
the
bottom
of
the
release
readme
into
the
LTS
section,
but
somewhere
we
could
put
it
to
make
more
prevailing.
We
have
the
release
phases
section
with
the
bullet
points
saying
this
is
what
Karen
is,
and
the
Subscribe
active
LTS
means
I
think
adding
it
to
the
active
LTS
to
say
that
bullet
point
to
say
in
theory,
all
the
commits
have
been
released
on
current
for
two
weeks.
Adding
it
right
there
near
the
top
probably
makes
sense
as
well.
A
Okay,
awesome,
yeah
and
I
guess
for
this
issue
in
particular,
a
month
ago,
more
or
less
than
a
month
ago,
we
had
this
discussion
and
we
kind
of
like
summarized
the
changes
we
kind
of
were
proposing.
Let
me
just
kind
of
go
over
down
here
and
like
if
everyone
is
on
board,
like
maybe
we
should
just
like
start
implementing
these
like
remove
this
from
ggenda
and
just
like
start
working
on
on
implementing
these
changes,
but
yeah
we
would
be
keeping
the
tentatively
monthly
Cadence
for
LTS.
A
We
will
be
removing
December
minor
limitation,
so
LTS
releases
would
be
kind
of
prepared,
similar
fashion
as
the
as
the
current
releases
and
at
an
extra
row
that
allows
for
a
four
weeks
period
of
baking.
Time
for
commits
that
landed
on
current
land
on
LTS
effectively
to
the
releases
would
be
running
red
stiff
against
the
second
to
last
published
version
of
currents,
so
yeah
so
kind
of
increasing
that
period.
I
guess
from
two
weeks
to
four
weeks,
but
removing
the
sember
minor
limitation,
yeah.
B
Two
kind
of
separate
things
I
think
one
way
of
just
choosing
to
go
forward
with
dropping
the
same
for
minor
restriction
would
be
I,
think
we're
at
the
time
we
probably
should
start
having
a
draft
LTS
schedule
for
node
18
and
if
we
add
that
to
the
table
and
just
put
the
sum
for
miners
in
for
each
month,
you
know
put
those
in
then
we've
kind
of
done
that,
just
by
look
at
our
schedule,
we
now
have
a
minor
scheduled
every
month.
So
right.
A
B
The
plan
the
draft,
so
that
would
be
a
way
of
moving
forward
on
that
one
I
do
think
the
full
week,
baking
time,
I'm,
not
sure,
if
I'm
not
sure
how
widely
that
suggestion
has
been
broadcast
and
discussed
and
shared.
So
it
might
be
worth
us
breaking
that
out
as
a
separate
topic
to
debate,
I
think
I
think
I
maybe
suggested
it
that
was
to
there
was
concern
if
we're
shipping
center
miners
every
month.
B
Now
the
features
don't
have
long
enough
as
long
to
bake
before
they
get
released,
and
it
was
the
kind
of
like
another
way
of
you
know
giving
them
more
time
to
stabilize
before
they
get
shipped
and
down
to
yes,
and
actually
it's
probably
easier,
rather
than
us
having
to
have
different
baking
times.
For
you
know
patch
versus
a
feature.
B
A
A
We
can
yeah
I
believe
we
have
enough
Quorum
here
to
maybe
also
just
reach
yeah,
or
we
can
continue
on
the
issue
like
whatever,
wherever
folks
prefer,
but
I
believe
it
sounds
super
reasonable
right
like
to
increase
a
little
bit.
So
basically,
we
would
always
be
targeting
the
previous
version
of
the
current,
rather
than
the
the
latest
one
that
came
out
so
that
it
should
give
about
a
month
like
baking
time
period
for
any
December
minor
feature
that
landed
on
current
before
it
gets
to
the
forest
LTS
release.
B
Yeah
and
we
always
have
the
exceptions
for
like
bug,
fixes
and
things
like,
though
those
would
still
apply
like
we're
not
going
to
wait.
Make
someone
wait
four
weeks
for
an
obvious
known
bug
fix
that
we
want
to
put
in
I
I
kind
of
think
it's
easier
to
for
the
rest
of
the
collaborator
base
to
understand
that
now,
because
we
could
just
say
they're
like.
Why
is
this
feature
not
been
shipped
and
we're
like?
Oh
we've
not
got
a
7
for
minor,
scheduled
until
December.
It's
a
bit
confusing
now
like.
B
C
I
think
it's
worth
trying
their
guidelines
and
we
have
some
flexibility
that
if
we
suddenly
need
a
patch,
we
can
pull
it
Forward
earlier
if
need
be.
You
know
if,
for
example,
some
test
is
completely
broken
and
consistently
finding
the
CI,
we
could
pull
like
a
test
fix
in
the
head
of
head
of
schedule,
but
the
the
point
is
to
have
a
documented
default
policy,
which
is
this
is
what
will
happen
unless
there's
a
good
reason.
Otherwise,
then
it
would
have
to
be
a
good
reason.
B
Yeah
I
guess
one
thing
to
track
is
like
how
many
exceptions
do
we
start
making
and
if
that
number
starts
to
be,
you
know
so
high
that
it's
causing
more
work
than
what
the
old
baking
rule
had.
Then
we
would
re-evaluate,
but
I,
think
I
think
it's
good
to
attempt
that
and
be
easier,
I
think
all
round
to
communicate
to
process
to
do.
B
D
A
Let's
keep
in
mind
if
it's
not
me,
whoever
gets
to
updating
that
table,
keep
in
mind,
then
adding
tentative
miners
for
each
month.
I
think
that
will
do
it
for
trying
to
communicate
to
the
rest
of
the
collaborators
at
least,
but
then
yeah,
let's
see
if
I
can
also
know
that
it's
a
good
idea
to
document
the
second
to
last
current
release
as
a
reference.
A
B
I
I
guess
like
so
all
of
us
here,
I'm
sure,
based
on
our
judgment,
we
would
look
at
that
and
be
like.
Oh,
this
was
an
exceptional
case.
We
did
two
releases
in
the
same
week,
so
actually
I
should
Branch
off
the
tank.
The
last
scheduled
release
or
second
to
last
schedule,
release
that
we
plan
to
do,
but
it's
just
whether
what's
the
easiest
way
of
putting
in
instructions
such
that
we're
consistent
and
is
that
using
Michael's
statement
that
He
suggests
or
including
the
one
month
mention
I,
don't
know
I'm,
not
sure
yeah.
B
D
A
D
B
Yeah,
the
two
the
thing
I
was
like
Hey.
Would
it
be
nice
if
we
could
create
a
table
when
people
could
put
their
name
next
to
it
as
early
as
you
know
a
year
in
advance,
but
actually
that's
probably
unlikely,
because
not
many
of
us
know
what
we're
doing
in
three
months
time
so
I
think
the
best
way
to
solve.
It
is
just
to
add
some
policy
to
our
major
release,
guidance
to
say
in
the
quarter
before
the
next
major.
B
A
B
D
B
Pull
out
the
policy
from
the
instructions
and
get
agreement
on
both
a
good
time
to
do
that
would
be
during
or
shortly
after
the
period
of
you
going
through
the
releases,
because
you
know
I'm
sure
you
have
lots
to
add
and
lots
to
Lots.
That's
missing!
So
it'd
be
good
time
to
reevaluate.
E
A
C
Why
are
you
bringing
that
up?
There
is
an
issue
in
build
that
I've
opened
and
need
to
probably
discuss
here.
We've
been
informed
that
the
AIX
machines
we're
using.
They
want
to
do
some
system
maintenance,
which
involves
taking
the
machines
down
sometime
between
the
26th
of
September
and
the
sometime
in
the
beginning
of
October,
so
I've
lost
it
now,
but
I
wasn't
sure.
C
What's
happened
to
the
so
when
we
look
at
the
plans,
it'll
be
good
to
to
confirm
what
the
dates
are,
because
if
we've
got
releases
planned
in
that
period,
I'll
communicate
that
to
the
folks
at
Ozil
that
are
doing
the
maintenance
and
see
if
we
can
schedule
around
that,
because
otherwise,
you
know
not
having
the
ax
machines
is
always
going
to
prevent
us
testing
or
building
binaries
on
that
platform.
E
Basically,
there
are
two
things
I
would
like
to
share
here.
The
first
one
is
that
in
that
plan
it's
missing
the
secret
release
that
will
be
between
the
18.9.0
and
18.10
and
I
was
in
the
schedule.
We
were
planning
to
have
a
regular
release
20
of
this
month,
but
due
to
the
secret
release,
I
won't
be
able
to
do
it.
So
I
postpone
it
to
27.
That
fits
perfectly
in
the
day
that
ax
machine
will
not
be
stable.
C
C
You
know,
for
example,
if
the
release
was
going
to
be
on
the
27th,
then
maybe
we
can
push
The
IX
maintenance
to
later
in
that
week,
so
it
would
still
be
still
be
in
the
period
that
they've
earmarked,
but
it
would
avoid
so
so
if
we
do
releases
at
the
beginning
of
that
period
and
push
push
the
maintenance
into
after
the
release,
you
know
that
that's
something
we
can
try
and
negotiate
with
the
the
team
that
Ozil
looking
off
the
machines.
C
E
Yeah
I
mean
I
was
really
planning
to
release
it
2027..
If
the
secret
release
comes
today
as
expected
tomorrow,
I
will
create
the
proposal
for
the
next
regular
release
and
I
I
would
take
at
least
one
day
of
baking
time
to
to
run
CIS
and
so
on
and
27
I'm
planning
to
release
it.
E
A
So
to
confirm
Richard
what
is
the
window
of
time.
E
We
I
will
include
the
secrets
release
to
the
table
as
well.
Okay,.
C
So
the
window
we
were
given
is
between
the
20
26th
of
September
and
the
6th
of
October,
but
it's
it's
not
that
the
machines
are
out
for
that
entire
period.
What
they're
saying
is
at
some
point
in
that
period
they
want
to
do
the
maintenance
and
we're
asking
asking.
Are
there
dates
that
we
need
those
machines
up
on
and.
C
Yeah
so
so
this
was
coming
back
to
the
I'm
looking
at
schedule,
but
then
I'm
aware
that
there
was
some
discussion
between
Raphael
and
Daniel
about
shuffling
around
releases
because
of
the
security
release.
C
That's
that's
what
I
want
at
the
end
of
this
meeting.
I
want
dates
for
in
in
that
period.
What
what
dates
are
we
playing
on
releases
for
and
then
I'll,
I'll,
email
back
to
Ozone
and
say
these
are
dates
that
we
required?
We
would
like
those
machines
available
for
so
we're
happy
for
the
maintenance
to
occur
outside
of
those
dates,
but
for
these
dates
we
really
want
them.
D
A
Okay
cool,
so
I
have
a
team
here
and,
like
Raphael,
said,
I
I
updated
the
date
here
to
show
27
and
I
see
that
Rafael
just
added
the
security
here
so
I
think
we're
all
booked
for
and.
D
A
E
D
D
So
it
would
still
be
I
think
like
10
11
days,
so
it's
not
too
bad,
but
yeah
I'm
happy
to
push
it
out
also
I'm
good
with
either
one,
because
then
that
adds
another
week
of
of
commits
that
we
could
put
in
the
next
18
so
either
one's
fine
I
think.
B
To
one
one
thing:
just
we've
tended
to
consider
around
that
time
is
the
LTS
date
and
we
try
not
to
cut
a
a
new
18
with
lots
and
lots
of
commits
very
close
to
the
LTS
date,
because
then
we
don't
have
much
time
to
you
know
fix
things
before
we
do.
The
LTS
transition
release,
which
is
just
a
single
commit,
so
I'm
still
pushing
back
a
week,
would
be
like
completely
fine,
if
that
makes
more
sense
to
pick
up
a
few
more
commits.
E
Yeah
and
regarding
the
the
next
major
release
yeah,
we
have
been
operating
The
Proposal.
We
still
need
to
do
a
bunch
of
work
like
create
content
about
the
notable
chains
and
the
blog
post
and
so
on.
I
guess
and
as
I
said
before,
I
will
be
able
to
do
it
until
they
28th
of
this
month.
E
Then
I
will
travel,
I
I
mean
I,
can't
do
it,
but
I
won't
be
able
to
do
it
all
day.
Just
I
will
have
just
a
few
slots,
so
would
it
be
great
to
to
coordinate
like
at
least
the
the
content
that
we
want
to
share
about
the
next
major
release
right.
B
A
B
Tends
to
be
a
bit
of
cat
hurting
and
trying
to
find
people
that
are
willing
to
contribute
sections
and
maybe,
as
an
FYI,
probably
in
a
couple
of
weeks
we
should
put
the
TSC
just
to
be
aware
that
appraisals
opened
and
we're
looking
for
notable
changes
or
just
mention
it
in
the
section,
so
they
can
volunteer
to
these
things
in
I'm,
just
going
back
to
the
node
18
schedule.
One
thing
that
is
relevant
to
the
major
release
is
the
cut.
The
current
release
before
it
goes.
B
Lts
is
the
tag
that
you
run
Branch
if
on
for
the
major
release
that
was
probably
really
hard
to
Grog
by
the
way,
I've
just
explained
it,
but
Danielle's
release
in
October
will
be
what
you
use
as
your
branch
diff
for
the
major,
because
you
you
compare
between
the
latest
18
right.
D
B
A
Yeah
but
and
Raphael
one
thing
I
like
to
imagine
that
I'll
be
around
to
to
promote
the
19
release.
So
you
don't
have
to
worry
about
that,
because
I
know
you
could
be
traveling,
so
I
can
do
the
promotion
and
I
know
we
opened
the
pr
and
we'll
be
thinking
we'll
be
kind
of
like
taking
turns
on
updating
your
proposal
until
then,
but
yeah
I
can
also
help
out
with
the
yeah,
with
the
notes
and
the
notable
changes
trying
to
get
more
yeah
yeah.
E
Once
I
I
have
the
purpose
already
for
the
next
regular
leads.
I
will
have
more
time
to
at
least
work
in
the
in
the
notable
change,
and
so
on
help
you
to
to
get
it
ready
to
to
October.
D
B
Guide
is
it's
worth
running,
sit
gym
on
the
proposal
and
compared
to
18
to
see
you
know
see
if
there's
any
massive
breakages
shown
in
the.
E
Yeah,
actually,
we
are,
we
still
need
to
start
releasing
the
the
rrc
rate.
A
E
A
A
Okay,
so
yeah
we
can
move
to
the
16
release
line
here,
oh,
which
I
see
there
is
a
plan
release
for
this
month
with
no
release
there.
Yet
I
do
propose
myself
awesome.
D
I
I
do
not
have
time
to
prepare
it,
but
be
aware
that
I
already
pushed
a
lot
of
commits
on
the
staging
branch
good.
So
if
you
want,
you
can
just
prepare
a
proposal
from
from
staging
without
Cherry
blinking.
Anything
more
there's
already
a
lot
of
content
fantastic.
Thank
you.
A
A
E
Security
release
for
18,
but
I,
don't
remember.
We
need
to
push
all
the
change
that
we
did
for
for
the
18
to
the
main
as
well
right,
yes,.
B
A
B
Yeah,
what
I
tend
to
do
is
check
out
Maine
on
the
private
repo
and
go
into
the
P
the
commits
that
have
landed
in
the
18
proposal
and
Cherry
Picked
them,
because
they've
got
all
the
metadata
you
can
just
normally
do
it's
exactly
the
same,
commit
you
can
cherry
pick
and
run
the
tests
push
yeah.
B
Yeah,
you
can
cherry
pick
them
onto
the
private
main
branch
in
advance.
If
you
want
to
get
prepped
but
yeah.
B
And
the
good
thing
is
doing
doing
it
to
private
in
advance.
You
get
the
actions
runs.
If
we
have
actions
minutes
left,
they
should
run
and
give
us
some
feedback.
I.
C
Don't
think
we
do
have
action,
minutes
left
and
I,
don't
know
who
we
talked
to
about
that
because
I
don't
know
who's
who's
in
charge
of
the
I
mean
I.
Guess
it's
the
TSC
but
I
know
who
exactly
is
response.
You
know
who's
set
up
the
no
private
account
and
get
up
and
who
has
contacts
to
try
and
get
those
minutes
extended
if
possible.
B
C
I'm
not
aware
there's
been
an
issue
opened
I
I,
just
because
I'm
on
the
TSC
we
get
the
the
automated
emails
from
GitHub
saying
you
you've
reached
100
of
your
allotment.
C
You
can
do
it
in
the
TSC
or
in
node.js
private
either
of
those
two
I
mean
if,
as
long
as
you
don't
leak,
anything
in
the
private
stuff
put
it
in
the
in
the
TSC,
repo
or
admin
one
of
those
two
yes
I
mean
it's
effectively
just
saying:
we'd
run
out
of
minutes
because
that
we're
gonna,
the
node.js
private
is
a
private
organization.
It's
sorry
it's
on
a
private
repo,
so
the
minutes
aren't
free.
A
A
B
We
don't
tend
to
specifically
plan,
we
tend
to
build
up
some
things
on
staging
and
when
it
gets
to
the
point
of
maybe
it's
sat
there
for
two
months,
we're
like
yeah,
we
should
just
ship
these
out.
Normally
what
happens
is
we
start
gradually
building
up
backboards
and
Landing
them
and
then
something
more.
B
You
know
urgent
pops
up
that
drives
us
to
ship
a
release
and
get
them
out.
So
we
probably
we
we
could
get
more
decisive
about
what
we
want
to
do.
Maybe
maybe
we
should
aim
to
do
at
least
one
every
quarter
if
there's
anything
on
the
staging
Branch.
If
there's
nothing
on
the
staging
Branch,
we
don't
do
one,
but
just
say
things
aren't
waiting
for
like
six
months.
Maybe
that's
a
fair
thing
to
do,
but
generally
it's
been
ad
hoc
and
are
cool
and
whenever
there's
something
warranting
release,
which
is
quite
hard
to
Define,.
A
B
I
kind
of
think
that
somewhat
discouraged
by
policy
from
doing
that,
because
our
policy
is
like,
we
only
really
want
in
maintenance
releases,
we
only
really
want
things
that
are,
you
know,
really
causing
problems
or
really
need
to
be
fixed.
So
people
don't
tend
to
go
to
the
effort
unless,
unless
they
really
are,
you
know,
want
the
drive
of
cross-version
compatibility
or
something.
D
I
was
waiting
for
the
security
release,
because
there's
only
one
or
last
I
checked,
there
was
only
one
back,
Port
and
yeah
I
just
didn't
want
to
put
an
entire
release
out
before
there
was
a
security
release,
so
I
was
just
waiting
for
after
the
next
one,
oh
yeah,
okay,
yeah,
so
yeah,
just
just
waiting
for
that.
That's
it.
A
A
Think
with
that
well,
is
there
anything
else
we're
getting
here.
A
D
A
C
The
LTS
release,
but
then
we've
got
nothing
planned
after
that.
At
the
moment,.
A
B
Sure
yeah
I
guess
we
just
need
to
schedule
each
month
and
we
can
do
X.
You
know
XX,
we
don't.
We
probably
don't
need
to
be
so
prescriptive
on
which
exact
week
in
the
month
it
gets
released.
Maybe
just
whenever
we
have
time
or
volunteers.
D
C
We'll
also
need
a
19.
Is
that
true,
yeah.
B
It
was
normally
just
around
the
time.
I
started
working
on
the
proposal.
It's
not
written
down.
Another
thing,
that's
not
written
down
that
we
should
probably
write
down
and
probably
put
templates,
so
you
don't
have
to
go
digging
around
and
copying
from
old
ones,
but
what
I
tended
to
do
is
use
Excel
or
sheets
or
whatever
set
the
release.
Date
add
two
weeks
and
then
just
drag
it
all
the
way
down
to
copy.
You
know
copy
two
week
intervals
for
the
rest
of
and
then
paste
it,
and
so
it.
B
I'm
sure
I'm
sure
there
is
but
30
seconds
of
excel
versus
having
to
code.
I
went
for
the
easy
problems.
A
A
B
One
thing
there
was
some
comments,
I
think
really
should
have
been
acid
in
it,
or
at
least
LTS
around
happy
eyeballs
support
in
node
18,
and
there
seems
to
be
a
drive
to
get
it
into
a
team
before
it
goes.
12.
Yes,
I
does
that
infer
that
it's
a
potentially
breaking
change
and
therefore
we
want
it
in
sooner.
C
I
think
the
argument
is
that
the
the
the
change
that
stopped
us
reordering
addresses
from
DNS
lookups
yeah
so
prior
to
node
18,
we
always
used
to
return
ipv4
addresses
ahead
of
IPv6
addresses
and
now
node
18,
currently
just
returns
them
in
the
order.
The
operating
system
returns
them
in,
which
means
you
can
get
an
IPv6
address,
even
if
so
so,
if
your
DNS
lookups
return,
an
IPv6
address,
first
you'll
get
that
even
if
you
actually
have
no
roots
that
IPv6
address
through
your
local
network
configuration.
C
So
the
argument
is
the
happy
eyeballs.
Is
this
an
amelioration
for
that?
Where
it
will
try
the
IPv6
address,
and
if
that
doesn't
work,
it
will
fall
back
to
the
ipv4
equivalent.
C
So
it
could
be
argued
that
it's
like
a
bug
fix
or
a
yeah.
It
kind
of
looks
okay,
but
at
the
moment
it's
failing
tests,
so
we
kind
of
need
those
tests
fixed
before
it
can
merge,
but
yeah
it's
it's
I'd
be
okay
with
it
going
into
18
before
it
drops
into
LTS
providing
the
tested
all
clean,
which
they're
not
at
the
moment.
B
C
B
A
So
he's
there
already
PR
there.