►
From YouTube: SIG Release 20180731
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
All
right
welcome
everyone.
It
is
Tuesday
July,
31st
2018.
This
is
the
kubernetes
cig
release
bi-weekly
meeting
I.
Am
your
chair
person,
Jason,
singer,
Dumars
I
worked
at
Google
and
your
other
co-chair
of
Caleb
miles
could
not
make
it
so
I'll
be
running
this
meeting.
If
you
want
to
follow
the
agenda
after
the
fact,
I
usually
have
a
great
bitly
for
it,
but
I
don't
know
what
the
one
is
for
this,
so
I'll
try
and
fit
that
and
post
it
in
the
slack
channel.
A
The
full
link
is
available
in
the
psych
channel
as
needed,
and
also
in
the
chat
so
without
further
ado.
We're
gonna
go
ahead
and
get
started
on
the
agenda.
First
thing
is
that
we
need
to
talk
about
the
cig
release
charter
so
tears,
because
the
one
we
have
is
not
in
the
new
template
format.
So
we
need
to
go
through
and
do
a
diff
and
get
that
sorted
out.
So
I
believe
we
need
to
get
some
volunteers
on
that
to
to
work
on
that.
So
anybody
feeling
particularly
excited
about
this
I
know
Steven.
B
So
myself
and
Tim
volunteer
at
the
first
time
around
I
just
have
not
gotten
to
actually
copy
and
pasting
a
bunch
of
the
stuff
if
someone
wants
to
take
it
up.
Instead,
a
lot
of
the
information
that
is
in
the
readme
for
the
release
team
in
sick
relief
is
pretty
accurate
and
kind
of
just
defines.
What's
in
scope
for
not
just
the
sick
release,
release
team
read
me
but
simulates
readme
itself,
so
I'll
post
that
hold
on
as.
C
A
steering
committee
member,
although
I,
forget,
if
I,
actually
signed
up
to
review
your
thing
or
not
I,
will
tell
you
like
we
don't.
We
don't
necessarily
want
to
spend
a
ton
of
time
reading
a
lot
of
really
detailed
stuff
either.
The
thing
that
makes
makes
our
lives
easier
stand.
The
reason
we
have
this
sort
of
newer,
shorter
template
is
we
really
kind
of
want
to
focus
on?
C
What's
your
scope
and
make
sure
we
have
the
right
boundaries
and
six-four
scope
like
if
you're
going
to
go
through
the
process
of
saying
that
all
the
different
release
team
roles
happen
to
be
part
of
your
sakes
governance.
That
sounds
like
it's
going
overboard
to
me,
but
if
you
consider
like
the
release,
team
effort
is
a
sub
project
of
the
releasing.
That
seems
a
little
more
appropriate
yeah.
B
A
D
I,
don't
know
if
you're
taking
a
call
for
volunteers,
you're,
honest
put
our
names
there.
What
I'm
willing
to
to
stay
involved
I've
had
quite
a
few
things.
Come
up
the
last
few
weeks
where
somebody's
ping
me
and
said:
hey,
you
need
to
do
X
and
I
sort
of
said
well,
I'll
bring
that
up
in
the
sig
release
meeting,
because
it's
clearly
under
the
Charter
of
sig
release,
but
I,
don't
think
it
falls
quite
under
my
purview
for
the
112
release.
D
A
I
would
love
for
you
to
be
involved
in
that
I'm
gonna
go
and
put
my
name
on
that
list
as
well,
because
I
I've
already
done
all
the
meta
issues
for
the
steering
committee
on
on
those
things.
So
I've
been
staring
at
a
lot
of
these
things
and
doing
a
lot
of
thinking
about
ways
that
we
can
sort
of
pare
this
down.
A
I
think
something
Erin
mentioned
is
really
true
is
that
we
want
to
have
it
succinct
enough
that
somebody
can
quickly
understand
what
our
governance
model
is
and
and
doesn't
need
to
go
into
the
gory
details,
but
on
the
other
hand,
the
the
sort
of
rule
of
law
of
the
project
is
that
the
string
Committee
owns
all
power
of
the
project,
except
that
which
it
explicitly
delegates.
So
the
sig
charter
is
a
way
in
which
part
of
that
power
is
delegated
out.
So
we
need
to
be
mindful
of
that.
C
A
E
Thanks
for
having
me
so
with
the
recent
spam
attacks
on
the
users
list
and
stuff
Trebek's
is
looking
to
close
it
down
and
we
certainly
think
about
different
ways
to
automate
stuff
and
I
notice.
When
we
do
release
updates,
you
guys
posted
the
list
and
then
we
have
like
a
Twitter
thing,
and
then
we
have
like
a
slight
thing.
So
I
was
hanging
out
with
some
of
the
fellows
and
we're
like
hey.
We
should
automate
this
for
cig
release
and
make
them
love
us,
so
we've
integrated.
So
as
a
test
we
integrated.
E
If
that's,
then
that
which
is
our
third
party
service
this
just
as
a
prototype,
if
we
can
monitor
when
kubernetes
releases
things
and
then
automatically
have
that
post
on
discuss
that
IO
and
then
from
there
automatically
post
to
a
Twitter
account
that
we're
going
to
have
that's
more
contributor
related
as
opposed
end-user
related
and
then
perhaps
also
automatically
post,
that
to
the
slack
Channel
so
as
I
was
investigating.
I
also
found
that
your
release
box,
Anna
Anna
somebody
and
a
tool
sanika.
Thank
you
that
ago,
yes.
D
E
Go
has
a
little
flag
that
you
all
type
and
send
to
this
mailing
list,
so
I
was
thinking.
Is
there
a
way
that
I
can
like
tie
that
all
together
to
make
disgust,
be
the
once
or
get
how
be
the
one
source
of
truth
and
then
I?
We
Auto
generate
that
for
you
and
then
post
it
on
whatever
properties
that
you
have
but
I
don't
know
enough
about
the
release
process.
To
know
like
it's
annoying
is
it's
going
around
posting
announcements
everywhere,
like
is,
that
is
that
useful
for
you
basically
I
think.
D
It
could
be
useful,
definitely
and
it's
one
of
the
questions
in
my
mind
right
now,
so
we're
actually
going
through
today
trying
to
do
our
alpha
release
and
try
and
understand
between
two
very
old
documents.
What
the
actual
process
is
and
update
it,
and
one
of
the
the
late
gaps
clearly
are
just
having
gone
through
the
documentation
where
we're
not
quite
sure
how
it
happens,
but
that
triggering
of
events
we're
not
quite
sure
how
that
happened.
D
E
D
E
D
The
the
old
document
said
they
do
something
to
which
nobody's
quite
sure
how
to
actually
get
so
either.
There's
magic,
plumbing
and
place,
or
something
and
we'll
be
looking
to
define
that
something
and
make
it
less
magic
and
a
connection
to
discuss
would
be
awesome,
so
will
will
hopefully
be
pinging
you,
okay
this
week,
but
in
the
coming
weeks,
as
we
cycle
through
this
okay.
E
So
what
we've
done
is
because
we
need
to
make
sure
it
works,
but
I
can't
make
sure
it
works
until
you
all
actually
release
something.
Is
we
hooked
it
all
up
to
a
test
account?
So
whenever
your
release
we'll
be
able
to
look
to
see
what
it
is
and
then
we're
kind
of
in
the
process
of
screenshotting
and
documenting
things?
So,
ideally,
if
you
like
it,
I
just
want
to
turn
around
with
a
bunch
of
documented
processes
and
be
like
here.
You
go.
Okay,.
D
And
that
sounds
good
and
let
just
double
check
the
safety
net
so
say
say,
say
we
we
iterate
and
accidentally
make
a
couple
of
alphas
today.
Are
you
gonna
automatically
start
sending
out
announcements?
The
other
would
just
your
little
test
account
to
see
no.
E
Just
let
you
know
is
we
can
tie
in
other
releases
from
around
the
ecosystem,
so
we'll
be
able
to
give
users
not
just
a
cool,
so
they'll
be
able
to
subscribe
only
the
core
releases
if
they
want
or
if
they
want
related
tools
like
they'll,
be
able
to
and
I
I,
don't
know
that
will
give
users
nothing
more
granularity
than
just
like
signing
up
to
an
announce
list
or
individual
project
lists,
but
we'll
see
how
that
goes.
I
just
wanted
to
run
the
idea
by
you.
A
E
A
Alright,
let's
move
to
features
process,
reboots,
P
tau,
so
basically
there's
a
few
bullet
points
in
here,
but
basically
Steven,
Augustus
and
myself
have
been
revisiting
the
features
process.
Yet
again
we
had
a
meeting
with
sig
p.m.
this
morning
to
kind
of
get
people
who
will
get
it
and
we're
gonna
try
and
schedule
a
working
session
and
maybe
get
some
more
eyes
on
this,
but
essentially
trying
to
solve
for
this.
A
This
problem
we
have
about
too
many
things
in
distributed
places
and
things
not
tying
back
to
caps
and
all
the
stuff
that
I've
railed
endlessly
on
about,
and
basically
Steven
has
some
ideas
about
automation,
I,
have
some
ideas
about
process
and
hopefully,
in
the
middle,
we'll
find
a
way
to
tie
all
those
things
together.
So
what
I
did
was
post
a
link
in
the
agenda
to
the
two
different
proposals
and
basically
would
ask
people
to
take
a
look.
A
A
B
Hey
yeah,
so
the
the
general
overarching
feel
is
processed
bad
right
now,
let's
fix
process,
but
shifting
that
process
requires
I
mean
one.
There
are
some
some
churn
as
Tim
was
mentioning
in
the
previous
meeting
around
deciding
where
to
go
and
how
quickly
we
can
go,
and
if
we
choose
one
thing,
how
long
it'll
take
to
try
to
shift
into
a
different
process,
so
I
would
say
my
my
proposal
is
heavily
around.
How
can
we
fix
near-term?
B
Sorry
for
the
slack
things?
So
how
can
we
fix
near-term
by
putting
essentially
a
set
of
features,
triage
labels
around
the
the
key
features
and
Kay
Kay
Kay
time
feature
issues
and
jaysis
proposal
is
definitely
more
top-level.
How
do
we
do
this
on
a
policy
basis
figuring
out
how
to
one
drive
adoption
into
grading
caps
tie
those
caps
into
actual
trackable
units
of
work
across
the
release
cycles
and
mostly
have
a
have
a
means
of
visibility,
one
for
the
the
release
team,
the
marketing
team
and,
and
the
sake
sake
leadership
essentially
across
the
release
cycle.
B
B
C
Oh
host
disabled
screen,
sharing
great
I'm
going,
could
share
some
really
violent
stuff
here.
I
think
I
have
all
the
the
necessary
links
in
the
notes
anyway.
So
basically
the
milestone
re
so
talk
level.
I
want
munchkin
up
to
go
away
forever
and
ever
there
are
three
big
things
that
are
in
my
way
for
that
one:
the
milestone
maintainer
muncher
to
the
cherry-pick
stuff:
three,
this
admit
queue.
The
submit
queue
is
being
worked
on.
Let's
not
talk
about
that!
Cherry-Pick
I.
C
If
we
have
time
at
the
end
of
the
meeting,
I
can
talk
about
that
milestone,
maintainer,
milestone.
Maintainer.
Is
this
thing
that
sweeps
around
like
every
day
and
checks?
Whether
or
not
your
issue
has
won
one
of
three
kind
labels
to
one
of
four
different
priority
labels?
No
sorry,
three
different
priority
labels,
three
any
sync
label,
and
then,
after
some
amount
of
time
it
will
remove
the
issue
from
the
currently
configured
milestone.
C
If
those
criteria
aren't
set,
then
once
you
flip
a
flag
and
we
redeploy
Munch
github,
it
starts
yelling
at
you.
If
there's
no
status
approved
for
milestone
label
and
then
I
think
when
we
flip
another
flag,
it
starts
yelling
you
if
there
isn't
also
a
status
in
progress
label,
it
will
also
post
comments
if
all
of
those
criteria
are
satisfied,
hopefully
letting
you
know
that
it
has
swept
through
all
of
the
issues
that
you
could
potentially
receive
notifications
for
and
checked
them
and
sent
you
a
bunch
of
notifications
about
that.
C
Please
stop
me
if
I'm
like
mischaracterizing
the
way
that
it's
Bam's
but
I,
think
that's
that's.
The
level
of
spam
I've
heard
frustrations
about
okay.
So
why
did
we
have
all
this
status
stuff
in
place
like
what's
the
deal
with
that
so
way,
back,
I?
Think
in
the
1
7
release
timeframe,
whenever
Don
Chen
was
leading
the
release
process,
we
had
this
problem
where
people
would
sneak
their
code
into
the
milestone
without
anybody
really
noticing,
because
a
lot
of
developers
did
and
still
do
have
direct
right
access
to
the
repo.
C
So
those
privileged
few
who
have
Directorate
access
to
the
repo
can
just
pings
at
the
milestone
on
their
pull
request,
and
then
it
would
kind
of
slip
on
by
so
we
added
the
ability
to
gate
pull
requests
from
merging
unless
they
also
have
this
status
label
that
was
going
to
be
gated
on
membership
of
a
much
smaller
group.
The
milestone
maintainer
groups
that
I
think
we're
gonna
have
a
discussion
about
that's
actually
what
that
group
was
for
originally
was
to
help
maintain
all
those
status
labels.
C
Today
we
have
a
milestone
command,
so
people
can
add
the
milestone
without
being
a
member
without
having
direct,
write
access
to
the
repo
and
that
milestone
command
is
in
fact
gated
to
the
same
group,
but
people
could
still
like
sneak
their
milestone
so
conceivably.
We
might
still
want
that
status
label
as
that
extra
gate,
or
that
extra
check
that
people
aren't
sneaking
their
work
into
the
milestone
during
code
slush
and
during
code.
Freeze,
we're
trying
to
be
really
mindful
of
what
code
is
in
there
personally
I
think.
All
the
status
stuff
is
way
too
much.
D
C
For
it
to
go
away
entirely,
but
that's
that's
just
my
thing
and
honestly
I
think
the
whole
milestone
maintainer
thing
was
a
ton
of
noise
and
I'm,
not
sure
how
helpful
it's
been
like
going
through
and
reading
the
issue.
Triage
handbook
I've
seen
that
the
issue
triage
person
seems
to
be
running
queries
themselves
manually
to
go
check
for
issues
that
have
all
the
labels,
issues
that
might
have
been
kicked
out
accidentally
issues
that
might
need
some
of
the
labels,
and
so
it's
unclear
to
me
what
value
the
bots,
providing
and
I
just
wanted
to
have.
C
Okay,
so
to
sum
up,
I
think
what
I
see
you're
useful
functionality
as
you've
liked
that,
if
those
three
label
criteria
that
I
laid
out
at
the
beginning,
trying
to
prioritise
sake,
aren't
met
within
a
certain
time
within
a
certain
interval
that
the
issue
is
removed
from
the
milestone
yeah.
That's
the
only
thing
you
like
about
it.
C
D
Other
thing
that
I
like
that
it
does
is
it
has
a
time
lag,
so
there's
a
grace
period,
the
not
that
the
nags
are
proving
effective,
but
the
idea
that
hey
we're
pinging
for
some
more
information
because
we
genuinely
want
it.
We
don't
our
goal,
isn't
just
to
remove
things
from
the
milestone
so
that
that
feedback
loop
is
still
something
that
I
would
be
looking
to
enable.
D
There's
this
huge
document
that
describes
it,
but
the
the
code
basically
goes
through
at
a
certain
interval
scanning
and
then
based
on
things
that
are
found
to
not
be
matching
whatever.
The
current
criteria
is
for
the
phase
of
the
process
weights
anywhere
from
24
a
day
to
seven
days
before
it
ejects
the
issue.
C
D
C
So
I
think
I
could
simplify
those
rules
like
here's
an
example
of
a
simplification
of
those
rules
that
we
could
put
in
place
today,
the
same
commenter
there's
a
like
a
comment
or
utility.
We
right
that
you
give
it
a
github
query
and
then
you
give
it
an
updated
threshold
so
time
since
the
thing
was
last
touched
by
a
human
being,
and
then
you
give
it
a
comment,
template
and
that's
what
we
use
to
implement.
That's
what
fada
bot
is
like.
C
Maybe
I,
don't
know
this
I'm
an
engineer.
So
I
don't
know,
but
it
seems
a
lot
more
clear
and
intuitive
to
me
if
you're,
just
looking
at
what
looked
kind
of
like
cron
jobs
with
github
issue,
queries
that
I
can
run
myself
to
see.
When
does
this
run
and
how
long
do
I
have
before
it
gets
kicked
out
now,
admittedly,
to
Tim's
point
about
these
thresholds,
changing
during
different
phases
of
the
release
cycle
like
you
would
have
to
change.
F
A
A
I'm
gonna
make
some
observations
that
I
that
are
dismal
my
POV
issues
in
the
milestone,
don't
matter
Intel
code
freeze
period,
there's
no,
there's
no
reason
to
know
the
the
whole
reason
that
we
have
an
issue
in
the
milestone
at
all
is
to
purely
know.
Is
there
something
that
is
a
known
defect
that
is
targeted
for
release
in
that
milestone,
that
we
need
to
either
remediate
document
or
or
or
I?
Guess
those
two
things
either
immediate
fix
it?
A
It's
fixed,
or
it's
documented
as
a
known
bug
and
is
gonna,
be
fixed
in
a
point
release
like
literally
that's
the
use
case,
and
so
the
whole
the
whole
rigmarole
around
this
ahead
of
code
freeze
is
relatively
pointless.
Now
what
happens
is
that
the
fire
drill
starts
when
code
freeze
happens,
there's
an
issue,
we
don't
know
if
it's
actually
release
impacting
or
if
it's
a
flake
or
some
other
thing,
and
then
we
have
to
figure
out
how
to
chase
it
down
who
owns
it.
A
What
is
the
deal
with
this
thing
like
that
whole
that
whole
process
of
trying
to
find
that
begins
with
the
cig
label?
It
begins
with
a
priority,
so
hopefully
it's
been
classified
as
a
priority.
That
indicates
the
true
impact
on
the
release,
because
that's
really
what
the
priority
is
all
about,
and
then
hopefully,
somebody's
commenting
and
I
and
making
people
know
that
it's
actually
being
worked
right.
So
we
want
to
understand:
is
it
real
or
not?
Yes,
no
is
it
in
the
milestone?
Yes,
no
is
it
going
to
be
fixed
before
the
release?
A
If
it's
impacting
and
not
able
to
be
shunted
with
a
release
flag,
so
they're,
there
I
think
that
if
we
reverse
engineer
the
process
to
say
what
are
we
trying
to
accomplish,
then
that
drives
out
the
requirements
of
the
bot
a
lot
more
clearly
than
trying
to
say:
where
should
we
go
with
the
bot
we
have,
if
that
makes
sense.
So
that's
my
that's.
My
two
cents
I
mean.
F
C
A
A
F
C
This
is
this
is
why
I'm
just
telling
you
like
I,
went
into
the
code
and
I
was
like
it's
weird:
how
this
doesn't
seem
to
be
the
reasoning
behind
it,
isn't
in
the
code
and
I
wanted
to
have
a
discussion
with
folks
who
done
this
before,
because
I'm
not
sure
I
could
find
three
different
documents
of
the
truth.
Yeah.
A
No,
that's,
it
should
mean
again
going
back
to
the
spirit,
all
job
one.
We
have
one
job,
let's
not
release
it,
kubernetes
with
known
defects,
so
we
could
have
caught
if
we
just
saw
an
issue
that
documented
that
thing
and
let
us
know
what
it
was.
That's
the
thing
is
that
these
these
issues
are
like
they're
like
a
map,
a
treasure
map
with,
except
instead
of
treasure,
its
land
mines.
So
we
need
to
make
sure
that
we're
not
releasing
a
version
of
communities
that
has
known
defects
in
it
that
have
could
have
been
avoided.
C
D
Write
the
overall
release
team
process
is
trying
to
do
everything
that
the
bot
does
is
well,
but
manually
so
I
can
and
the
to
feel
redundant
and
if
I
were
to
go
with
one
option
of
manual
versus
automated
I
would
buy
us
automated.
But
in
this
case
the
way
it's
noisy,
it's
proved
to
us
that
it's
not
effective
and
that
the
human
one
on
one
way
gives
you
a
lot
more
effectiveness,
because
each
one
can
be
its
own
snowflake
and
you
have
to
figure
out
and
do
some
assessing
and
mental
exercise
there
anyway.
C
But
so
that's
I
think
that's
in
the
context
of
issues
and
I
know
chase
has
a
bunch
more
loaded
up
on
PRS,
but
yes,
I,
agree.
I
feel
like
the
issue.
Triage
playbook
is
basically
a
list
of
queries.
You
click
and
you
run
through
every
day
as
a
human
which
is
kind
of
what
the
bots
going
to
alright
tears.
A
So
PRS
I
believe
firmly
every
PR
that
goes
into
a
release
should
have
a
milestone
attached
from
the
get
because
otherwise
we
have
no
idea
what
things
are
and
there's
no
good
way
to
actually
see
that.
So,
starting
with
that,
as
principle
number
one,
that
milestone
should
only
be
applied
by
somebody
with
the
powers
of
the
cig
and
or
owners
or
whoever.
Whoever
is
qualified
to
say
that
and.
A
I,
it's
a
little
bit
weird,
because
if
it
gets
merged
to
master,
then
it's
there
go
it's
in
the
release,
whatever
the
next
one
is,
so
that
could
be
automated
just
by
date.
So,
basically,
we
have
a
start
date
of
the
release
which
we
call
out
anyway,
but
don't
actually
enforce
and
basically
say
that
all
PR
is
after
X
date
sees
the
cease
being
the
prior
milestone
and
become
the
next
or
whatever
that
is
but
bottom
line
is.
F
B
People
do
so
I
mean
it
on
the
top
level.
It
sounds
like
we
need
a
you
know,
a
behavior
change
right.
So
it's
it's
not
just
it's
not
just
a
label
fixing
it's
not,
and
it's
not
just
the
rushing
towards
code
slush
and
code
freeze
around
making
sure
that
the
labels
are
set
properly.
It's
making
sure
the
labels
are
set
properly
all
the
time.
B
A
Me
tell
you
a
little
story
about
PRS
I've
seen
go
through
to
people
get
in
a
room,
and
one
of
them
has
merge
privileges
or
right
privileges,
like
literally
there
are
people
putting
stuff
in
all
the
time
with
extremely
low
or
no
visibility.
People
there's
no
enforcement
on
the
approve,
lgt
em,
coming
from
different
person.
C
C
A
What
I'm
saying
is
that
the
the
whole
like
just
like
your
average
startup
environment,
if
somebody
just
goes
in
and
starts
mucking
with
master
and
men,
doing
like
one
reviewer
type
merges
and
if
they're
over
a
size
small
that
that's
a
huge
red
flag,
that's
like
that
is
that
is
not
acceptable.
That's
I,
don't
think,
there's
any
place
that
has
a
large
code
base
that
has
that
kind
of
acceptability.
Some
nice
person
I
look.
F
And,
and
usually
when
that
happens,
those
PRS
also
lack
labels
and
release
notes.
So
that's
number
one
and
then
number
two
we
see
in
the
release
team.
All
the
time
is
the
release
notes
person
having
to
spend
a
lot
of
extra
effort
tracking
stuff
down
that
should
have
been
in
the
PR
in
the
first
place,.
C
Yeah
I,
just
requiring
milestones
up
front
so
requiring
a
milestone
up
front,
sounds
an
awful
lot
like
what
we
tried
to
do
way
back
when
we
required
an
issue
to
be
linked
in
the
pull
request
description,
which
was
something
that
there
was
much
wailing
and
gnashing
of
teeth
until
we
couldn't
find
a
way
to
just
work
around
that
with
approve
no
issue,
because
ain't
got
no
time
to
file
an
issue
right
like
why
so
much
friction
like
so.
If
I
find.
B
F
C
Right,
but
it
just
sounds
like
you're
telling
me
that
from
now
on
forever
and
ever
I'm
always
gonna
have
to
go
find
a
third
person
on
top
of
bugging.
My
reviewer
in
my
approver
I'm
gonna
have
to
go
bug
somebody
else
from
a
sig
in
order
to
make
sure
they
apply
yet
another
label
to
my
pull
request.
Well,.
A
The
suggest
apply
or
the
sick
label
has
to
be
applied
anyway,
so
the
so
in
PR
is
the
the
the
milestone
label
is
not
precious
in
issues.
It
is
because
it
indicates
a
potential
red
red
flag
for
a
release
that
they're
totally
different
purposes.
The
the
the
milestone
integral
in
the
PR
is
to
say
this
code
will
be
released
in
this
version
in
the
issue.
It
says
this
issue
pertains
to
this
version,
so
totally
different
use
cases
for
one.
C
Okay,
I
I
see
your
point
on
that.
The
the
get
nerd
in
me
says
well
sure
you
can
take
that
and
you
can
compare
it
to
the
range
of
commits
from
before
the
last
milestone
before
the
last
release
was
cut
and
the
current
release
was
cut
and
every
commit
in
there.
You
know
that's
in
this
thing,
but
that's
not
I'm
clicking
on
a
pull
request
and
I
see
the
milestone
signified
in
there,
and
that
I
agree
is
something
that
automation
could
automatically
help
with
yeah.
A
F
Well,
the
milestone
the
mouse
went
under
once
we're
in
code
freeze
and
maybe
encode
slash.
It
requires
the
approved
for
milestone,
labeled,
the
saddest
thing
which
I
would
like
to
get
rid
of,
and
do
some
other
way,
okay,
the
because
just
because
for
one
thing,
when
you
actually
look
at
it,
the
idea
that,
for
three
weeks
out
of
the
cycle,
we're
going
to
acquire
a
proof
for
milestone
when
we
don't
require
it
at
any
other
time.
F
A
C
Yeah
I
think
that's
what
the
milestone
you
originally
like
in
code.
Freeze,
the
milestone
is
the
thing
that
says.
Yes,
we
want
this
to
go
into
milestone
as
part
of
a
pull
request.
Right
code
freeze
is
literally
not
merging
anything
unless
it
into
master
unless
it
has
a
milestone
applied,
and
so
it
used
to
be
that
we
were
using
presence
of
a
milestone
as
a
gating
factor
and
the
reason
we
added
the
additional
status
label
was
because
any
old
Joker
was
right.
C
D
B
Yeah
Jace
is
shaking
his
head.
Minds
does
somewhat
of
a
triage
process
right,
so
the
idea
would
be
feature
is
well.
Let
me
maybe
pull
it
up.
The
idea
is
like
a
feature
is
rather
PR
submitted.
It's
marked
as
if
it's
marked
this
kind
feature
or
somesuch,
then
a
bot
comes
by
and
is
hey.
This
needs
triage
right
from
that
point.
B
C
D
I'm
really
curious
to
see
that
and-
and
it's
also
I
say
I-
throw
future
branch
out.
There
is
a
phrase
because
people
have
heard
that,
but
just
branches
and
branches
it
doesn't
rain.
Sic
Fuu
is
letting
me
as
a
release,
lead
now
we're
ready
to
merge
our
current
work
in
a
week's
worth
of
chunk.
Thor
we've
gone
and
approved,
and
it's
a
sane
set
of
stuff.
It
passes
test
as
opposed
to
having
to
affirm
every
single
feature.
The
onus
is
on
them
to
choose
what
they
pull
into
their
branch
and
whatever
workflow
they
have.
C
That
starts
to
look
a
lot
more,
like
the
lieutenant
model
that
you
know.
Other
larger
open-source
projects
have
used
in
the
past,
but
so
try
not
to
boil
the
ocean
I
definitely
recognize.
There
are
a
lot
of
ongoing
unsolved
problems,
but
I
think
really
Tim.
You
have
the
final
say
since
you
are.
The
current
release
lead
I'm,
proposing
that
we
just
turn
off
the
milestone.
Munder
entirely.
Are
you?
Okay,
with
that
I.
D
Am
okay
with
it
yeah
I
think
that
the
the
point
of
I
really
view
the
release
team
as
a
set
of
people
who
are
doing
that
risk
management
and
the
the
anecdotal
sense
I
get
and
from
others
as
well.
I
feel
like
is
that
that
nagging
just
hasn't
worked,
I,
don't
know,
but
maybe
maybe
it's
another
release,
wiru
the
choice,
but
I
I
don't
feel
like
I'm,
seeing
what
we
would
miss
from
turning
it
off.
D
A
My
ask
is
a
stakeholder
in
this
is,
if
we
turn
it
off,
there
is
some
verbage
somewhere
that
says:
how
are
we
going
to
handle
the
specific
use
cases
of
managing
quality
from
a
from
a
PR
and
issue
standpoint
like
how
are
we,
how
are
we
managing
those
things?
What
what
is
the
actual
thing
that
happens,
because
we
can't
not
do
that?
That
is,
that
is
simply
not
an
option
that
is,
that
is
reckless,
so
so
I
would
agree
with
that.
I
mean
to
me,
it's
like
are.
C
F
A
So
as
a
thought
experiment,
let's
say
two
days
before
code
release
are
before
a
code:
freeze,
I
go
in
and
I
write
an
issue
that
has
no
labels,
no
milestone,
nothing
in
it,
and
it
says
my
experience
with
my
cluster
using
the
code,
as
is
from
master
I
build.
My
own
wrote
my
own,
my
own
version
tested.
It
has
a
critical
defect
that
is
going
to
you
know
some
massive
part
of
functionality
once
it's
out
what
what
is
the
process
through,
which
that
is
discovered
and
and
actually
brought
to
the
release
team's
attention
today.
A
Well,
visibility
and
is
I
mean
if
it
didn't
have
any
labels
on
it
at
all,
it
would
give
bagged,
and
once
you
start
adding
labels,
then
it
starts
becoming
more
naggy
right
because
you
so
yeah
adds
sick,
sick,
sick
foods
got
visibility
of
it.
So
sick
food
looks
at
this
thing,
I'm
like.
Oh,
that
really
is
an
issue
and
then
they
label
it.
So
it's
basically
that
first
level
of
visibility
that
you
see
so.
C
D
C
B
A
C
D
C
Sounds
like
Jase
is
talking
about
improving
our
issue:
our
label,
hygiene,
consider
label,
consistency
on
all
issues
and
all
PRS
which
I
agree.
I
want
us
to
do.
I,
don't
think
killing
the
miles
that
disabling
the
milestone
and
maintainer
prevents
us
from
doing
that,
and
I
think
that
discussion
could
be
better
served
by
fleshing
out
what
those
requirements
are,
and
then
we
probably
already
automation
that
can
get
us
most
of
the
way
there
and
if
we
can
start
by
building
what's
missing
in
the
proud
and
that
the
way
less
work
then
porting
over
the
milestone.
C
D
Well,
I
I
have
the
same
worry
because
I
part
of
what
you're
expressing
is
the
the
unknowns.
Certainly
we
don't
want
to
release
I
mean
we
individually
look
bad
for
releasing
something
that
we
knew
was
bad,
but
there
is
also
still
a
significant
gap
here
that
we
need
to
figure
out
how
to
iterate
on
to
have
less
unknowns
as
well.
Yeah.
A
Because
I
had
I'm
never
1.8,
there
was
a
Black
Swan
performance
issue,
they
came
out.
There
was
an
issue
that
was
sitting
out
there.
People
know
about
it,
but
they
didn't
raise
it.
Nobody
worked
in.
It
was
just
sitting
there
waiting
to
to
basically
torpedo
the
release,
so
those
are
the
things
that
are
that
are
scary,
okay.
So
what.
A
B
I
think
by
having
so
back
to
the
whole
requiring
a
cig
label,
if
we
can
have
some
sort
of
process,
we're
required,
like
one
it's
blocked
on
merged
with
data
sick
label
to
by
having
the
sig
label
your
also
pinging,
someone
from
the
sig
to
actually
do
a
review
on
that.
If
they're,
not
just
that
code,
section
also
a
reviewer
from
the
fake,
so.
C
That
last
part,
like
labels,
they're
paying
people,
you
have
to
trust
that
people
have
the
discipline
to
actually
go
query
for
their
label.
We've
also
tried
github
teams
which
seem
to
go
off
into
the
void
like
really,
unfortunately,
human
contacting
another
human
seems
to
be
the
only
signal.
That's
consistently
paid
attention
to
so
we'll
get
better
at
I
kind
of
wanted
to
cap
us
off
here,
because
we're
well
past
245
I
had
something
else
in
here
about
an
end-of-life
policy
for
older
release.
C
Jobs
I
wanted
to
tie
that
into
tests
in
frozen
going
responsibilities
like
how
they
already
create
release
branches.
Why
don't
we
have
them
time
it
like
delete
the
old
release
branches
at
some
time.
This
has
never
been
a
formal
policy.
It's
been
a
thing.
That's
been
done,
ad
hoc!
That's
why
I
wanted
to
get
it
documented.
If
you
have
any
objections
raised
it
in
that
issue.
C
B
Mean
I
really
good
I
I
have
very
little
skin
in
the
game
as
I.
Don't
manage
the
milestones
actively
I
kind
of
put
that
issue
up
for
just
for
review,
so
people
can
shout
out
and
we
could
collate
the
notes
somewhere
so
that
PR
will
probably
get
tossed,
but
we
should
at
least
use
it
or
toss
it
up
in
a
Google
Doc
somewhere.
So
we
can
continue
the
discussion.
B
C
Like
yeah
I
know
somewhere
down
the
line
here,
we're
getting
a
github
management
sub
project
together
as
part
of
contributor
experience
and
we're
going
to
drive
we're
going
to
have
the
ability
to
you
know,
set
up
customs
based
on
a
file
and
we're
hoping
to
see
if
we
could
use
hierarchical
teams.
So
I
could
see
a
world
where
there's
like
a
milestone,
maintainer
thing
and
then
sub
teams
under
that
for
each
different
SIG's
representative.
If
we
wanted
to
go
that
route,
so
you
knew
who
you
needed
two
things
specifically.
You
have
the
superpowers
anyway.
So.
B
A
Your
meeting
pretty
much
that
is
all
we
got
then
right.
There
was
one
more
thing
at
the
bottom:
the
doc.
Oh
wait!
That's
the
thing:
yeah,
okay,
cool,
yeah,
I
think
this
has
been
a
really
good
meeting
and
I
want
to
thank
everybody
for
having
the
discussion
around
this
stuff,
because
it's
it's
hard
because
fundamentally
we're
at
the
crux
of
developer,
workflow
and
release
sanctity
and
I
mean
we.
A
We
have
a
very
high
bar
as
far
as
the
trust
of
our
community
goes
and
I
want
to
maintain
that
so
whatever
we
do,
we
have
to
have
that
as
the
primary
concern,
because,
frankly,
if
we
release
shoddy
code
that
we
could
have
done
better
and
that
stops
being
used
out
in
the
world,
then
none
of
this
matters
we
have
essentially
torpedoed
the
project,
so
with
our
most
highest
duty,
is
to
preserve
visibility,
transparency
and
accountability
across
everything.
We
do
so
I
appreciate
everybody.