►
Description
https://bit.ly/k8s114-minutes
https://bit.ly/k8s113-retro (part 3)
A
So
I
see
that
we
are
recording
I,
think
I've
not
been
the
greatest
about
trimming.
The
beginnings
of
these
meetings.
I
may
change
the
settings
so
that
it
doesn't
auto
record
until
somebody
presses
the
button.
So
having
said
all
of
that,
if
you're
here
you
are
at
the
weekly
114
release
team
meeting,
this
is
week.
Three
today
is
January
the
21st
and
you
are
being
recorded
and
will
be
posted
to
a
publicly
available
YouTube
later.
A
If
you
are
here,
if
you
would
be
so
kind
as
to
put
your
name
in
the
meeting
notes
under
the
attendees
section,
then
well
know
you
were
here,
I
guess:
I'll
go
ahead
and
put
myself
down
as
the
host
for
this
and
I
will
roll
into
my
update
for
the
week
and
I'm
super
excited
to
hear
updates
from
everybody
else,
so
they
I
have
a
link
to
the
contact
spreadsheet,
where
I
have
contact
info
for
all
of
the
different
roles
for
the
114
release.
What
I
would
like
to
see
is
contact
info
for
your
shadows.
A
As
you
choose
your
shadows
from
the
outcomes
of
last
week's
survey,
I've
had
a
lot
of
people.
I've
had
a
couple.
People
ping
me
about
what's
a
reasonable
number
of
shadows,
and
so
I'll
just
say
up
front
that
my
my
stance
on
this
is
your
shadows.
Are
your
responsibility
I'm
not
going
to
tell
you
how
to
do
your
job
with
your
shadows?
A
I
will
share
with
you
what
I
have
chosen
to
do
with
my
shadows,
although
I'm
a
little
bit
of
a
special
case,
because
the
criteria
for
being
or
lease
lead
shadow
is
basically
the
same
criteria
for
being
a
release.
Lead.
So
I
know
that
my
shadows
have
already
been
through
the
release.
Process
and
I
know
what
I
know
they
already
understand
what
time
commitments
they
have
to
bring
to
the
table,
but
I
basically
have
chosen
one
to
two
shadows,
because
I
am
a
very
busy
person.
Life
gets
in
the
way.
A
I
may
not
be
able
to
show
up
to
each
and
every
one
of
these
meetings
and
I
want
to
trust
them.
Well
enough
to
be
able
to
pretend
to
be
me
if
I'm
not
around
so
that
means
I
expect
these
1
to
2
people
to
show
up
to
this
meeting
to
get
some
context
in
color
or
watch
recordings.
If
they
can't
show
up
just
understand,
generally
speaking,
how
things
proceed,
I
expect
them
to
be
reviewing
any
changes.
I
make
to
the
playbook
as
I
go
along.
A
A
B
A
A
Okay,
I
think
what
would
be
helpful
as
we
roll
through
each
person's
updates
is
just
a
little
brief
update
on
where
you
are
with
your
shadows,
selections.
Some
other
administrivia
I
have
to
do
I
apologize
makeup.
Project
management
does
not
come
to
me
super
naturally,
so
I
think
I've
fallen
down
on
some
two
key
components.
One
would
be
a
114
release
calendar
that
y'all
can
subscribe
to.
That.
Has
things
like
the
milestones
as
dates
and
has
the
appropriate
meetings
in
place
and
I
also
haven't
been
sending
out
weekly
email
updates?
A
A
So
there
is
a
template.
Update
to
the
cap.
I
would
appreciate
eyes
on
that
to
see
if
that
has
roughly
speaking
the
right
content.
I
am
taking
caps
as
a
sub
project
and
handing
that,
over
to
sake,
p.m.
because
I
feel
like
product
project
and
program
managers
pick
2p.
All
three
of
them
should
be
showing
up
to
say
p.m.
and
they
probably
have
ideas
and
experience
on
how
best
making
that
on
how
to
best
make
that
process
work
for
everybody.
A
So
there's
that
and
then
the
next
upcoming
milestone
that
I
am
aware
of,
is
enhancements,
freeze,
which
is
at
the
end
of
January.
If
we
have
time
at
the
end
of
this
I,
also
volunteered
that
we
could
finish
the
rest
of
the
113
release
retro
because
we
did
not
get
to
it
during
last
week's
sake,
release
meeting
any
questions.
C
Are
yes
so
my
update
as
Erin
said
between
myself
him
and
his
shadows?
We
went
to
a
bunch
of
SIG's
last
week
and
kind
of
give
them
updates
on
wanting
cups
for
everything
and
checked
in
on
what
enhancements
were
slated
in
addition
to
that,
I
went
through
and
pained
all
of
the
open
issues
in
kubernetes
enhancements
that
had
not
gone
stale
without
stating
intent
of
doing
something
in
1:14
and
they
saw
in
feedback
from
those
of
plans.
A
One
other
bit
of
administrivia
that
comes
to
mind
when
you
have
chosen
your
shadows.
If
you
could
make
that
selection
by
peering
opening
a
PR
to
the
release
team
file
that
we
can,
that
way,
we
can
sort
of
have
written
down
like
who
they
are
and
what
their
handles
are.
So
I'll
drop
a
link
to
that
in
chat.
A
D
Absolutely
so
see,
I
signal
has
has
not
many
new
since
last
week,
which
could
be
a
positive,
but
there
are
two
failing
jobs
in
master
blocking
one
one
for
seek
storage
and
one
for
sick
scalability.
The
second
1/6
scale,
everything's
already
on
topples,
I'll
just
work
with
six
storage
over
the
next
couple
of
days
to
see
if
they
can
start
work
on
the
first
one
Mustard's
upgrade
is
looking
quite
boring
by
wearing
I
mean
pretty
much
read
across
the
board,
but
the
goods
in
quotes
news
is
that
it
seems
that
the
it's
the
same.
D
That
goes
for
most
of
the
failures
and
there's
not
an
issue
for
them
in
terms
of
shadows.
It
was
quite
nice
to
see
so
many
people
interested
in
CI
signal
I've
gone
through
the
candidates
this
morning
and
have
picked
them
and
now
in
the
middle
of
reaching
out
to
confirm
that
they're
still
available
and
interested
and
hope
to
PR
in
names
sort
of
in
the
next
couple
of
days.
A
D
E
Okay,
so
I
also
finalized
on
my
shadows.
There
were
about
more
than
60
plus
responses
for
that
and
I
finalized
on
three
of
them
and
all
three
of
them
confirmed
it
and
I
also
entered
and
P
heart
to
the
release
team.
So
that's
finalized
now
and
then
the
number
of
PRS
he
has
emerged
in
KK
this
week
or
about
84
and
while
gathering
this
information
I
also
happen
to
notice,
as
the
velodrome
is
pretty
slow
down
now,.
B
A
D
F
A
Cool
well
just
to
read
out
for
Jim
since
he's
kind
enough
to
update,
so
he
does
have
his
shadow
selected.
You
informed
them
via
slack
and
we're
gonna.
Let's
see
he's
also
gonna
send
out
notice
to
anybody
who
did
not
get
selected.
You
had
Doc's
as
one
of
their
preferences
and
we'll
start
checking
out
where
we
are
with
Doc's
PRS
in
general,
as
we
get
there
in
the
schedule.
G
Those
Dave
Dave
yeah,
so
we
have
shadow
selected
and
confirmed
so
I'll,
do
a
PR
to
the
release
team
filed
today.
I'll
also
be
submitting
the
PR
for
the
initial
draft
of
the
release
notes
today
and
some
things
that
our
team
will
be
working
on
is
automating
some
of
the
verbage.
Through
the
release
note
tools,
there
is
one
other
outstanding
item
I
had
for
out
of
tree
release,
notes.
I
know
this
was
a
big
topic
of
conversation.
G
A
A
B
A
G
H
G
B
B
A
J
J
J
A
Could
you
do
me
a
favor
and
invite
the
sake
release
kubernetes,
cig
release,
Google
Groups
comm,
address
this.
The
reason
I'm
asking
about
this
and
the
one
of
the
sig
release
chairs
is
on
here.
So
he
can
correct
me
if
I'm
wrong,
but
I'm
trying
to
get
us
in
the
practice
of
if
there's
a
sake,
release
related
sub
project.
That's
got
its
meeting
going
on.
A
I
highly
encourage
you
to
participate
in
that
discussion.
If
you
haven't
had
a
chance
to
provide
your
input,
because
that
is
absolutely
how
we
roll
around
here
but
I-
think
that
we're
looking
for
people
to
be
sub
project
owners
for
the
release.
Engineering
effort,
honest
since
you
wrote
since
you're
running
on
this.
Maybe
I
should
reach
out
to
you
separately
on
this.
A
A
So
I
have
a
couple
people
from
Google
who
are
interested
in
stepping
up
there
and
I
know
there
are
a
number
of
people
from
heavy
Oh,
slash
VMware,
slash
just
say,
cluster
lifecycle
in
general,
who
are
interested
in
helping
out,
and
there
was
a
bit
of
an
off-site
last
week
that
maybe
didn't
quite
allow
communication
to
flow
as
freely
there.
So.
J
A
A
A
A
K
Sounds
fair
to
me
and
I'm,
just
looking
at
the
the
list
of
things
and
I'm
realizing
so
formally,
we
don't
have
eyes
and
Josh
who
were
half
of
the
names
on
the
remaining
items.
Not
here.
I
think
that
we
could
discuss
these
still
I
think
that
there
are
things
that
were
brought
up
and
we
have
visibility
into
the
names
next
to
them.
Are
the
people
who
brought
them
up.
K
B
K
The
shared
dock
there
for
folks
who
are
following
along,
if
you
scroll
down
a
couple
of
pages,
basically
to
the
end
of
the
document,
nearly
just
above
the
action
items
table
you'll,
see
a
big
dashed
line
that
says
content
below
to
be
discussed
and
next
cig
release.
Meeting
we've
failed
at
that
a
couple
of
times,
but
here
we
are
so
there's
four
bullets
there,
the
first
one
there
was
some
question
or
discussion
around
what
fixes
and
PR
is
qualified
to
get
into
master
during
code
freeze,
so
priority
critical
urgent.
K
K
And
this
is
also
something
that
Alexander
and
I
way
there
have
discovered?
We
need
to
similarly
weigh
post-release
in
patch
management,
because
we
have
a
variety
of
things
that
get
proposed
there.
So
the
the
formal
definitions
and
that
the
gating
criteria
are
a
weak
area,
I
think
is
what
people
have
perceived.
I
saw.
This
also
is
release
leap
of
prior
to
ice.
K
Do
does
anybody
on
the
call
have
thoughts
on
how
we
might
better
define
those
criterias
or
perhaps
one
of
the
ways
about
this
would
be.
For
example,
Alexandra
and
I
have
been
talking
about
trying
to
figure
out
how
we
do
this
as
we
go
through
it
and
writing
it
down,
but
we
could
also
reach
out
to
ice
for
113
or
I.
Have
my
experiences
from
112.
K
We
could
talk
to
Josh
and
Jace,
for
example
prior,
but
maybe
we
could
could
formalize
that
the
other
the
other
option
between
formalizing,
it
is
to
say
it
is
left
to
the
folks
discretion,
which
is
the
way
things
are
kind
of
right
now,
but
that
that
is
fuzzy
and
that
I
think
that's
why
I
bring
zit
up?
Can
we
can
we
remove
some
of
that
fuzziness,
so
thoughts
from
anybody.
M
Else,
a
developer
and
contributor
than
parodies
manager
that,
for
me
it
seems
very
confusing
if
we
accept
that
priority
critical
urgent
means
something
different
depending
on
the
branch
the
PR
is
against
or
depending
on
the
time
in
the
release
cycle.
Right
now,
it's
like
it
sounds
a
lot
like
people
are
using.
This
label
like
I
want
to
match
it,
even
though
it's
freeze
or
even
though
it
is
to
a
stable
branch
and
that
doesn't
sound
good.
L
A
K
Can't
speak
to
a
I
SH
was
seeing,
but
I
felt
like
his
release.
Team
lead
I
actually
had
very
little
documented
on
that,
and
similarly,
from
the
perspective
of
patch
management,
we
do
have
the
patch
manager
a
role
handbook.
They
do
some
words
around
this,
but
it's
actually
one
of
the
ones.
That
goes
into
a
lot
of
effort
to
paint
a
broad
picture
of
a
lot
of
variability
and
options
that
are
open
for
your
discretion.
A
So
part
of
me
feels
like
we
may
be.
What
you
are
describing
is
that
we
haven't
flushed
this
out
enough,
or
maybe
it's
not
written
for
the
appropriate
number
of
audiences
and
another
another
thought
just
if
I
scroll
start
up
to
the
top,
where
it
talks
about
the
the
TLDR
portion,
because,
sorry,
that's,
like
kind
of
the
only
part,
I
look
at
they're
like
all
these
additional
things
that
have
to
be
added
to
get
your
PR
to
land
during
code
freeze.
A
A
We
like
gradually
ramped
up
that
sorry,
so
I
guess
what
I'm
trying
to
say
is
we
used
to
gradually
ramp
that
friction
up
by
introducing
code,
slash
phase
and
the
current
/
phase
just
said
it's
got
to
be
the
pr
has
to
be
in
the
milestone
and
we
gate
who
is
allowed
to
apply
the
milestone
command
by
the
milestone,
maintainer
x'
team,
which
we
just
purged
and
refreshed
this
year.
So
it
should
be
populated
by
the
release.
A
Team
members
and
sig
leads
the
hope
being
that
those
individuals
aren't
going
to
be
irresponsible
and
just
willy-nilly
at
these
PR
Xin
just
because
they
think
their
stuff
deserves
to
get
in,
but
that
they've
actually
thought
through
it
and
reasoned
it
out
and
then
code
freeze
added
the
additional
call
it
like
social
friction
of
adding
a
priority,
critical
urgent
label
to
your
PR.
So.
B
A
You
have
to
justify
not
just
that
you're
like
arbitrarily
adding
it
to
a
milestone,
but
that
you
really
think
this
PR
is
critical
and
urgent.
So
you're
saying
that
the
benefits
really
high,
you
may
not
necessarily
be
appropriately
evaluating
or
representing
what
the
risk
slash
cost
of
that
PR
is,
but
so
that's
a
little
bit
of
context
on
like
how
we
got
to
now.
A
I,
don't
know
that
I
have
opinions
on
how
to
like
simplify
that
process,
though
I
agree,
it
could
be
simplified
and
somewhat
related
to
this,
because
we
use
milestone
as
one
of
the
gating
features.
We
also
kind
of
have
an
open
question
on.
What's
the
criteria
to
add
something
into
a
milestone,
which
is
an
open
issue
in
the
114
milestone
for
kubernetes
sake,
release,
add
information
about
what
qualifies
for
a
milestone.
If
anybody
wants
to
help
out
with
that.
K
Thoughts
did
I,
think
you
hit
on
you
hit
on
one
keyword,
a
paragraph
or
two
back.
Why,
like
the
TLDR,
gives
the
list
of
things
that
must
be
applied
when
during
the
phases,
but
that's
like
you
must
have
these
things
to
get
it
to
merge,
but
why
you
would
choose
to
want
to
merge
it
in
that
time
frame
or
not,
and
why?
Whether
a
developer
would
make
that
choice
to
not
to
defer
or
why
the
cig
leads.
Reviewers
owners
would
choose
to
not
apply
it
and
similar.
K
Why
a
release
team
leader,
patch
release
manager
would
choose
not
to
apply
it
like
those
those
gating
criteria.
I
did
notice,
since
you
pointed
it
out,
the
the
section
on
priority
label
does
have
a
couple
bullets
that
say
would
so
like.
Just
as
a
keyword
did
look
off
of,
if
you
see
like
would
require
a
pat
relief
if
let,
if
less
left
undiscovered
or
would
not
require
patch
release.
That
is
a
why
rationale,
but
it's
a
pretty
verse
one
I
don't
know
if
there
are
others,
but
maybe
that's
that's
sufficient.
K
H
Depends
III
for
the
last
five
minutes
been
looking
for,
like
an
actual
definition
of
what
that
label
would
mean,
and
it's
multiple
different
definitions,
depending
on
whether
it's
an
issue
or
whether
it
is
a
PR.
If
it's
a
PR,
what
state
it
is,
is
it
in
so
like
I,
said
so
box.
Just
something
I
want
to
point
out,
because
it's
kind
of
relevant.
A
Probably
like
there
is
a
definition
right
there,
there
is
one
like
github
has
a
description
field
for
labels.
So
if
you
hover
over
that
label,
you'll
see
text
that
says
what
that
labels
supposed
to
mean.
But
what
you're
talking
about
is
dictionaries,
don't
matter
it
comes
down
to
how
people
use
the
words
in
in
conversation,
and
so
you
feel
like
there
are
different
groups
of
people
who
use
that
particular
label
in
different
ways
and
aren't
describing
how
or
why
they're
doing
that
and
so
try
and
either
different
things.
I,
don't.
L
A
A
Okay,
I
can
take
an
AI
to
propose
that
we
drop
priority
critical
urgent
from
code
freeze
criteria,
updating
the
docs
and
notifying
the
community.
Since
this
is
a
workflow
change
process,
I
don't
know
if
I
should
be
seeking
lazy
consensus
or
not
versus
just
saying.
This
is
the
way
we're
gonna
do
things,
but
you
know
that
this
will
have
changed
by.
F
K
We
can
give
that
a
trial
114
see
how
it
goes
will
toward
seen.
The
cycle
will
understand
whether
it
brought
an
undue
risk
or
people
fell
to
this
nice.
Simplifying
change
so
next
on
the
list.
How
closely
should
handbooks
be
followed?
Our
rule
books
too
prescriptive?
This
is
from
Nico
and
he
and
I
had
actually
discussed
this,
so
I
have
some
sense
into
what
he
was
thinking.
K
Prescriptive
must
I
do
everything
that's
listed
here
and
I
think
Nico
phrases
his
question
well
in
terms
of
saying
how
closely
should
handbooks
be
followed,
as
opposed
to
must
so
like
Erin's
already,
like
said,
like
hey
I,
didn't
do
a
couple
of
these
things
that
were
on
my
handbook
and
and
I
think
practically
speaking,
that's
been
the
case
every
time
each
of
us
have
approached
the
roles
with
a
certain
pragmatism
and
I.
Think
that's
good.
That's
normal
open-source
community,
but
he
wanted
sort
of
broader
clarification
from
from
the
group.
K
I
think
in
terms
of
what
other
people
thought
should
we
refine
the
books
to
be
worded
in
a
way
that
makes
it
clear
that
their
guidance
make
it
makes
it
clear
which
things
are
definitely
required
for
consistency,
then,
from
Leeson
across
the
the
different
preferences
of
the
individual
running
things
at
that
time,
around
I
think
it's
a
great
thing
to
discuss
more
broadly.
So
with
that
context,
water
folks
think
I.
L
Have
an
opinion
on
this
that
I
tried
to
do
with
the
release,
notes
and
book
recently,
and
it's
that
you
know
there's
a
lot
of
aspects
of
the
release
notes
process
which,
as
someone
who
participated
in
it
for
a
few
releases,
I'm
really
like
not
psyched
about
like
it,
could
be
very
different
and
or
very
improved.
But
I
tried
to
make
the
handbook
and
explicit
account
of
what
I
completed
as
a
part
of
the
release.
L
Notes
as
the
release
notes
lead
that,
like
led
the
release
to
going
out
successfully
and
then
pointed
to
the
areas
of
improvement,
so
I
personally,
don't
think
that
we
should
have
to
fought
like
leads,
should
have
to
follow
to
a
letter.
What
happened,
but
I
do
think
that
everything
that
did
happen
should
be
there,
so
that,
if
future
leaves
want
to
change
the
process,
they
know
all
of
the
exact
things
that
need
to
be
accomplished.
For
the
release
to
go
out.
You
know.
K
K
K
You
I'm
gonna
guess
so,
even
if,
if
nobody
speaks
up
I'm
gonna
guess
for
the
shadows
on
the
call,
some
of
you
are
gonna,
read
the
handbook
or
have
it
already
at
this
point
and
you're
gonna
read
the
handbook
and
be
like.
Why
do
we
do
that?
Ask
that
question
out
loud
I
really
encourage
you
to,
because
that's
one
of
the
best
things
your
new
eyes
bring
to
the
process.
The
questioning,
if
there's
not
a
great
reason,
we
can't
dig
it
up
for
some
reason.
Then
maybe
we
should
not
do
it.
A
And
gonna
break
my
rule
again:
I'll
try
not
to
rant
as
much
this
time
the
the
TLDR
rant.
Most
of
you,
maybe
have
heard
me
say
if
you
haven't
welcome
to
it-
is
that
they're
way
too
many
words
in
these
release
books
that
as
much
as
I
am
happy
that
the
release
team
has
become
this
super
amazing
all-inclusive
thing.
A
It
makes
me
sad
that
there
are
more
and
more
humans
being
tossed
into
the
machine
when
really
I
would
love
to
live
in
a
world
where
we,
like
just
turn
a
crank
and
some
gears
get
turned
and
stuff
magically
pops
out
the
other
side.
So
I
love
to
live
in
a
world
where
I
take
all
of
the
really
boring
administrivia
and
I
hand
that
over
to
BOTS
or
scripts
or
machines
or
programs,
and
they
make
my
life
a
lot
easier.
A
How
I
I
think,
like
statement
of
like
I
described
the
state
of
today,
while
I,
really
aspire
to
a
much
better
tomorrow,
is
a
problem
we
face
in
a
lot
of
different
places
in
the
project,
and
I
have
been
pretty
explicit
with
the
folks
that
I
talked
to
you,
they're,
like
you,
you
do.
You
I
need
to
be
clear
about
my
expectations
about
like
what
I
need
from
you,
but
you
you
do
it
how
it
works
best
for
you.
That's
it
a
question
that
maybe
I
have
in
responses
like
the
release.
A
A
This
weird,
like
dry
thing,
I,
have
don't
repeat
yourself
thing
I
have,
though
we're
like,
should
all
of
the
specific
milestones
for
each
of
the
different
tasks
be
called
out
in
that
one
uber
schedule,
or
should
I
leave
that
up
to
each
of
the
individual
playbooks
like
how
would
I
enforce
that
those
things
tie
together.
I
have
no
great
idea.
B
A
A
K
I
definitely
like
that
idea
of
splitting
that
stuff
out
one
into
a
higher-level
schedule,
which
we
already
had
the
top-level
readme,
has
schedule,
which,
in
a
lot
of
ways,
is
redundant
relative
to
the
Leeds
handbook,
so
pushing
the
actual
actions
out
into
the
delegates.
Handbooks
makes
a
lot
of
sense
and
the
Leeds
becoming
a
shorter
key
items
checklist
that
could
make
a
lot
of
sense
that,
if,
if
you
fiddle
around
with
some
markdown
that
does
that
this
cycle
I'd
be
really
curious
to
see
it.
K
L
That
I've
noticed
that
the
release
lead
and
book
has
a
very
like
I'm,
saying
it's
very
structured
format
about
on
a
week-by-week
basis,
but
a
lot
of
the
other
hand
books
may
not
follow
that
format.
Is
that
something
that
you
guys
endeavor
to
see
more
standardized
in
the
future,
so
that
it
would
be
easier,
for
example,
Aaron?
If
you
wanted
to
like,
take
your
one
of
your
week,
c6
tasks
and
be
like?
Oh,
this
should
be
the
CI
signal
lead
instead
of
the
lead.
A
I,
don't
have
a
great
answer
for
that.
I,
don't
know
like
I
I
started
the
handbook
thing
off
when
I
wrote
when
I
was
CI
signal
and
I
realized.
I
was
doing
a
lot
every
day
and
so
I
just
needed
to
write
it
down
as
like
a
survival
skill
I
didn't
write
it
down.
I
knew
I
was
gonna
eventually
forget
it
it'd
be
nice
if
they
followed
a
common
format,
but
I
I
feel
like
that's
I.
A
B
A
Kind
of
difficult
to
work
with,
if
I'm,
just
trying
to
grok
like
what's
going
on
I,
think
the
way
that
I'm
trying
to
model
the
release
life
cycle
in
my
head
is
to
break
it
up
in
distinct
phases
rather
than
trying
to
boil
it
all
the
way
down
concretely
to
week
by
week,
things
because
I'm
trying
to
imagine
a
far-off
future
where
the
release
life
cycle
lasts
longer
than
a
quarter.
I
definitely
had
a
couple.
A
A
So
I
find
like
some
of
the
books
like
see.
I
signal
and
issue
triage
definitely
talk
about
how
your
duties
are
going
to
concretely
change.
You
have
like
daily
duties
that
are
gonna
change
from
one
phase
to
the
next,
and
some
of
them
get
like
extra
judicious
and
start
talking
about,
like
you
should
do
these
extra
things
to
prepare
for
the
transition
into
burn
down,
and
then
you
should
do
these
extra
things
to
prepare
for
the
transition
into
code.
K
Alright
I'm
gonna
move
on
to
the
next
one.
This
has
been
a
repeated
question,
although
the
specific
form
here
is
slightly
different,
that
the
basic
question
has
been.
How
do
we
ensure
that
tests
get
merged
early
in
the
cycle
so
that
we
can
then
either
keep
them
green
throughout
the
cycle
or
or
know
that
they've
started
out
red
intentionally
and
are
intended
to
go
green
and
thus
become
a
blocker,
as
opposed
to
having
started
as
informing.
K
Anybody
have
thoughts,
I
think
when
it
may
be.
One
of
the
extra
things
to
note
here
is
that
this
could
be
becoming
more
of
an
issue
so
that
there's
a
lot
of
mentions
specifically
here
in
this
bullet
of
the
plug
in
infrastructure
changes
or
changes
to
api's
like
cloud
provider,
and
maybe
this
thing
gets
into
the
whole
ecosystem.
Distribution
versus
kernel
type
of
discussion.
But
is
this
ongoing
problem
becoming
a
worse
problem
as
we
move
forward.
L
I
think
we
have
to
treat
this
like.
We
do
features
I
mean
you
can't
put
in
a
test
for
a
feature
when
the
feature
isn't
merged
yet
right,
but
we
could.
You
know,
attempt
to
require
that
the
test
go
in
with
the
feature
are
that,
similarly,
you
can't
add
tests
once
we're
in
freeze
I,
don't
know
how
well
we
can.
You
know
enforce
this,
though
other
than
the
people
that
are
improving,
milestone
and
so
forth.
Being
weird
list.
A
A
Again,
I
guess
like
I,
want
to
live
in
a
world
where
things
that
are
plugins
and
things
that
are
out
of
tree
can
be
released
on
an
independent
cadence,
then
kubernetes
proper.
If
they
need
to
be
tied
to
the
cadence
of
kubernetes
proper,
for
whatever
reasons,
then
they
probably
need
to
have
a
cap
explaining
I.
K
I
I'm
relatively
comfortable,
still
kind
of
moving
ahead,
just
because
we
know
we
have
a
lot
of
eyes
on
this
general
space
about
the
this
looming
question
distro
versus
Colonel.
How
do
we
truly
allow
things
to
run
at
their
own
Cadence's
and
have
something
still
at
the
end
of
the
day?
That's
coherent
and
integratable
together.
There's
a
lot
of
discussion
of
that,
but
and
people
on
the
release
team
who
are
following
that
discussion.
Wait.
So
when
you
say
that
discussion
is
happening
like
where
it's
not
happening
somewhere,
though
yeah.
That's
a
good
point.
K
A
Phrase
it
this
way,
we're
like
I,
went
around
to
a
number
of
people
involved
in
the
cloud
providers
sake
and
not
quite
hands
and
knees,
but
definitely
pleaded
with
them
not
to
try
and
do
any
sort
of
refactoring
or
breaking
up
of
stuff.
I.
Don't
want
to
answer
the
question
about
how
we
release
out
of
tree
stuff
as
part
of
the
release
life
cycle.
I
agree.
It's
an
important
question
to
be
answered,
but
let's
not
answer
it
during
114.
A
K
K
K
Okay,
we'll
take
it
as
resolved,
since
somebody
has
put
it
in
there.
We
can
look
in
the
revision
history
and
see
if
that
was
Josh.
Actually
so
the
action
items
list
I
believe
each
of
these
has
been
getting
discussion.
I
know
the
unreleased,
that's
one
Aaron,
you
have
said
UO
writing
that
up.
I
figured
that
at
least
on
that
when
you're
you
and
your
leaves
are
gonna,
be
collaborating
on
something
for
a
change
the
cycle
and
that
it's
early
for
that
still
maybe.
A
Yeah
I
think
just
general
theme.
The
thing
that
concerns
me
is
my
name
is
on
each
and
every
one
of
these
I
would
really
love
so
for
shadows.
This
is
totally
the
place
to
step
up
and
help
out,
and
I
am
really
okay
with
somebody
forcefully
grabbing
one
of
these
issues
away
from
me,
because
I
can't
seem
to
help
myself
and
I
keep
signing
up
to
write
these,
but
I
don't
necessarily
get
around
to
doing
all
of
these,
and
if
you
want
to
do
them,
that's
totally.
A
Fine
I
will
try
to
summarize
the
release,
notes
rants
since
the
rant
spilled
out
of
my
head.
But
if
you
want
you
could
like
watch
the
last
retro
video
and
transcribe
it
and
and
see
what
happens
there
and
maybe
that's
the
great
place
for
Dave
to
Dave
and
his
shadows.
To
start
from
Burleigh's
notes,
perspective
and
I
did
have
a
chat
with
Maria
about
she.
A
A
But
it's
a
little
concerning
to
me:
I
like
what
I
try
to
do
is
take
action
items
turn
them
into
github
issues,
assign
them
to
the
milestone,
assign
them
to
myself.
So
I
know
that
that's
a
thing
that
I
said
I
would
do
and
then
I
go
try
and
do
it
by
the
way
I
can
follow
up
to
see
if
I've
done
any
done
any
improvements
afterwards.
If
other
people
want
to
help
out,
I
would
appreciate
it.
A
K
L
K
A
A
But
I
forget
how
or
when
or
maybe
it
wasn't
even
me
it
just
randomly
happened
and
I
do
have
a
114,
retro
doc
started
for
people
who
want
to
talk
about
stuff
like
I
already
have
an
item
in
there
about
oops
I,
don't
seem
to
know
how
to
use
calendars
to
schedule
recurring
meetings
very
well,
because
that
wasn't
spelled
out
super
clearly
for
me
in
my
playbook
so
anyway,
thank
you
for
moderating.
Tim
very
much
appreciate
it.