►
From YouTube: Node.js Release Working Group Meeting 08/27/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).
B
Awesome
so
we
will
be
running
from
the
agenda,
which
is
in
the
node.js
release
issue
and
it's
issue.
Number
606..
We've
got
three
or
four
items
on
the
agenda
today,
but
I'll
start
with.
Are
there
any
announcements.
B
I
guess
I
have
one
49
went
out
just
now.
The
blog
post
should
be
available
soon
very
soon,
so
that
was
promoted.
B
Today
and
if
there
are
no
other
announcements,
we'll
move
on
to
the
first
item
on
the
agenda-
and
it
is
the
special
treatment
for
package
json
resolution
and
exports,
I
can't
remember
how
long
this
one's
been
on
the
agenda.
B
B
Awesome
yep
saves
us
discussing
again
the
next
one
is
one
that
I
raised
yesterday:
a
proposal
for
a
slack
channel
on
for
the
release
working
group
and
this
kind
of
stemmed
from
I
kind
of
find
myself
quite
often
like
pinging,
richard
or
other
people
directly
or
in
group
channels
that
we
happen
to
all
be
in
various
problems
with
the
release
or
build
machines
and
stuff
just
as
a
kind
of
double
check.
B
But
I
think
if
we
collated
all
of
that
into
one
shared
release
working
group
channel,
it
would
probably
be
a
useful
resource
for
the
rest
of
the
releases.
Especially
now,
we've
got
a
larger
pool
of
releases,
keeping
in
contact
with
everyone
separately.
It's
probably
a
bit
more
difficult
and
when
we
see
things
like
hey
the
14
next
staging
branch
is
currently
failing.
Ci
it'd
be
good
to
have
kind
of
a
dedicated
place
for
us
to
exchange
that.
B
So
I
was
thinking
of
either
the
node
a
channel
in
the
node
slack
or
the
openjs
slack,
I'm
not
sure
which
one
I
know
the
other
working
groups
like
package
maintenance
and
build
currently
have
channels
in
the
node
slack,
so
I'm
not
sure
which
one's
best
placed
but
definitely
talking
about
a
channel
and
one
of
the
existing
yeah.
Okay,
perfect.
D
B
That
was
the
trade-off
I
was
kind
of
thinking.
Would
it
be
nice
to
have
it
in
node
one,
or
would
it
be
nice
to
have
the
history
from
the
open
js
like?
I
think
history
is
probably
quite
a
draw.
B
Okay,
are
there
any
concerns,
or
I
I'm
feeling
it
can
be
a
public
channel
and
we
keep
all
of
our
private
communications
in
the
node.js
private
all
for
security
releases
for
now,
so
I
think
it'd
be
good
to
let
other
people
see
what's
going
on
with
releases,
particularly
the
other
members
of
the
tsc
and
anyone
that
has
an
interest
in
releases
in
general.
D
B
Yeah
sure,
okay,
so
if
there's
no
objections,
I
can
kind
of
take
an
action
to
find
an
open,
js
slack
admin
to
create
a
channel
and
I'll
link
it
in
the
minutes
or
something
I.
A
It
okay
so
and
just
call
it
release.
It
probably
needs
to
have
a
node
somewhere
in
there.
If
it's
on
the
openjs
one.
Oh
so
you
said:
open.js
not
node,
okay,
awesome.
B
D
B
I
will
share
my
screen.
The
next
couple
of
items
on
the
agenda
are
to
quickly
run
through
the
schedules,
see
if
we
need
to
make
any
amendments
or
expedia
anything.
B
So
for
node
14
we've
got
richard
down
to
do
the
next
one
due
to
be
released
next
week.
Is
that
under
the
week
after
isn't
it.
B
B
I
think
we're
scheduled
people
can
feel
free
to
sign
up
for
the
october
ones.
For
note
12,
we
probably
need
to
push
12
19
out
again.
A
B
Yeah,
I
think
we're
all
pretty
busy,
so
let
me
bring
up
the
calendar,
I
guess
tentatively.
A
B
Okay,
leave
it
there
and
feel
free
to
change
the
dates
to
what
you
see
fit
and
think
that
you
could
do.
If
that's
the
case
and
if
not
we'll,
just
look
back
and
try
and
figure.
E
B
B
B
So
that
was
kind
of
it
for
what's
on
the
agenda
I'll,
take
a
quick
look
at
the
recently
opened
issues
and
one
we've
not
discussed
in
a
meeting
yet
I
saw
michael
raised
an
issue
around
the
maintenance,
lts
naming
and
terminology.
A
I
I've
scanned
it.
I
did
not
spend
too
much
time
on
it.
I
know
that
this
is
something
that
we've
gotten
pedantic
about
on
and
off,
like
I
feel
like
that
happens
once
a
release
cycle
like
right
before
something's,
about
to
either
go
to
maintenance
or
go
to
or
go
to
lts.
I
can't
really
speak
directly
to
exactly
what
was
said
in
the
in
the
post,
but
I
do.
A
I
do
think
that
it's
worth
remembering
that,
like
the
stuff
is
super
subjective
and
the
language
that
we
use
is
very
ambiguous.
So
I
I
think
you
know,
I
think,
that's
all
that
I
can
maybe
appropriately
say
without
actually
reading
the
discussion.
That's
that's
happened,
but,
like
we've,
augmented
the
terms
many
times
over
the
years,
I
think
like
we
can
again,
but
I
yeah
like
it's
not
gonna,
always
work
for
everyone.
C
I
did
comment
somewhere
in
there,
so
there
was
something
about
the
end
of
maintenance.
I
think
we've
been
fairly
consistent
about
that,
but,
like
you
said,
we
have
modified
the
wording
around
things
that
are
actually
in
maintenance,
but
I
don't
think
we've
had
an
instance
where
something
has
become
end
of
life
and
then
had
an
update.
I
think
once
something's
going
to
end
up
like
we've
always
just
left
it.
B
B
A
I
think
they
were
mostly
dosses
but,
like
those
came
out
within
a
number
of
weeks
of
the
of
eight
going
end
of
life,
and
we
did
not
patch
them
and
if
I
recall
correctly,
we
rushed
through
and
update
to
npm,
because
there
was
that
vulnerability
like
the
bin.
Roy
can
maybe
remember
the
exact
vulnerability,
yeah.
A
There's
a
little
christmas
present
that
we
like
rushed
during
to
release
as
its
own
standalone
security
update,
so
that
that
could
get
innate,
and
I
think
the
discussion
that
we
had
had
there
was
that
if
we
had
not
gotten
that
out,
we
would
not
have
even
updated
npm.
A
C
Yep-
and
we
need
to
be
quite
clear
about
it,
because
one
of
the
things
that
we
do
do
is
when
releases
actually
go
end
of
life.
I
can't
remember
the
time
period,
but
they
we
don't
keep
the
build
machines
around
for
that
much
longer
so
so
we
don't
delete
them
immediately,
but
as
soon
as
a
release
does
drop
off,
we
do
flag
sort
of
the
the
older
os's
and
stuff
that
we
can
potentially
take
out
of
the
ci
and
replace
with
sort
of
new
os's.
C
So
we
do
have
to
be
reasonably
strict
in
that
you
know
it's
not
just
the
decision
as
to
whether
we
would
or
not
it's
whether
we'd
even
be
able
to,
and
in
my
mind
sticking
to
a
sort
of
yes,
that
this
is
a
line
in
the
sand
that
we
stop
here
and
yes,
we
can
keep
machines
around
for
a
week.
You
know
a
couple
of
weeks
just
in
case,
but
the
reality
is.
C
They
would
probably
be
quickly
repurposed
because
it
is
a
bit
of
a
strain
on
the
build
team
to
keep
older
operating
systems,
which
you
know
themselves
may
be
getting
to
the
end
of
their
their
maintenance
windows.
Running.
C
But
I
think
mikael
is
more
michael's
more
about
trying
to
get
to
what
messaging
we're
sending
out
to
the
ecosystem,
which
is
probably
something
that
we've
not
traditionally
been
to.
C
C
B
And
they
have
put
out
blogs,
I
believe,
even
on
the
node
foundation
medium.
I
think
it
was
about
what
what
versions
of
nodes
you
should
be
testing
with
and
which
ones
you
should
provide
support
for
in
your
module
when
you
write
it.
B
So
I
I
think
I
might
mention
this
in
package
maintenance.
I
can
see.
Wes
has
commented
on
it
here
too
and
see
if
they
have
any.
I
know
suggestions
about
this
messaging
in
terms
of
how
we
can,
I
don't
know
check
what
the
statements
package
maintenance
have
and
check
what
we
have
in
the
release.
B
Information
see
if
they
kind
of
say
the
same
message
and
don't
contradict
at
least
I
can
take
an
action
to
do
that.
I
believe
part
of
this
is
that
just
picking
out
this,
in
my
view,
maintenance
means
to
get
off
this.
That's
something
that,
bearing
in
mind,
I
think
we
now
have
an
18-month
maintenance
window.
B
B
B
Nope,
okay!
Well,
I
can
mention
it
to
the
package
maintenance,
folk
and
check
out
their
blogs
and
documentation
and
just
see
what
they're
messaging
us
and
compare,
but
other
than
that.
I
don't.
I
don't
think
we
plan
to
change
the
naming
of
release
lines
anytime
soon,
just
because
of
the
disruption
and
we've
stuck
to
this
messaging
for
quite
a
while
now
and
straying
away
from
it
might
cause
even
more
disruption
and
confusion.
B
B
B
No,
if
not
I'll,
give
you
half
an
hour
of
time
back
and
call
the
meeting
to
a
close.
Any
last
minute
comments,
discussion.