►
From YouTube: 2022-08-25 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
All
right,
I
do
see
the
icon
now,
I
guess
we're
live
on
youtube,
so
welcome
everyone.
This
is
the
node.js
release
working
group,
today's
august
25-
and
we
do
have
an
agenda
here
to
follow
up.
But
before
that,
do
anyone
have
any
announcement.
Anything
they'd
like
to
discuss.
B
A
Nice
yeah
cool
yeah
and
yesterday
we
also
had
a
the
1808
release
that
went
out
so
there's
that
so,
let's
start
with
the
agenda
here.
We
do
have
this
first
item
for
imminent
issue
for
children,
users.
B
C
Yeah
for
historic
calculations,
I
think
it's
still
useful.
I
think
someone
raised
that
before,
like
when
you're
doing
historic
date,
different.
B
So
it
looks
like
there
are
actually
two
open
pr's,
which
I
guess
are
trying
to
do
the
same
thing,
but
neither
of
them
have
landed
yet.
B
I
think
the
first
one
is
landable.
I
can't
see
the
actual
ci
results,
but
it
did
say
there
were
46
successful
checks,
which
normally
means
it
all
passed.
C
B
Sorry,
yeah
yeah,
those
two
pr's,
the
first
one
I
think
is.
I
think,
though,
we
probably
need
prs
for
the
other
release
lines
as
well,
because
they
all
have
different
versions
of
icu.
B
B
B
C
B
Release
where
it's
only
really
the
time
zone
update,
I
mean
we've
just
done
an
18
release
time.
Presumably,
hopefully,
there
won't
be
much
much
to
go
into
an
18
release
anyway,
given
all
the
way
all
the
good
work
you
did
to
to
get.
Eighty
eight
out
so.
A
C
C
B
A
B
B
So
I
don't
know:
if
that's
going
to
complicate
things,
I
hope
not
because
it
won't
be
good
if
everything
stops
because
I'm
not
available
yeah.
I
guess
the
first
thing
to
be
to
try
and
get
one
of
those
two
pr's,
ideally
the
earlier
one,
because
that
looked
to
have
got
the
ci's
passing
get
that
landed
and
then
try
and
get
somehow
get
equivalent
pies
opened
for
14
and
16,
and
then
you
know
get
releases
lined
up
for
next
week.
D
One
thing
that
probably
will
release
that
we
are
just
waiting
for
for
a
particular
fix
to
vladimir
land,
to
let
me
create
the
secret
release
before
the
mine.
I
I
I
know
that
the
mine
was
scheduled
to
like
sticks
of
next
month.
I
guess,
but
before
that,
I
think
that
we
are
going
to
have
a
security
release.
D
C
I
think
the
workflow
is,
if,
if
there
was,
is
one
being
planned,
it's
on
the
steward
of
the
release
to
try
and
solve
an
appropriate
date
and
releases
to
that
can
do
that,
but
you're
right.
If,
if
we're
sourcing,
you
know
it
sounds
like
we
might
have
two
releases
to
do,
one
that
needs
to
be
done
to
cover
that
fix
and
one
for
the
time
zone
thing
and,
if
they're,
all
aligned
for
the
same
date.
That
might
be
a
bit
of
a
problem.
B
A
Yeah,
honestly,
if
we
don't
have
bandwidth
like
and
there
is
like
a
one
one
issue-
release
coming
up
on
the
six
for
you
raphael
like.
Maybe,
then
I
can
try
to
get
one
of
the
lts's
for
at
least
a
time
zone,
and
then
we
can
maybe
find
someone
else,
but,
like
maybe
maybe
dude
we'll
have
to
wait
an
extra
week.
D
Yep
yeah,
that's
fine
yeah!
I
I
have
the
release
schedule
for
the
day
six
and
day,
twenty
so
yeah.
I
think
that
I'm
good,
I
will
do
both
releases
so
yeah.
C
I
guess
one
thing
I
think
richard
I
I
asked
about
it
and
you
dug
in
and
found
the
answer.
There
is
a
way
of
overriding
the
time
zone
directory
which
might
be
a
reasonable.
C
B
There
is
I
I
don't
know
how
easy
it
would
be
to
deploy
to
any
sort
of
production
in
a
production
environment,
but
there
is
a
there
is
a
potential
workaround
involving
putting
things
on
onto
a
local
directory,
you
download
things
into
local
directory
and
then
setting
an
environment
variable.
I
do
believe
that
there
are
some
places
where
it's
actually
difficult
to
set
environment
variables,
but
it's
kind
of.
A
Right
yeah,
another
thing
we
can
do
if
you
think
it's
appropriate,
we
can
maybe
just
leave
a
note
in
the
releaser
channel
like
poke
the
active
releasers
and
see
if
someone
else
that
is
not
here
in
the
meeting
today
has
bandwidth
and
like
wants
to
volunteer,
but
otherwise
I
think
we
just
follow
the
regular.
A
And
well,
I
might
try
to
accommodate
an
extra
one
for
lts
but
yeah.
What
do
you
think.
C
C
B
We
generally,
wouldn't
it's
not
so
we
couldn't,
but
it
wouldn't.
C
Yeah
for
current
we're,
sometimes
a
bit
more
relaxed,
but
not
generally
failed
to
yes,
but
then,
if
this
release
is
gonna,
the
argument
is
is
like.
When
a
security
release
comes
out,
you
want
as
small
as
list
as
commits
as
possible.
So
there's
no
friction
people
updating,
but
if
this
other
release
is
gonna
happen
before
then
anyway,
then
that
argument
holds
less
weight,
because
they're
gonna
have
to
pick
up
that
change
as
well
anyway.
D
Okay,
yeah
so
okay
yeah,
so
just
to
mention
we
have
the
issue
737.
That
is
like
the
schedule
of
the
the
the
regular
release
when
actually
when
we
have
the
date,
we
need
to
include
it
to
this
table
right.
D
B
A
C
C
The
problems
that
that
you
know
introduced
is
that
when
you've
got
a
bunch
of
center
miners
that
you
have
to
wait
until
the
end
of
the
quarter
to
get
shipped
in
a
release
that
creates
to
get
history
out
of
sync
and
can
cause
more
problems
and
make
the
patch
releases
harder
at
the
time
when
this
was
decided,
there
were
a
lot
of
companies
out
there
saying
conceptually
they
avoid
miners
but
and
treat
patches
as
easier
releases
to
upgrade
to.
C
But
generally
you
know
in
my
experience
of
releases
are
released,
it's
painful
to
upgrade.
It
doesn't
matter.
If
it's
a
you
know
a
patch
or
a
miner.
If
you
end
up
being
bitten
by
a
bug,
you
end
up
being
bitten
by
a
bug:
it's
not
normally
determined
by
whether
it's
a
patch
or
a
miner,
from
what
I've
had.
So
I
think
michael
sasso's
proposal
to
try
and
stop
the
divergence
in
history
across
you
know
so
much
or
to
reduce
it
is
to
just
say,
like
we
did
with
current
every
month.
C
We
do
a
semva
minor
release,
or
we
just
cherry
pick
from
what's
on
the
node
18
branch
onto
16..
If
it
happens
to
pick
up
some
minors,
it
will
be
a
minor
release.
If
it
doesn't,
then
it
would
be
a
patch,
but
generally
it
will
likely
be
a
minor
because
we
do
minus
so
often
for
18..
C
There
were
some
concerns
around
like
historically,
we've
had
additional
baking
time
for
features.
So
one
of
the
proposals
I
put
in
there
was
we've
got
the
two
week
baking
time
so
things
on
current
at
the
moment.
C
But
then
we
tried
to
aim
for
a
little
bit
longer
for
features,
and
I
wondered
if
we
just
set
a
longer
default
baking
time
of
like
four
weeks
that
would
mitigate
the
fact
that
we're
shipping
features
sooner
because
you
know
it's
a
trade-off
like
we're
getting
extra
baiting
time
there
they're
still
getting
time
to
bake,
and
I,
like,
I
just
think,
that's
simpler,
to
explain
to
just
say
once
something's
been
released
on
current
for
a
month.
C
It
can
then
go
into
lts
that,
rather
than
people
being
like
hey,
when
can
this
feature
land
and
we're
like
no,
not
until
two
months
time
when
the
next
mine
is
scheduled,
or
you
know
no,
not
until
this
time
it's
extra
baiting
time.
If
we
would
just
had
a
flat
rule
of
one
month,
then
it
can
land
on
lts.
C
That
might
be
a
good
mitigation.
I
think
that's
a
summary
of
as
much
of
the
thread
I
read,
I
don't
know
if
there's
any
thoughts
or
opinions.
A
C
It
shouldn't
need
manual
intervention.
What
I
would
do
is
look
for,
so
if
you
use
the
node
18
release,
you
can
kind
of
backtrack
and
say
node
1860
was
released
four
weeks
ago.
Therefore,
when
I
run
branch
diff,
I'm
gonna
run
it
against
the
tag
of
1860,
and
then
it
will
pick
up
everything.
That's
only
baked,
for
you
know,
that's
baked
for
long
enough.
C
C
But
I
I
kind
of
feel
that's
a
reasonable
step
to
making
life
a
little
bit
easier
and
keeping
history
in
sync
and
a
small
step
see
how
well
it's
received
for
a
while
seems
reasonable
and
then,
if
we
want
to
go
further
to
simplify
more,
we
can,
if
we
get,
you
know
negative
feedback,
saying
it's
too
fast
or
something
we
can
adapt.
But
I
feel
like
it's
it's
worth
trying
at
this
point.
It's
been
a
suggestion,
a
few
years
back
and
it's
again
now
so
plus
one
to
trying.
C
A
C
D
C
C
Yeah,
I've
done
it
for
quite
a
while.
It's
quite
a
lot
of
work,
probably
not
gonna,
have
time
to
do
it
this
round,
and
also
I
just
think
it
would
be
good
to
have
someone
else.
You
know
familiar
with
the
process,
so
we're
not
relying
on
one
single
person
having
the
history
of
it.
C
I
will
be
around
to
help
if
anyone
would
like
to
steward
it,
but
it's
just
I
think
rotation
makes
sense
just
from
how
much
work
it
is
and
like
some
folks
on
the
team,
don't
even
get
that
dedicated
time
from
their
employer
to
work
on
these
things
so
committing
to
it
for
eternity
like
I
have
been
in
the
past,
wow
just
doesn't
seem
reasonable.
I
just
think
a
rotation
would
make
sense,
but
the
pain
of
that
is,
you
know,
need
to
go
for
an
onboarding
process,
improve
the
onboarding
docks.
C
Have
someone
different
pick
it
up
this
time,
which
is
going
to
cause
a
little
bit
more
friction
this
time?
Just
because
you
know
learning
a
new
process
always
involves
that,
but
I
think
it
it
would
be
a
good
outcome
getting
to
the
point
where
we
have
more
than
one
person
who's
taking
can
take
charge
on
a
major
release.
D
Yeah
I
would
like
to
to
to
volunteer
to
these
this
one.
At
least
I
mean
not
by
myself,
because
I
really
would
need
some
help
in
that,
like
first
time
in
major
release
but
yeah,
I
would
like
to
be
included
in
that
rotation
to
help
help
you-
and
you
know,
because
I
know
that
is
like
a
lot
of
work
to
do
and
yeah.
D
Yes,
when
the
the
next
major
is
schedule.
C
It's
scheduled
it's
normally
around
the
20th
of
october.
I
need
to
check
the
date,
but
it's
it's
always
the
third
tuesday
in
october,
so.
C
D
C
So
for
me,
it
was
like
a
six
week
process,
six
weeks
before
the
release,
it
was
creating
the
branches
four
weeks
before
it
was
creating
a
proposal.
C
D
C
C
Yeah,
you
could
even
like
be
involved
in
a
branch
creation,
maybe
cut
one
or
two
to
release
candidates
in
advance,
and
that
would
that
would
be
enough
to
understand
the
mechanics
of
updating
the
proposal.
Updating
the
change
log
and
that's
kind
of
half
the
work
anyway
and
then
maybe
we
can
just
figure
out
who
does
the
clicks
the
button
on
the
day
and
ships
to
release
later.
D
C
Together,
like
anyone
from
now
in
the
next
week
or
so
to
get
the
branch
created
and
maybe
get
you
know,
a
very
valuable
early
draft
proposal
and
then
from
there
just
iterate
to
see
who's
going
to
have
time
closer
to
the
release,
which
actually
might
be
a
good
thing
anyway,
to
try
and
make
it
more
than
a
single
person
process.
In
the
first
place.
B
A
C
Yeah
yeah,
that's
that's
normally
fine,
if,
like
sometimes
I
skipped
a
release
candidate
one
week,
because
I
was
just
not
available
and
you
know
it's,
it
is
the
best
effort
like
everything
else.
We
do
but
sounds
like
a
good
approach
to
you
know
raphael
or
you
may
be
able
to
pick
up
a
release
candidate,
each
or
two,
and
then
you
know
some
of
the
process
and
we
can
figure
out
the
actual
release
date.
Mechanics
after.
A
What
should
I
should
I
take
notes
here
should
I
take
notes,
then
maybe
raphael
and
I
were
interested
in
and
yeah.
C
Yep,
I'm
happy
to
jump
in
with
some
notes
as
well
after
the
call
and
just
say
like
in
the
dark.
C
What
we
probably
need
is
a
a
screen
share
or
something
between
anyone,
who's
interested
probably
next
week
and
then
go
from
there.
A
Cool
so
yeah
with
that.
I
think
the
remaining
items
here
are
the
release
plans
yeah,
which
for
18,
I
think
we're
good
right,
given
that
rafael
is
already
scheduled
for
the
six
and
20
september.
So
current
is
scheduled
until
basically
end
of
september,
there's
a
spot
already
october.
If
any
one
wants
to
volunteer.
C
A
C
C
A
A
I'm
considering
it,
but
I
have
to
I
have
to.
A
C
In
theory,
we
could
put
a
placeholder
in
for
a
patch
release
to
pick
up
the
time
zone,
change.
C
C
C
B
I
don't
think
I
don't
think
it
needs
to
given
the
title,
the
nature
of
the
timezone
update
because
effectively
you're
rebuilding
the
icu
data,
so
there's
no
benefit
for
it
to
to
wait
for
the
thing
to
get
current,
because
it
will
be
a
different
file
anyway,
and
we
it
it
will
be
scoped
down
to
the
time
zone
updates
itself
rather
than
pulling
anything
else.
B
Hopefully
measuring
there
was
a,
I
think,
there's
a
pr
another
pr
open
to
do
to
try
and
automate
the
process,
but
I
I'm
not
sure
what
state
that's
in.
I
haven't
had
time
to
look
at
it.
A
A
I
think
we
did,
you
know
just
take
their
agenda
label
out
of
this
one.
Then
yeah.
A
B
Yeah,
so
the
only
reason
to
keep
that
open
would
be
whatever
the
next
one
was.
Wasn't
it,
but
that's
like
years
ago.
A
C
C
Yeah
so
now,
michael,
I
think
michael
zaster
is
planning
to
be
there,
maybe
danielle.
I
know
she's
at
no
clumps,
I'm
probably
going
to
be
alive.
So.
D
Yeah
I'll,
be
there
too,
but
I
I
have.
I
have
scheduled
two
sessions
for
diagnostic
working
group
and
also
to
the
security,
so
I'm
not
sure
if
they
will
be
able
to
join
to
the
releases.
One.
A
Yeah,
that's
a
good
point
yeah.
I
was
just
going
to
say
that
they
usually
try
to
avoid
the
overlaps
like
and
they
will
listen
to
you
like
the
organizers,
like
people
trying
to
arrange
the
rooms.
If
you
yell
loud
enough
that
you
would
like
to
beat
in
this
and
not
in
that
they
will
try
to
organize
it
so
that
everyone
can
be
happy
but
yeah.
A
C
A
Cool
yeah,
but
that's
a
good
reminder.
Beth.
Thank
you
for
the
reminder
there.
I
think
I
I
think
it's
it's
nice
to
at
least
have
a
session
to
just
raise
awareness,
like
maybe
some
introduction.
C
Yeah
we
we
have
on
boarded
new
releases
from
those
sessions
before
so
maybe
it's
worth
having
it
just
just
a
short
session
from
that
side.
Even
if
we
don't
have
a
particularly
strong
agenda
that
we
need
to
discuss
there
in
person.
A
Yeah
yeah,
but
even
yeah
yeah,
that's
also
nice,
like
because
I
remember
when
I
was
just
starting
right.
I
kind
of
what
I
wasn't
bored
of
during
one
of
the
collapse
moments,
kind
of
thing
and
it's
nice
when
you're
there
for
the
first
time-
and
there
is
actually
you
know
there
is
an
actual
meeting
and
they
go
through
the
agenda.
It's
also
nice,
just
from
like
picking
your
urls
derived
from
folks
that
are
just
starting
yeah.
So
yeah!
That's
that's!
Keep
that
in
mind
like
I
might.