►
From YouTube: Node.js Release Working Group Meeting 2021-01-13
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
are
now
live
on
youtube
with
the
january
13th
edition
of
the
node.js
release.
Working
group
got
a
couple
different
things
on
the
agenda
today,
but
I
think
richard
you
wanted
to
maybe
start
with
this
number
576,
which
was
an
intimate
time
zone
update,
although
imminent
was
may
4th
2020,
so
yeah.
B
So
I
didn't
quite
I
didn't
get
a
new
issue
created
someone's
commented
in
the
existing
issue
and
that
existing
issue
was,
as
you've
pointed
out
old.
So
previously
we
had
an
issue
covering
which
year
it
was
now,
but,
as
you
said,
it's
an
old
one
where
there
was
a
time
zone
update
and
the
question
was
updating
the
times
and
information
in
like
the
lts
releases.
B
B
and
the
reason
for
that
is
the
timezone
updates
have
to
be.
It
basically
involves
rebuilding
the
icu
data
files
and
the
icu
data
file
in
12
is
a
small
icu
data
set.
So
we
can't
just
back
port
the
node
14
icu
update
to
12.
It
needs
to
be
a
explicit
back
port,
but
I
think
actually,
we've
probably
got
different
versions
of
icu
in
all
versions
of
equipment.
B
All
the
release
lines,
just
just
as
we
you
know
they
go
out
in
different
icu
versions,
and
we
tend
not
to
update
too
much
because
we
have
run
into
people
have
had
issues
where
things
have
changed
in
sort
of
output
formats
and
some
of
the
output
isn't
guaranteed
in
that
it's
intended
to
be
human
human
output.
But
then
some
some
applications
are
parsing
it
anyway.
So
we
had
a
different
discussion
about
whether
we
should
be
updating
icu,
but
the
time
zone
information
is
separate,
although
it
is
rolled
into
the
same
data
file.
B
So
we've
got
previous
where
we
have
updated
the
time
zone,
information
independently
of
the
icu
update,
but
it
does
mean
rebuilding
the
icu
data
file.
So
there
was
a
comment
posted
a
few
days
ago,
saying:
hey,
there's
a
daylight
savings
change.
The
one
specifically
cited
was
for
jordan
coming
up
on
the
22nd
of
february,
so
the
question
was
whether
we
could
get
the
time
zone
updated
in
the
lcs
releases.
B
I
did
a
little
bit
investigation
because
I
did
read
at
the
end
of
last
year
that
there
was
some
drama.
I
guess
is
the
word
in
the
time
zone
project
over
the
time
zone
database
was
dropping
some
historical
data
and
emerging
time
zones,
and
there
was
disagreement
as
to
whether
that
was
a
sensible
thing
to
be
doing,
but
it
turns
out
that
icu
have
opted
to
keep
the
historic
data.
B
So
if
we
do
what
the
maintaining
maintaining
guides
in
node
says,
so
there
was
a
guide
written
to
how
to
update
the
timezone
information
that
has
us
pulling
from
the
icu
data
github
repository,
and
that
is
the
latest
time
zone
plus
the
historic
data.
So
it
is
actually
maintaining
the
historic
data,
and
that
was
my
concern
initially
that
if
things
were
being
dropped,
when
we
updated
the
time
zone,
information
that
might
you
know
have
a
risk
to
any
applications.
So
I
think
it's
reasonably.
B
It
sounds
like
it
would
be
safe
to
do
the
update-
and
I
just
kind
of
wanted
to
flag
it
up
in
in
this
meetings,
and
if
anyone
had
any
any
thoughts.
We'd
obviously
need
to
get
get
sort
of
pr's
raised
against
all
the
release
lines
with
the
actual
change.
I'd
potentially
give
that
a
go,
but
you
know
if
we're
happy
with
that
principle.
B
We
have
not
a
firm
date
yet,
but
we
had
penciled
in
releases
this
month
as
a
sort
of
center
miner
on
the
lts
release
line.
So
that
is
potential
a
potential
sort
of
target
that
we
can
target
to
get
time
zone
updates
out
in
and
if
it
was
this
month,
that
would
be
ahead
of
the
sort
of
february
date
that
the
the
particular
change
being
discussed
was
referencing.
So.
C
To
complement
well,
I
mean
a
question
for
richard
here
so
that
he
can
complement
all
this
thinking.
Do
we
have
tests
for
that
like
and,
if
yes
like,
how
much
do
we
trust
them?.
B
I
don't
think
we
have
tests
for
it.
I
suspect
it
should
be
possible
to
write
a
test
to
sort
of
have
a
forward
date,
switch
to
the
affected
time
zone
and
see
what
it
gives
back,
because,
presumably
there
will
be
an
overlap
period
where
it's
like
an
hour
out
or
however,
however
long
the
actual
daylight
savings
adjustment
is-
and
I
think
that's
the
best,
we
could
probably
do
because
you
know
we're.
Obviously
I
don't
think
it's
beyond
in
the
scope
of
the
node
project
to
have
tests
for
every
single
time
zone.
B
Daylight
segment
switch,
but
definitely
for
the
ones
that
people
have
opened
issues
for.
We
could
potentially
have
regression
tests
and
that
will
give
us
some
peace
of
mind
that
at
least
for
the
thing
being
complained
about
that
the
update
has
fixed
it.
There
will
obviously
be
risks
about
whether
there's
anything
regressed
with
the
timezone
update
that
I
think
it's
less
risky
than
it
would
be.
If
we
take
the
time
zone
updates
directly
from
the
time
zone,
project.
D
I
have
a
question
about
version
16
and
14.
Would
it
be
easier
to
just
update
icu?
Like
a
cherry
pick,
the
icu
update
that
we
did
in
17.
B
Yes,
as
long
as
it's
as
long
as
v8
in
those
virgins
is
happier
with,
is
it
icu,
70
or
71
or
70?
I
think
the
current
version
of
icu
is
yes.
C
B
Do
we
do
have
the
shared
shared
library
builds
which
build
against
the
minimum
icu?
So
as
long
as
all
of
that
is
happy,
I
would
be
okay,
I
think
updating
icu
for
16,
maybe
14.
yeah.
The
the
question
is
whether
anything
would
would
break
with
the
older
icus,
but
we
have
previous,
where
we
then
just
patched
alternate
branches
into
v8.
If
beer
has
dropped
or
changed
something
to
cater
for
the
updated
icu.
B
B
A
Okay,
so
I
guess
that
that
covers
that
one
before
we
get
into
release
plan
work,
I
noticed
there
is
one
additional
like
kind
of
long-standing
issue
here
that
maybe
we
can
close
about
a
proposal
to
rename
the
sikkim
team
to
release
automation
or,
alternatively,
we
need
to
just
take
action
and
do
it.
Where
are
we
at
on?
That
is
anyone
kind
of
up
to
date
on
this
one.
A
And
said:
if
we
don't
want
to
move
forward,
we
should
close
it
and
if
someone
says
they
think
we
should
do
it,
we
can
do
that.
A
But,
like
I
guess
my
thinking
right
now
and
tell
me
if
I'm
wrong
is,
it
has
been
almost
two
years
without
doing
this
and
it
hasn't
caused
any
issues
leaving
things
the
way
they
are
in
the
status
quo
and
if
no
one's
kind
of-
and
also
I
guess-
I
guess
one
thing
here
too,
is
the
automation
team
which
existed
at
the
time
that
this
was
putting
together
doesn't
even
exist
anymore.
A
A
B
Go
out
yes,
so
on
that
was
last
this
monday
just
gone.
We
did
security
releases
on
all
lines,
so
that's
17,
16,
14
and
12.,
so
the
security
releases
went
out.
If
that
was
a
regular
release,
pencil
didn't,
then
no,
we
haven't
done
a
break.
Well
110.
It
was
the
security
releases.
They
have
been
done.
A
Okay,
so
I've
got
you
down
for
that
one
and
then
that
would
put
the
following
in
february
for
the
eighth,
but
I
guess
maybe
we
can
pick
that
up
in
the
next
meeting.
A
Okay,
cool
cool,
so
I
think
that
covers
that
covers
us
until
almost
the
end
of
february
and
we
still
have
the
lts
one.
So,
let's
I
think
that
that's
probably
reasonable.
A
For
february
we've
got
danielle
signed
up
for
a
6.14
this
month,
I'm
guessing.
Similarly,
we
can
maybe
wait
until
the
next
meeting,
because
the
next
16
hasn't
gone
out
yet,
and
we
don't
have
everyone
here,
the
14
richard
you
did
that
security
release
for
14.
B
A
3
we
wanted
to
do
a
14
19
this
month.
It
looks
like.
B
B
So
so
what
what
we
did
at
the
end
of
last
year
is
we
sort
of
just
sketched
in
because
I
think
we
we
were
sort
of
saying
have
have
a
minor
per
quarter,
although
12
and
14
are
in
maintenance,
but
I
think
the
idea
was
to
put
the
placeholders
in
and
it
has
been
a
while,
since
for
those
so
yeah,
I
could
potentially
do
the
14,
okay
yeah.
Why
don't
you
put
me
down?
Put
me
down
for
the
14.
A
And
then
are
we
doing
like
one
week
now
between
release
candidate
and
release
for
these
kinds
of
things,
so
that
would
be
like
fab,
one
tentative
release
and
we
can
figure
that
out
afterwards
yeah.
Let's,
let's
do
that:
okay,
cool
and
then
12.
A
B
Yeah,
let's
do
that
so
12
12
will
be
just
things
that
we
think
should
go
out
and
at
the
moment
I
believe
the
staging
branch
is
clear
for
12..
So
the
only
thing
that
I
know
of
is
this
potential
time
zone.
Update
plus
you
know
if
anything
else
comes
up
in
the
meantime,
but.
A
Yeah
bear
with
me
for
one
second
here
so
I'll,
just
put
a
tentative
20
2201
was
it
25,
I'm
making
that
up
and
2022
02
01
and
richard?
Are
you
volunteering
to
take
that
one
as
well
or
do
you
want
some
help
with
that?
Actually,
roy,
have
you
done
an
lts.
A
So
so
I
will
just.
I
will
just
throw
this
out
there
that,
like
you're
about
to
do
the
current,
which
will
get
you
like
ramped
up
again
and
this
release
should
actually
be
fairly
small,
and
one
of
them
is
the
npm
thing
that
you're
doing
anyways
and
richard
will
be
working
on
the
other
lts
I'll
offer
to
help
pitch
in
and
support
you.
If
you
need
it.
A
A
B
A
A
Release
bundled
in
there
too,
I'm
gonna
have
to
drop
in
about
two
minutes,
but
I
think
we
covered
everything.
Are
there
other
things
that
folks
want
to
talk
about
at
all.