►
Description
B
B
Cool
so
we
appear
to
be
recording
I,
don't
know
who
started
that
or
maybe
this
is
set
up
to
Auto
record,
so
I
should
probably
go
ahead
and
give
the
disclaimer
that
you're
not
being
publicly
you're
being
recorded,
and
this
will
eventually
be
posted
to
YouTube
publicly.
So,
please
keep
in
mind.
We
have
a
code
of
conduct
here
at
the
where
we
again
write
kubernetes
114,
release
team
meeting.
B
B
If
you
can
go
ahead
and
add
your
name
to
the
attendees
list,
for
those
of
you
who
are-
and
if
you
have
a
physician
putting
it
there,
it
would
also
be
cool
I
figure,
since
we
are
back
from
break.
But
it's
kind
of
slow
I
know.
Traditionally
the
first
kickoff
meeting
everybody
kind
of
goes
around
and
introduces
themselves
I
figure.
B
We
can
do
a
much
longer
version
of
that
next
week
when
we
have
a
fuller
roster,
but
we
could
just
take
a
couple
minutes
now
for
folks
who
are
here
if
you're
on
the
114
or
at
least
t1
14
released,
he
yeah.
Okay,
fine
go
ahead
and
introduce
yourself
who
are
you
what
role,
what
company
time
zone
so
hi
I'm
Aaron
of
SiC
beard,
I'm,
your
release,
lead
I
work
for
Google
and
I
am
in
the
Pacific
time
zone,
I'm
going
to
hand
off
to
cons
because
in
my
screen
he's
on
the
top
left.
D
E
B
G
B
B
I
A
K
B
M
N
B
O
P
Tim
pepper,
her
of
Sig
release,
SiC,
Trebek's
and
I
think
we
need
a
sick,
Tim
there's
so
many
Tim's
victim
I
work
for
VMware,
I'm,
Pacific
time
zone
and
along
with
Alexandra,
who
is
having
mic
issues,
Patrick
release,
Co
manager
for
113,
and
we
are
looking
to
bring
that
and
to
more
of
a
team
effort
moving
forward
in
a
sustaining
way,
instead
of
one
individual
owning
patch
release
for
a
given
release
branch
for
nine
months
at
a
time.
So
that's
what
our
goal
is
for
114
to
be
patch
release
management,
team.
Q
B
So
number
of
you
have
said
you
are
not
on
there
Lee's
team
and
you
would
like
to
shadow
things
at
this
point.
I
kind
of
want
to
kick
it
over
to
Steven.
To
talk
about
this
questionnaire.
I
think
that
you
were
gonna
put
together.
Oh
CET
central-european
got
you
sorry,
that's
even
better
for
Petula's,
okay
Steven!
Do
you
wanna
talk
a
little
bit
about
this
shadow
questionnaire
that
I
think
you
and
Josh
had
been
working
on
yeah.
E
Sure
so
so
this
time
around,
we
decided
that
we
were
getting
a
lot
of
basically
the
way
that
released
team
HR
works
is
I,
put
up
a
PR
for
the
release
and
people
sign
up
for
that
and
and
then
I
kind
of
calculated.
All
the
people
who
have
signed
up
and
the
company
that
they
work
for
and
who
signed
up
when
and
we
kind
of
determined
chat
is
based
on
that.
We
decided
this
time
around.
That
we
want
to.
E
Team
role
leads
so
kind
of
firming
that
up
and
and
turning
through
the
holiday
backlog
that
will
be
out
this
week.
The
expectation
is
that
anyone
who
is
interested
in
shadowing
for
this
release
fills
out
that
survey.
Anyone
who
does
not
do
that
will
not
be
considered.
I
will
post
that,
on
the
on
the
volunteer
on
the
volunteer
issue,
that's
going
to
take
release
right
now,
as
well
as
on
ktab,
when
that's
ready,
so
I
am
hoping
to.
E
So
that
will
collating
the
survey
answers
as
well
as
having
the
release
role,
leads
kind
of
interview.
The
shadows
I'm,
not
sure
that
that's
realistic
I
think
that
maybe
we
can
move
forward
with
a
few
shadows
or
people
can
add
people.
People
could
add
their
shadows
to
their
their
roles
as
they
see
fit
and
kind
of
interview
as
I
see
fit,
but
we
have
all
the
leads
locked
in
so
I
think
I
think
it's
fine
to
roll
with
that.
In
the
meantime,.
B
Okay,
I
guess
I
can
follow
up
offline,
but
I
I
will
certainly
say
from
from
my
perspective,
I'm
looking
to
each
of
the
different
roles
to
staff
their
shadows
up.
However,
they
best
see
fit
for
people
who
are
looking
to
shadow.
The
release.
I
would
go
talk
to
those
Mitchell
role
leads
as
documented
and
released
team
link
in
the
meeting
notes.
I
can
also
paste
it
in
chat
here.
B
Because
for
me
it's
it's
about,
you
might
be
surprised
what
time
expectations
are
to
formally
staff.
Some
of
these
roles,
so
shadowing
will
give
you
a
really
good
chance
to
kind
of
shoulder
surf
and
be
mentored
to
get
a
better
view
for
how
things
work.
It
also
is
a
great
opportunity
to
help
improve
a
given
position
before
you
step
into
you
fulfilling
that
position,
and
also
we
could
pretty
much
use
all
the
help
we
can
get
on
the
release.
B
So
just
because
your
name
doesn't
have
the
word
need
to
or
shadow
next
to
it
does
not
mean
you
are
unproductive
human
being
who
are
going
to
completely
ignore.
If
you
remember
for
those
of
you
who
are
at
the
contributor
summit,
we
actually
gave
like
a
special
award
to
DIMMs,
because
he
has
showed
up
time
and
again
at
each
and
every
release
and
done
some
incredible
things
to
help
push
things
forward.
So
we
greatly
appreciate
any
and
all
effort
you
want
to
put
towards
this
and
I
think
we're
going
to
be
looking.
B
B
As
we
have
a
documented
I
think
you
could
sort
of
have
up
to
three
shadows
per
roll
again
I'm
gonna
delegate
to
each
of
the
people
for
their
their
different
roles,
because
it
kind
of
depends
like
I.
I
personally
cannot
handle
three
people
shadowing
the
lead,
so
I
have
two
shadows.
Other
people
may
feel
like
they
want
more,
so
I
would
figure
out
the
rules
that
you're
interested
in
and
interested
in
and
go
talk
to
those
folks.
B
B
Cool
so
never
mind
the
thing
on
the
right:
I'll
just
go
ahead,
and
then
one
close
that
that
was
me
looking
at
all
the
release,
minutes
for
all
the
previous
releases,
trying
to
figure
out
how
we
do
things
around
here
on
the
left.
Here
is
a
spreadsheet,
because
lord
knows
I
love
spreadsheets,
and
this
was
my
way
of
trying
to
visualize
what
the
schedule
is
going
to
look
like
for
114,
I
kind
of
wanted
to
remain
pretty
on
controversial
and
boring.
B
Much
like
what
you
have
seen
for
any
other
release,
it's
the
sort
of
thing
where
we
end
up
releasing
kind
of
towards
the
end
of
the
quarter.
There
is
about,
let's
see
here
about
one
and
a
half
weeks
from
the
start
of
the
year,
for
us
to
get
our
act
together.
So
we're
in
that
the
half
week
was
last
week.
This
is
the
full
week
after
we
get
our
act
together.
We
didn't
have
about
three
and
a
half
weeks.
Is
that
right
to
get
kept
slanted?
B
And
after
that,
we
have
about
five
weeks
from
that
point
in
time
to
actually
land
code,
and
then
we
have
about
anywhere
from
two
to
three
weeks
of
code
being
flushed
or
frozen
before
we
actually
saw
the
code
and
then
another
week
before
we
cut
I
plan
on
pulling
together
putting
this
into
a
PR
where
we
can
have
a
more
substance
of
discussion.
But
I've
run
this
through
your
sig
release,
chairs
former
release
leads
and
my
shadows
and
nothing
super
crazy
has
come
up
out
of
this.
J
Here
and
I
have
one
just
in
regards
of
keps,
just
as
maybe
this
will
help
me
to
help
Claire
out
when
it
comes
time
to
start
doing
enhancement,
collection.
Last
time
going
through
this,
you
know
we
had
the
idea
that
we
wanted
to
have
a
lot
of
the
enhancements
have
some
sort
of
kept
associated
with
it.
J
However,
it
seemed
like
I
would
say,
75%
or
more
probably
didn't,
because
they
were
following
the
old
process
and
I
didn't
know
of
any
things,
if
any
ones
that
are
still
old
if
they
need
to
actually
go
through
the
whole
kept
process
versus
what
was
in
the
the
cake
community
or
if
those
are
gonna
follow
I.
Guess
like
a
grandfather
clause,
or
they
just
you
know
they
kind
of
make
their
way
in
no
matter
what
versus
stuff
that's
net
new
that
does
require
cap.
Okay,.
E
So
so
all
enhancement
issues
should
always
have
some
sort
of
design
proposal
or
kept
attached
to
them.
So
design
proposals
are
the
old
caps.
Are
the
new
this
release
moving
forward?
There
is
no
grandfathering
in
every
issue
needs
to
have
a
cap
like
that
is
a
hard
rule.
Every
issue
needs
to
have
a
cap
or
it's
not
going
to
release
what
about
stuff.
That's
already
say
beta.
What's.
E
J
B
That's
a
really
good
question
that
I
think
we're
still
trying
to
hash
out
but
like
I
need
to
add
a
minimum,
see
a
test
plan
and
I
need
to
see
some
consideration
around
upgrade
boundary
see
I,
see
Hannes
nodding
his
head.
There
I've
been
saying
this
repeatedly
since
before
we
even
cut
113
I've
said
it.
That's
a
contributor
summit.
I
said
it
multiple
times
it
could
come.
People
are
nodding
their
heads,
so
we
agree
that
that
sounds
great.
How
is
this
going
to
work?
That's
a
good
question
and
I.
B
Don't
have
concrete
answers
there,
but
considering
that
Stephen
is
basically
the
kept
guy
and
caps
are
largely
an
architecture
process
and
the
next
cig
architecture
meeting
is
this
week.
Thursday
I,
anticipate
we'll
have
much
better
answers
for
you
next
week
or
just
as
this
conversation
goes
on,
but
like
at
a
minimum,
I
would
find
a
way
to
go.
Take
a
look
at
the
cap
template
and
and
write
up
a
cap
for
your
enhancement,
if
you
haven't
done
so
already
and
then
just
make
sure,
there's
something
in
there
about
testing
and
an
upgrade
downgrade.
E
L
B
Yes,
I
was
gonna
say
we
live
in
a
brave
new
world
now,
where
we
don't
talk
about
features
anymore.
If
we
talk
about
enhancements,
because
cap
stands
for
kubernetes
enhancement
proposal,
it
seems
kind
of
weird
and
silly
to
me
because
I
keep
thinking
about
them
as
features
but
they're
enhancements,
though
so.
E
Yeah,
so
the
idea
being
that
enhancements
are
multi
release
multi,
release
scopes,
whereas
features
are
single
release
it's
if
you're
looking
about
something
out
within
the
scope
of
one
release,
that's
a
feature
if
you're
looking
to
do
something
like
seccomp
or
something
like
that,
I
don't
know
HPA
right.
That
is
an
enhancement
right.
It's
going
to
take
multiple
releases
to
get
done.
M
One
thing
that
we
did
see
in
113
that
helped
again
added
at
the
risk
of
adding
more
work
for
you
and
Claire
is
actually
going
to
the
individual
SIG's
and
then
driving
what
the
main
points
that
we
want
like,
for
example,
if
you
want
all
of
them
to
follow
caps,
talking
to
them
beforehand,
kind
of
helped
us
sell
things
a
lot
last
time.
So
just
FYI
yeah.
B
I
agree
completely
I'm,
hoping
that
we
can
get
some
kind
of
plan
together
this
week
and
start
at
that
March
next
week,
so
we've
sort
of
jumped
ahead
thanks
Kenny
everything
must
have
a
cap
section
in
the
open
discussion
portion
of
the
meeting
notes.
So
my
straw,
man
is
basically
yeah.
Every
tracking
issue
has
to
have
a
cap
associated
with
that
and
that
caste
kept
must
at
least
have
a
test
plan
and
upgrade
downgrade.
Those
are
my
asks.
B
I
agree
that
the
things
like
Docs
and
a
checklist
for
alpha,
beta
or
beta
to
stable
graduation
criteria
are
also
really
really
great
things
that
that
latter
thing
is
actually
that
checklist
is
really
what
I
want
and
I
kind
of
want
test
plans
and
upgrade
downgrade
and
Docs
to
all
be
part
of
that
checklist,
but
those
first
two
things
are
the
ones
that
are
really
really
big
for
me.
Yeah.
E
So
something
that
I
I,
don't
think
we
can
or
should
get
into
here
is
the
idea
that
we
don't
have
a
global
I'm
just
mentioning
this,
so
that
people
are
aware
we
don't
have
the
idea
of
a
global
graduation
criteria
for
all
kubernetes
projects
right
so
in
in
introducing
enhancements.
People
don't
provide
this
because
they're
I
think
I
think
partially,
because
there's
no
baseline
to
kind
of
compare
them
against.
So
that's
something
that
needs
to
change,
but
let's
all
stop
there.
B
Yeah
there's
some
really
bright
individuals
who
have
a
long
and
storied
history
with
the
project
in
cig
architecture
who
have
strong
opinions
on
what
it
means
for
something
to
be
alpha
or
beta
or
stable.
I
want
for
those
individuals
to
get
it
written
down,
build
consensus
on
that
and
then
we,
the
release
team,
are
merely
consumers
of
that
checklist.
B
L
B
L
B
I'm
only
concerned
with
this
release
since
I
am
the
release
lead
for
this
release.
I
think
it's
a
question
for
the
broader
community
about
what
we
mean
when
we
talk
about
stability
and
quality
for
the
project
as
a
whole.
I
would
hope
we
could
get
our
act
together
where
we
feel,
like
things,
are
more
stable
and
it's
less
of
an
angle
process
sounds.
L
B
Okay,
my
so
my
plan
is
to
take
a
survey
of
all
of
the
existing
enhancements
that
are
out
there
just
to
get
a
feel
for
what
is
currently
slated
for
the
release
and
so
that
I
have
more
of
an
idea
of
what
we're
talking
about
substantively.
When
we
talk
about
this
at
save
architecture,
I
know
minimum
the
largest
Boulder
would
be
the
Boulder
around
Windows
notes
and
what
it
means
for
the
that's
level
of
support
to
go
GA
that
took
up
a
lot
of
conversation
in
the
1:13
release
cycle.
B
So
if
once
I
get
bad
laid
out,
I
will
schedule
the
rest
of
the
meetings
and
create
some
more
wonderful,
bitly
short
links
for
all
of
that
stuff.
If
you
are
a
member
of
the
114
release
team,
you
are
hopefully
subscribed
to
the
kubernetes
milestone,
milestone.
Burndown
Google
Group
is
generally
the
Google
group
that
gets
all
of
the
tactical
communication
or
coordination
around
the
release,
such
as
invites
to
this
meeting
and
invites
to
all
future
burn
down
meetings,
as
well
as
discussion
around
things
like
letting
in
enhancements
and
things
like
that
past.
B
B
This
allows
them
to
be
assigned
issues
and
use
a
number
of
other
bot
commands
that
are
useful
and
then,
finally,
a
little
bit
more
specifically
once
you
are
a
member
of
the
github
org
we'd
like
for
you
to
become
a
member
of
the
kubernetes
milestone,
maintainer
x'
team,
although
I
want
to
hold
off
on
that
for
just
a
little
bit,
because
I
have
a
modest
proposal
that
we
completely
purge
that
team's
membership
and
start
from
scratch.
Since
it
is
the
new
year,
it
just
seemed
like
new
year
new
team,
so.
E
I'm
I'm
in
favor
of
that
heavily
in
favor
of
that
we
have
wanted
to
clean
this
list
for
a
while,
it's
fallen
out
of
sync
with
E
there's
a
list
of
to
incriminated
kubernetes,
which
is
not
accurate
anymore.
This
list
is
probably
not
accurate.
I
know.
Tim
was
working
towards
doing
this.
Oh
like
one
half
ago,
maybe
but
yeah,
but
I
do
think
it's
time.
I
I
can
I
know
you've
mentioned
that
on
an
issue
already
so
I'd
like
to
move
forward
with
it
this
week,
I
think
I've
located
tim's
okayed
it.
B
E
So
I
just
want
to
note
that
for
the
people
who
are
watching
that
are
interested
in
shadowing
you
had
mentioned
being
a
kubernetes
or
ember
it
foreshadow.
It
is
not
a
strict
requirement,
although
you
should
be
working
towards
it,
you
should
absolutely
be
working
towards
it
and
the
scope
of
the
the
release
cycle,
but
don't
think
that
that's
a
blocker
for
you
actually
shadowing
I
just
wanted
to
note
that
for
people
who
are
new
to
the
process.
B
B
Yada
yada
is
the
largest
one
for
me,
but
I
know
we
talked
about
a
number
of
things
at
the
113
retro,
which
we
didn't
actually
get
a
chance
to
walk
all
the
way
through
down
to
action
items
we
could,
if
you
would
like
use
the
following
30
minutes
to
walk
through
the
rest
of
the
1:13
retro
and
drill
into
you
action
items
that
we
want
to
carry
forward
into
the
release.
We
could
just
kind
of
have
an
open
discussion
about
what
you
want
to
do
differently
for
this
release.
B
I
put
down
a
couple,
different
suggestions
from
my
head,
but
just
to
make
sure
that
I
don't
fall
into
the
anti
pattern
of
monologuing
for
every
release.
Team
meeting,
I
kind
of
want
to
hear
from
other
folks
here
about
how
they
would
like
to
best
use
the
next
30
minutes.
Thinking
about
how
to
make
this
release
go
better
than
the
last
release.
So.
K
B
P
B
The
line
is
pretty
much
for
this,
but
what
I'm?
Looking
for
what
I'm
interested
in
is
to
see
like
what
we
can
fill
this
out
with
I,
especially
like
the
ones
that
are
links
to
issues,
because
then
I
can
add
those
issues
to
the
Wow.
The
Internet
is
great
here.
I
could
do
things
like
adding
those
issues
to
the
release
milestone
to
track,
what's
going
on,
which
brings
me
to
one
of
my
suggestions:
I,
don't
know
how
many
people
know
that
we
had
projects
that
corresponded
to
different
kubernetes
releases.
B
That's
how
previous
release
teams
tried,
tracking
it
I'm
personally,
not
a
massive
fan
of
project
boards,
just
because
they're,
not
incredibly
automation
friendly
at
the
moment,
but
I
am
a
huge
fan
of
using
milestones,
because
I
can
issue
github
queries
for
those,
so
I'm
using
a
114
milestone
to
track
everything
that
needs
to
be
done
as
part
of
the
v1
14
release.
So
I
figure
things
that
we
want
to
implement
to
improve
the
release
are
probably
sig
released,
related
issues
that
we
can
put
in
here.
B
M
P
Strong
evidence
that
I
could
point
to
and
github,
but
I
I
feel
like
I've,
had
the
sense
that
sig
leadership
does
use
it
as
a
way
of
saying
like
hey
this.
This
thing
doesn't
quite
look
ready
like
we're
it
we're
at
code.
Freeze
now
were
we
at
code
freeze
now
we
would
probably
say
no,
and
we
only
have
a
couple
of
days
since
we're
in
the
slush
period
like
it.
It
feels
almost
like
a
fun,
a
pre,
forcing
function
and
I.
P
Think
I've
seen
sig
leadership,
use
that
to
do
some
risk
assessment
on
things,
because
there
is
the
risk
that
Oh
code
freeze
is
coming.
Let's
put
this
in
and
then
sure
maybe
it's
buggy
whatever
we
rush
it
in,
but
then
during
code
freeze
we
can
fix
bugs
so
I
get
the
rationale
to
that.
But
I
don't
know
it's
certainly
not
formally
documented,
and
this
is
one
of
the
things
that
I
deliberately
in
my
sig
release
presentations
over
the
last
year,
I've
talked
about
the
way
the
cycle,
progresses
and
I
kind
of
hand.
P
Wave
around
code
slush
and
I
was
hoping
that
somebody
at
some
point
would
push
back
and
be
like
no
no
hand
waving,
there's
a
solid
thing
here.
It
means
this
and
nobody's
ever
sort
of
offered
up
that.
So,
if
nothing
else
I
like
the
idea
of
whether
we
make
it
go
away,
like
really
saying
like
what
are
the
concrete
criteria
that
apply
here,
because
it
third
there.
B
P
B
So,
in
terms
of
objective
criteria,
the
closest
thing
we
have
might
be
the
set
of
labels
that
are
necessary
for
something
to
get
merged
during
code
slush,
which,
okay,
you
have
to
say,
your
thing
has
a
certain
priority
and
you
now
have
to
say
that
it's
part
of
the
milestone,
which
is
something
only
a
select
group
of
people,
can
add.
So
it
gives
it
some
additional
level
of
scrutiny,
but
I
think
there
are
some
people
who
feel
like,
oh
great
just
for
labels,
it's
kubernetes
they
like.
So
we
use
labels
for
everything.
B
Wait
which
week
is
it
which
set
of
labels,
do
I
have
to
use
in
terms
of
prose.
There's
a
file
called
code
slush
that
lives
in
the
ephemera.
A
directory
of
sig
release.
Ephemera
is
documented
as
a
place.
That's
supposed
to
be
short
lives.
It's
its
short.
Life
has
been
about
18
months,
give
or
take
now,
which
feels
like
six
releases,
I.
Think
in
kubernetes
release
parlance
that
doesn't
seem
like
super
short
lives
to
me.
B
So
one
of
the
other
issues
I
have
is
to
maybe
like
clean
that
out
and
I
assigned
a
couple
different
people
whose
roles
it
seems
like
this
overlaps
with
but
code.
The
code.
Slash
thing
here,
talks
about
how,
during
this
period,
new
features
or
large
reef
actors
might
be
turned
away.
So
this
seems
to
be
kind
of
a
gate
that
says
if
you're
trying
to
land
something
huge
and
you
haven't,
landed
it
by
now,
don't
bother.
G
E
Yet
so
I
have
weird
feelings
about
that
too,
because
there
are
I
mean
there
are
requirements
that
we
note
in
membership
around
being
on
mailing
list.
If
you're
going
to
be
on
a
mailing
list,
you
should
be
watching
the
mail
on
the
mailing
list
if
you're
going
to
join
milestone
burden
if
you're
going
to
join
sick
relief,
things
like
that,
you
should
be
watching
the
mail
I
think
it's
enough
to
notify
their
and
and
do
that,
a
few
times,
I
Aaron's
making
faces
I,
don't.
B
Know
like
I,
his
history
has
taught
me
that
people
don't
read
and
there's
a
class
of
contributor
who's
only
interested
in
shoving
code
into
the
project
and
I
don't
want
to
dissuade
them
from
doing
that
because
they're
highly
productive
people,
and
so
you
could
argue
that
making
sure
that
there's
information
communicated
down
at
that
level
is
a
helpful
redundant
reminder
of
where
we
are
in
the
release
life
cycle.
But
I'll,
then,
is
just
having
such
a
tough
time.
G
Hypothetically,
if
such
a
thing
were
a
meme,
it
could
get
reposted
through
all
the
usual
channels,
and
people
would
actually
look
at
it
because
it
was
not
a
thing
to
read.
I
think
a
lot
of
people
do
catch
this
through
things
like
SIG's,
Lex
and
Twitter
and
stuff
I'll,
see
some
of
the
more
activist
leagues
will
themselves
reiterate
the
warning
that,
like
by
the
way,
we're
entering
this
phase-
yes,
okay,
hi,
so.
M
M
B
That
to
me
sounds
like
it's.
A
communications
issue
and
memes
are
great
for
communication,
I
shocking
that
then
we'll
talk
about
using
memes
or
emojis
to
communicate
something.
So
that
sounds
like
a
good
idea
to
me
that
might
be
less
work
for
testing
for
and
it
might
simplify
at
least
some
parts
of
the
process.
F
N
B
Okay,
there
was
one
other
issue:
I
thought
was
maybe
worth
discussing
with
the
group,
which
was
revisiting
the
release
tracking
issues
so
again,
I'll
share
my
screen.
I,
don't
know
how
many
of
you
live
in
the
state
release
repo
on
a
daily
basis,
but
if
I
click
through
to
the
issues
thing
just
to
roughly
see
what
our
what
our
workload
is
like.
B
There
are
a
lot
of
these
release,
tracking
issues
that
are
listed
as
stage
stable,
and
some
of
them
are
in
milestones,
but
some
of
them
aren't
and
they're
all
created
by
this
case
release
robot
and
they
don't
seem
that
actually
have
too
much
human
interaction.
In
fact,
if
I
go
back
to
the
query,
just
to
see
like
what
these
are
like,
there's
really
a
yeah.
E
M
B
I
think
it's
some
part
of
I
tried
crapping
in
the
kubernetes
release.
Repo
and
I
saw
mention
of
Kate's
release
robot,
but
I
still
haven't
found
the
code
that
actually
creates
the
issues,
so
I
still
lacks
in
context.
One
thing
I
did
want
to
point
to
you,
though.
Let's
see
here
back
in
the
one
nine
days,
oh
boy,
this
is
going
to
be
kind
of
rough
and.
B
With
me
here
back
when
I
was
part
of
the
one
nine
release
team
because
bug
triage,
then
we
used
releases
to
signify
like
or
we
used
issues
to
signify.
We
want
to
cut
this
release,
and
so
we'd
say
we're
gonna
cut
it
on
this
date
and
then
we
could
link
issues.
There
were
all
requests
back
to
this
issue
say
like
hey.
This
given
test
here
is
preventing
us
from
cutting
this
build
of
the
release
and
I
personally
found
it
kind
of
useful.
B
You
also
had,
like
an
ongoing
place,
a
place
to
have
like
an
ongoing
discussion
about
the
status
of
a
given,
build
with
kubernetes
separate
and
apart
from
the
sinc
release
channel,
but
as
far
as
I
can
tell
this
was
never
used
again
after
1:9.
I
haven't
actually
gone
back
into
the
retro
to
see
like
if
people
felt
it
that
it
was.
It
was
too
much
friction,
but
it's
something
I'll
put
out
there
as
an
idea
to
use
for
the
114
release.
E
P
Okay,
what
are
your
suggestions
on
better
ways?
I,
like
I've,
I've
kind
of
like
the
github
buckets
for
things
like
that,
because
they're
they're,
visible
and
I
do
have
a
worry
about
the
various
Spreadsheets
and
Google
Docs
that
end
up
kind
of
ephemerally
coming
into
existence
during
the
release
to
do
some
of
the
similar
knocking,
but
those
aren't
visible
beyond
the
team
I
either
when.
E
B
P
D
E
I,
like
I,
like
the
milestone
and
that
it
aggregates
like
these
common
github
issue
types
as
opposed
to
I,
mean
there's
also
something
to
be
said
for
the
the
umbrella
issues
which
aggregates
all
that
stuff
and
one
issue,
I,
think
it
depends
on
who's
using
it
and
what
it.
What
it's
used
for,
I
don't
find
any
I'd
like
I,
don't
find
any
current
usefulness
in
what's
what's
being
put
out
by
that
bot
like.
F
B
Yeah,
like
I,
said
how
I
might
use
preempted
issues
rather
than
issues
that
are
created
after
a
release
is
cut,
is
to
link
github
issues
or
pull
requests
that
could
potentially
be
blocking
a
given
release
from
being
cut
and
I
feel
that
would
be
more
useful
than
a
milestone,
because
it
would
give
me
a
place
to
focus
discussion
and
it
would
be
I
cuz.
We
currently
scope
milestones
to
the
entire
quarter,
long
release,
whereas
those
issues,
at
least
when
I
use
them
on
the
one
line,
release
life
cycle.
B
We
use
them
for
every
alpha
and
beta,
and
our
C
thing
that
we
cut,
which
may
be
worth
keeping
in
mind
as
I
know.
One
of
the
things
that
I've
heard
discussion
about
is
some
folks
from
sig
clustered
lifecycle,
who
are
motivated
to
make
sure
that
Debbie
and
Deb
and
rpm
files
are
cut
for
every
alpha
and
beta
release,
not
just
the
final
thing
so
it
could
be.
B
We
would
want
to
progressively
see
like
improvements
on
how
that's
done
for
each
milestone,
so
it's
not
something
I'm
all
over
I'm,
not
super
sold
on
it
either
like
I.
Do
agree
that
if
it's
not
something
that
just
organically
was
carried
forward,
that
could
be
a
sign
that
it
was
too
much
friction
to
organically
happen
could
be
that
nobody
realized
that
was
there
as
an
option.
B
So
I
put
together
a
doc
that
I
link
to
the
meeting
notes
where
I'm,
just
trying
to
like
when
I
have
time
play
around
with
it
or
play
around
with
the
idea
of
integrating
between
github
and
air
table
in
general.
So
hey
should
be
world
comment
about
why
not
just
having
something
dumped
into
Google
sheets
since
we're
already,
we
already
live
in
a
world
where
most
everything
is
in
Google
sheets
I.
Don't
have
a
great
answer
for
that.
B
Could
you
know
my
dream
that
I
have
documented
here
is
like
give
me
a
github
query
like
everything,
that's
in
the
kubernetes
org,
that
has
label
area
conformance
and
then
maybe
have
something
that
knows
how
to
parse
and
understand
the
area
kind
and
priority
labels
like
those
into
their
own
column.
And
then
you
can
do
like
cool
stuff
by
like
let's
group
everything
by
author
in
this
thing,
and
so
you
can
see
this
particular
view.
J
practice
opened
these
three
issues.
B
I
could
group
by
other
things,
so
I
don't
know,
I'm
I'm
playing
it
around
with
it.
If
there's
somebody
who
wants
to
also
play
around
on
it
feel
free
to
ping
me.
That
seems
like
kind
of
a
neat
thing,
but
I'm
more
interested
in
having
the
conversation
with
my
enhancements
need
to
understand
how
she
would
best
like
to
track
enhancements,
starting
from
there
and
then
see
how
bug
triage
would
like
to
track
issues
and
see
how
CI
signal
would
like
to
track
on
flakes
and
see.
B
So
that's
pretty
much
all
that
I
wanted
to
await.
I
have
one
other
thing
that
I
would
actually
appreciate
leads.
Taking
a
look
at
I
tried
to
create
a
document
based
on
the
template
because
I
as
I
jump
from
thing
to
thing,
it's
really
super
easy
if
I
can
just
copy
paste
something
with
a
bunch
of
to
do's
and
then
fill
out
the
to
use
until
it's
done
so
I
figured
for
our
weekly
meetings.
I
could
take
this
thing.
That's
at
the
bottom
of
the
meeting
minutes
just
copy-paste
that
and
say:
okay.
B
B
Well,
here
all
here's,
the
number
of
enhancements
that
I
see
this
week
for
114
and
if
we're
really
trying
to
drill
in
on
the
cap
thing
like
here's,
the
number
of
enhancements
that
have
a
camp
associated
with
them
or
don't
have
a
cap
system
with
them.
A
BCI
signal
wants
to
tell
us
about
the
number
of
release
blocking
jobs
that
are
failing,
or
maybe
the
number
of
test
issues
that
they're
tracking
just
some
some
kind
of
one
to
two
numbers.
B
If
you
ever
listen
to
the
Planet
Money
podcast,
the
like
indicator,
the
the
like
just
some
random
number
that
you
can
show
each
week,
so
we
can
sort
of
see
how
things
are
changing
over
time.
It's
a
good
habit
to
build
up
now,
as
we
start
to
get
to
burn
down.
We're
like
burned
down
by
its
very
name
kind
of
indicates
that
we're
going
to
be
looking
to
burn
some
numbers
that
start
high
and
wait.
B
You're
start
high
and
go
down
low,
and
so
what
are
those
numbers
that
we
want
start
high
and
go
down
low
that
we
start
tracking
now,
so
we
get
used
to
tracking
them
on
a
more
frequent
basis
so
that
template
down?
There
was
just
my
my
guess:
it's
some
metrics
that
might
be
useful
I
have
no
idea
how
easy
some
of
these
numbers
are
to
produce.
So
it's
not
like
it
is
a
mandate,
but
I
would
appreciate
the
different
folks
taking
a
look
at
that
and
seeing
what
makes
sense
to
them.