►
From YouTube: 2022-03-10 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
nigest
release,
working
group
meeting
on
the
10th
of
march
2022
and
we'll
start
by
going
we'll
be
working
through
the
agenda,
which
is
in
the
node.js
release
repository
and
it's
issue
732,
but
first
start
with
some
announcements
and
one
I'll
mention
is:
we
did
ship
node.js
1770
yesterday
there
is
a
regression
in
it.
The
fix
the
regression
is
related
well
is
surfaced
via
yarn.
A
B
Yeah,
it
doesn't
affect
the
releases
as
such,
but
I
have
just
in
the
last
couple
of
days
switched
over
the
builds
for
the
master
branch
and
I
guess
node
18
when
we
start
doing
node
18
builds
so
that
it
now
builds
on
relate
rather
than
centos
7
on
the
linux
platforms.
B
So
there
has
been
a
switch
in
building
machine
and
it
will
affect
what
operating
what
distributions
of
linux
the
binaries
can
run
on.
So
I
am
going
to
pr
change
up
to
the
building
file
in
the
core,
hopefully
later
today,
to
explain
all
this,
but
just
to
make
people
aware
of
anyone
who's
trying
to
use
the
nightly
binaries.
There
has
now
been
a
change
in
building
building
machine
and
environment.
A
A
Yes,
I
related
later
on
january,
tagged
where
we,
we
did
a
very
long
time
ago
suggest
the
idea
of
creating
a
little
bit
of
guidance
on
what
to
do
when
a
release
is
broken
and
then
also.
Similarly,
we
also
have
the
working
around
working
out
a
policy
for
reverts
for
lts
branches,
so
the
order
of
operations-
and
I
believe
at
the
time
it
was
like
hey
we
should
on
master
and
then
the
release
branches.
Or
can
we
revert
on
the
release
branches
first
and
leave
it
on
master
so
yeah?
A
So
reading
the
description
it
seems
to
suggest
we
should
have
some
guidance
on
what
collaborators
should
do.
What
is
the
responsibility
of
the
releases
and
it
would
be
nice
to
document
what
finds
breaking
and
how
to
triage.
A
I
kind
of
feel
like
this
is
going
to
be
a
case-by-case
basis
because,
particularly
in
the
case,
I
think
surfaced
this.
The
breaking
change
landed
like
five
or
six
release
versions
back
and
at
that
point,
at
that
point
you
have
to
weigh
up
like
we're,
reverting
this
back
to
what
used
to
be
actually
cause
more
suffering
than
what
leaving
it.
As
is
at
that
point,
and
just
going
back
and
documenting
it.
A
B
A
A
B
A
Yeah
to
me,
it
kind
of
seems
like
the
default
state
should
be
inform
the
person
that
introduced
the
breakage,
possibly
just
because
you
want
to
offer
them
the
opportunity
to
patch
the
break
rather
than
just
a
flat
reverb.
But
then
you
know
in
the
interest
of
time
we
would
choose
to
revert
and
then
re-land
again
when
it
was
fixed,
so
yeah
in
terms
of
responsibility
for
actually
fixing
the
the
problem
itself.
I
I
do
think
for
us
it'd
be
trying
to
pr
author
or
failing
that
open
a
re
revert.
A
For
the
case
of,
I
wonder
if
we
do
want
to
document
kind
of
like
for
the
case
of
if
we
ship
a
release
that
has
a
break
in
it.
I
think
generally,
at
least
at
least
for
me,
if
I've
done
a
release
and
it's
like
significantly
broken,
I
always
kind
of
allocate
a
little
bit
of
time,
just
in
case
to
try
and
get
a
patch
release
out.
A
You
know
the
next
day
I
wouldn't
obviously
we
all
have
other
things
on
our
plate,
so
there's
no
expectation
that
everyone
can
do
that,
but
I
think
generally
we've
kind
of
followed
that
people
with
they've
accidentally.
You
know
if
something's
slip
through
the
net,
it
tends
to
be
the
releaser
that
will
offer
to
patch
it.
If
not,
I'm
sure,
a
number
of
releases
who
did
have
time
would
do
it
so.
B
I
mean
we
can
say
things
like
you
know
we
will
we
we
will
default
to
reverting
as
soon
as
possible,
but
on
a
case-by-case
basis.
I
don't
know
I
I
think
generally,
we
would
revert
it's
only
the
case
of
if
it's
now
been
in
a
release
for,
like
you
know,
if
it's
been
in
such
a
couple
of
releases
since
it
broke,
that's
yeah,
we
start
getting
a
bit
hesitant,
but
if
it's
immediate,
then
I
can't
see
why
we
wouldn't
revert
if
it
was
like
an
immediate
spot
that
you
know
this.
B
A
Sometimes
the
authors
like
very
quickly
said:
actually
I
can
get
a
fix
ready
in
the
same
amount
of
time
it
would
take
for
you
to
get
a
revert
so.
A
A
So
that
might
be
another
thing
that
factors
into
odds
into
our
decision,
because
if
this
was
a
breaking
change,
that
was
a
side
effect
of
another
breaking
change
that
we
just
admitted
documenting.
A
I
feel
like
if,
if
people
still
feel
that
breaking
change
was
the
right
thing
to
do,
and
it
happened
in
a
major
retrospectively
documenting,
it
seems
okay
and
from
that
point
of
view,
if
if
we
would
still
make
the
decision
to
include
it
again,
if
we
could
go
back-
and
I
don't
see
you
know-
it
seems
fair
like
like.
A
A
So
in
terms
of
actually
getting
some
actions
on
this
out
of
this
meeting,
what
what
would
that
look
like
for
the
question
of
what
do
collaborators
do?
Does
that
that
loosely
indicates
to
me
maybe
an
extension
to
the
collaborator's
guide
to
say
what,
if
you've
introduced
a
break.
A
Yes,
I
think
yeah.
So
in
minutes
and
in
this
issue
I
can
just
added,
like
a
to-do
in
action,
to
extend
that
part
of
the
collaborative
guide
to
cover
what
to
do
when
reverts
in
the
interest
of
time.
We
probably
won't
get
to
the
point
of
drafting
what
that
will
say
today,
but
I'll
just
leave
it
as
that.
As
a
tangible
thing,
someone
could
pick
up
and
create
the
words
for
prn.
A
B
Yeah,
it
may
be
affected
by
other
factors
such
as
you
know
how
long
it's
taken
to
spot
spot,
the
regression
yeah
because
yeah.
If,
if
it
has
been
in
a
couple
of
releases,
then
you
might
imagine,
people
would
have
adapted
code
to
it.
But
if
it's
immediately
in
the
release,
that's
just
gone
out
should
be
small
enough
time
window
that
you
know
we
can
get
the
message
out
and
people
can
just
wait
for
the.
A
Yeah,
so
maybe
in
that
wording
we
need
to
say
like
highlight
that
trade-off
like
to
say
considering
how
long
it's
been
since
it
landed,
bear
in
mind,
reverting
may
come
at
a
cost
and
whether
this
cost
is
you
know,
in
the
best
interests
of
consumers,.
A
A
C
Perhaps
in
the
interest
of
making
sure
that
if
we
are
talking
about
releases
that
fix
issues,
people
are
saying
we
ought
to
make
sure
they
get
out
relatively
quickly,
perhaps
some
amount
of
coordination
or
like
identified
coordination
channels.
Saying
hey.
Let's
make
sure
everybody's
talking
about
this
in
in
the
release
channel
on
slack
or
something
to
that
effect
might
be
worth
documenting
just
so.
It's
very
obvious
where
to
coordinate.
A
A
My
gut
would
be
that
might
also
be
in
the
collaborators
guide
so
like.
If
you
support
a
regression,
inform
the
release
working
group
so
that
they
can
schedule
the
next
release
to
ship.
The
revert.
A
Any
other
comments
on
this
one
I
can.
I
can
list
out
that
tangible
thing
of
expanding
the
cardboard
guide
not
entirely
sure
on
what
we
would
craft
on
the
releases
side
to
kind
of
handle
the
situation.
I
think
we've
just
generally
handled
it
amongst
ourselves,
so
I
don't
really
know
what
we
could
write
down
to
say.
You
know
when
something
needs
to
go
out
urgently.
B
B
We
could
do
is
a
revert,
but
we've
never
had
to
I
I
don't
recall
where
we've
had
to
do
the
revert
I
mean
normally,
someone
else
would
just
open
revert
pr
and
it
would
get
merged
anyway,
and
it
doesn't
have
to
be
a
releaser.
It
could
be
anyone.
A
B
A
A
Or
in
the
next
release,
or
something
like
that
whenever
next
is
yeah,
I
agree,
I
don't
think
we
want
to
put
any
more.
You
know
weight
on
the
release's
shoulders
and.
B
I
think
we've
also
also
in
the
past
we've
made
judgment
calls
based
on
perceived
severity,
so
I
think
occasionally,
we've
done
say
a
release
on
a
friday,
but
otherwise,
if
we
felt
that
it
is
a
regression,
but
it's
not
majorly
super
urgent
one.
We
then
normally
punt
it
into
like
the
next
week
or
like
the
next
tuesday,
or
something
because
tuesday's
a
normal
release.
Date.
A
B
D
Yeah
exactly
yeah,
so
I
just
mean
like
it's
not
like.
We
have
an
sla,
but
I
think
I
think
for
current,
like
you
know,
if
something's
broken
or
like,
if
there
was
unexpected
breaking
change,
you
know
unless
it's
completely
experience
breaking
for
everyone.
There
is
a
pretty
reasonable
solution
which
is
downgrade
to
the
previous
release
and
wait
a
week
which,
like
I
think,
is
reasonable
in
the
contract
of
current.
A
Great
okay,
so
yeah,
we
spent
a
little
bit
time
on
this.
One
I'll
add
to
the
issue
the
one
tangible
thing
to
expand
the
collaborators
guide
and
maybe
pull
in
some
of
our
notes
that
we've
discussed
here.
But
the
moment
it
sounds
like
we
don't.
A
We
don't
feel
we
need
to
add
any
explicit
policy
or
anything
about
what
us
releases
have
a
responsibility
to
do
in
terms
of
shipping
releases
when
there's
a
break.
B
Maybe
I
mean:
is
this
again
going
back
to
writing
down
things
like
whether
we
prefer
things
to
be
reverted
or
master?
First
and
cherry
picked.
B
Yeah,
I
kind
of
feel
that
might
be
worth
doing
in
terms
of
income
in
in
conjunction
with
what
we
were
talking
about
previously.
So
maybe
something
in
the
collaborative
guide
saying
you
know:
river
revert
and
master
if
possible.
I
guess
the
only
the
there
might
be
situations
when
when
that
wouldn't
happen,
for
example,
if
someone's
picked
something
onto
directly
onto
a
release,
for
example,
maybe
it's
a
v8
patch
that
has
to
be
applied
to
a
release
line,
but
not
it
doesn't
apply
to
master,
because
the
v8
versions
are
quite
far
apart.
B
A
I
think
that
that
might
be
a
factor
in
the
tooling
as
well.
That
might
actually
be
related
to
what
happened
in
the
case
that
mary
reported
because
of
our
branch-
diff
tooling,
because
that
committed
already
landed
on
that
branch
and
then
subsequently
be
reverted,
because
we
didn't
fully
revert
it
on
the
master
branch.
Our
branch
diff
didn't
pick
it
up.
I
think
that
might
have
happened
so
that.
A
B
A
A
A
Okay,
I
think
we
talked
about
that
one
quite
a
lot.
The
other
item
on
the
agenda,
but
possibly
shouldn't
be
anymore,
is
the
proposal
to
rename
the
citrum
team
to
release
automation.
I
think,
in
the
last
release
meeting
we
discussed
actually
just
changing
the
permissions
such
that
on
those
release.
Tooling
repositories,
it
just
has
the
releases.
As
you
know,
the
releases
group
is
accessed
to
read
and
land.
A
A
Yeah
I'll
need
to
rename
this
because,
but
yeah,
we
just
want
to
make
sure
that
the
release
group
has
access
to
these
tools
because
they're
pretty
much
within
our
remit.
These
days.
A
So
we
have
it's
just
released
it
shipped
yesterday.
Hopefully
a
patch
release
imminent
and
then
brian's
volunteered
to
do
his
first
release
promoted
by
himself
on
the
22nd,
and
then
we
also
have
the
one
or
the
start
of
april,
which
I
think
one.
You
said
that
time
worked
for
you
as
you're.
Preparing
your
first
release.
Is
that
correct.
B
Yeah
I've
got
the
proposal
branch
for
1771
as
well
ready.
A
We
can
get
that
built
and
then
merged,
so
it
also
looks
like
we
have
a
16x
release
planned
and
I've
seen
danielle
the
proposals
open
for
that
one,
but
I
think
there's
an
issue
on
it.
B
Yet
the
the
windows
github
workflow
is
broken
and
I
think
it
looks
like
it's
related
to
an
actions
runner
up
update
where
there's
a
newer
version
of
visual
studio
installed,
but
that's
as
much
as
I
know
so
running
a
previously
passing
workflow
on
an
older
commit
on
16x
staging
now
fails,
so
I
think
it's
an
environment.
I
think
environmental
change
has
triggered
it.
B
I
don't
know
if
there's
a
cause
or
something
that
can
be
worked
around
in
the
code,
but
yeah
we've
basically
got
a
failing
windows,
github
ci
on
the
16
branch.
I
don't
believe
it's
only
17
or
master,
but
in
that
I've
not
seen
it
fell
there.
So
I
don't
don't
really
know
what
to
do,
though.
B
It's
quite
hard
to
get
windows
knowledgeable
people
to
look
at
things,
yeah.
B
I
have
no
idea
because
you
just
specify
windows,
20
2022
as
the
runner,
so
I
don't
know
if
it's
pinnable
to
particular
versions
within
that.
B
I
can't
even
remember
if
you've
even
got
windows,
we've
got
visual
studio
2022
in
the
ci
we
may
not.
I'd
have
to
go
back
and
look.
A
If
we
were
to,
if
we
were
to
add
2022
we'd,
probably
add
that
support,
we
wouldn't
add
that
to
all
release
lines
retrospectively
typically,
would
we.
B
Windows
is
very
weird,
there's
a
very
there's,
a
document
in
the
build
repository
with
a
matrix
of
what
runs
where
and
it's
kind
of
like
a
cross
matrix
between
verges
of
node
and
then
what
versions
we
build
on
and
then
what
versions
we
test
against,
because
we
do
build
add-ons
on
different
versions
of
visual
studio
compared
to
the
versions
that
we
use
to
build
node,
I
mean
traditionally,
it's
jail's
been
looking
after
all
of
this,
so
most
of
the
rest
of
us
haven't
really
looked
the
only
general
awareness
that
it's
all
there,
we've
not
really
sort
of
maintained
it
in
terms
of
well.
B
So
yeah
that
that
could
be
true,
that
2022
is
not
officially
sporting
16.
I
don't.
I,
I
probably
not.
A
B
It
started
failing
and
then
when
we
went
back
to
like
a
workflow
which
passed
and
then
we
ran
it,
it
failed.
So
the
commit
hadn't
changed.
So
you
know
it
was
the
same
level
of
node
code
but
re-running
it
on
the
current
runners
failed.
So
this
seems
to
be
some
sort
of
incompatibility
between
whatever
whatever
it
was
upgraded
to
yeah.
I
would
imagine
it's
probably
the
thing
that's
changed.
A
Okay,
it
seems
it
seems
like
at
this
point.
The
16
release
would
probably
be
pushed
to
next
week.
So
if,
in
that
time,
I'll
try
and
add,
you
know
comments
to
our
discussion
that
we've
had
here,
maybe
see
if
I
can
find
a
commit
that
introduced.
A
B
A
A
Yeah
so
yeah,
then
I'd
be
yeah,
I'd,
agree
and
also
the
fact
that,
like
it's,
not
anything,
we've
changed.
So
we
know
we're
not
introducing
further
regressions.
A
Okay,
that's
interesting,
so
we
just
need
to
prepare
it
again.
Somehow.
B
A
Cool
yeah
makes
sense
cool
good
to
have
a
link
to
that
in
the
minutes
that
helps
us
figure
out
what
to
do
so.
Going
back
to
the
january,
I
regime
danielle
once
fixed
the
windows
situation,
we'll
manage
to
get
the
release
out
and
then
we
don't
have
another
schedule
until
april,
so
we
can
probably.
A
B
I
don't
know
what
everyone
else
thinks,
but
it's
it's
a
lot
of
churn
for
the
docs
and
I
think
I'd
rather
take
take
the
risk
that
something
that
lands
in
the
future
might
have
a
conflict
that
needs
to
be
fixed
up
versus
everything
versus
trying
to
change
everything.
Yeah.
A
B
A
I'm
not
sure
why
I
did
that.
I
was
editing
the
wrong
section.
That's
fine,
I'm
going
to
sensitively,
put
like
one
for
april
in
just
you
know,
might
be
a
good
time
to
get
a
release
out
based
on
how
long
it's
been
that'd
be
like.
A
If
anyone
thinks
they
will
have
time
in
april,
to
get
a
release
out
for
14..
Of
course,
if
there's
something
happens
in
the
meantime,
that
means
we
need
to
expediate
that,
and
that
makes
sense,
but.
A
My
preference
would
probably
be
late
march
mainly
because
we
don't
want
to
ship
a
release.
You
know
two
weeks
before
the
end
of
end
of
life
and
risk
us
breaking.
You
know
if,
if
we
end
up
breaking
something
in
the
last
two
weeks
and
having
to
do
two
releases
in
the
last
two
weeks,
that's
just
more
of
it
on
us.
I
think
before
end
of
life
is
a
good
balance
there
to
tidy
up
what
needs
to
be
landed
and
we
could
try
and
release
the
same
day
as
14..
A
Think
about
it,
I'm
completely
out
that
last
week
of
march.
So
if,
if
I
had
time
to
do
it,
it
would
only
be
the
following
week.
I
can
certainly
volunteer
to
do
one
of
those
if
needed.
So
I
might
lean
towards
the
fifth
first
tuesday
of
the
month
as
well
patch
tuesday,
so.
B
A
B
A
A
A
Cool,
that's
it.
We've
got
something
in
the
pipeline
that
we
can
work
to
for
14
and
12.
What
did
we
say
for
16?
A
We
also
had
one
a
patch
earmarked.
Does
it
make
sense
to
try
and
do
the
same
day
for
that
one
as
well?
If
anyone.
A
If
anyone
can
do
it,
but
wants
to
move
today,
feel
free
you're
doing
the
work
you
can
move
that
to
see
yeah.
I
should
be
able
to
help
out
with
at
least
one
of
these,
but
I'll
leave
them
for
people
to
sign
up
once
they
know
their
availability
for
that
month.
A
Next
few
weeks,
the
last
17
release
just
hopping
back
to
that
quickly
is
on
the
same
day,
so
we
lost
note
17
release.
I
suppose
we'd
need
to
create
a
schedule
for
the
18
releases
and
for
that
I'd
probably
just
copy
this
again.
You
know
two
weeks
two
week
gap
and
just
go
by
that.
I
think
that's
worked
pretty
well
in
past
releases
for
current.
A
And
on
the
topic
of
node
18,
I'm
going
to
try
and
add
some
more
information
to
the
docs
this
this
time
around
to
try
and
make
it
more
reproducible
just
from
following
the
docks,
because
I
think,
there's
still
a
lot
of
bits
missing,
but
hopefully
so
someone
else
can
go
for
it
next
time
or
wants
to
go
for
it.
This
time.
Just
let
me
know.
A
Yeah
yeah
so
like
generating
the
change
log
where
you
have
to
use
branch
diff
instead
of
change
log
maker,
I
think
it'd
be
nice
if
I
actually
pulled
the
commands
in
into
that
door,
so
someone
else
could
take
over
and
do
it
if
needed.
B
A
B
You
opened
one
at
the
end
of
like
one
of
the
released.
A
Yeah
yeah,
but
I'll
try
and
I'll
go
back
and
do
it
because
I
probably
want
to
make
it
the
same
color
because
I
think
they're
consistent
colors
across
you
know
but
yeah.
So
we
keep
track
of
this
because
this
is
problematic
might
have
time
to
dig
into
it
next
week
day,
one
looking
at
making
things
a
bit
healthier,
so
you
might
be
able
to.
B
B
So
the
reason
the
labels
are
not
being
excluded
is
because
it's
not
fetching
the
labels
at
all
and
I
think
we
need
to
export
the
label,
fetching
command
out
of
change
log
maker
or
do
a
rather
more
drastic
restructuring
of
how
change
lawmaker
and
branch
diff
work,
but
I'd
rather
defer
that,
to
some
other
time.
A
Yeah
sure
michael's
just
said
we
could
like
change
what
latest
points
to
so
it
doesn't
point
to
v2
the
internet.
B
I
need
to
check
whether
I
do
or
not.
I
may
not.
I
think,
oh
no
way
this,
I
think,
self-publishes.
I
I
think
this
has
an
action
that
publishes
itself
that
semantic
release
plot.
B
A
A
B
A
Sure
I
can
record
that
in
notes
and
maybe
try
and
open
an
issue
just
say
hey.
I
suppose
it
kind
of
goes
hand
in
hand
with
the
changing
the
permissions
as
well,
because
if
we
change
the
permissions
who
can
read
to
write
to
it,
then
it's
probably
a
good
time
to
address
who
can
publish
as
well.
A
B
A
Yes,
it
makes
sense
to
talk
about
so
the
node.
Oh,
I
just
ignore
why
post
for
the
currents,
the
odd
numbered
currents
according
to
our
schedules,
we
always
end
of
life
them
at
the
start
of
june.
I'm
now
starting
to
question
like
why.
Why
have
two
currents
that
we
need
to
take
care
of
security
releases,
for
when
you
know
I
I
think
it's
completely
fair.
A
If
the
odd
number
current,
for
example,
node
19,
went
end
of
life
at
the
end
of
april,
because
by
that
point
the
new
current
would
already
be
out
the
even
numbered
one
for
them
to
pick
up
and
obviously
our
our
whole
process
around
current
is
like
it's
the
one
you
want
to
be
on
for
latest
changes,
and
you
know
you
get
cutting-edge
features
so
17
at
the
moment
after
april,
we're
probably
not
going
to
do
any
more
releases,
so
it's
not
actually
going
to
have
that,
so
I'm
not
sure
who
it
would
make
sense
to
you
to
be
on
that
release.
A
So
the
suggestion
is
just
in
terms
of
timing
for
odd
numbered
releases,
instead
of
continuing
to
support
it
until
the
start
of
june.
We
we
just
say
end
of
april,
because
by
that
point
the
new
current
should
be
out
by
then.
A
A
Not
not
as
long
because
how
many
release
lines
will
we
have,
at
the
end
of
this
month
to
take
care
of.
B
What
just
before
the
end
of
the
month
so
12
goes
out?
Is
it
30th?
Isn't
it
yeah?
So
you
know
if
you're
looking
at
say
the
29th.
B
A
A
I
I'm
hesitant
to
reduce
it
to
17.
I
don't
think
we
can
break
the
contract
that
we
have
formally
informally
specified
here
to
reduce
the
end
of
life
date
for
17.
agreed
yep.
A
Okay,
I'll
just
open
an
issue
to
reduce
it
for
19
and
see
if
there's
any
policy
wording,
I
know
further
down
in
the
stock.
We
have
some
talk
of
timings.
B
A
Maybe
also
something
we
should
explore
and
investigate.
Okay
with
that,
do
you
want
to
reserve
five
minutes
just
if
there's
anything
to
talk
about
offline?
So
thanks
for
joining
everyone
today
to
the
live
section
got
for
the
agenda.
We've
scheduled
our
dates
for
the
next
next
month
and
I'll
also
go
through
and
try
and
add
all
those
links
to
the
docs
and
relevant
issues
thanks
everyone
and
I'm
going
to
stop.