►
Description
A
Welcome
everybody:
this
is
the
kubernetes
114
release
team
meeting
today
is
Monday
January
28th.
We
are
at
week
4
of
the
kubernetes
114
release
life
cycle.
This
meeting
is
being
recorded
and
will
be
posted
to
a
publicly
available
YouTube
playlist.
So
please
keep
in
mind
that
the
kubernetes
community
adheres
to
a
code
of
conduct
that
basically
boils
down
to
don't
be
a
jerk.
A
A
So
my
goal
is
to
make
this
all
the
outstanding
work
that
the
release
team
has
to
deal
with,
and
the
rule
of
thumb
I'm
trying
to
use
is,
if
I'm
working
on
a
thing
I
will
assign
myself
to
it
with
the
slash
assign,
but
if
I'm
not
assigned
to
it.
That
means
that
I
recognized
that
the
Docs
or
something
need
to
be
updated,
but
I
personally,
don't
have
the
bandwidth
to
commit
to
doing
that.
A
Also,
if
you
want
to
know
where
I
got
this
handy-dandy
github
theme
talk
to
me
afterwards,
I
was
inspired
by
our
we're.
Looking
at
a
replacement
for
guru,
nadir,
that's
got
a
dark
theme,
and
now
I
just
can't
seem
to
help
myself.
So,
for
example,
there
were
some
people
asking
about
the
kubernetes
release,
team
or
kubernetes
milestone,
burndown
team
and,
like
I
realized,
that's
kind
of
not
super,
well
documented,
it's
kind
of
documented
in
these
issues.
If
we
could
turn
that
into
actual
documents,
that
I
can
point
people
to
that'd
be
great.
A
Let's
see
the
other
thing
that
I
am
working
on
is
trying
to
assign
ownership
of
some
of
our
release.
Blocking
jobs.
I'll
probably
defer
to
Maria
to
talk
a
little
bit
more
about
this,
but
the
short
version
is
if
we're
trying
to
enforce
their
release
blocking
criteria.
So
if
I
go
to
kubernetes
SiC
release,
if
I
go
to
release
blocking
jobs,
we
have
a
list
here
that
describe
pretty
much
all
of
the
reasons
we
think
jobs
should
belong
in
the
release
blocking
dashboard,
at
least
talking
to
release
blocking
dashboard
as
I'm
sure
you're.
A
If
the
job
happens
to
fail
for
whatever
reason,
and
so
right
now,
I'm
hashing,
that
out
in
the
description
field
of
the
jobs
thing
on
scrolling
past
the
code
that
actually
enforces
the
thing
so
I'm,
adding
a
description
field
where
I
think
best
guess
that
a
lot
of
the
jobs
are
going
to
be
owned
by
the
sync
release
team.
Under
the
guise
of
we
have
people
on
the
CI
signal
role,
who
should
be
monitoring
a
lot
of
the
release,
blocking
jobs
and
then
federating
out
the
failures
to
the
stakes
that
own
those
individual
test
failures.
A
A
So
one
of
the
next
steps
is
to
go
around
and
make
sure
that
SIG's
are
aware.
This
is
happening.
I
kind
of
don't
necessarily
want
to
be
a
volunteer,
but
at
the
same
time,
I
really
do
want
to
end
this
week
with
email
addresses
for
all
of
these
I
also
have
some
other
two
do's
that
I'm
aspiring
to
get
to
like,
maybe
describe
what
the
if
I
could
automatically
provide
a
link
to
the
file
that
defines
this
job.
That
can
maybe
help
people
answer.
A
Questions
like
what
is
this
job
actually
doing
if
they
can
read
like
the
regular
expressions
and
stuff
that
are
used
to
skip
the
job
and
then
the
other
thing
that
I
had
spent
some
time
doing
is
I
broke
up
the
number
of
dashboards
that
we
have
for
test
grid.
So
there
again,
this
is
kind
of
to
make
Maria's
life
easier
and
the
lives
of
the
CI
signal
people
easier
and
just
the
lives
of
the
project
easier.
In
general,
there
are
three
dashboards
that
have
anything
to
do
with
the
currently
in
development
release.
A
Its
sake,
release
master
blocking,
which
we
already
know
about
sake,
release
master
informing,
which
are
jobs
that
might
provide
useful
signal,
but
we're
not
going
to
be
gating
on
or
sweeping
over
as
quickly
and
then
sake,
release
master
upgrade.
So
there
are
other
there
were
other
jobs
like
coops,
ETL,
skew
or
master
upgrade
optional
or
whatever.
If
you
really
want
to
know
where
those
jobs
went,
I
didn't
delete
them
they're,
just
on
other
dashboards
and
I
can
link
you
to
the
PRS
that
made
these
things
happen.
A
Our
upcoming
milestones
and
I'll
just
stop
sharing
the
houses
you
all
should
see.
My
smiling
face,
so
enhancement
freeze
is
tomorrow
enhancement,
freezes
end
of
day
Pacific
time
tomorrow.
We're
not
necessarily
enforcing
this
with
any
automation,
though
I'm
happy
to
listen
to
any
suggestions.
Claire
makes
instant
enhancements,
fries
means
you're,
you
must
have
an
enhancement
issue
open,
it
must
be
in
the
milestone
and
it
must
have
a
cap
associated
with
it,
and
that
cap
must
be
in
the
implementable
status.
A
Hannes
is
also
going
to
cut
the
next
alpha
build
of
the
114
release
for
us
super
looking
forward
to
that
and
I'd
like
to
do
the
issue
where
he'll
track
his
progress
on
that.
Looking
a
little
bit
further
out
two
weeks
from
tomorrow,
we'll
be
cutting
the
next
build
I.
Think
that's
everything.
I
have
any
questions
before
I
hand
over
to
Claire.
B
Right
so,
as
mentioned
enhancements
freeze
is
tomorrow,
Zod
Pacific.
So
unless
someone
has
any
good
suggestions
for
automation,
my
plan
was
Wednesday
morning
to
mark
any
issues
that
don't
have
a
cup
as
deferred
for
the
next
release
and
then
send
out
an
email
and
ping
on
those
issues,
letting
folks
know
that
they've
been
deferred.
B
Currently
we
have
42
enhancements
that
are
slated
of
those
42
26
have
a
cup,
so
we're
missing
a
little
over
10
I
can't
do
math
this
quickly,
but
we
have
an
exception
process
that
I've
dropped
a
link
to
for
folks
who
want
to
read
up
on
what
that
is.
So
any
item
that
doesn't
have
a
cup
that
gets
bumped
will
need
to
fill
out
the
exception
process
to
get
added
back
in
or
any
new
issues
that
come
up
that
want
to
make
114
after
kind
of
day
tomorrow
will
need
to
file
these
an
exception.
C
A
A
D
Okay,
good
awesome,
so
main
piece
of
news
for
this
week
is
that
there
seems
to
be
a
PC
capacity
issue
that
is
causing
lots
of
master
blocking
in
master
upgrade
jobs
to
fail.
That
was
the
majority
of
failures
that
we're
seeing
at
the
moment
in
first
grade,
I
believe
that
there
is
an
open,
I
guess
tract
of
work
to
fix
it.
So
I'll
just
follow
up
on
that
over
the
next
couple
of
days.
D
Other
than
that
there
is
an
issue
in
six
storage,
I
believe
that
I
haven't
just
heard
back
from
the
sake,
so
I've
poked
them
today
on
the
slack
channel,
because
it's
also
failing
on
their
dashboard,
so
I
just
want
to
see
what
sort
of
they're
up
to
and
I
think
that's
about
it.
At
the
moment,
you've
covered
most
of
the
things
that
I
want
to
talk
about
related
to
the
separation
between
blocking
and
informing.
D
So
it's
like,
essentially
anything
that
used
to
being
blocking,
but
that
didn't
run
often
enough
and
was
not
quick
enough
in
a
way
has
now
moved
to
to
informing
I
will
keep
it
sort
of
the
back
of
my
head
to
see
if
there
is
part
of
these
tests
or
some
of
these
tests
that
could
make
their
way
back
to
blocking
in
the
future.
But
for
now
it's
so
much
better
to
have
everything
sort
of
a
bit
more
flame.
They
separated.
E
E
Yeah,
it's
more
investigation
and
other
news,
triage
handbook
has
been
rewritten.
The
link
is,
there
has
been
reviewed
and
it's
needs
a
meetin
LGD
MP
to
be
merged.
I
wrote
a
piece
on
on
case
law
and
filtering
in
general
regarding
the
later
stages,
it's
still
short
and
abstract,
but
it
could
be
expanded.
E
E
A
A
A
Okay
and
my
I
I'll
put
it
this
way.
I
don't
want
to
sound
like
a
curmudgeon
I
I
was
around
one
six.
When
we
did
the
flight
reports,
if
we
don't,
we
don't
generally
do
them
now,
and
sometimes
that
could
be
taken
as
evidence
that
they
didn't
necessarily
work
or
it
could
be
taken
as
evidence
that
the
person
who
really
cared
about
that
they
can
carry
it
forward,
see,
for
example,
using
github
issues
to
track
release
being
cut.
A
That's
that
stopped
after
Anthony
stopped
leading
their
release,
but
I
really
like
that
as
an
idea,
so
I'm
carrying
it
forward
to
this
release
and
I
really
appreciate
Hannes
helping
out
there.
So
if
this
is
something
you'd
like
to
carry
forward
this
release,
that
that
sounds
great
I
shared
some
details
with
Maria
about
the
many
publicly
available
data
sets.
We
have
that
would
allow
you
to
compute
this.
A
We
have
tried,
in
the
past
to
like
set
up
a
bot
to
automatically
file
the
top
ten
flake
clusters,
as
identified
by
our
triage
dashboard
and
a
number
of
other
things
in
historically.
The
statistics
have
not
been
that
great
at
it
encouraging
human
involvement.
It's
not
until
a
human
actually
goes
and
starts
talking
to
people
that
we
have
really
seen
any
attention
on
these
issues,
but
anything
we
can
do
to
increase
the
visibility
of
the
state
of
today
and
the
progress
we're
making
is
welcomed.
A
So
we
do
have
a
big
old
e
flaking
board
in
general,
if
you're
not
aware
I'll
post
a
link
to
that
in
the
chat
as
well,
that
Maria
sort
of
helped
put
together
and
I
went
through
and
took
every
existing
issue.
That
I
was
aware
of
in
the
project
that
had
anything
to
do
with
D
flaking,
including
the
creation
of
dashboards
and
put
it
on
this
board.
This
is
something
that
I
would
welcome.
A
Help
from
literally
anybody
on
doesn't
even
have
to
be
the
release
team
if
you're
interested
in
test
health,
if
you're
interested
in
visualizations
to
help
us
keep
track
of
this
if
you're
interested
in
incentivizing
good
behavior.
If
you
are
interested
in
digging
through
the
fine
notes
that
Maria
took
during
our
multi
hour
discussion
about
this
across
multiple
days
at
coop
con
and
identifying
the
the
work
items
that
are
not
on
this
board,
because
I
suspect
there
are
plenty
and
Nico
I
think
you
were
there.
I
would
also
really
appreciate
that
help.
E
A
G
Yes,
so
this
week
we
merged
about
80
peers
in
kk.
Apart
from
that,
we
had
an
exciting
week
for
prowl.
There
were
two
outages
one
caused
because
of
a
bad
config
change
and
the
other
one,
because
we
changed
the
reporting
behavior
from
plank
to
crier
and
that
caused
us
to
lose
like
run
out
of
data
tokens.
Both
of
those
have
been
fixed
now
or
I,
believe
reverted,
and
there
were
notification
sent
out
to
ke
dev
and
also
worked
on
the
what
went
wrong
dog.
G
Apart
from
that,
we
also
have
a
behavioral
change
from
tied
the
mood
from
from
using
included
repose
to
excluded
repos
for
the
kubernetes
org,
and
the
main
change
that
would
affect
us
is
that
newly
created
repos
in
the
org
will
automatically
be
selected
for
using
tag
and
since
I
am
coincidentally,
the
uncle
I
just
squeeze
in
that
I'm
working
on
the
GC
out
of
capacities.
Donation
and
that's
me
well,.
A
D
H
A
A
A
A
F
So
still
need
the
metrics
as
far
as
docs
in
the
universe,
president,
that's
gonna
be
a
little
easier
to
get
once
we
have
the
enhancements,
freeze,
really
no
kind
of
scope
down
what
kind
of
enhancements
were
looking
at.
What
needs
stock
so
more
to
come.
They're
submitted
the
docs
date
for
review
Aaron
and
also
I,
saw
you
sent
out
the
sig
ducts
that
was
a
under
site
on
my
behalf,
so
I
appreciate
you
doing
that.
F
Definitely
want
to
get
their
input
on
those
day
seem
to
be
pretty
much
in
line
with
the
112
and
113
release
as
far
as
how
they
were
kind
of
timed
roughly
so
it
seems
to
have
worked
well
for
us
in
the
past
and
so
once
that
kiss
murder
should
be
good
to
go
there
Bobby.
So
we
can
wait
for
for
everyone
to
buy
in
and
then
also
I
sent
a
PR
an
issue
out
in
the
K
website,
repo
for
the
localization
folks-
and
this
is
a
advice
from
Tim
Fogarty,
the
last
sig
Docs
lead.
F
He
said
that
the
localization
efforts
and
there's
multiple
coordination
of
different
branches,
a
little
complex
to
merge
kind
of
at
last,
like
when
everything's
on
fire
of
the
day
of
the
release,
so
he
suggested
reaching
out
to
them
early,
seeing
what's
the
best
way
to
contact
you.
What's
the
you
know,
preferred
method
and
then,
along
the
lines
of
me,
recreating
the
docks
kind
of
role
play
book
handbook,
whatever
you
want
to
call
it
I
want
to
make
sure
I
include
the
localization
scope
in
there
as
well.
F
F
J
Sam,
so
the
initial
draft
PR
was
submitted,
so
one
of
the
things
were
also
wanting
to
work
on
is
within
the
release.
Are
the
release
tooling
or
release?
Note
tooling
and
I
believe
Jeff
actually
submit
a
PR
to
move
that
under
cig
release
is
haven't
support
kind
of
automate,
some
of
the
verbage
that
we
use,
because
that's
been
a
common
problem
that
we've
had
in
the
previous
releases
is
what
verbage
within
the
release
notes
we
pull
down
and
I
know.
Lindsay
and
Jeff
had
some
thoughts
around
that.
J
So
that's
some
of
what
we'll
be
working
on
also
putting
together
and
based
on
kind
of
Mike's
presentation
he
did
at
cube.
Con
is
getting
some
best
practices
for
the
SIG's
for
the
release
notes.
One
of
the
things
we
also
want
to
address
with
that
is
getting
in
release,
notes
and
major
themes
earlier
than
later,
because
previous
releases,
that's
also
kind
of
been
the
issue
that
we're
getting.
J
J
A
Yeah
I
think
I
saw
something
in
releases
past
about
doing
it
on
a
weekly
basis,
and
this
was
one
of
those
things
where,
like
I
wasn't.
I
wasn't
entirely
sure
how
much
of
this
should
be
explicitly
spelled
out
versus,
suggested
and
left
up
to
the
individual
leads
and
called
out
on
their
own
individual
schedules.
That's
kind
of
gets
back
to
the
issue.
A
So
I
hear
you
I
agree
that,
like
maybe
less
frequent
updates
now
could
maybe
make
sense
on
this.
But
on
the
other
hand
like
just
doing
it
every
week
before
this
meeting,
so
we
could
see
like
a
fresh
copy
of
the
release.
Notes
might
might
be
a
good
habit
to
get
into,
because
this
is
the
calm
before
the
burn
down.
Basically
yeah.
J
A
C
C
E
A
Specifically,
I've
been
not
super
involved
in
that
discussion.
There's
a
meeting
on
the
cig
release,
YouTube
channel
that
I
think
folks
sort
of
disgusts
that
kepanis.
What
where
I
as
release
lead,
am
most
interested
/
concerned.
/
paranoid
/
excited
is
sort
of
the
integration
touch
points
of
this
effort,
because
the
really
conservative
version
of
me
wants
to
make
sure
that,
like
it's,
it's
all
done
before
code
freeze
that
that
we
don't
like
completely
change
how
we're
cutting
everything
right
before
we
actually
cut
everything
and
I
present.
A
C
So
I
did
not
have
as
much
time
as
I
wanted
to
go
through
the
comments
on
the
cap,
I
opened
or
the
other
caps
that
have
been
opened
in
regards
to
packaging
or
promotion
of
artifacts
and
that
that's
a
thing
I
planned
for
the
coming
days.
To
be
honest,
I
don't
see
much
of
the
stuff
happening
in
114,
because
it's
just
too
late
but
I
said
I
need
to
catch
up
on
all
the
things
and
I
really
cannot
answer
your
question
on
on.
C
Where
are
we
standing
right
now
really,
but
I
said
I
tried
to
do
that
the
next
day
and
then
try
to
summarize
this
in
some
form
or
the
other,
maybe
in
in
one
of
those
caps
or
somewhere
else,
but
I
need
to
get
an
overview
myself.
First,
but
again,
I
don't
see
much
happening
or
I,
don't
see
a
big
change
for
114.
C
That
is
true.
That
is
one
of
the
like
one
of
the
main
issues
which
kind
of
all
or
many
of
those
caps
floating
around.
Try
to
address
that
might
change
I'm,
not
sure
about
that.
But
I
would
me
as
a
release.
Branch
manager
would
only
do
it
very
consciously,
so
only
if
I'm
sure
that
that
there
is
not
nothing
braking
and
not
in
a
like,
not
alone,
I
won't
flip
the
switch
alone.
A
So
one
other
general
program,
administrivia
thing
that
comes
to
mind
after
we've
been
talking
about
all
of
this,
recognizing
that
I've
been
kind
of
slow
on
documenting
all
the
words
that
come
out
of
my
mouth
with
respect
to
caps.
One
of
the
things
that
I've
been
trying
to
do
is
that
caps
as
a
process
used
across
the
entire
project
to
manage,
enhancements
and
features
that
land
in
kubernetes
is
something
that
I
have
asked
sake
p.m.
to
take
on
as
an
effort.
A
And
so
what
I'm
trying
to
have
us
do
is
take
any
discussion
about
questions
about
the
what's
and
the
whys
and
caps
and
have
those
over
in
the
sake
p.m.
slack
channel.
There
are
absolutely
going
to
be
questions
about
what
has
to
be
in
by
enhancements.
Freeze
today
and
I
will
try
and
answer
those
in
the
cig
release
channel.
But
if
we
start
asking
questions
about
like
what
all
needs
to
be
in
there
or
where
should
I
look
for
this
stuff,
I
want
us
to
have
that
conversation
in
cig
p.m.
A
and
this
is
purely
to
preserve
my
own
sanity,
because,
historically,
when
I've
had
to
talk
about
changing
how
we
do
things
with
respect
to
caps,
I've
had
to
get
a
talk
to
sake,
release
sig
architectures
sake,
PM,
say,
contributor
experience,
just
just
all
the
SIG's,
and
so
one
place
for
taps,
SiC
p.m.
so
if
people
are
pinging
you
about
this
and
you're
having
these
discussions
privately,
maybe
consider
if
it
would
be
valuable
for
other
people
to
hear
the
the
questions
and
answers
over
in
the
sig
PM
slack
channel.