►
From YouTube: Node.js Release Working Group Meeting - 9th April 2020
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
Okay,
so
when
we've
been
through
all
of
our
schedules
recently
and
adjusted
the
timings
bearing
the
current
situation
in
mind,
I
think
the
agreement
was
that
we
would
not
date
than
a
14x
and
we
will
be
more
mindful
of
our
cadence.
Of
the
other
LTS
release
lines,
we
have
put
out
a
blog
on
no
jest
org
detailing
our
approach
to
this
so
changes
to
the
release
schedule.
A
So
all
of
our
information
is
that,
thanks
to
Shelley
for
writing,
this
woke
up,
and
that
covers
what
our
schedule
is
going
to
be
in
light
of
the
current
situation
so
other
than
just
an
update
on
what
we've
done
in
regards
to
this
issue.
I,
don't
know
if
there's
anything
else
left
on
it.
That
needs
to
be
addressed.
I.
A
D
At
least
for
the
release
next
week,
yes,
I
will
prepare
it
I'm
going
to
try
the
working
progress
PR
that
Shari
did
for
her.
The
the
last
steps
of
the
release
procedure
so
I
think
now
almost
everything
should
be
automated
in
North
Korea
tools
with
that
PR
is
really
nice
and
yeah.
If
there's
no
objection.
D
A
Said
I
think
Oh
schedule
Jason
in
the
release
repo
mentions
like
the
first
of
June
off
the
top
of
my
head,
but
we
don't
schedule
when
he
releases
after
April
is
just.
If
some
massive
bug
came
in
and
someone
asked
for
a
release,
we
would
consider
doing
it
just
out
of
minimizing
disruption
to
users
if.
C
D
A
A
A
A
C
A
A
A
A
I
I
did
go
through
them
said,
attend
twenty
release
that
went
out
yesterday
yesterday
yesterday
and
landed
any
patches,
I
saw
actually
possible
to
fix
and
everything
else
that
was
left
I
can
didn't,
seem
like
we'd
be
able
to
easily
patch,
and
it
was
some
things
were
just
always
going
to
stay.
That
way
and
some
things
remote
on
massive
back
paws,
so
I
think
I
landed.
What
I
could
there's
nothing.
I
was
standing
in
the
room.
A
E
A
A
E
A
So
I
start
with
the
proposal
to
rename
the
search
team
team
to
release
automation.
So
there's
been
quite
a
few
thumbs
up
in
the
issues
here.
I
may
go
ahead
and
rename
unless
anyone
shows
objections
here.
But
the
the
reasoning
behind
this
was
that
the
automation
team
isn't
as
active
as
it
used
to
be
when
it
was
first
set
up,
and
essentially
the
release
team
should
have
some
level
of
responsibility
over
the
release
tools.
A
A
A
A
C
When
we
talked
about
these,
like
at
least
when
I
was
suggesting
it
I,
was
imagining
these
kind
of
like
independent
bits,
so
the
LTS
bit
is
what
would
allow
you
to
do
anything
related
to
LTS
work.
So
if
you
were
not
a
release
or
having
the
LTS
bit,
would
give
you
access
to
lending
things
on
staging,
but
not
doing
releases.
That's
a
role
that,
for
example,
Anna
has
filled.
F
C
C
A
Guess
do
we
see
having
so
bit
so
I
think
we
want
to
encourage
people
to
participate
in
LTS
discussions,
and
we
want
to
make
that
discussion
more
open
for
everyone.
Users
rely
on
note,
may
have
opinions
on
which
features
go
back,
etc.
But
then
it
seems
like
we're.
Also
using
the
LTS
team
to
say
you
have
permission
to
release
an
LTS
release
and
I'm,
not
sure
how
you
can
kind
of
use
it
to
satisfy
both.
If
we
see
releasing
a
LTS
releases,
something
it
requires
elevated
permissions
of
sorts.
C
C
But
perhaps
we
do
need
an
extra
level
of
granularity,
but
I,
don't
think
that's
a
level
of
granularity
that
we
really
have
right
now,
because
we
kind
of
have
the
release
your
steam
and
the
back
borders
team
in
the
LTS
team,
and
there
are
members
of
the
LTS
like
pretty
much
everyone
who's
on
the
LTS
team.
At
this
point
now
has
backporting
access
and
the
only
difference
between
releasers
and
those
they
can
do.
The
LTS
releases
is
that
kind
of
membership
in
the
SD,
ok,
yeah.
F
A
A
D
B
A
A
One
thing
I
might
mention
as
an
aside
as
all
of
the
releases
that
have
gone
out
on
ten,
twelve
and
thirteen
and
now
no
to
roast,
which
means
you
shouldn't
see
the
warning
on
Catalina
or
anymore.
When
you
try
to
open
it,
I
think
it's
worth
keeping
an
eye
on
the
issue
tracker
for
any
reported
issues
as
a
side
effect
of
the
changes
we've
made,
I
think
Richard.
You
saw
that
there
might
be
one
already.
Yes.
B
B
It's
probably
the
hardening
of
the
binary
rather
than
the
motorisation,
the
yeah
I
dad's
as
much
as
I
I
know,.
A
Think
so
I
said
I
think
that
was
all
we
needed
to
do.
Maybe
we
could
link
to
the
minute
so
I'm,
just
opening
the
minutes
to
see
whether
there
was
a
discussion
that
we
can
point
cheat
before
closing
it.
Yeah
I
can
link
to
this
same
discussed
in
this
release.
Meeting,
maybe
even
go
as
far
as
linking
to
the
YouTube
video.
If
we
can
find
out
the
correct
URL
for
it
and
link
to
it,
okay,
trying
to
place
that
on
faster
meeting.
A
The
release,
mentoring
and
streaming
is
still
happening
where
it
can
is
still
in
their
Jessel
calendar
on
tuesdays
every
other
tuesday.
I
guess
something
else
worth
mentioning.
Is
nine
fourteen
and
it's
due
to
go
out
on
the
21st
of
april
and
the
foundation
has
been
in
touch
asking
for
some
marketing
and
some
like
blog
content
and
go
out
with
the
sink
builders,
still
updating
for
a
few
of
the
tool
chains.
So.
B
E
A
Yeah
one
one
thing,
I
kind
of
toyed
with
is
suggesting
that
when
people
add
the
notable
change
label
to
OPR
in
note,
if
they
followed,
a
generic
structure
is
a
little
comment.
That
said
notable
change
with
some
identifiers
or
Tigers
anything,
and
we
would
be
able
to
automate
that
and
pick
it
up.
So
when
people
add
the
label,
they
could
be
like
hey
I,
think
this
is
an
important
change.
I'm
gonna
write
some
text
because
I
contributed
to
change
I'm
the
one
who
knows
how
best
to
convey
it
to
our
users.
A
D
D
D
A
E
A
A
E
One
more
thing,
I
would
like
to
change
about
our
change
box
in
general,
because
often
it's
difficult
to
distinguish
important
changes,
even
if
it's
just
a
minor
fix
from
only
internal
things.
So
what
I
would
love
is
to
have
a
clear
distinction
between
all
testings,
for
example.
Test
is
never
important
for
the
reader.
We
should
maybe
even
just
have
a
generic
comment
about,
and
we
had
a
lot
of
Testaments
or
something
like
that,
and
that
pretty
much
also
applies
to
documentation
changes
mostly
not
always
and
to
some
other
commits
as
well.
E
A
D
G
A
E
D
Something
that
I
also
did
recently
is,
if
there's
a
one
PR
that
has,
that
is
simple
minor,
for
example,
but
it
has
five
commits,
and
only
one
of
them
is
the
central
minor
part
I
remove
the
silver
minor
words
from
the
change
drug
I.
Don't
know
if
any
of
you
did,
that
I
think
that's
that's
it's
better
to
not
mark
central,
nine
or,
for
example,
to
commit
that
adds
a
test.
I
did.
B
B
E
About
changing
our
tooling,
in
this
case
s
fall,
it
might
not
be
completely
straightforward,
but
and
when
we
land
at
a
PR
and
something
is
cember
major
and
we
see
that
not
all
commits
are
actually
is
ever
major
or
minor,
then,
and
we
could
and
just
apply
a
comment
that
says,
and
these
in
these
cotton
commits
are
ex
we
zember
major
or
SF
a
minor
that
way.
The
tooling
could
pick
that
comment
up.
E
B
B
This
goes
back
to
who
raised
something
somewhere
about
the
format
of
our
commit
message,
whether
whether
we
should
revisit
the
current
format,
which
is
the
sub
system,
you
know
all
those
rules
about
line
length
and
everything,
as
opposed
to
other
projects
that
mark
commits
with
like
feature
rule,
or
you
know
that
kind
of
would
make
it
easy
pause,
but
I
mean
that
would
be
a
big
change.
The
case,
the
commit
format.