►
From YouTube: Node.js Release Working Group Meeting -19 Dec 2019
Description
A
We've
had
a
few
people
say
that
they'd
be
interested
in
this,
so
I
guess.
My
first
question
would
be
with
any
of
the
other
releases.
Have
the
time
or
the
opportunity
to
do
this.
Would
they
be
able
to
read
Berkeley's
schedule
an
hour
at
whatever
interval
you
can
and
so
host
a
call
where
you
could
kind
of
mentor
someone
else
or
people
could
just
drop
in
and
get
a
filter
due
process.
A
B
I
definitely
want
to
help
with
this
I
guess.
One
thing
that
might
be
helpful
is
if
we
pick
sometimes
is
like
a
working
group
that
way
if
one
person's
schedule
changes
that,
like
we're
not
like
constantly
like
trying
to
find
times
that
work
okay
he's
like,
but
we
had
that
like
ongoing
time,
Tuesday
mornings,
every
other
Tuesday
for
example.
So
if
we
just
like
picked
that
time
and
then
like,
we
just
have
a
time
where
either
releasers
or
mentees
can
just
show
up,
I
can.
C
B
A
A
B
B
A
A
A
The
next
item
on
the
agenda
is
the
collapsed
summit
issue.
I
kind
of
added
this
one.
Just
to
summarize
what
we
talked
about
in
the
hour-long
session,
and
so
we
covered
what
release
team
do
and
the
responsibilities
we
started
talking
about
the
onboarding
technique,
so
how
people
can
get
involved.
So
that's
where
the
idea
of
shadowing
and
mentoring
and
formal
kind
of
video
shattering
calls
was
raised.
A
That
said,
they
would
like
to
listen
to
our
process
and
get
some
more
information
about
how
our
process
works,
so
that
they
could
then
help
with
the
automation
side
of
things,
because
that's
where
they
were
more
interested
in
the
intra
automation
of
the
releases.
So
that's
what
happened.
We
had
about
20
people
there.
It
was
good
session
and
I
think
there
was
only
three
of
us
and
from
the
release
working
group
there.
So
a
lot
the
rest
of
the
people
in
the
room
had
some
interest
in
getting
involved
or
contributing
in
some
way
or
another.
B
B
I
mean
I,
don't
think
that
there's
two
currents
at
that
point,
but
I
see
what
you're
saying
yeah
like.
If
we
assume
the
current
can
only
ever
be
one
release
line,
then
like
yeah
I,
think
in
either
case
like
this
is.
This
is
like
fairly.
It's
just
kind
of
semantics
to
me,
like
I
know
that
it
confuses
tooling
and
stuff,
but
it
kind
of
feels
like
we
lose
them.
A
B
A
A
B
E
B
E
A
Okay,
we
can
add
a
comment
to
the
effect
that
we
will
try
and
schedule
the
the
major
release
to
be
a
week
before
the
previous
release
goes
out.
Yes,
I
felt
like,
but
we
add
a
caveat
to
that.
Saying
right,
it
could
be
based
on
a
release,
reveal
ability
and
it
may
change
so.
We
may
hit
this
problem
again.
B
The
other
possibility,
if
the
only
thing
we're
doing
on
LTS,
is
flipping
a
bit
like
we
could
schedule
them
on
the
same
day,
but
I
think
it's
good
for
us
to
not
make
any
specific
commitments.
I
think
we
could
like
one
thing
we
could
try
to
commit
to
is
doing
the
current
release
prior
to
the
LTS
release.
Yeah.
B
A
A
E
B
A
Yep
I
feel
like
that's
that's
a
fair
and
and
then
we
can
also
reference
saying
we're
doing
our
best
effort
and
the
currently
scheduled
14x
and
going
out
yes
and
15
X
release.
We've
scheduled
it
to
hopefully
not
cause
this
problem
in
October
next
year,
but
that's
obviously
subject
to
releases
availability
and
priorities
and
etc.
At
a
time.
A
Okay,
Mika's
trust
fund,
Jerry
Rubin
that
we
kind
of
say
we're
not
making
explicit
statement
which
will
come
first,
but
we
will
try
to
schedule
well.
The
draft
release
dates
for
14
and
15
a
schedule
to
avoid
this
issue
that
they
are
subject
to
change
like
all
of
our
release,
dates
or
subject
to
change.
Yeah.
A
A
A
A
Defining
about
all
current
releases
so
and
the
release
collapsed
summit
session,
people
all
agreed
that
the
words
supported
made
sense
to
them,
in
terms
of
which
should
release
line,
starts
still
having
releases.
So
it
moment
it
would
include
eight
eight,
ten,
twelve
and
thirteen
so
they'd
like
the
time
support
it.
A
I
still
think
we
should
have
a
a
kind
of
like
glossary
on
the
home
page,
probably
just
under
this
table
here
or
under
under
this
graph,
and
stating
what
current
active
and
maintenance
are
because
I
know
a
few
people
are
confused
on
the
the
wording
and
what
what
each
release
includes
I
think
in
a
release
and
read
me
Rubin
to
answer
your
question.
I
think
that's
where
it
should
be
I'm,
not
sure
where,
if
it
should
be
in
the
note
core
repo
as
well.
A
A
C
A
B
A
A
A
C
B
Guess
a
question
for
everyone
on
this
so
like
we
did
the
security
release
on
Tuesday
and
then
we
identified
a
regression
and
I
just
went
ahead
and
pushed
the
follow-up
release.
Does
anyone
have
concerns
with
that
like
in
the
past?
That's
how
I
had
done
it,
but
there
weren't
as
many
releasers,
and
we
do
have
a
schedule
here,
like
four
thirteen
and
current
since
we
don't
really
have.
You
know
like
as
much
of
a
need
for
a
schedule
like
do
people
feel
uncomfortable
with
you
know.
Out-Of-Band
releases
like
that.
D
D
B
I
mean
I,
think
I
think
in
general
we
don't
want
to
be
doing
like
many
many
releases
in
a
week
but
like
in
the
past,
with
current,
we
did
it
as
often
as
once
a
week
as
long
as
there
were
releasers
who
were
available
and
wanted
to
do
it
I
mean
getting
the
commits
out
and
getting
people
using
them
helps
surface
bugs
sooner.
It
helps
get
commits
ready
for
LTS
quicker.
So
you
know
I
I'm
positive
on
it.
E
B
E
A
B
We
can
we
actually
push.
This
is
something
it
was
important
to
talk
about.
Can
we
push
the
semver
minor
to
the
28th?
Would
you
be
upset
with
that,
because
we
have
a
handful
of
things
in
the
modules
team
that
we're
trying
to
get
together
in
time
and
an
extra
week
in
January
for
December
minor
would
be
very,
very
helpful
for
us
I.
B
B
B
A
E
E
B
A
A
A
After
the
meeting
I'll
go
through
and
now
we've
got
the
dates
for
this
to
be
released,
update
it
all
and
rebase,
and
then
kick
up
some
neesee
ice
and
see
what
happens:
okay,
okay,
that
works
and
okay,
so
st.
we
could
fit
eight
twelve
releases,
so
we're
gonna
have
one
on
the
7th
of
January
and
then
a
minor
on
the
28th.
So
two
releases
in
general.
That's
good
and.
A
B
B
A
A
A
B
That's
actually
I
mean
for
twelve.
Also
we're
gonna
have
to
spend
some
time
going
through
it
that
we
probably
want
to
maybe
schedule
one
of
the
early
working
group
meetings
in
January
or
an
add
a
band
session
specifically
for
reviewing
December
miners
and
reaching
consensus
on
which
ones
we
want
to
put
on
the
different
branches.
Yeah.
A
B
A
A
A
B
This
is
like
a
separate
thing.
We
don't
need
to
dig
into
it
right
now,
but
it
might
be
a
good
thing
for
us
to
do
a
follow-up
on
about
how
flexible
we
want
to
be
with
CI
on
releases,
especially
when
it's
clear
that,
like
the
red
CI,
is
unrelated
to
the
release
itself,
I
think
it
might
be
good
for
us
to
draft
some
work.
B
Was
a
policy
around
that
because
I
ended
up
like
for
I
think
it
was
ten
and
twelve
well
I
think
it
was
ten
twelve
and
thirteen
no
13
got
a
green
one
and
eight
got
a
green
one,
but
both
ten
and
twelve
I
could
not
get
one
single
run.
That
didn't
have
one
of
the
flakes
going
and
it
was
absolutely
like
flaky
and
unrelated,
because
the
only
change
was
the
NPM
change
in
the
CI
change.
B
A
Agree
we
should
we
should
look
into
that,
because
I
definitely
had
to
like
rerun
and
I've
got
a
green
CI
on
my
previous
LTS
release
and
then
I
run
that
same
tag,
and
it's
now
got
a
red
CI,
but
I
know
it
was
green
because
I
saw
it
in
my
LPR
and
it'd
been
ticked
as
green
and
I.
Don't
remember
those
feelings
when
I
did
a
last
release
and
it's
like
something's
clearly
changed
and
infra.
Because
then
the
commits
are
the
same
and
yeah.
B
Yeah
so
so
maybe
we
can
make
an
issue
just
about
kind
of
tracking
and
documenting
that
jump
and
maybe
separately
from
that.
Maybe
it's
like
we
make
a
comment
and
then
get
a
thumbs-up
from
another
release
or
something
I.
Don't
know
how
we'd
want
to
make
policy
around
it,
but
you
know
just
something
to
think
about
for
a
future
meeting.
Yeah.