►
From YouTube: Kubernetes 1.11 Release Retrospective Part 2 20180703
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
Welcome
everybody
today
is
Tuesday
July
3rd
2018.
You
are
in
the
kubernetes
1.11
release
retrospective
part
2.
If
you're
interested
in
part
1,
it
will
be
under
the
community
meeting
that
happened.
Last
Thursday
I
don't
have
the
date
I'm.
Sorry,
you
might
have
to
do
something
to
figure
that
out,
but
essentially
this
is
the
continuation
and
I
want
to
go
ahead
and
give
a
couple
things
to
start
here,
which
is
first
and
foremost.
A
A
So
if
you
have
something
that
you
want
to
change
or
discuss
in
a
way
that
you
want
to
see
differently,
please
focus
on
solutions
and
be
positive
and
supporting
all
of
us
and
remember
that
it's
usually
process
or
technology
behind
the
root
of
a
problem
and
people
are
rarely
to
blame
and
the
end
of
it.
So,
let's
go
ahead
and
proceed
if
you're
looking
for
the
document
for
this
retrospective,
it
is
located
at
a
bitly
/
K,
UB,
e-111
retro
cube
111
retro
and
we
will
go
ahead
and
fall
in
there.
A
Oh
and
just
show
so
there's
also
available
at
Kate's,
one-one-one,
retro,
so
multiple
ways
to
get
to
the
same
file
and
what
we're
gonna
do
is
we're
gonna
go
to
that
document
and
we're
going
to
go
to.
There
is
a
section
we
use
for
the
community
meeting
at
the
top,
but
if
you
scroll
down
you'll
see
a
lot
of
duplication
of
information
after
the
did,
we
say
what
we
did.
We
do
what
we
said.
We
do
and
that's
what
we're
gonna
go
ahead
and
start,
and
that
section
is
in
what
could
have
gone
better.
A
B
B
I'm
not
gonna
list
off
all
the
names,
because
I'm
sure
I
will
forget
somebody
out
of
the
16
people
on
the
team,
I
believe,
but
I
thought
the
entire
release
team
was
amazing.
I
was
really
as
release
lead.
I
was
really
able
to
be
sort
of
the
manager
of
the
release
and
deal
with
escalated
issues
and
deal
with
timing,
rather
than
necessarily
mean
to
be
in
the
weeds
on
individual
PRS
until
the
very
last
week,
and
at
which
point
pretty
much
everyone's
in
the
weeds,
the
I,
so
I
thought
everybody
did
a
terrific
job.
B
C
B
Was
going
to
say,
given
that
half
the
time
when
you
asked
when
you
asked
a
quote-unquote
silly
question,
the
answer
was
well
I.
Don't
know
why
we
do
that.
It
was
good
we're
asking
those
questions.
Yeah.
A
So
just
I
have
to
say,
as
somebody
who's
been
a
shepherd
of
this
process
now
for
two
years,
that
is
to
mean
what
you
just
said
is
the
highest
possible
compliment,
that
this
is
a
that
this
is
a
safe
space
for
people
to
learn
and
grow
is,
is
to
me
there's
no
greater
aspiration
of
anything
we
do
in
this
community
than
that.
So
thank
you
so
much
that
is
really
good
here.
D
Yeah
I
want
to
amplify
that
too
and
say
that
this
was
really
cool,
that
we
all
work
at
different
companies
in
our
day
jobs,
and
we
all
have
other
things
that
we're
doing.
We
have
time
zone
issues
and
I
felt
like
we
all
work
together,
really
well
and
we
took
I
think
each
most
kind
of
work
hard
to
help
each
other
out
when
there
were
questions.
So
I
really
appreciated
that
I
never
felt
like
I
was
left
on
my
own
to
figure
something
out.
A
That's
wonderful
super
good
to
hear
yeah
and
I've
always
loved
that
to
that
sort
of
camaraderie
across
companies.
This
is
really
you
know.
When
I've
written
in
the
past
said
I
don't
work.
For
you
know
any
other
company
I
really
worked
for
kubernetes
and
that's
this
release
team
is
is
absolutely
the
pinnacle
of
that.
So
ooh
all
right.
A
Well,
if
anybody
thinks
so
anything
else
that
they
want
to
shout
out
as
we
go
through
the
retro
go
ahead
and
do
it
in
chat
and
we'll
call
those
outfit
we're
going
to
go
ahead
and
move
on
to
what
could
have
gone
better
because
hopefully
one
of
the
main
goals
of
this
process
is
to
do
it
better
every
time
so
Josh
I'm
going
to
turn
this
over
to
you.
You
want
to
just
go
ahead
and
start
from
there
and
I'll
jump
in
if
I
need
to
okay,
so.
B
A
lot
of
our
what
could
have
gone
better
is,
you
know,
advice
to
the
112
release
team
which,
which
some
people
are
continuing
on.
Please
tinker
with
this,
so
the
first
one
of
these
is
one
that
we
touched
on
the
community
meeting,
which
is
the
feature
freeze
process
and
as
I
understand,
that
the
purpose
of
the
feature
freeze
process
is
so
that
we
can
keep
track
of
features
worthy
of
mention
and
features
requiring
Docs
and
release,
notes
and
other
things.
I
must
and
test.
E
B
And
things
needing
tests
as
well
yeah,
the
I.
So
basically
you
know
if,
if
you
know,
there's
a
certain
level
of
feature
at
which
it
needs
all
the
things-
and
you
know
the
sort
of
purpose
of
feature
freeze
was
to
actually
capture
those
so
that
we
didn't
lose
track
of
them
so
that
we
made
sure
that
they
had
all
the
things
by
the
time
release
came
out.
The
end
was
also
the
purpose.
B
Was
there
was
a
PR
purpose,
but
we
kind
of
dropped
that,
because,
because
of
the
problem
that
we
realized
with
the
sort
of
declared
feature
free
is
a
month
into
the
release,
which
is
that
like
for
111,
we
had
think
originally
forty-three
declared
features
and
of
those
eighteen
had
dropped
out
by
code
freeze,
so
almost
half
had
dropped
out
and
in
the
meantime
we
got
I
think
three
things
that
were
not
on
that
list
that
qualified
as
major
features
on
that
people
just
got
done
for
code
freeze
so
and
then
the
other
thing
that
has
happened
over
the
release
actually
based
on
our
experience,
either
with
one
9
or
110
I.
B
F
B
So
so
the
question-
and
this
is
something
we're
turning
over
to
the
112
team-
is:
how
do
we
want
to
rejigger
that,
if
we're
not
doing
feature
reads
for
PR
purposes,
we
don't
need
to
worry
about
that.
We
don't
need
to
worry
about.
What's
on
the
feature,
freeze
tracking
until
code
freeze
time
we're
actually
preparing
the
announcements
or
code
slush
or
whatever
week.
It
is
that
we
from
heard
of
the
announcements
then,
and
our
main
purpose
is
to
make
sure
that
we're
tracking
that
stuff.
A
Yes,
so
I
I
think
there's
a
few
things
here.
What
is
it
historically
speaking
so
this
this
process?
The
features
process
goes
way
back
almost
a
1.0,
and
the
original
genesis
of
this
came
from
the
fact
that
giant
segments
of
what
we
think
of
as
ordinary
functionality
now
we're
being
delivered
back
then.
A
So,
when
a
feature
back
in
the
102
1.4
time
frame
was
a
big
thing,
it
was
all
the
things
that
we
think
of
as
being
sort
of
fundamental
features
now,
so
the
what
we've
seen
is
this
trend
toward
sort
of
sharpening
the
blade,
instead
of
making
the
blade,
and
so
the
the
processes
that
apply
to
those
broad
sweeping
large-scale
implementation
efforts,
don't
really
necessarily
apply
anymore.
So
what
we
have
now,
though,
is
a
lot
of
tinkering
with
features
that
can
actually
negatively
impact
the
project
on
our
user
base
without
a
lot
of
visibility.
A
B
E
B
As
act,
one
Zach
identified
one
other
problem
with
the
current
sort
of
feature
feed
feature
tracking
process,
which
is
it's
pretty
much
entirely
separate
from
release
cycle
to
release
cycle.
But
he
pointed
out
we
need
to
keep
track
of
the
state
of
a
feature
as
it
advances
from
alpha
to
beta
GA
over
multiple
release
cycles,
because
one
of
the
things
that
we
do
is
sometimes,
if
a
feature
is
alpha,
we
give
it
lighter
dock
and
testing
requirements.
But
that
means
the
next
release.
B
D
B
G
A
Yeah,
so
this
is
this
goes
back
to
my
my
proposal
and
and
processed
thing
around
tiny
caps
to
features,
because
technically
these
things
should
not
be
happening
without
a
cap
anymore.
So
if
we,
if
we
get
wind
of
somebody
trying
to
do
something
big
in
a
release-
and
we
ask
where
is
your
cap
on
this
and
we're
the
thing
they're
gonna?
They
should,
in
theory
give
us
one
of
two
answers.
Is
that
this
predates
the
kept
process
and
there's
either
a
proposal
or
some
sort
of
sick
documentation
or
oops?
A
We
didn't
know
that
we'll
go
we'll,
go
bake,
one
up
for
you,
so
you
have
one
in
release
and
then
from
then
all
of
the
the
PRS
and
anything
else.
That
is
where
that
feature
should
reference
that
cap.
So
in
theory
you
you
search
for
that
cap
and
you'll
have
every
single
thing
issues
the
the
feature
the
the
PRS.
The
documentation
should
have
that
cap
associated
with
them.
So
that's
that's
how
we
actually
make
this
work
and
that
that
is
survives
milestones.
It
survives
release
teams.
A
A
B
E
A
A
A
B
D
I
Kind
of
exactly
what
I
was
thinking
this
day
so,
but
how
do
we
detect
things
that
are
definitely
not
keps,
like
I,
don't
know
like
minor
bug,
fixes
or.
A
Pr,
it's
like
that.
Well,
so,
if
its
type
feature
then
so,
if
the
I
guess
what
I'd
say
is
if
it's,
if
it's
in
this
case
it
might
muddy
the
waters
a
little
bit
because
in
theory
you
could
have
a
bug
fix
that
applies
to
a
cap,
in
which
case
it
might
still
be
type
feature,
but
I
I,
don't
know
this
this
honestly.
This
part
of
the
cap
process
is
sort
of
like
hand
wavy,
and
we
come
to
work
with
Sagarika
texture
to
figure
out
how
we
answer
this.
The.
B
Ben
and
Ben
actually
lead
led
into
the
the
second
sort
of
sub
part
of
feature.
Freeze,
freaking
feature
tracking
right
there,
which
is
we
have
a
lot
of
stuff
that
goes
into
release
that
doesn't
rise
to
the
level
of
track
feature
like
doesn't
rise.
The
level
of
this
is
something
we're
going
to
list
in
the
PR,
and
this
is
something
that
it
needs
to
be
in
the
feature
sheet,
but
nevertheless
has
dependencies
like
requires.
A
release.
B
Note
requires
a
Docs
change,
requires
a
test
change
and
as
the
release
team,
we
currently
don't
have
any
organized
way
to
track
those
I'll
say
it's
particularly
bad
with
stuff
that
goes
in
early
in
the
release
cycle,
because
and
now
I
actually
finally
understand
their
no
chase
that
you
added
here
is
I'm.
Looking
at
the
stuff
that's
going
in
this
week,
for
mostly
targeting
112,
we
apparently
don't
have
any
label
requirements
of
any
content
early
in
the
release
cycle.
People
are
merging
stuff
that
doesn't
have
a
kind
label.
B
It
doesn't
have
a
cig
label,
it
sakes,
no,
nothing
yeah.
So
when
it
comes
time
to
reconstruct
what
actually
went
in
and
whether
or
not
that
got
docks,
etc,
we're
not
gonna
have
any
idea.
No.
B
So
hurry
well
I
mean
I,
think
I
they
isn't
when
we
switch
to
tie
it.
Isn't
that
going
to
require
milestones
for
everything.
B
Yeah
so
I
mean
that's,
that's
it
because
cuz
like
we
don't
these
things
aren't
going
to
have
kept.
They
might
not
be
a
dependency
for
a
cap.
A
lot
of
these
are
just
little
things
like
hey
this
thing.
That
was
one
command-line
switch
for
goop
control,
we're
splitting
into
two
separate
switches,
because
there's
actually
different
things.
People
want
to
do
that
needs
a
dock.
It
may
need
a
test.
I
I
want
to
throw
out
that
I
think
it'd
be
very
feasible
if
we
wanted
to
start
requiring,
like
kind
and
Sigyn
things
to
merge.
Two
communities
I'm
also
wondering
if
anyone
has
any
insight
under
why
we
stopped
requiring
a
link
tissue
like
if
there
was
a
good
reason
for
that
or
like
if
we
just
need
better
tooling
so
yeah.
B
B
K
My
lot
of
times
they
just
yank
out
the
whole
block,
template
block
and
yeah
the
other.
It's
a
balance.
Right
I
mean
yes,
we
have
a
need
to
do
all
these
things,
but
then
we
are
slowing
people
down
because
it's
hard
for
people
to
find
other
people
who
can
switch
on
the
labels
for
them.
It's
getting
easier
by
the
day,
because
the
number
of
people
who
are
getting
into
the
queue
at
his
Argos
getting
you
know,
is
a
lot
of
people
getting
in.
So
it's
getting
easier.
B
I
B
I
K
E
Enforce
the
requirement
and
then
you're
back
into
the
same
position
of
people
saying
this
is
too
much
labeling
overhead,
correct
and
pushing
back
for
a
lighter-weight
process.
Yeah.
K
D
E
I
think
for
sure,
for
the
the
bigger
picture,
features
and
there's
something
I've
been
talking
to
Steven
about
I've
got
a
whole
list
of
things.
That
I
would
like
us
to
be
pushing
on
for
initial
questions
like
hey:
what
about
X,
what
about
Y
but
for
every
single
PR
that
goes
by
I.
Think
that's
a
just
a
scalability
problem
that
we
won't
tackle
successfully.
D
A
K
Okay,
one
thing
that
really
worked
well,
this
time
was,
you
know
us
reaching
out
to
the
sig,
leads
going
to
their
channels
and
pinging
them
and
telling
them
to
pay
attention
to
some
specific
stuff.
That
I
think
worked
this
time
really
well
compared
to
the
earlier
guesses
right,
so
I
think
we
should
definitely
need
to
continue
to
do
that.
But
if
we
start
that
process
earlier,
then
it
will
be
even
better
I
think
yeah.
L
So
one
of
the
one
of
the
goals,
moving
forward
and
kind
of
chase
and
I
are
knocking
it
back
and
for
us,
as
well
as
Tim,
is,
is
to
actually
start
something
of
a
planning
process
on
the
feature
side
around
the
code
freeze
period
for
the
previous
release,
it's
not
possible
to
do
it
at
this
point.
I
was
like
Jase.
Can
we
like
squeeze
this
into
one
soil?
But
it's
like
it's
not
feasible
to
do
at
this
point,
but
we
can.
A
And
then,
basically,
if
you
like
Tim,
said
or
everybody's
saying
like,
we
need
to
facilitate
the
working,
the
SIG's
wherever
possible,
but
I
do
have
to
I.
Do
have
to
raise
an
objection
and
I
feel
like
it's
a
relatively
vehement
one
is
that
there
are
certain
minimal
things
that
take
someone
five
seconds
to
do
in
a
PR
for
labeling
like
are
adding
milestone
that
later
down
the
road
take
us
hours
to
do
like
there.
There
is
no
excuse
to
have
a
human
come
up
and
clean
up
something
that
is
totally
completely
avoidable
and
minimally
invasive.
A
E
A
Who
has
that
happen
will
know
the
next
time
that
they
need
to
do
it
that
there's
that
they're
supposed
to
do
it
that
so
it's
an
education
process
as
well.
So
if
somebody
just
flails
their
hands
around
and
said
you
know,
I
did
this
ten
times
and
I
forgot
every
time.
Well,
I'm,
not
sure
I.
Actually,
that's
not
somebody
that
has
the
level
of
diligence
and
care
required
to
be.
B
Need
to
okay,
so
other
things
so
initially
was
shortening
code.
Freeze
deadlines
without
changing
the
docs
headlines,
causing
some
issues
for
feature
developers,
see
discussion,
topics
below
that
ties.
In
the
discussion
topic
we
did
bring
up
at
the
community
meeting,
which
is
rejiggering
the
relationship
between
the
docs
deadlines,
the
code
freeze
with
the
shorter
code
freeze,
possibly
having
a
longer
code,
saw
I
that
was
brought
up
in
the
community
meeting.
B
B
Okay,
the
other
thing
is
having
automated
dashboards
for
the
things
that
we
need
to
track:
PR
status,
issue,
status,
etc.
Still
a
big
to
do.
I
put
in
work
on
it
in
the
111
cycle
that
work
ended
up
being
useless
because
of
upstream
problems,
namely
that
the
work
was
dependent
on
on
github
archive
and
github
archive
started
failing.
I
someone
will
need
to
tackle
that
within
the
next
cycle,
because
having
released
team
members
copy
and
paste
things
from
github
to
google,
docs
is
really
not
an
effective
use
of
anybody's
time.
B
If
we
can
get
gah
archives
list,
dev
stats
working
reliably
enough
for
this
I'll
tackle
it
again
within
the
next
release
cycle
or
alternately.
I
was
talking
to
somebody
I
think
been
about
using
a
different
method
to
pull
this
so
one
way
or
another.
This
will
happen
involving
I,
think
people
who
are
not
currently
on
the
release
team,
which
I
think
is
a
good
plan
for
stuff.
That's
that
sort
of
tooling
items
and.
B
E
B
I
you
know,
and
then
it
just
sort
of
what
that
what
the
tooling
ends
up
being
like
that
is
going
to
depend
on
sort
of
what's
available.
I'll
start
with
is
using
PRS,
because
that's
the
area
that
I
know
the
best
and
then
we'll
look.
If
there's
some
way,
we
can
enhance
CI
signal,
probably
not
because
the
extra
information
that
ash
was
posting
in
her
reports
required
a
lot
of
digging
into.
Why
was
this
test
failing
and
it's
hard
to
figure
out
how
we
automate
that
ace?
B
C
One
is
the
only
thing
that
could've
been
automated
is
like
looking
looking
at
the
failures
and
then
probably
pulling
the
changes
or
the
PRS
that
could
have
gone
in,
but
other
than
that
yeah
I
had
to
do
a
lot
of
digging
to
see
like
when.
Did
it
fail?
What
is
history?
Is
it
a
flaky
test?
All
of
that
has
it
fail
for
this
reason,
before
anything
of
that
sort
was
I,
don't
know
how
we
could
automate
it.
C
M
C
Error
logs
are
not
very
clear,
I
mean
it
shows
it
highlights.
A
lot
of
you
know
errors
as
like
possible
causes,
but
then,
if
you
compare
with
a
successful
run,
you'd
see
the
same
errors
already.
So
there's
no
way
to
know
if
that's
like
red
herring,
or
it
was
a
real
thing-
that's
causing
that
particular
run
to
fail.
So
that
was
really
difficult
for
me,
like
half
the
time
and
it'll
look
like
a
network
issue,
because
it
is
something
about
ingress
and
bunch
of
things.
But
then
it'll
complain
about
that
enough.
C
A
I
would
love
to
have
somebody
help
me
with
some
of
these
things
that
I've
like
this
in
the
features
process
and
stuff
that
I
have
I,
have
taken
the
time
to
do
that,
all
the
work
to
actually
determine
what
a
good
policies
and
can
buy
him,
but
I
can't
I,
don't
have
the
bandwidth
to
socialize
all
these
things
and
get
them.
So
if
anybody
wants
to
help
me,
try
and
solve
some
of
these
deeper
core
issues,
I
would
seriously
welcome
that.
A
B
B
Some
other
administrative
things
number
one.
This
came
up
in
the
110
cycle
again,
which
is
that
we
don't
have
any
trustworthy
and
comprehensive
place
where
we
can
map
github
user
names
to
slack
handles
to
email
addresses
when
we
need
to
contact
contributors
or
reviewers
and
the
Majora's.
It's
not
a
problem
right
for
90%
of
them.
B
The
connection
between
these
is
is
obvious,
but
then
you
run
into
a
handful
of
people
that
either
aren't
on
slack
or
where
their
slack
name
is
just
really
different
from
their
github
handle,
and
you
know,
and
then
we
don't
have
any
way
to
contact
them
in
a
hurry.
If
there's
a
a
problem
with
their
PR
I,
don't
know,
I
didn't
put
in
a
proposal
for
what
to
do
about
this,
because
the
problem
is
that
it's
almost
like,
we
actually
don't
need
a
comprehensive
list.
B
B
I
E
B
Okay
but
yeah,
it
sounds
like
there
actually
is
potentially
some
automation
that
we
could
do
there
and
automation
would
be
far
better
than
manually,
maintaining
something
because
anything
we
manually
maintained
would
run
into
the
same
problem.
The
CNC
F
list
runs
into,
which
is
nobody
has
time
to
maintain
it.
There.
N
Is
one
thing
about
that?
We
thought
about
doing
this
with
owner's
files
like
sticking
emails
and
slack
handles
and
that
kind
of
stuff
in
there,
but
it
came
out
that
that
could
be
against
github
Terms
of
Service
right,
so
yeah,
probably
just
something
github
side
of
things,
but
it's
some
keep
in
mind.
Yeah.
N
B
N
B
E
I
think
we
have
that
sorted
out
now.
Initially
it
was
just
a
question
of
where
folks
were
trying
to
add
themselves
to
the
the
PM
group
versus
milestone
maintainer
as
I
think.
J
E
B
So
other
things,
so
this
is
something
that
I
point
out
here,
both
under
things
that
could
have
gone
better
and
things
that
we
could
do
in
the
future.
Some
release
cycle.
We
need
to
have
an.
We
discuss
it
in
community
meeting
a
major
project
to
get
people
to
test
the
betas,
and
that
will
be
a
major
project
because
it'll
start
with
trying
to
get
some
of
the
vendors
to
release
beta
versions,
which
will
be
a
non-trivial
exercise.
B
E
Yes,
so
in
the
last
two
cycles
we've
had
a
few
things,
we're
a
go.
Dep
was
updated
by
somebody
to
address
an
issue
that
they
saw
locally
and
then
it
caused
other
follow-on
issues
and
there
have
been
some
series
of
fixes.
Andry
fixes
and
I've
noticed
from
an
issue
triage
in
in
both
the
110
and
111
cycle.
Looking
at
these
things,
it
just
said:
update
dependency.
It
didn't
say
why
so
I'm
hoping
that
we
can
just
drive
a
little
bit
of
cultural
change
or
if
we
see
these
things
going
by
that
we
say
hey.
E
Why
are
you
updating
the
dependency?
Can
you
describe
it,
and
this
is
in
in
theory,
this
is
just
general
get
commit
hygiene,
but
I
think
this
is
a
particular
area
where
there's
pretty
immediate
consequences
to
having
done
it
poorly,
because
somebody
sees
a
change
and
reverse
the
change
and
then
his
rebrand
the
thing
that
the
change
had
meant
to
fix
for.
K
111
the
one
thing
that
happened
like
that
was
this
PA
advisor
and
we
couldn't
have
forecasted
what
the
problem
it's
the
advisor
update
was
going
to
be.
You
know
when
we
were,
but
either
way
the
number
of
people
who
can
approve
the
good
apps
change
is
very
limited,
and
these
are
supposed
to
be
our
senior
people
who.
K
Yeah,
that's
why
I'm
saying
that
it
it's
very
difficult
from
just
looking
at
the
PR
that
what
you
know
know
what
what
we
ended
up
seeing
in
in
the
flakiness.
You
know,
and
we
had
the
reward
dance
done
a
couple
of
times
for
see
vizor,
so
the
only
thing
I
would
say
is
we
should
make
sure
that
the
good
app
updates
happen
earlier
in
the
cycle
and
not
hold
on
till
the
last
minute
and
typically
see
advisor.
They
wait
till
the
last
minute
to
do
that.
K
So,
if
you
can
figure
out
a
way
to
get
those
kinds
of
earlier
in
the
cycle,
that
would
be
good
plus,
it's
not
just
good.
Have
changes,
also
changes
in
images
right,
image
versions
that
that
is
another
source
of
similar
issues.
When
we
update
the
image
version
right
at
the
last
minute,
and
then
you
know,
we
really
don't
know
whether
what
went
into
that
image.
So
it's
a
similar
problem
there
as
well.
B
Okay,
so
other
things
I
next
thing,
some
downgrade
test
failures.
Do
you
test
changes
getting
merged
in
late
in
the
cycle?
The
suggestion
coming
out
of
this
was
that
there
should
be
a
test
freeze
date,
after
which
only
bug
fixes
and
tests
are
accepted,
no
no
modification
of
contents
of
tests
etc.
When
that
should
be
exactly
as
is
TBD.
C
A
C
K
B
I
For
for
that,
adding
things
to
blocking
I've
just
made
it
a
standing
policy
that
that
always
needs
to
go
through
sig
release
yeah,
so
I,
don't
think
that
one's
just
a
problem
for
cute
kids
images,
I,
mean
I,
would
say
we
could
freeze,
but
I'd
also
say
that
just
like
we
don't
ever
want.
We
want
to
never
be
breaking
on
that.
So
we
just
want
to
improve
the
process
to
just
not
break
at
any
point
in
the
cycle.
B
The
okay,
so
I'm
gonna
take
a
bundle
of
things
that
could
have
gone
better,
and
these
are
all
related
to
release,
notes
the
and
I'm
actually
going
to
start
with.
The
start
of
thing
is
that
I
have
not
been
able
to
find
a
policy
anywhere
that
we've
written
on.
What
requires
our
release?
Note
and
I
just
wanted
to
confirm
in
this
this
last
meeting
that
such
a
policy
does
not
exist,
and
then
that
should
stay
on
the
to-do
list
of
things
that
we
need
to
do.
A
B
Cuz
I
was
starting
out
with
misuse
of
release.
Note
none
but
then
I'm
like
how
can
I
call
it
misuse
if
we
don't
have
a
policy
yeah
people
are
just
using
their
best
judgment
with
maybe
a
tiny
bit
of
laziness,
but
they
could
argue
that
they
had
reasons
and
then
we
had
the
release,
note
extractor
failing,
but
that
is
being
completely
reworked.
I
So
that
was
pretty.
That
was
pretty
pretty
change
tool.
So
I
took
the
tractor
like
reorganize
it.
We
were
kick
some
like
strategic
tests,
but
I
wound
up
just
like
taking
the
like
best
bits
of
it
and
making
a
different
tool
that
contextualizes
the
release,
notes
and
a
bit
of
more
of
an
ideal
way.
So
they've
definitely
used
some
eyes
on
that
PR.
If
anyone
wants
to
review,
go
PR
but
I'm
happy
with
how
that's
going
so
far,
yeah.
B
Mind
you
I'll
point
out
that
this
once
again
ties
into
the
the
lack
of
required
labels
early
in
their
lease
and
why
it's
not
just
something
for
the
the
release
team
to
clean
up
later.
In
my
opinion,
because
if
something
doesn't
have
a
kind
label,
then
we
don't
know
if
it's
supposed
to
be
a
feature.
If
we
don't
know
it's
supposed
to
be
a
feature,
then
we
don't
note
it
to
nag
somebody
about
a
release
to
note
yeah,
but
again
that
needs
to
be
taken
up
in
other
forums.
B
B
D
D
I
also
think
that
when
people
write
a
feature
without
having
a
well-defined
car,
sometimes
they
don't
even
realize
that
they
are
bugs
or
weird
behaviors.
Until
we
start
asking
the
questions
that
we
need
answered
to
write,
the
docs
no
I
mean
I,
know
that
there's
tension,
because
people
would
rather
be
writing
code
than
writing
Docs
about
the
code
and
that
this
kind
of
came
up
in
the
community
meeting
where
I
think
it
was
Tim
a
different
Tim
who
was
it
almost
sort
of
seemed
like
burning
the
candle
at
both
ends
with
saying?
D
M
H
Just
I
would
like
to
create
a
culture
of
expectation
that
Doc's
come
with
the
code,
mainly
because
as
a
developer,
having
Docs
for
previous
features
for
related
things
for
related
bugs
that
I'm
working
on
it's
just
wait,
a
minute
might
work
easier,
there's
going
to
be
less
use
and
enjoy
spending
more
time
writing
code
rather
than
sitting
down
a
rabbit,
hole
and
tracing
down
people
that
worked
on
it
previously,
that's
I
see
them
rod,
so
I
must
not
be
the
only
one.
Well.
D
I'm
not
sure
how
you
can
attest
something
without
the
testing
people
having
something
to
look
at
for
how
this
is
supposed
to
work.
It
seems
like
it's
making
more
work
for
everyone
when
we
don't
have
I
mean
and
the
docs
that
we
need
it's
not
like
polished
paragraphs
of
Docs.
It's
like
an
outline
or
like
basic
just.
How
is
this
supposed
to
work?
What
were
we
going
for
when
we
wrote
this?
That's
what
we
need
is
the
first
pass.
That's
all
we
need.
We
need
like
a
back
of
envelope
thing.
E
We
can
really
push
for
the
things
that
are
reaching
our
attention
early,
just
like
with
ice
this
last
cycle
on
and
on
CIN
test
that,
similarly
we're
all
what
kind
of
keeping
an
eye
out
for
pushing
saying
hey
what
about
some
initial
draft
documents,
even
just
a
few
sentences
that
first
guidance
what's
going
on
here,
but
beyond
that
I
think
it
goes
back
to
the
earlier
conversation
about
needing
some
cultural
change
and
reviewers,
and
especially
approvers
/,
saying
that
this
is
something
that
they're
making
is
an
expectation
of
their
individual
contributors.
Well,.
D
L
So
so,
if
we're
asking
people
initially,
a
new
MSD
you've
been
shouting
out
like
hey.
Can
you
at
least
put
up
a
draft
Docs
PR
I,
don't
see
what
the
problem
would
be
to
do
that
around
the
futures,
freestyling
right,
if
there's
going
to
be
a
draft
anyway
having
it
in
place,
especially
the
facts
of
keps
or
somesuch.
Having
that
in
place,
and
at
least
mentioning
the
cap
I
think
is
enough
and
you
could
be
maybe.
D
We
need
a
template.
Maybe
we
just
need
to
give
people
a
template
which
is
like
or
blanks
for
them
to
fill
out
or
something
like
that,
and
maybe
even
something
like
a
Google
Doc
form.
Something
I
mean
it's
pretty
basic
answers
that
we
need
and
it's
kind
of
I
don't
know
I
can
think
about
it.
Maybe
we
can
come
up
with
something.
E
H
A
great
idea,
I
also
think
that
if
you
make
it
clear
to
people
that
this
is
an
iterative
process
and
they
don't
have
to
write
like
super
polished
release
notes,
then
they
have
to
defend
in
court
or
something
I.
Think
that
reduces
the
barriers
a
lot
just
like
get
something
out
there.
Yeah.
B
D
I
still
think
we
could
do
some
automation
around
that
too.
We're
either
in
feature
PR
or
in
the
code.
Pr
have
something
for
crowd.
That's
like
slash,
Doc's,
PR
and
then
either
have
none
and
make
them
defend.
Why
it
doesn't
need
to
have
any
Doc's
or
have
a
link
to
a
draft.
Pr
like
everybody
knows
how
to
open
a
PR
and
they
did
it
for
their
code.
D
D
L
We're
gonna
if
we're
gonna
say
that
if
we're
gonna
say
that
the
person
who
opens
a
feature
is
essentially
the
project
manager
or
a
feature
owner
I,
don't
think
that's
a
high
bar
at
all
misty.
If
you
check
out
the
sig
PM
notes,
the
agenda
I
mentioned
some
of
the
things
that
you're
talking
about
right
now.
So
if
you
want
to
take
a
look
at
maybe
comments
that
people
can.
B
Okay,
I'm
gonna
move
on
so
that
we
can
finish
up
the
rest
of
the
stuff,
so
I
suggested
that
we
should
also
have
a
final
cherry-pick
deadline,
that's
published
so
that
people
know
that
cherry-picks
are
supposed
to
get
in
48
hours.
You
know
three
working
days
whatever
we
set
it
at
before
the
release,
because
people
were
submitting
cherry-picks
twelve
hours
before
the
scheduled
release
and
again
we
didn't
tell
them
not
to
so.
B
The
so
try,
oh
tracking,
with
Doc's
complete
free
tweeter
in
each
stage.
We
talked
about
that
for
changes
to
how
we
handle
feature
tracking
automated
switchboards.
Oh
one
release
notes
thing
I
forgot
to
mention,
which
is:
we
need
a
policy
in
what
goes
in
that
list
of
dependency
version
changes,
because
right
now
we
don't
have
one
yeah
and
that
could
be
anything
from
just
the
things
where
versions
were
mentioned
in
PRS.
But
then
is
it
all
of
those
things
or
everything
that
changed
can
go
depths,
which
is
a
much
longer
list.
C
I
I
was
just
looking
at
this
more
so
so
that
I
understand
which
different
projects
or
releases
we
have
to
track.
I
know
that
min
was
one
and
then
towards
the
end.
We
got
the
scheduler,
the
preemption
okay,
so
I
will
just
give
this
a
picot
maintain
an
own
list
of
this
somewhere,
so
that
and
we
can
engage
with
those
specific
teams
sooner
than
later
yeah.
B
Yeah
I
don't
know
I
feel
like
we
could
start
out
by
having
some
sort
of
list
of
the
ones
that
we
know
about.
So
those
are
people
we
could
at
least
nag
that
we
could
say
hey.
You
know
were
two
weeks
out
from
code
slash.
Are
you
guys
planning
on
having
an
update
the
so
at
least
those
wouldn't
take
us
by
surprise,
yeah.
B
B
B
Not
sync
their
external
projects,
the
oh
right
so
you're
talking
about
other
ecosystems
like
reefs
good.
Yes,
it's
actually
kind
of
a
mixed
bag.
Right
is
we
have
external
projects
that
are
actually
owned
by
kubernetes
SIG's,
and
then
we
have
other
things
like
for
cryo.
That's
actually
a
complete
external
project
with
its
own
governance,
not
really
governed
by
a
cig,
but
they
do
tie
their
releases
to
kubernetes
releases.
So
when
they
go
GA
with
kubernetes
they're
going
to
want
to
coordinate.
B
A
A
In
the
past,
what
we
did
was
we
have
those
umbrella
issues,
basically
for
the
dependent
projects
where
they
would
capture
blocking
issues
or,
or
you
know,
release
blocking
items
in
that
issue.
So
basically
that
stays
open
until
the
very
end
of
the
project,
and
then
that
way
we
don't
have
to
monitor
anybody
else's
repo.
So
all
these
projects
should
have
a
112
milestone
issue.
A
This
stays
in
the
milestone
until
the
very
end
that
is
considered
blocking
until
that
project
actually
gives
us
the
green
light
and
and
then
basically,
we
would
make
the
decision
if
they're
holding
our
release
up
for
a
week
for
something
on
their
end,
then
we
can
kick
them
out
and
say
basically
that
I
really
should
not
be
I've
done.
That
for
this
assignment.
B
A
B
A
B
N
Leave
so
I
think
that
Maru
had
plans
to
but
I
think
they're
gonna
be
railed.
Yeah.
B
B
B
O
G
B
B
A
So
there
is,
there
is
a
you-
can
put
a
PR
against
gates,
audio
for
short
links
currently,
but
somebody
somebody
out
there
who's
who's,
inspired
I
have
wanted
to
make
a
kubernetes
specific
short,
URL,
technically
type
service
for
forever
and
I
even
have
the
domain
Kate
Sh
that
I
would
donate
to
the
project
in
order
to
make
this
happen.
So
if
somebody
is
really
passionate
about
this,
can
can
we
talk
because
I
wanna
I
wanted
to
do
this
forever?
Well,.
A
K
B
K
E
As
much
as
like
right
now,
I'm
finalizing
those
links
and
though
1.12
schedule,
so
we
are
the
ones
who
create
the
documents
that
present
those
links
to
the
community.
So
if
people
are
in
official
Docs,
they
should
see
reasonable
links.
If
those
Doc's
end
up
meeting
switch
to
some
other
owner,
all
of
the
content
would
change
and
the
links
would
be
updated
to
a
new
place
as
well.
I
mean
it.
We
do
have
a
management
point,
whether
it's
a
bit
dot,
leave
admin
console
or
just
the
docs.
We
use
it's
not
completely
out
of
control.
E
I
We've
been
talking
about
that
happen.
De
toros
like
live
editing
for
markdown,
which
is
cool,
but
I,
guess
one
thing
that
I
wanted
to
understand
more
about
what,
if
possible,
was
the
inefficiencies
and
or
the
deficiencies
and
using
clerks
and
if
that's
something
that
we
could
solve
with
you
know
more
more
approvers
or
something
like.
If
that's
a
process
thing
we
can
solve
or
if
it
assessor
Tate's,
using
some
more
lives
tool
like
Google
Docs
or
happened.
B
B
M
When
we
have
I
mean
sending
something
well,
doc
is
huge,
is
like
30
or
60
pages
or
whatever,
and
we
have
a
lot
of
I
mean,
as
you
said
in
some
most
of
it
is
auto-generated,
but
for
sig
leads
actually
to
go
and
care
about
sort
all
those
issues
and
for
people
actually
to
be
able
to
collaborate
together.
We
need
some
kind
of
interactive
real-time
tool
as
changes
happen.
All
the
time
waiting
for
one
or
two
or
three
persons
would
approval
access
to
sig
release
is
all
just
takes
too
much
time.
M
So,
instead
of
having
some
kind
of
process
that
sig
leads,
are
able
or
or
have
write
access
to,
whatever
real-time
tool
were
using
and
then
the
sig
members
write
suggestions
is
and
then
maybe
doing
like
a
checkpoint
every
day
like
I,
think
Nick
did
or
something
or
every
other
day
makes
sense,
and
then
we
actually
can
start
the
process
of
collecting
release
its
earlier
as
well.
I'll
compare
the
real
last
minute.
I
I
I
want
to
reason
about
is
whether
or
not
we
can
have
like
the
tool,
output
into
Google
Docs
and
then
use
Google
Docs
to
like
edit
to
release,
notes
and
then
export
into
markdown,
because
I
have
exported
some
Google
Docs
and
to
mark
down
before
so.
If
the
formatting
would
be
easier,
you
know
something.
I
B
B
Okay,
so
the
couple
of
things
the
cudeman
upgrade
tests,
namely
that
kuben
has
a
set
of
a
great
test
that
they
run
that
are
not
part
of
the
general
test
grid
dashboard,
whereas
the
cudeman
tests
that
are
in
the
test
score
dashboard
are
not
the
ones
that
the
team
themselves
uses
to
see
whether
or
not
Goodman
is
working.
So
that
seems
like
something
to
straighten
out.
Yes,.
M
B
So,
where
is
the
one
cudeman
one
that's
in
upgrade
downgrade
is
one
that
still
has
a
needed
fix
against
it.
So
the-
and
it
just
seems
like
something
too
straight
now.
Okay,
so
we
have
then
other
stuff
that
we've
discussed
that
a
lot
detail
about
moving
tests
in
and
out
I
don't
feel
like.
We
need
more
discussion
on
that,
but
if
somebody
does
interrupt
me
with.
B
M
So
last
time
I
check
the
blocking
dashboard.
It
only
had
like
a
few
like
build
verify
integration
or
something
I
see
it's
grown
a
bit
and
I
guess
people
haven't
just
I
I
mean
myself
from
the
Cuban
team
haven't
been
aware
of.
You
know
us
growing
this
dashboard,
so
yeah
we
haven't
just
added
them
there,
but
we
used
signals
lifecycle
for
tracking
a
long
term.
I
hope
that
we
can
start
moving
the
cube
up
stuff
upgrade
tests
out
up
to
like
commodity
infra
running
on
cubed
M
clusters.
Okay,
but
yeah,
okay,.
B
Okay,
so
other
things,
so
one
of
the
other
calendar
jiggering
that
was
suggested
was
I
suggested.
Having
a
longer
code
saw
something
I
agree
with
because
this
time
around
our
code
working
days,
but
the
problem
is
the
first
two
of
those
working
day
just
waiting
for
the
PRQ
to
clear
meaning.
We
actually
only
have
four
working
days
where
we
can
actually
do
anything
and
and
this
time
around
that
led
to
a
one
day,
release
that
wouldn't
delay
that
would
not
have
had
to
be
there
if
we'd
had
along
the
good
thaw.
B
A
N
B
A
E
We
could
have
a
bit
more
overlap
where
the
one
is
formally
ramping
like
in
a
way
we
started
to
informing
the
team
here
and
let
the
other
one
bleed
in
to
the
start
so
say
we
were.
We
were
actually
releasing
111
next
week
by
plan
I'm
thinking
about
the
112
schedule.
Would
we
get
some
of
these
extra
times?
Do
we
want
to
try
to
do
that,
which
would
mean
a
112
release
in
early
October,
as
opposed
to
late
September?
E
E
B
F
Yeah,
so
first
I
just
want
to
thank
everyone
for
making
this
process
super
smooth.
Overall,
the
communications
process
went
really
well
this
time
around
this.
This
piece
I
want
to
address
because,
with
their
current
process,
we
work
really
closely
with
the
release,
lead
and
features
lead.
F
F
So
I
think
something
I'd
like
to
do
in
1.12
is
look
the
greater
relief
team
in
this
whole
process
into
this
process,
and
really
the
only
expectation
is
that
if
the
reporter
comes
to
you
with
their
request
just
to
loop
in
the
communications
lead,
but
also
open
any
other
ideas
on
that
and
your
dress.
Did
you
want
to
talk
speak
to
the
other
point.
B
Yeah,
what's
exhuming
I
would
say
is
that
some
of
us
work
for
companies
where
we
have
PR
staff,
who
will
be
doing
things
around
the
kubernetes
release,
and
this
can't
be
a
hard
requirement.
Obviously,
but
it
could
be
the
expectation
that
those
PR
people
will
check
in
with
whoever
the
comms
lead
is
just
if
nothing
else
to
tell
the
comms
lead
that
hey
this
article
is
going
to
be
coming
out.
B
Hi
yeah
Jason
pointing
out
that
some
companies
or
sick
press
press
things-
and
that's
certainly
the
case
but
like
I,
know
at
least
one
case
with
an
article
that
I
was
quoted
in
where
it
was
simply
a
matter
that
Kelly
forgot
to
mention
that
to
Caitlin.
It
wasn't
a
case
of
any
kind
of
policy
anything.
B
So
it's
really
useful
for
our
comms
lead
to
know
what's
coming
out,
even
if
they're
not
involved
in
it,
particularly
in
cases
where
the
kubernetes
comms
lead
may
be
reaching
out
to
a
particular
reporter,
and
that
reporter
may
have
already
started
the
process
of
doing
an
article
with
one
of
the
kubernetes
supporting
companies
and
in
cases
where
we
can
share
that
information.
It
makes
everybody's
life
easier
to
do
so.
F
Yeah
and
we
have
so
for
anyone
we
use
as
a
spokesperson
on
the
release
team,
we
have
their
PR
team
sit
in
on
those
calls,
so
they're
lifting
from
the
start.
I
think
we
just
maybe
need
to
expand
this
to
other
members
of
the
release
team
who
have
someone
on
their
PR
team
who
needs
to
be
included
or
who
may
be
receiving
media
opportunities
separately.
I.
E
Really
appreciate
you
bringing
this
up,
there's
somebody
who's
mostly
been
a
heads-down
engineer
and
is
now
in
this
lead
role
and
having
press
people
contact
him.
This
has
been
a
big
change
and
for
me
so
having
the
awareness
of
how
this
stuff
happens,
this
there's
not
magical
that
you
all.
This
is
your
profession
and
that
we
can
rely
on
you
and
and
supplement
to.
You
is
really
useful
thinking.
E
B
I
was
going
to
suggest,
could
you
and
the
CNC
F
arranged
in
an
online
media
training
for
members
of
the
release
team.
F
Yeah
and
I
will
have
Kristin
jump
in
on
that
I
was
gonna,
say
it
might
be
helpful
for
the
release
like
in
one
of
the
initial
release,
meetings
to
almost
do
like
a
5
to
10
minute,
just
media
overview,
or
something
like
that.
Kristin
do
you
wanna
speak
to
what
we
could
do
from
a
CNCs
perspective
on
on
a
training,
I
think
you're
on.
D
B
No,
there
was
like
I
said
there
were.
There
was
actually
a
particular
article,
the
particular
reporter
that
Caitlyn
had
reached
out
to.
He
had
not
responded
to
her
and
he
was
doing
an
article
with
Red
Hat
about
the
coup.
Bernays
release
and
Caitlyn
did
not
know
this
and
there
wasn't
any
good
reason
for
it.
It
was
just
people
did
not
share
information.
F
F
F
B
B
F
O
You
hey
there.
Oh
there,
we
go
okay,
so
sorry
I'm
behind
a
few
questions.
Yes,
we
can
prep
everybody,
so
we
usually
put
together
a
media
FAQ
for
the
identified
spokespeople,
so
that
just
gives
everybody
some
key
messages.
Some
talking
points
any
sticky
questions
we'll
have
some
answers
too.
So
we'll
just
make
that
available
to
everybody.
O
The
only
reason
is,
it
isn't
usually
widely
shared
it's
just
because
people
aren't
usually
all
taking
interviews,
but
now
we
can
just
kind
of
share
that,
with
the
whole
release
team
that
way,
if
anyone
has
any
requests,
they
can
look
at
that
and
then,
as
Caitlin
was
mentioning,
we
just
kind
of
want
to
be
looped
in
if
reporters
are
reaching
out
to
you.
I
think
that
was
him.
That
was
mentioning
that
reporters
were
starting
to
reach
out
to
you.
O
So
just
that
way
we
can
help
answer
any
questions
we
can
be
listening
in
on
you
to
help
take
any
action
items
and
just
keep
everybody
kind
of
on
a
unified
messaging
front,
and
then
we
can
also
coordinate
the
opportunities.
Any
action
items
that
kind
of
stuff
the
the
issue
that
everybody
was
mentioning.
There
was
a
reporter
who
wasn't
interested
in
holding
the
embargo,
so
that
was
a
conversation
that
we
had
where
we
said.
O
B
All
that
sounds
good,
so
I'm
gonna
mention
one
more
thing
and,
and
then
I
think
we're
gonna
turn
it
over
to
Jason
wind.
This
up
and
the
one
of
the
things
I
didn't
get
a
chance
to
mention
other
contacts
that
I
guess
I'm
dumping
in
Isis
lap.
Now
one
of
the
things
I'd
meant
to
do
is
release
lead
was
to
actually
have
some
meeting
/tracking
of
just
the
shadow
shadows,
to
make
sure
that
the
shadows
were
getting
the
training
that
they
needed,
etc.
B
And
you
know
in
for
that
matter
to
monitor
their
status,
because
we
had
a
couple
of
shadows,
drop
out,
yeah
and
I.
Just
kind
of
ran
out
of
time
to
do
this,
and
since
we
have
a
shadow
release,
lead
I'm
suggesting
that
that
might
be
a
responsibility
of
the
shadow
release
lead
on
is
to
to
sort
of
lead
the
shadows,
because
we
do
have
this
mentoring
process,
but
part
of
it
involves
checking
with
the
mentees
as
well
as
the
mentors.
C
B
A
H
A
Would
respectfully
request
that
if
you
feel
like
you're
on
the
hook
to
do
something
put
your
name
down
in
the
to
Do's
and
the
thing
that
you're
committing
to
do,
because
that
is
helpful
for
us
to
track
otherwise
we'll
be
hitting
a
lot
of
these
issues
during
the
cig
release
meetings
in
the
future
and
that's
sig
release
is
going
to
be
canceled
today,
because
we
obviously
did
this
in
the
holiday.
So
any
rate.
Thank
you,
everybody
and
have
a
great
rest
of
your
day
and
if
you're
in
the
u.s.
have
a
good
holiday,
yep.
B
And
again,
thank
you
so
much
pretty
Glee
to
everybody
on
the
111
release
team,
but
everybody
else
and
doing
so
much
to
actually
make
this
a
great
release,
best
release
team
ever
I
Tim,
hopefully
Tim
will
be
able
to
say
that
the
112
release,
but
but
right
now
the
you
111
are
the
best
release
team
that
that
we
have
had
so
far.
Thank
you
thanks.
Everybody
bye.