►
From YouTube: Node.js Release Working Group Meeting 2019-06-20
Description
B
Repayed
and
we've
only
got
three
items
on
the
agenda
this
week,
but
there
might
be
some
other
things
to
discuss
afterwards
and
the
first
on
the
list
is
a
proposal
for
changes
to
out
yes
and
I.
Think
this
is
an
issue
miles
you
opened,
I,
don't
know
if
you
want
to
give
some
background
to
the
people
that
may
not
have
seen
this
yeah.
A
So
we've
been,
this
is
something
we've
been
talking
about
for
a
while.
Currently
the
way
that
LTS
works
as
a
release
comes,
it
has
six
months
as
an
active
release
than
18
months.
I
mean
six
months,
is
a
current
release,
18
months
as
active
LTS
and
then
twelve
months
of
maintenance
and
the
general
sentiment,
and
this
isn't
a
hundred
percent
the
case.
But
it's
that,
like
you,
get
kind
of
monthly
releases
as
the
cannons
were
aiming
for
during
active
and
then
no
set
number
of
releases
in
maintenance.
A
We
also
up
until
now-
and
this
is
something
that
can
be
written
revisited.
But
up
until
now,
we
generally
have
tried
to
avoid
doing
some
ver
minor
releases
during
maintenance
unless
it
was
necessary
due
to
security
release.
But
some
recent
changes
to
napi
have
had
us
revisiting.
That
I
think
that
is
a
separate
conversation,
but
what's
being
proposed
in
this
change,
is
swapping
the
timeframes
for
active
release,
active
LTS
and
maintenance,
so
that
active
LTS
would
only
be
12
months
and
then
maintenance
would
be
18.
A
One
of
the
benefits
of
this
would
be
having
less
releases
to
maintain
at
the
same
time.
So
currently,
with
the
18-month
window
we
end
up
having
two
LTS
releases
at
the
same
time
that
are
inactive
and
that's
a
lot
of
work,
whereas
if
we
had
12
months
for
active
they're,
never
actually
would
be
to
overlapping
active
LTSs.
A
The
older
LPS
will
still
be
supported
for
another
year
and
a
half
after
it
moves
to
maintenance,
but
it
would
significantly
reduce
the
maintenance
burden
on
this
team
and
I
think
as
well.
More
accurately
reflect
the
release
cadence
that
we
really
can
do
that
late
in
the
release
cycle
of
a
release.
So
that's
the
the
high-level
overview.
B
B
A
D
B
E
Did
I
add
an
addendum
to
that
last
one
sure
miles
why
I'm
absolutely
in
favor
my
was
a
suggestion.
I
thought
that
there
was
an
item
and
played
to
discuss
what
he
said.
Wasn't
gonna
get
discussed
as
part
of
that
issue,
which
is
basically
not
not
pulling
all
the
summers
out
and
then
releasing
them
in
batches.
Is
there
Bethany
didn't
you
have
a
proposal
to
do
that
somewhere
or
I?
Think.
E
C
A
B
B
A
It's
a
little
complicated
so
in
in
my
experience,
and
it
could
and
I
think
that
we
should
go
out
and
and
do
a
little
bit
of
user
research,
or
this
don't
just
take
my
word
for
it.
People
want
less
semver
miners
in
LTS
releases
these
people,
including,
but
not
limited
to
downstream
Linux
distributions
running
their
own
LTSs,
as
well
as
platforms
running
their
own
serverless
operations.
A
Some
examples
to
this
include
platforms
like
Amazon
lambda.
This
has
actually
been
a
pain
point
that
we
ivic
seen
people
experience
in
managing
client,
libraries
and
node
libraries
that
claim
to
target
like
no
date
or
no
ten,
though
these
platforms
can
end
up
taking
quite
a
time,
quite
a
a
larger
longer
amount
of
time
to
upgrade
December
miners,
because
they're
generally
viewed
as
less
stable
than
December
patch
updates.
A
And
so,
if
you
go
and
look
at
various
runtimes
and
the
latest
version,
you
will
notice
that
they
tend
to
be
on
the
latest
patch,
but
might
be
a
couple.
Semver
miners
behind
I
am
genuinely
concerned
that
if
we
switch
to
this
model
of
back
porting
that
we
will
end
up
more
or
less
having
every
release
the
assembler
minor
and
in
from
an
LTS
perspective,
I
view
that
as
a
burden
on
external
teams
were
adopting
our
LTS
releases
yeah,
that's
that's
one
of
them.
A
The
other
one
is
there's
a
premise
here
that
lambing
things
in
order
will
make
things
simpler
and,
to
be
blunt,
I
am
not
convinced
of
that
premise.
A
lot
of
code
caches
different
subsystems,
the
second
that
we
have
to
make
a
patch
that's
specific
for
a
release
line.
We
already
are
off
on
our
own
historic,
like
history.
I
am
not
convinced
that
simply
landing
things
in
the
right
order
will
significantly
simplify
or
reduce
the
burden
of
back
porting.
A
A
lot
of
the
burden
to
back
porting
is
having
to
go
through
and
audit
every
single
commit
when
I've
gone
and
done
these
LTS
releases
in
the
past,
you
have
to
go
through
hundreds
of
commits
the
biggest
difference
between
that
and
current.
Is
you
don't
need
to
audit
every
single
commit
so
even
for
a
commit
that
lands
cleanly?
A
You
know
it
takes
three
to
four
times
as
much
time
as
a
current
release,
because
you
have
to
do
far
more
due
diligence,
so
I
I
know
where,
where
these
suggestions
had
come
from
in
the
summit
and
I,
unfortunately
missed
that
session
and
I
wish
I
had
been
able
to
express.
You
know
these
feelings
earlier,
but
I
am
concerned
that
this
process
would
actually
degrade
the
value
of
LTS
and
I'm,
not
convinced
of
the
benefit
of
it.
Okay,.
B
One
one
thing
maybe
is
that
I
know
reburn
is
trying
to
backport
majors
to
an
LTO.
Well,
currently,
no
12-2
current
as
a
moment
with
compatibility
patches
to
see
if
that
helps
the
conflicts
and
things
like
that.
So
I
guess
we
could
see
how
that
goes,
and
if
it
is
positive,
maybe
revisit
this
but
I,
don't
know
what
the
actual
next
steps
on
this
would
be
other
than
us
going
and
changing
our
release
schedule
to
be
your
minors.
E
Basically,
there's
conflicts,
they'd
fix
conflicts
and
files
and
often
their
conflicts,
because
just
some
of
their
dependent,
you
know,
commits
had
not
been
merged
in
so
I'd.
Go
back,
find
what
it
depended
on
cherry
pick
that
in
then
cherry
picked
Els
one
three
the
conflict
would
disappear
in
the
file.
Life
is
good.
E
Go
on
to
the
next
file
figure
out
what
it
depended
on
and
as
I
did,
that
I
started
to
realize
that
moving
back
along
those
dependencies,
because
they're
being
cherry
picked
in
as
needed
to
fix
conflicts
and
particular
files,
we're
starting
to
land
in
different
orders
and
I
I
ended
up
in
this
situation,
where
I
I
couldn't
get
I,
couldn't
figure
out
the
order
that
all
the
old
commits
had
to
land
in
in
order
to
stop
making
a
huge
mess
every
time.
So
it
gave
me
this.
E
You
know
it's
only
one
experience,
though
it
did
kind
of
cut
across
a
bunch
of
the
codebase,
but
I
gave
me
the
very
strong
impression
that
the
order
of
commits
landing
it
can
be
like
knock
so
painful
at
first,
but
has
this
ripple
effect
where
just
gets
worse
and
worse
and
worse
with
time
when
things
came
out
of
water?
Why
surprise
it?
You
don't
think
the
order
is
really
important.
A
E
Right,
but
what
we're
going
to
say
is
it
difficult
to
prove,
but
what
I
went
back
so
yeah?
Obviously
the
key
notes
being
missing
is
what
may
tell
us
one
free
land,
but
when
it
in
attempting
to
find
the
missing
ones
and
land
the
missing
commits
those
missing
commits
themselves
wouldn't
land
unless
they
landed
in
a
particular
order,
and
then
they
depended
on
other
commits
that
also
wouldn't
have
yes,
so
it
kind
of
so
I.
E
E
Is
it
it's
a
little
bit
hard
to
experiment
like,
but
it's
hard
to
know
for
sure,
unless
somebody
goes
through
the
effort
of
either
redoing
ten
decks,
not
redoing
and
releasing,
but
like
reattempt
to
land
it,
but
everything
in
the
right
order,
which
is
such
a
massive
undertaking,
nobody's
gonna.
Do
it
I,
don't
think
so
here
is
to
try.
An
experiment
like
I
think
would
be
interesting
to
try
landing
in
order.
So.
A
I
think
there's
a
premise
here,
though,
that's
being
missed.
Is
we
as
much
as
possible
attempt
to
land
in
order
from
the
beginning,
Rubin
tears
in
attendee
and
is
looking
to
get
promoted
so
Sam
when
we're
generally
doing
backwards,
we're
making
a
list
of
all
commits
that
haven't
been
back
ported
and
we
are
back
putting
them
in
order?
The
only
thing
that's
not
landing
in
order
is
the
is
when
things
don't
land
cleanly
and
require
backwards,
and
then
those
land
out
of
water
and.
A
And
send
reminders
yes,
but
I
mean
and
I
I.
Don't
want
to
be
too
hard
about
this,
but
I
want,
like
I,
am
extremely
strongly
-1
on
regular,
send
reminders
for
LT
s
and
there's
no
way
to
the
IC
to
reconcile
that
with
landing
everything
in
order,
including
minors,
because
of
the
way
in
which
we
handle
current.
E
Ok,
so
we
shouldn't
confuse
the
two
things:
I
mean
if
you're
to
me,
it's
like
there's
two
things
going
on.
One
is
so
you
so
whether
or
not
it
makes
things
landing
in
order.
It
makes
it
better
or
not.
It's
not
worth
talking
about
well
right
now,
maybe
because
you
just
don't
like
their
gear,
some
for
minor
LTS
releases
every
time,
yes,
ok,
no
I
I
think
would
be
interesting
to
gather
more
data.
On
that.
E
My
my
impression-
and
you
know
we
all
see
different
parts
of
the
node
world-
is
that
people
are
definitely
reluctant
to
upgrade,
which
is
and
just
basically
don't
unless
they
have
to.
If
they've
got
running
code
so
and
I
don't
see
that
as
to
being
depending
on
the
specific
version
it's
in
those
type
of
there.
What
I've
seen
is
they're
very
conservative
users
if
they
just
just
just
don't
unless
they're
forced
to.
A
Believe
from
having
seen
it
when
I
back
ported
them
that
cember
miners
are
more
likely
to
have
bugs
and
errors
because
they
are
new
and
giving
them
a
couple
months
to
bake
and
find
the
errors.
I've
very
rarely
seen.
Semper
miners
get
back
ported
that
you
not
come
with
a
handful
of
tail
commits
that
are
fixing
up
the
edges
of
that
semper
miner.
That
were
discovered
over
a
handful
of
months
afterwards.
E
You
believe,
there's
I
believe
that
their
difficulty,
maintaining
LTS
and
the
growing
backlog,
let's
physically
just
throw
more
bodies
at
it.
I'm
not
sure
that
would
even
help
like
strikes
me
that
it's
getting
it
gets
harder
to
maintain
the
OTS
inactive
very
quickly
and
all
of
the
permits
that
are
supposed
to
land
like
there's
a
what
is
it
a
few
thousand
backlog
right
now?
E
E
A
My
impression
from
having
done
the
works
and
the
back
porting
over
70%
of
the
commits
do
not
have
conference,
so
the
problem
of
like
finding
the
time
and
haven't
handling
the
backlog.
The
backlog
is
not
growing
and
due
to
conflicts
or
doing
to
do
two
things
not
landing.
It's
literally
just
the
amount
of
time
that
it
takes
to
triage
with
our
current
process.
So
I
I
I
do
not
believe
that
landing
an
order
would
affect
that
at
all.
That
is
a
client
thing.
F
So
and
there
there
are
multiple
things
here
and
that
you
are
discussing
at
the
moment.
It
seems
to
me
and
I,
for
example,
had
a
different
experience
when
it
comes
to
backporting.
So
when
we
have
out
of
order,
commits
I
ran
into
some
serious
problems
back
working,
something
else
because
and
then
there
was
a
manual
backward
of
something
we.
F
Had
to
revert
multiple
commits
to
Dan
land
commits
in
the
correct
order
afterwards
again,
so
this
is
the
biggest
pain
and
that
I've
seen
was
out
of
order
commits
and
then
about
having
a
risk
for
a
landing,
Deborah
minor
or
not.
Yes,
there's
definitely
sometimes
hope
low
up.
There
is
to
to
fix,
as
cases
I
think
that
it's
fine
mainly
for
the
reasons
that
Sam
outlined
about
that.
It's
it's
still
something
new
and
yes,
we
try
to
backward
everything.
F
We
could
go
into
a
different
which
is
like
a
middle
ground,
pretty
much
for
both
stand
points,
and
there
is
something
there.
The
only
open
pull
request
and
in
the
release
working
group
I
have
to
update
it,
but
it
is
pretty
much
exactly
that,
because
what
it
is
is
you
have
a
Denver
miner,
each
let's
say
mm-hmm
at
moment,
it's
every
three
months
and
on
the
LTS
releases
ray
and
when
we
release
that
afterwards,
the
next
release
would
be
a
patch
release
and
then
another
patch
release
and
then,
as
every
miner
again.
F
The
important
part
is
that
the
second
Denver
miner,
with
not
built
on
top
of
the
former
pet
release,
but
would
have
a
separate
branch
which
includes
the
correct,
commit
order
of
all
the
others
in
between.
They
would
then
allow
to
have
the
correct
order
again,
mostly
and
and
still
allowed
to
have
pets
releases.
I
cannot
tell
if
perhaps
releases
really
have
a
huge
benefit
or
not.
I
only
know
that
our
back
parts
themselves,
the
manual
ones.
F
A
What
you're
saying
but
Ruben
we
have
3,000
commits
that
haven't
been
back
toward
it
LTS
right
now
and
I.
Think
what
you're
experiencing
is
a
localized
problem
to
backporting
specific
things,
but
is
not
a
general
problem
and
I
think
that
I
honestly
believe
that
the
solution
that
is
being
proposed
is
over
correcting
in
a
way
that
will
significantly
hurt
the
value
of
LTS.
We
cannot
be
doing
regular
minor
releases
on
our
LT
s,.
A
Know
what
what
I
think
would
maybe
make
sense.
Reuben
I
do
not
believe
that
you've
done
an
extensive
backporting
of
commits
for
LTS
before
I
think
that
it'll
for
you
to
go
through
the
current
process
that
we
have
and
see
where
the
pain
points
lie
and
perhaps
even
help.
I
will
nominate
you
to
you.
Lts
releases
I
think
help
doing
one
or
two
of
the
LTS
releases
first
may
help.
You
see
why,
like
I,
really
personally,
do
not
believe
that
the
optimization
that
you
are
suggesting
will
really
help.
A
Think
even
the
different
branches
I
don't
like
we.
It
takes
already
so
much
time
to
manage
what
we
have
right
now
having
to
manage
two
branches
and
then
switching
between
the
December
minor
release.
It
seems
like
creating
twice
as
much
work
or
at
least
like
30,
to
40%
more
work
than
we
currently
have,
and
we
already
can't
keep
up
with
the
backlog
and
to
do
that.
The
only
advantage
that
it
would
create
would
be
to
save
a
bit
of
time
in
backporting
miners
which,
to
be
honest,
backporting
miners
should
not
be
the
priority
of
LTS.
A
A
Does
that
will
be?
How
does
that
work
with
the
dot
X
release
branch,
though,
if
you
can't
change
the
history
of
the
dot
X
release?
So
if
he's
been
tracking
the
patch
release
against
dot
X,
and
now
we
want
to
land
the
minor
release,
we
can't
just
force
push
over
X
like
we're
gonna
have
to
then
let
cherry-picks
on
the
minor
release
onto
the
patch
release.
Now
we
would
have
to
force
push
over
a
dog,
ax,
yeah
and
and
I.
We
can't
do
that
dot.
F
F
A
Consistent
source
of
truth
that
we
have
had
in
release
is
that
X
is
a
forward
facing
branch
that
will
never
change
that
teams
that
are
doing
releases
in
potentially
even
building
their
own
releases
that
are
patching
things
on
top
of
us
can
be
guaranteed
that
the
dot
X
release
will
always
be
a
fast
forward
branch
breaking
that
breaking.
That
is
a
huge
break
to
to
commitments
that
we
make
downstream.
F
A
F
A
Can
you
outline
the
implications
of
a
downstream
if
I'm,
a
downstream
consumer
of
a
node,
LTS
branch
and
I'm
floating
commits
on
top
of
it?
If
we
force
push
over
the
dot,
X
branch
and
I
now
go
to
rebase
that
commits
that
I've
been
floating
on
top,
they
may
completely
be
different
now,
as
opposed
to
like
rebasing,
on
top
of
a
small
set
of
known
changes.
A
If
we,
if
we
force
pushed
for
every
single
minor
there
potentially
be
thrash,
and
without
like
a
thousand
to
two
thousand
commits
in
between
releases,
where
that
rebase
now
we'll
have
to
rebase
against
thousands
of
units
instead
of
a
hundred
or
150,
it's
a
huge
amount
of
extra
labor
that
we're
putting
on
external
teams
that
are
potentially
floating
things.
On
top
of
our
releases.
F
I,
don't
know
like
in
general,
I
would
like
to
beg
port
more
because,
like
that's
what
people
were
also
saying,
and
at
least
what
I
heard
like
that,
they
would
like
to
use
this
feature
ABC,
it's
normally
always
they
want
to
have
like
when,
when
people
come
in,
it's
only
hey
could
this
be
back
for
it?
It
could
just
be
back
for
it.
Dude
I
have.
A
Survey
could
make
sense.
We
could
also
do
like
user
empathy
sessions,
there's
the
user
and
Enterprise
at
which
groups
that
will
help
organize
like
group
sessions,
there's
a
couple
different
ways
that
we
definitely
could
approach.
This
I
also
would
like
to
encourage
those
that
are
offering
new
solutions
to
the
space
to
pitch
in
and
try
to
work
with
the
current
process,
a
couple
times
to
at
least
get
a
strong
feeling
for
what
you're
trying
to
optimize.
E
To
say
something
so:
I'm
not
yeah
I
mean
it'll,
be
good
to
get
more
outreach
and
stuff
I'd
like
to
equivalent
speaking
of
someone
not
who
works
in
node,
Corp
and
merging
stuff
back
and
doing
that.
But
speaking
of
someone
who
maintained
hundreds
literally
hundreds
of
NPM
packages
for
strongloop
and
later
for
IBM
for
a
while.
This
is
why
I
want
why
some
of
our
miners
going
back
helps
me
so
because
our
packages
are
usable
enterprises.
Those
enterprises
are
possibly
risk
averse
to
dumping
local
miners,
but
definitely
risk
aversion
jumping
over
majors.
E
We
have
many
customers
who
are
still
on
hate
and
are
like
just
now
considering
moving
to
ten.
So
so
our
packages
have
to
work
as
far
back
as
the
oldest
LTS
and
if
they
also
have
to
work
on
the
newest
node,
they
are
the
current
release.
So
what
what?
What
I
did
is?
I
made
sure
that
I
always
coded
to
the
lowest
possible
common
denominator
and
at
its
worst
point,
that
was
keeping
two
0.10
feature
sets
in
language.
You
know:
Java
language
sets
way
past
it.
E
When
there
were
newer
nodes,
I
think
was
up
to
node
4
at
one
point:
I,
probably
the
numbers
wrong,
but
I
was
still
coding,
2-0
10,
because
anything
that
I
published
it
didn't
work
on
0
10,
wouldn't
work
for
corporate
customers
who
are
still
stuck
on
the
older
style.
Yes,
but
that's
that's.
Why
looking
to
me
some
reminders
back
because
it
allows
a
consistent
API
across
all
of
the
supported,
like
node
supported
versions
and
allows
me
to
publish
packages
that
easily
support
all
those
without
having
to
do.
You
know
doc.
E
You
know
if
depp's
based
on
node
version
or
other
horrible
stuff,
now
I'm
not
I,
want
to
be
clear
miles.
I'm,
not
I'm,
not
trying
to
override
your
concerns,
I'm
not
going
to
try
and
push
a
real
change
for
that.
It's
not
my
place
not
going
to
do
that.
I'm
just
giving
this
feedback
and
I.
Also
one
part
of
me
as
well
takes
exact
opposite
point
of
view,
which
is
I
kind
of
like.
E
If
some
of
our
miners
don't
go
back.
You
know
TLS
one
three
never
ends
on
ten
people
start
asking
me
about
TLS
one
three
on
ten
I
can
be
like:
hey,
listen,
buddy.
You
know
it's
it's
time
to
upgrade
twelve.
Is
you
know
for
a
while
move
on
up?
That's
where
you
get
the
new
features,
I'm,
not
so
sure
I'll
be
actually
able
to
get
people
to
move
up,
but
I
guess
if
the
pressure
is
high
enough,
maybe
they
will
but
wait
any
other.
A
Mean
one
thing:
the
level
set
that
I
think
is
worth
remembering
all
this
with
doing
one
minor
per
quarter,
which
is
what
we've
been
trying
to
average.
That
means
one
out
of
every
three
releases
is
December
minor,
so
we
already
do
have
a
fairly
decent
cadence.
The
issue
is
identifying
the
central
miners
and
back
porting
them
and.
E
How
easy
it
is
to
bring
the
back
parts
back
and
there
again
I
like
I,
absolutely
take
your
point.
People
doing
LTS
have
the
best
feeling
for
what
makes
it
better
but
I'm
here,
because
in
an
attempt
to
bring
a
miner
back
that
I
thought
would
be
worthwhile.
I
I
started
having
to
look
at
the
things
it
depended
on
the
things
it
depended
on
the
things
that
depended
on
me.
B
E
B
A
A
A
F
A
Generally,
there's
there's
the
wiki,
which
has
all
the
timelines.
If
you
think
about
it.
From
a
cadence
perspective,
we
cut
a
release.
Two
weeks
later,
we
cut
in
our
see
two
weeks
later
we
cut
a
release,
so
it's
kind
of
rolling
every
two
weeks
and
then
there'll
be
much
more
intensive
testing
and
Sikkim
and
multiple
RCS
as
we
catch
problems
and
and
get
them
working.
A
And
so,
and
just
for
example,
here,
if
you
look
at
like
our
release
Cadence's
it
already,
is
we
had
a
summer
minor
in
May,
then
a
patch
in
July,
and
then
another
minor
already
scheduled
for
August.
So
you
know
they're,
pretty
reasonable.
Cadence
already
of
minor
is.
The
question
is
just
making
sure
that
those
minors
can
land
Sam.
It
sounds
like
you
had
a
pretty
frustrating
situation.
I've
definitely
been
there
on
some
of
the
minors.
A
My
experience
has
been
that
those
are
more
outliers
than
than
the
norm
in
backporting
things,
but
when
it
definitely
gets
bad
and
hairy,
what
you're
also
feeling
is
like
from
10
to
12?
There's
been
a
lot
of
several
major
changes
in
crypto
and
a
lot
of
churn
and
the
more
churn
that
there
is
in
sub
systems,
especially
turn
that
relies
on
sembra
majors
the
more
acutely
we
feel,
those
as
well.
E
B
So,
in
terms
of
this
next
release,
rebored
my
nail
I
think
even
kyani
all
expressed
some
interested
in
figuring
out
like
getting
a
feel
for
what
we
do
to
create
an
LTS
release,
I'm
happy
to
block
off
some
time
in
my
calendar
and
kind
of
do
what
you
used
to
do
with
me
miles
and
watch
a
bit
of
the
process
and
I'll
talk
you
through
how
we
go
about
it.
If
that
works,
for
people
over
WebEx,
Lavigne
or
something.
A
A.M.
he's
in
time
on,
on,
like
every
other
Tuesday
works
for
people,
that's
like
a
standing
meeting
that
that
that
I
have
originally
for
going
over
backwards.
You
know,
sometimes
we
just
use
it
to
catch
up
and
see
how
life
is,
but
that
would
be
helpful
for
people
I
suppose
sometime
I
can
donate
as
well.
D
A
Next
meeting
is
on
the
25th,
so
so
Reuben
for
yourself.
If
you
were
gonna,
volunteer
to
take
on
this
next
release,
what
it
would
mean
would
be
going
through
from
now,
basically
until
the
second
and
I
don't
know
how
many
back
parts
are
already
on
the
trendex
branch,
but
we
try
to
get
at
least
between
150
to
200
commits
on
that
branch.
Before
the
initial
arson.
A
A
A
You
can
pair
on
that
also,
and
just
like
audit
the
work
that
you've
done
and
ensure
that
you
know
nothing
landed
that
shouldn't
it's
kind
of
it's
it's
a
bit
of
a
pseudoscience
like
kind
of
once.
You
get
the
hang
for
what
makes
sense,
and
doesn't
you
know
it?
It
does
take
about
three
times
support
times
as
long
as
doing
the
current
release,
just
because
you
have
to
go
through
and
check
every
commit,
but
it
does
become
a
little
bit
more
intuitive.
After
doing
it.
For
a
little
while
and.
D
B
B
B
B
B
B
B
F
Yeah,
so
if
I
remember
correct,
we
actually
also
discussed
that
before
in
the
meeting,
and
we
were
like
okay,
we
would
be
fine
doing
something
like
that.
As
long
as
the
build
team
would
do
it,
I'm
I
think
it's
a
good
idea
to
ask
to
bring
it
to
the
TSC
and
because
it's
probably
something
more
fundamental.
B
A
A
Then
the
flip
side
of
it
would
be
I
think
that
if
this
is,
if
this
kind
of
like
small
script
to
select
releases
is
something
that
we
are
interested
in
landing,
there
has
been
discussion
about
interest
in
something
like
this
for
core
as
a
whole,
and
this.
If
we're
gonna
release
something
like
that,
and
it's
something
that
core
is
looking
into
as
well.
We
should
definitely
not
start
shipping,
something
that's
different
than
what
core
will
eventually
ship,
or
at
least
two
different.
A
B
C
So
on
the
wiki
there
is
a
security
release
date
reserved
the
25th
that
sound
Germany
outlook
as
to
whether
we
will
need
to
have
a
release
on
that
date
or
not
I
mean
it
was
reserved
for
security
related
that
were
not
critical.
I
was
wondering
if
things
like
the
open,
SSL
up
greater
progress
book
account
was
that
sort
of
thing
or
or
if
we
think
that
data's
an
it,
isn't
actually
going
to
be
needed
at
this
time
around
I.
E
Haven't
find
it
found
anything
to
release
on
those
dates
and
the
open
SSL
releases
will
be
just
they.
They
weren't
the
kind
of
things
I
was
thinking
of
and
I
I'm
trying
to
get
more
security
related
stuff.
You
know,
Ginty
the
normal
release
screen
process.
Okay
have
to
be
handled,
as
you
know,
special
things.
It
was
CI
lockdown
and
all
that
stuff,
so
I
mean
whether
or
not
the
release
team
on
wood
to
make
caches
like
I
guess
I
would
leave
it
as
a
written
I.
E
There's
I
was
I
was
thinking
that
there
might
be
some
kind
of
some
batched
private
security
fixes
it
might.
We
could
kind
of
collect
them
all
and
release
them
at
a
particular
predetermined
date,
because
I'd
seen
that
happening
in
the
last
couple
of
security
releases.
However,
this
security
release
looks
empty,
like
there
is
nothing
waiting
to
come
out
on
a
date.
We
reserved.
A
Theirs
generally,
what
we've
done
is
like
we
have
reports
and
for
certain
things,
like
you
know,
low
risk
bosses
or
like
things
that
are
very
low
risk.
We
let
those
kind
of
bundle
up
until
we
have
enough
and
then
we
plan
a
release.
I
think
this
was
the
first
one
where
we
had
kind
of
picked
a
date
in
advance,
but
you
know
I
can't
speak
too
much
about
what
is
and
isn't
embargoed,
but
you
know,
as
far
as
I
know,
right
now,
like
there
isn't
really
much
in
a
backlog.
That's
that's
embargoed
right
now.
A
That
was
part
of
the
reason
why
we
initially
kind
of
took
that
approach
rather
than
a
regular
cadence,
because
you
know
doing
a
security
release
for
just
one
thing
can
be
kind
of
disruptive,
especially
if
it's
not
like
a
high-risk
vulnerability,
but
maybe
that's
something.
Maybe
maybe
what
we
should
do
is
do
like
a
separate
out-of-band
pry,
the
meeting
between
the
security
to
the
arts
team
and
the
release
name
to
kind
of
get
on
the
same
page
about
that.
E
Yeah
yeah,
maybe
we
should
I
mean
I,
am
guilty
of
originally
suggesting
kind
of
a
release
cadence
for
security,
but
based
on
the
last
couple
students
I
saw
where
there
was
something
big
enough,
that
it
was
forcing
a
security
release
and
I
saw
that
then
made
some
people.
Okay,
let
me
finish
up
my
low
priority
stuff
and
get
it
into
that
spec
release.
So
I
was
thinking
that
by
pre-planning
one.
For
this
you
know
ender
June,.
B
E
E
E
It
I
don't
see
any
reason
or
the
OpenSSL
releases
which
are
public
to
the
world.
There
is
a
couple
seniors,
they're
low
priority
that
OpenSSL
themselves
didn't
even
release
a
thick
like
a
new
version
of
open
SSL.
They
just
kind
of
waited
till
they
had
their
next
regularly
scheduled
patch
update,
and
then
they
bundle
the
exes
in
so
I
I
think
treating
them
just
a
normal
released
rings.
F
B
Say
wow
this
meetings
been
had
six
people
here
today,
which
is
probably
in
mace
we've
had
in
a
while.
So
if
this
meeting
time
works
and
I,
don't
think
anything's
been
resolved
and
I
don't
know,
we
just
have
to
monitor
how
the
attendance
goes
over
the
next
couple
of
meetings,
but
I
can
keep
it
to
weekly.
For
now,.
F
So
because
what
I
suggested
was
actually
I
like
how
the
TSE
does
it
at
a
moment
and
with
I'm
having
in
the
schedule
every
in
this
case
every
week
for
this
ESC
but
and
let's
say
every
two
weeks
is
still
just
to
keep
it
and
we
could
cancel
it.
If
we
say
there
is
not
really
anything
to
talk
about
I'm
up
to
two
days
before,
okay.