►
From YouTube: Node.js Release Working Group Meeting
Description
B
C
A
C
Adding
the
necessary
change
to
it,
so
it
applies
properly
to
the
current
release
line,
and
that
way
the
review
is
much
easier,
because
then
we
can
see
what
has
actually
changed.
So
it
works
on
the
on
the
release
line.
Instead
of
having
to
manually
check
the
differences
between
the
original
and
PR
deadlines
that
or
the
original
commit
that
landed
and
the
manual
back
port
and
while
landing,
we
can
then
just
squash
those
commits
yep.
C
In
that
case,
there's
just
one
thing
to
do:
I
would
say
and
that's
updating
the
guidelines
for
many
Oh
backwards.
That's
why
I
just
self-assign
it
I'm
in
good
with
writing
something
about
that
and
opening
a
pull
request
and
no
Jericho
yep.
A
C
In
the
last
time-
and
we
spoke
about
it
in
depth
and
that's
why
it's
also
filled
out
much
more
now,
especially
for
one
point,
and
we
thought
it
would
be
good,
especially
to
get
some
more
feedback
from
miles.
So
in
this
case
since
you're
here
and
right
now,
it
would
be
pretty
cool
if
you
could
have
a
look
at
it
again
and
just
add
some
more
comments.
If
you
think
it's
important
or
or
change
something
yeah.
C
C
B
B
C
Right
and
so
we
did
not
get
em
right,
particular
questions
about
it.
First
of
all
that
was
together
all
the
pros
and
cons
pretty
much
for
the
different
proposals
that
we
brought
up.
I
think
there
are
three
different
proposals
to
change
the
current
release.
Handling
the
reason
for
them
is
that
we
gather
a
lot
of
concerns
about
the
current
way.
C
We
are
handling
it
and
we
are
trying
to
improve
that
I
think
we
are
all
aligned
with
that
and
there's
just
some
concerns
from
at
least
one
person
for
all
of
these
proposals,
and
therefore
it
was
meant
to
first
of
all
check
what
concerns
exists.
What
pros
exist
for
all
of
these
and
then
try
to
get
the
actual
questions
about
it
afterwards,
together.
C
So
if
you
could
just
read
through
it
through
all
of
these
things
again
and
then
especially
if
you
I
think
there
was
at
least
one
point
where
you
had
some
concerns,
where
at
least
no
one
else
from
the
last
meeting
where
we
went
through
it
in
depth
was
sure
what
it
was
explicitly
about.
Anymore,
yeah.
B
Okay,
so
I
guess
one
one
request
that
I
could
make
is,
as
Beth
was
showing
there
I
think
that
there's
stuff
I'm
just
trying
to
bring
it
up
on
my
own
computer.
That's
included
on
this,
such
as
the
proposal
to
always
create
some
of
our
minor
releases
yeah,
is
that
one
even
stick.
I
was
under
the
impression
that
that
one
had
been
primarily
tabled
as
a
discussion.
C
Yeah
and
that
was
and
leave
for
a
while,
we
we
discussed
about
that
at
last
and
collaborate,
the
summit
in
more
depth,
and
we
saw
that
would
be
a
good
thing
to
do,
but
afterwards
there
were
a
few
concerns
brought
up,
especially
by
you
in
this
case.
So
we
saw
that
then
that
then
I
proposed
to
make
like
a
survey,
because
it's
not
completely
clear,
at
least
for
MU
what
our
users
actually
think
they'll
release.
C
B
B
C
Well
and
what
we
said
in
there,
it's
a
little
bit
sad
that
you've
not
been
at
a
meeting
where
we
spoke
about
it
in
depth
last
time,
because
at
least
I
think
it
was
the
Sam
Congress
and
me
at
least,
who
believed
it
and
I
hope.
C
You
say
correct
that
we
doubt
that
the
nodejs
release
process
is
really
comparable
to,
let's
say,
for
example,
the
Linux
kernel,
where
people
would
be
more
afraid
of
updating
into
a
new
version,
and
that's
why
it's
good
to
have
like
all
the
patch
releases
and
nodejs
I
personally,
am
more
afraid
about
a
patch
release
than
a
minor
release,
because
of
all
the
implications,
how
we
create
the
release
and
I
honestly
believe
that
most
users
do
not
know
about
these
implications
or
yeah
the
way
and
we
release
things.
So
that's
one
point
and
another
point.
B
B
C
So
when
we
do
a
patch
release,
instead
of
as
ember
miner,
we
create
a
lot
more
out
of
order
commits
we
have
a
lot
more
manual
backwards
and
even
if
there
is
no
manual
back
part
needed
and
a
commit
lands
cleanly
afterwards,
it
might
cause
side
effects
that
we
did
not
anticipate
because
earlier
commits
are
missing
and
and
that's
something
I
am
personally
more
afraid
about
and
then
actually
breaking
something
with
a
new
feature,
because
zember
miners
should
never
break
something
officially,
of
course,
and
they
can
always
be
regressions,
but
that's
possible
with
every
commit
every
code
change
that
we
do
so.
C
For
me,
there
is
a
higher
risk
in
doing
in
this
manual
work
and
then
trying
to
get
all
the
commits
in
that
we
feel
comfortable
because
I
mean
normally.
We
already
have
the
period
of
time
when
we
land
something
on
the
current
release
line
until
we
feel
comfortable
that
it
should
be
back
ported
to
the
LTS
release
line.
So
there's
at
least
1
months
in
between
where
people
were
also
able
to
attest
the
code,
and
normally
things
are
brought
up
thoroughly.
C
If
it
is
something
urgent
and
and
then
we
can
still
block
that
commit
for
the
LTS
release,
we
could
also
say:
okay,
there
is
a
follow-up
commit
that
has
to
land
at
the
same
time
as
this
commit,
because
otherwise
it
would
break
something.
This
has
happened
before
as
well,
but
I
feel
that
this,
the
safety
time
in
between
is
already
enough
and
better
than
just
doing
the.
B
C
B
B
Problems
that
miners
caused
are
not
as
subtle
as
bugs
it
is
as
simple
as
like
if
a
new
feature
gets
introduced
in
LTS.
A
really
great
example
is
what's
going
on
with
serverless
runtimes.
So
if
you
look
at
Amazon's,
lambda
lamda
does
not
necessarily
keep
their
version.
Eight
runtime
or
version
10
runtime
on
the
latest
minor
they
do
keep
up
to
with
the
latest
patch,
but
for
them
to
update
to
a
minor
for
their
runtime
is
a
fairly
big
deal
and
can
take
six
months
or
so
for
them
to
go
up
to
date.
B
That's
in
production,
so
we've
actually
had
tons
of
issues
and
actually
had
to
like
remove
feature
usage,
because
the
version
of
node
that's
running
inside
of
lambda
doesn't
is
not
on
the
latest
semver
minor
and
all
the
packages
underneath,
because
the
latest
semver
minor
supports
a
feature
start
breaking
on
that
release
line.
This
is
the
primary
reason
why
both
most
LTS
programs
don't
introduce
new
features,
because
once
something
goes
into
LTS
from
a
support
perspective,
you
don't
want
things
breaking
at
all.
You
want
to
be
able
to
update
even
your
dependencies.
B
B
Without
it
even
being
clear,
the
rate
of
miners
that
we
have
has
kept
that
somewhat
constrained
and
we've
been
somewhat
constrained
on
the
number
of
miners
that
we
land,
but
if
we
start
doing
this
actively,
it's
going
to
be
an
issue.
The
other
thing,
too,
is
like
I
really
do
think
that
it's
like
the
claim
here,
that
everything
would
be
in
order.
I
I,
don't
see
how
that's
a
case,
because
we
won't
be
landing
every
miner.
We
won't
be
landing
every
patch.
It
will
never
be
close
to
the
pristine
other
branch.
C
So,
first
of
all,
thanks
for
it,
if
you
think
this
is
especially,
and
if
you
think
that
we
were
looking
for
last
time,
so
I
would
can
be
asked
to
fill
out
those
details
in
in
the
concerns
of
the
Reedy
survey.
Tab,
yeah,
sorry
in
the
issue
and
I
mean
in
this
case
it's
not
like
my
personal
opinion
only
it
like.
We
spoke
about
it
a
couple
of
times
and
we
thought
about
it.
C
So,
thanks
for
bringing
up
these
things
again,
one
thing
that
I
wonder
about
when
you
say
that
AWS,
for
example,
has
trouble
updating
to
minor
releases.
I
would
like
to
get
to
know
the
reasons
for
that
and
because.
B
It's
purely
time
like
even
at
Google,
it's
like
our
team's
put
more
time
into
supporting
and
updating
minor
releases.
Then
they
will
have
a
patch
this
just
period
across
all
runtimes,
and
it
doesn't
matter.
If
we
go
and
say
oh
well,
no
does
a
special
thing:
they
don't
care.
Patches
means
something.
Miners
mean
something
patches
will
have
a
shorter
time
frame
at
which
they
update.
Internally,
miners
will
take
longer.
C
Okay,
I
cannot
judge
on
that
because
I'm
not
working
on
that
process
so
and
that
that's
and
what
I
saw
should
be
the
release.
Purples,
sorry
really
serving
about
to
especially
get
feedback
from
companies
and
like
a
demo,
yes
and
more
and
and
to
get
to
know
what
the
day
would
like
to
have.
So
we,
instead
of
having
a
survey
like
that,
we
could
even
like
write
a
couple
of
emails
to
a
few
people.
B
I'm
trying
to
find
the
right
way
to
say
this
and
in
say
it
in
a
way:
that's
not
just
like
completely
shutting
this
down
and
I
know
that
this
needs
to
be
a
consensus
thing.
I,
don't
have
time
to
work
on
this
and
I
honestly.
Do
not
believe
that
it
is
the
right
move.
I
won't
stop
you
from
from
doing
this
on
working
to
try
to
do
it,
but
I
don't
have
time
to
support
the
research,
because
I
just
do
not
believe
in
it.
C
B
Like
Reuben,
what
I
can
do
is,
if
you
have
something
specific
I,
can
give
you
a
quick
review
before
you
want
to
send
it
out
and
I'm
happy
to
help
introduce
it
to
the
people
from
Google.
But
you
know
I've
made
my
points,
I
think
pretty
clear
on
this
call,
and
it
will
be
extremely
hard
to
get
me
to
change
the
viewpoint
that
I
have
right
now.
I
think
truthfully
that
this
specific
proposal
is
fairly
misguided
and
I
think
that
the
premise
is
incorrect.
A
A
B
C
A
A
Last
one
is
defining
the
words
or
current
releases,
actually
the
package
maintenance
team
and
are
also
considering
this.
At
the
moment,
they've
asked
for
feedback
from
the
release,
team
and
I.
Think
what
they're
trying
to
do
is
define
a
way
your
module
could
specify,
which
versions
have
node
it
supports,
or
which
versions
have?
No.
You
protest
against
and
they've
come
up
with
some
tags
that
they
would
set
for
their
test.
C
So
how
would
it
exactly
work
abandon
is
like
we
explicitly
give
old
versions
on
the
abandoned
one.
C
A
C
B
A
A
A
C
A
B
B
C
B
A
B
B
Well
is
the
idea
that
these
would
be
used
for
our
releases,
or
that
like
I,
was
imagining.
These
are
more
like
when
you're
doing
an
nvm
install
or
when
you're.
Looking
on
the
note
downloads
page
or
something
as
they're
like
categories
of
how
you
think
about
the
releases,
they
wouldn't
be
what
we
would
like
call
the
release
when
we
do
the
release,
but.
A
I
think
this
is
more
unjust
terminology
about
how
you
would
group
like
the
various
release
lines.
Lts
is
easy.
That's
just
the
ones
during
LTS
mood,
right,
I,
think
our
gap
is
this
one
and
I
think
we
should
formalize
on
what
what
we
say
for
all
releases
still
electable
to
get
updates
by
everything.
That's
not
end
of
life.
A
A
A
A
Okay,
I
can
take
the
action
to
PR
this
I,
trying
out
so
as
soon
as
possible,
and-
and
we
can
talk
on
that-
which
word
we
want
to
use
for
all
non
end-of-life
releases
and
then
when
I
go
to
the
package
maintenance
meeting,
whatever
we
agree
on
in
release,
I
try
to
make
sure
they
follow.
So
it's
not
super
confusing
to
users.