►
From YouTube: Node.js Release Working Group Meeting - 12th March 2020
Description
A
A
B
B
So
an
example
of
this
would
be
something
lands
on
current
that
has
a
breaking
change,
but
isn't
noticed
that
bug
then
gets
the
LTS
and
the
bug
is
discovered.
Well,
it's
an
LPS.
Now
do
we
revert
from
master
and
then
revert
on
on
current
and
LTS,
or
do
we
revert
only
from
LTS
and
then
land
again
at
look
at
the
point
that
it's
been
fixed
on
current,
my
historically
I
have
done
the
latter
and
I
believe
Anna
was
asking
for
something
closer
to
the
former
and
I
think.
B
There's
cases
where
that
may
make
sense,
especially
for
like
bigger
breaks,
that
don't
have
clear
solutions
to
them,
but
in
some
cases,
like
the
large
pages
change,
for
example,
that
landed
on
the
recent
12
that
we
ended
up.
Reverting
it's
a
lot.
It's
a
lot
hairier
to
revert
something
that's
like
semver
minor.
That's
lived
on
master
for
a
while,
so
I
kind
of
feel
like
we
need
to
take
this
case
by
case.
A
Yeah
I,
agree
and
I,
don't
know
if
the
kind
of
expectation
around
LTS
releases
and
all
of
the
enterprises
you
using
them
in
production
may
even
add
to
us
wanting
to
get
an
LTS
release
out
as
fast
as
possible,
and
that
may
involve
just
creating
the
proposal
with
the
fix
in
it.
Rather
than
waiting
on
master.
B
Yeah
I
agree:
I,
think
that
perhaps
where
this
makes
the
most
sense
is
just
kind
of
waiting
until
the
next
time
that
we
have
this
I
mean
next
time.
We
hit
a
reversion,
a
bug
in
them,
like
kind
of
deciding
in
the
moment
like
what
makes
the
most
sense,
I
think
another
possibility
I
think
we
discussed
last
time
was
potentially
documenting
like
what
to
do.
B
If
there's
a
if
you've
released
a
bug
and
just
kind
of
have
a
document
that
outlines
a
couple
different
playbooks
and
you
know
having
the
revert
from
master,
be
one
of
the
potential
play
books.
I
think
you
know
like
Anna's
concerns.
We're
like
one
was
that
it
can
make
it
harder
to
keep
track
of
what
actually
needs
to
be
back
boarded
if
we
just
kind
of
revert
it
and
it
gets
left
and
another
one.
Was
that
like
hey,
if
it's
broken
on
LTS
and
it's
still
broken
on
current
then
like?
A
Yeah
I
agree,
I
think
having
a
what
to
do
when
there's
a
broken
release
guide
somewhere.
Maybe
in
no
Jess
release
would
be
really
useful
actually
and
maybe
it
could
involve
hey.
We
should
open
an
issue
on
the
release,
repo.
Just
so
will
the
other
releases
kind
of
know
what's
going
on,
and
that
was
a
broken
release
and
maybe
even
help
out.
If
that
was
a
people
were
stuck
for
time
or
something
like
that
to
jump
in
and
fix,
and
we
can
all
come
to
a
kind
of
collective
agreement
on
the
approach.
B
Michaels
saying
in
the
chat
also
that
he
thinks
maybe
Anna
meant
that
we
should
also
try
to
revert
on
master
and
much
sooner
and
I
absolutely
agree
with
that.
We
had
an
11
release
that
went
out
this
week.
Well,
like
I
guess
today
they
went
out
at
11:59
p.m.
East
Coast
time
so
I'm
calling
it
yesterday,
but
there
was
a
PR
that
landed
on
current,
that
four
streams
that
ended
up
breaking
a
whole
bunch
of
things
and
I
believe
that
we
got
all
the
patches
in
to
fix
it.
B
But
there
was
a
discussion
about
whether
or
not
we
should
just
revert
that
change
for
what
it's
worth.
The
reason
I
didn't
move
forward
with
just
reverting.
It
was
because
of
the
other
changes
that
landed
on
top
of
it,
including
a
whole
bunch
of
other
strings
back
ports
for
unrelated
fixes.
Just
reverting
it
would
have
been
like
a
huge,
tangled
mess
and
big
shout-out
to
roan
AG
for
working
kind
of
over
time.
A
A
And
also
auditing
the
current
list
of
LTS
numbers,
so
that
list
is
quite
lengthy
at
the
moment
and
we're
not
really
sure
it's
truly
representative
of
people
who
still
want
to
continue
to
be
involved
so
miles
I
saw
you
kicked
off
an
audit
for
that,
and
also
we
had
some
discussions
around.
This
should
probably
have
been
on
the
agenda
rotary,
dropping
the
back
Porter's
team
and
kind
of
moving
up
into
the
out
yes,
team,
I.
A
Think
mouths
your
your
suggestion
was
that
we
would
have
a
release
working
group
members
team,
which
is
everyone
who's
in
the
working
group,
a
release,
automation
team,
so
that
would
take
care
of
the
release.
Tools,
might
change
dollmaker
branch,
diffic,
cetera
and
releases,
and
that
would
be
anyone
who
can
promote
a
release
and
LTS,
which
would
be
focused
around
LTS
related
work.
That
would
probably
include
backporting
20s.
And
if
you
remember,
if
both
release
a
note,
yes,
you
would
be
doing
the
OTS.
You
could
promote
an
OTS
release,
site,
correct
Mouse.
That.
B
Was
just
kind
of
what
I
threw
out
there
I'm
happy
to
have
something?
That's
also
like
simpler.
So,
for
example,
maybe
we're
okay
with
all
of
the
release
team
members
having
access
to
all
the
tools
and
really
Automation
doesn't
need
to
be
its
own
separate
thing.
But
I
was
just
trying
to
look
at
the
structure
that
we
had
right
now
and
the
things
that
were
overseeing
and
trying
to
the
big.
B
The
most
important
thing
that
I
was
trying
to
capture
was
that
we
do
have
people
not
a
ton,
but
we
do
have
people
right
now
that
are
not
doing
releases
but
are
helping
with
back
ports
and
have,
by
our
current
model
permission
to
do
so,
and
I
would
like
for
us
to
continue
this
structure.
I.
Think
one
of
the
things
that's,
maybe
a
bit
of
a
challenge
here-
is
trying
to
mix
the
mental
model
of
like
I
am
which
is
specific
permissions,
as
opposed
to
like
working
streams,
which
is
like
how
we
work.
B
A
B
The
sense
that
I
definitely
want
to
see
more
people
doing
the
work
and
maybe
there's
a
way
in
which
we
can
document
that,
like
if
n
number
of
back
quarters,
approve
something
it
can
land,
and
actually
this
is
maybe
a
good
thing
for
us
to
poke
at
in
general-
is
like.
We
haven't,
really
used
the
general
collaboration
guidelines
for
landing
that
those
don't
really
apply
to
backwards
and
I'd
have
to
dig
through
our
governance
again,
both
in
the
project
and
an
LTS
I.
B
Don't
know
if
we
really
have
super
well-documented
policy
around
like
when
a
back
port
can
and
we've
actually
had
like
stronger
policy
around
like
who
can
land
the
backwards.
And
since
that
group
is
really
small,
they
can
kind
of
land
it
whatever,
because
we
trust
their
judgement.
So
I
do
think
that
like
if
we
wanted
to
like
another
approach,
could
be
allowing
anyone
to
land
but
like
requiring
that
someone
from
LTS
signed
off
on
it
that
could
kind
of
invert
that
relationship
and
allow
anyone
to
land
things
on
an
LTS
branch.
B
A
Yeah,
because
I
guess
we
the
way
we've
worked
is
we've
often
told
people
when
they're
landing
work
told
each
other
or
kept
each
other
up
to
date
when
we're
landing
things
on
the
staging
branches.
Just
so
we
don't
accidentally
kind
of
pusher
it
with
someone's
changes.
If
we've
had
to
back
something
out.
B
Not
to
put
people
on
the
spot,
but
Richard
and
Shelley
as
individuals
who
have
either
a
not
been
like
releasing
as
long
or
aren't
a
release
or
but
that
have
contributed
to
these
branches.
Do
you
have
any
feedback
or
thoughts
about
how
its
managed
or
there's
there
ways
that
you
think
we
could
manage
it
slightly
better
or
maybe
you
know,
remove
some
of
the
bottlenecks
from
from
our
process.
C
I,
don't
think
we
have
the
problem,
that
we
have
lots
and
lots
of
back
ports
that
would
sort
of
land
so
often
that
it
would
interfere
with
the
any
potential
sort
of
back
outs
of
staging
or
need
to
rebase
staging
I.
Think
if
anything,
the
issue
is
that
we
don't
get
enough
back
ports
for
things
that
we
actually
want
on
the
LCS
I
mean,
for
example,
ten
I
think
we've
got
to
the
stage
where
we're
not
that
forcing
anything
unless
people
are
asking
for
it.
So.
C
D
I
would
say
it's
like
beyond
the
bottleneck
that
I
really
see
occasionally
is
that
I
think
this
is
like
more
potentially
like
a
cultural
project
thing
than
anything
else,
but
sometimes
it
takes
a
long
time
for
things
that,
like
do,
you
need
to
get
back
word
it
to
get
back,
coordinate
because,
like
the
onus
ends
up
depending
on
the
PR
falling
on
the
back
borders,
you
don't
necessarily
have
contacts
in
the
PRI
motive.
Take
the
backboard
it
so
I
think
like.
D
If
there's
any
way
we
can
like
focus
policy
or
people
or
whatever
to
see
if
we
can
sort
of
like
create
more
of
like
an
end,
like
the
person
who
opens
the
original
PR
is
a
little
bit
more
responsible
for
the
back
part
to
whatever
staging
brands
we
wanted
to
get
on.
That
might
improve
things
a
little
bit.
B
That
haven't
landed,
but
you
know
currently
for
a
lot
of
collaborators
or
a
lot
of
people
who
are
committing
even
if
it's
drive-by,
the
definition
of
done
is
like
the
commit
lands
on
master
and
that's
kind
of
when
they
walk
away
and
perhaps
and
I
think
Shelley.
You
were
talking
about
some
automation
tools
that
electron
uses
like
we
could
give
people
some
sort
of
signal
about.
B
You
know
what
branches
things
land
cleanly
on
that
could
be
automated,
so
that,
like
that,
that
triggers
them
to
think
a
little
bit
more
about
where
they
want
it
to
live.
So
really,
you
know
expanding
on
that.
You
know
if
you
fix
a
bug
on
master,
because
you
found
a
bug
on
node
13,
but
you
didn't
actually
ensure
that
your
fix
works
on
node
13.
D
So
this
is
actually
a
great
question,
because
a
piece
of
tooling
that
we
have-
which
I
think
would
be
relatively
non-invasive,
is
that
when
you
open
up
PR
and
you
tag
it
with
certain
labels,
electron
will
automatically
tell
you
all
the
branches
always
clean
the
on
without
actually
taking
any
pull
across
section
or
anything.
It
just
shows
up
as
a
check
I.
A
D
D
D
Yeah
I'm
actually
genuinely
very
happier
like
port,
at
least
like
the
simple
aspects
of
that
tooling.
Here.
Here's
a
good
PR,
please
still
in
mind
the
fact
that
a
bunch
of
the
CI
is
currently
failing.
But
if
you
look
down
at
the
checks,
you
can
see
that
in
the
checks
panel
you
can
see
back
portable
8xy
completed,
failed
and
then
back
portable
9xy,
successful,
clean
backward
I.
C
It's
it's
a
much
easier
to
say
things
can
land
if
all
the
checks
of
casting,
but
if
we
have
any
checks
that
we
know
might
fail
because,
for
example,
they
don't
man
on
a
on
a
on
an
earlier
release,
branch
that
marks
the
PR
read
before
it
lands,
then
I
can
look
for
three
lots
of
questions
arcing.
How
do
I
fix
this?
You
know.
D
C
C
C
Because
we've
got
some
things
in
the
existing
CI,
like
the
one
that
checks
the
commit
message,
but
that
was
in
Travis
and
that's
now
not
showing
up
in
the
checks
API,
because
whenever
it
went
red
it
was
kind
of
decided
that
that
wasn't
something
we
wanted
to
concern.
The
authors
of
the
PR
with
it
was
more
kind
of
the
person
landing
it,
and
it
was
that
that
red
mark
and
most
all
the
other
check
indicators.
That
was
been
to
be
an
issue
so.
C
B
So
we
already
have
a
label
system,
that's
pretty
accurate
here,
there's
the
back
port
requested
label
and
there's
the
LTS
watch
label
and
we
already
have
a
bot
that
applies
labels
that
Shelley,
if
you
wanted
to
like
you,
could
work
this
as
a
pull
request
against
the
node
bot
because,
like
all
the
infrastructure
is
already
there,
so
you
could
just
kind
of
hook
into
that.
But
it
doesn't.
B
B
It
also
could
come
with
like
a
comment
like
essentially
auditing
the
step
that
we
do
when
we're
automating
the
step
of
auditing
more
or
less
because
it
would
immediately
people
when
they
open
the
PR
hey.
Should
this
be
on
those
branches
and
and
kind
of
put
that
onus
on
the
folks
who
wrote
it
because
most
times
you
we
don't
know
if
something
should
land
we're
deferring
to
the
folks
who
did
it
the
things
that
we
decide?
B
Maybe
shouldn't
land
are
the
ones
that
you
know
introduced
bugs
or
whatnot,
so
like
I,
guess
the
only
the
only
thing
that
may
be
less
than
ideal.
With
this
approach
is
we
don't
want
too
many
premature,
back
ports
being
opened
and
I
guess.
One
of
the
things
that
could
be
less
than
ideal
is
like
if
we
have
things
that
we
haven't
landed
yet
that
do
back
port
cleanly.
This
would
maybe
prematurely
tell
folks
that
things
don't
win.
B
Family
I
know
that
Joey
had
that
tool
that
can
kind
of
trace
the
lineage
of
a
pr2
like
say,
which
other
PRS
would
be
blocking
it.
So
like
I
guess
the
one
concern
I
would
have
with
this
tool
kind
of
running
at
time
that
the
PR
is
open
is
that
there
might
be
false
negatives
and
that
are
only
false
because
we
haven't
back
ported
other
things
yet
so.
D
D
So
like
anything
like
that,
like
I,
think
that
there's
definitely
like
a
ton
of
room
for
figuring
out
like
when
we
want
to
trigger
those
kinds
of
checks
and
what
kind
of
information
you
want
them
to
surface.
But
I
think
like
that,
would
definitely
sort
of
like
remove
a
lot
of
extra
work
from
us
of
like
having
to
audit
a
bunch
of
stuff
ourselves.
It
could
just
be
like
showing
up
in
a
check
that
says
like
here's,
the
failed
if
it
failed.
A
Sometimes
we
don't
want
it
to
land
at
all.
I
know
we
will
still
be
landing
it
manually,
but
I
guess
if
we
add
the
back
court
requested
label
or
the
board's
it
without
anyone
from
LTS.
Looking
at
it,
then
it's
an
indication
to
the
author
that
we'll
go
through
and
we'll
eventually
find
on
LTS
and
they
could
put
some
effort
into
a
back
court
for
us
to
then
look
at
and
say
hey.
We
really
don't
think
this
change
should
land
on
ten
or
twelve
or
a
previous
release
line
say
functionally.
A
C
C
And
it
could
be
that
maybe
somebody
somebody
from
the
well
the
OTS
or
release
team
would
put
put
the
label
on
to
say.
You
know
check
this
and
then
the
automation
would
go
off
and
decide
whether
it
is
bad
fault
or
not.
Now
that
that
point,
whoever
put
the
label
on
is
basically
said.
We
think
this
is
that
portable
I
guess.
The
question
then
is:
is
there
any
chance
that
we
would
want
to?
C
C
D
A
A
C
The
only
thing
I'd
say
on
that
one
was
I,
guess:
I.
Guess
it's
back
to
the
Moses
question
about
the
sort
of
access
management
versus
they.
We
have
a
team
because
it
groups
people
together
so,
for
example,
when
people
ping
the
OTS
team
in
Corps,
it's
more
yes,
sometimes
it's
a
question
about
when
things
were
going
to
a
release
and
then
sometimes
it's
a
question
of
whether
things
would
go
back
at
all.
C
And
the
question
then
is
you
know:
is
that
a
discussion
that
needs
to
happen
amongst
people
that
have
the
access
rights
to
landings
and
branches,
or
is
that
we
have
a
group
that's
wider
than
that?
That
would
be
able
to
respond
to
those
pings.
You
know
basically
making
decisions
and
it
comes
back
to
what
we
want
the
group
to
be
able
to
do
you
know:
do
we
want
to
allow
make
it
easier
for
people
to
join
the
group,
but
not
necessarily
be
landing
back
ports
or
making
releases?
C
So,
for
example,
you
know
do
you
have
to
be?
We
do
one
of
those
two
things
in
order
to
be
an
active
participant
in
this
working
group,
or
is
it
that
the
working
group
is
only
for
people
that
land
things
in
in
you
know
in
in
the
back
in
the
stage'
branches,
for
the
releases
or
doing
the
releases
themselves?
I
think.
B
B
Maybe
maybe
the
real
thing
to
do
here
is
just
have
release
and
these
other
subgroups
and
not
even
have
release
members.
If
we're
trying
to
not
like
over
engineer
the
membership
structure
here
and
have
those
subgroups
just
be
how
we
manage
the
I
am,
but
not
really
have
anything
to
do
too
much
with
membership.
I
think,
maybe
the
other
thing
that
we
need
to
figure
out
if
we
distinguish
you
know
like
a
difference
between
release
and
LTS.
B
Would
kind
of
imagine,
though,
that
like
if
we
had
a
group
called
LTS,
the
anyone
who
was
a
part
of
that
group
would
in
fury
be
involved
enough
to
have
permission,
especially
if
we
made
release
a
broader
thing
that
anyone
can
be
involved
in
an
LTS
would
be
a
portion
of
the
responsibility
of
release,
but
I'm
definitely
already
overthinking
this
and
very
open
and
amenable
to
a
simpler
approach.
I
mean.
C
B
C
Especially
for
release
in
particular,
I
can
see
there
being
a
group
of
vested
people
that
would
be
interested
in
things
going
in
to
release,
but
not
necessarily
doing
the
releases
identify
make
sense
like
so
people
that
might
want
to
monitor
discussions
about
things
that
potentially
go
into
LTS
releases
and
what
might
have
a
valid
opinion
as
to
whether
something
should
or
should
not
go
in.
You
know,
based
on
this
ability
criteria,
but
you
know
I
mean
having
permissions
to
even
even
even
that
stuff.
We
were
talking
right,
beginning
about
linings
back
ports.
C
That
is
a
bar
to
entry.
Because
of
that
kind
of
implies.
You
have
to
be
a
collaborator
to
start
with
in
order
to
make
Co
changes
to
call,
whereas
you
know
III
do
think
we,
we
can
open
up
discussions
about
whether
things
should
land
or
not
in
a
particular
release
line.
So
you
know
as
many
people
as
want
to
do
participate
so.
B
I
guess
then,
maybe
the
difference
here.
There
then
would
be
like
this
sounds
like
a
consensus
problem
more
so
than
anything
else
and
historically
I
guess
for
lack
of
a
better
way
of
framing
it.
Lts
has
kind
of
operated
as
like
a
be
DFL
model,
with
like
a
handful
of
benevolent
dictators,
as
opposed
to
like
consensus,
seeking
in
the
same
way
that
that
things
work
I
guess
we
still
do
reach
consensus
between
the
smaller
group
of
collaborators,
though,
but
that's
alright.
B
My
brain
is
connected
directly
to
my
mouth,
so
apologize
for
the
word
vomit,
but
I
guess,
like
part
of
what
I'm
thinking
about
right
now
is
like
they're,
even
value
at
this
point
anymore,
in
distinguishing
between
release
and
LTS,
and
perhaps
what
we
want
is
actually
to
keep
back
quarters
or
keep
some
sort
of
idea
of
the
permission
of
like
who
who
gets
to
land
the
thing.
Okay,
I'm.
Stepping
back
for
a
second
I
think
there's
two
different
things
that
I'm
talking
about
at
the
same
time.
B
Darcy
mentions
DEP
updates
here,
for
example,
but
like
how
do
we
make
it
feel
or
make
it
be?
Not
just
feel
that
the
discussions
are
open.
Well,
we
still
have
a
smaller
group
of
people
who
eventually
make
the
decision,
because
that
isn't
really
consensus,
but
maybe
it
is
if
we're
just
saying
that,
like
anyone
can
object
and
there's
a
larger
group,
then,
like
you
know,
those
who
have
a
little
bit
more
understanding
may
object,
but
the
flipside
would
be
is
like
if
we
made.
B
If
the
current
group
of
people
who
are
part
of
the
LTS
team
made
a
decision
about
what
lands
on
an
LCS
branch
I
mean
historically
I
guess
we
haven't
had
too
many
people
object
to
that,
but
like
as
it
is
set
up
right
now.
Other
members
of
release
at
at-large
wouldn't
really
be
able
to
object
to
those
decisions,
so
maybe
at
the
core
of
what
we're
trying
to
figure
out
here
is
like
what
is
what
is
the
decision-making
model
and
especially
I?
B
Think
since
when
we're
auditing
and
creating
an
LPS
branch
and
I,
maybe
Shelley
and
Beth,
can
speak
more
directly
to
this.
We
really
are
kind
of
acting
like
benevolent
to
the
branch
at
the
time
that
we're
doing
it
we're
not
really
asking
permission
of
other
people
we're
putting
together
what
we
think
to
be
right
and
then,
like
we,
we
probably
publish
the
proposal
now.
B
But
to
me
I
guess
I
would
I
would
want
to
figure
out
like
Richard.
It
seems
like
you're
asking
for
a
way
to
make
people
feel
more
empowered
to
as
part
of
the
decision-making
process
which
I
am
all
for,
but
I
want
to
figure
out
a
way
that
we
do
that
without
hurting
the
velocity
that
we
currently
have,
because
we
arguably
already
have
a
velocity
problem
and
I'm.
Assuming
that
you
want
to
improve
velocity
with
these
changes,
because
you
know
that's
what
we
all
want
to
see
happen
ya.
C
Know,
to
be
honest,
I'm
a
little
bit
a
little
bit,
I
guess
looking
at
it
from
sort
of
more
personal
lens,
whereas
you
know
it's
great.
That
I
now
have
that
nomination
to
join
the
backported
in,
but
up
until
now,
I
don't
I
haven't
had
that
and
yet
I
have
been
more
or
less
responding
to
OTS
pings
in
corps.
So
so
from
that
respect
you
know
I
had
been
participating
in
LTS
discussions,
even
though
technically
speaking,
I
do
not
have
currently
any
powers
to
land
anything
on
either
the
staging
branches
automate
releases.
C
So
I
don't
know.
Maybe
there
aren't
that
many
people
in
my
situation,
but
then,
given
the
number
of
people
in
the
current
LTS
group
that
aren't
releasing
I
guess
the
question
is:
why
did
they
join
that
group
in
the
first
place,
because
you
know
that
that
was
a
yeah
by
invitation
knowing
but
people
volunteered
to
join
that
group
they
weren't
just
thrown
into
it,
and
you
know,
people
that
they
might
circus.
That
just
may
have
changed
now
that
they're
happy
to
be
removed
from
that
group.
B
B
B
In
impact
with
without
authority,
it
has
kind
of
historically
been
how
this
group
has
operated.
So,
if
we're
better
or
for
worse,
the
pattern
that
you've
identified
here,
that
yourself
have
kind
of
been
doing
the
work,
but
didn't
really
have
the
authority
or
permission
to
do
it.
It's
very
much
the
way
that
this
group
is
kind
of
operated
historically
and
then
only
kind
of
in
like
oh
yeah.
B
C
I
mean
it
might
be
the
discussion
we're
having
on
new
to
anyway,
because
it's
realizing
people
volunteering
to
join
the
group
and
I
think
that's
been
a
challenge
not
just
for
this
working
group
to
get
people
to
volunteer
and
part
of
that
is
the
you
know,
barrier
to
entry,
and
you
know
for
good
reason.
We
don't
want
to
let
anyone
just
start
doing
releases,
but
on
the
other
hand,
there
needs
to
be
a
way
to
sort
of
ease
them
into
the
group.
A
Okay,
I
will,
where
absent
like
conversation
to
the
minutes,
as
people
may
wish
to
comment
on
those
I
just
hop
back
to
the
other
issues
so
days
with
the
kind
of
three
at
the
top
of
our
list.
I
did
raise
an
issue
for
creating
off-boarding
documentation,
slash
policy,
and
this
is
when
Jeremiah
left
and
we
realized.
We
didn't
actually
have
the
process
document
it.
So
that's
an
issue
that
we
should
probably
take
a
look
at
at
some
point.
It
should
be
relatively
straightforward.
A
Don't
think
there's
anything
new
one
thing,
I
kind
of
mentioned
is
doing
it
for
neon
scene,
but
they
call
you
tools
has
an
option
for
landing
back
ports,
so
you
can
do
get
note,
land
back
port
and
it
will
automatically
insert
the
back
port.
Our
URL
people
feel
free
to
play
with
that
to
try
and
land
back
ports
because
then,
if
there
are
any
bugs,
because
it's
quite
a
new
feature,
we
will
see
them
and
I
think
Shelley.
A
D
Yes,
so
I
found
some
time
a
little
bit
recently
and
open
up
a
PR
that
handles
the
preparation
step
for
releases
in
like
a
more
automated
fashion.
That
works
in
like
a
pretty
similar
ways.
A
lot
of
new
creative
stuff
does
where
it's
like.
It
prompts
you
and
like
a
sphere
confirmation
for
certain
things,
but
otherwise
like
abstract,
so
a
most
bits
are
releasing
like
or
their
preparation
stuff
like
creating
the
changelog
automatically
and
the
other
things.
So
I
would
love
some
more
eyes
on
that,
because
I
would
love
to
get
a.
D
The
only
part
of
it
right
now,
that's
like
not
100%
working
well,
not
working
I
guess,
but
it's
like
the
changelog
doesn't
the
charge.
A
slug
maker
doesn't
really
have
a
great
option
for
formatting
little
changes
in
like
a
plain
text
way.
So
it's
a
little
bit
difficult
right
now
to
automate
creating
the
release
to
it
beyond
making
it
like
a
little.
B
D
Cool
yeah,
and
that
sounds
like
please
I
mean
feel
free
to
you,
know,
review
it
and
like
it's
definitely
like
if,
like
I
said
at
Hallows
known
for
you
to
a
format.
But
it's
definitely
like.
If
there's
things
you
find
like
annoying
or
like
could
be
more
less
require
more
or
less
like
human
confirmation
and
prompting
like.
Please
feel
free
to
and
put.
A
Awesome
I'll
give
it
a
try
and
yeah,
so
I
think
we've
covered
it.
We
covered
everything
on
the
agenda
and
had
some
discussions
I'm
just
looking
at
the
release
schedule
just
overview.
The
next
release
is
jus
next
week,
4:30
so
probably
1312
next
week
and
Reubens
got
his
name
against
that
one
and
for
no
12,
where.
D
A
4:10,
oh,
this
is
probably
something
worth
mentioning:
the
last
7
4
minor
of
10
and
the
release
date
for
the
17th.
The
proposal
PR
is
open
and
I
think
it's
got
pretty
much
everything.
That's
gonna
go
out
with
it
in
there
it's
only
like
35
commits,
but
it'd
probably
be
the
last
chance
to
get
new
features.
C
Think
I
should
probably
mention
from
the
build
working
group
perspective.
I
think
we
are
ready
to
start
rolling
out
notarization
for
Catalina
for
a
10,
Mac,
OS,
10,
15,
so
I
think
rod
is
aiming
for
the
next
13
releases.
The
one
next
week
to
be
the
first
released
of
it
would
have
killed
on
the
new
1015
max.
A
C
We've
had
we
have
had
to
butter
to
bump
the
in
order
to
do
the
notarization.
We
need
to
release
an
Anu
and
that
Vince
I
think
the
current
race
is
run.
Ten
eleven
of
Mac
OS
and
with
with
hats,
boots
bump
to
at
least
ten
fourteen.
So
we've
got
ten
fifteen
and
the
release
CI
and
that
that
will
be
the
new
release
machine,
but
we're
rolling
that
out
gradually
so
13
will
be
first.