►
From YouTube: Kubernetes SIG Release 20200728
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
Hello,
hello:
everyone
today
is
july
28th.
This
is
a
sig
release
meeting.
It
is
a
meeting
that
is
recorded
and
available
on
the
internet.
So
please
be
mindful
of
what
you
say
and
do
please
be
sure
to
adhere
to
the
kubernetes
code
of
conduct
and
in
general,
just
be
awesome
people.
A
A
So,
as
of
119,
I
think
you
know
we're.
We've
officially
landed
a
pr
on
the
master
branch
and
that
has
been
fast
forwarded
into
the
119
branch
to
build
on
top
of
go
115
rc1.
A
So
this
is
an
interesting
event
for
us
and
kind
of
a
celebratory
one.
I
guess
it's
the
first
time
that
we
have,
as
far
as
I
know
at
least
we've
consumed
a
go
pre-release
ahead
of
the
actual
minor
release.
A
There
are
a
variety
of
reasons
for
us
doing
that
part
of
it
is
to
keep
up
with
the
go
support
cycle,
as
we
consider
as
we
consider
the
move
into
annual
support
for
kubernetes
overall.
So
we
want
to
ensure
that
kubernetes
is
on
a
version
of
go
that
will
continue
to
be
supported
for
the
life
cycle
of
the
release.
A
Go
114
was
known
to
have
some
stability
issues,
so
the
suggestion
I
I
think
the
the
agreement
we
we
landed
on
was
to
what
was
to
stay
was
to
try
to
move
as
quickly
as
possible
to
to
go
115..
A
That
decision
will
also
ripple
into
the
previous
release
branches,
so
we're
planning
on
also
back
porting
go
1415
into
the
118
and
117
release
branches.
Again.
The
reason
for
this
is
go
support
right,
so
the
kubernetes
support
cycle
is
a
little
bit
more
elongated
and
even
more
so
now
than
the
go
support
cycle,
which
means
if
we
go
to
go
115
once
ago,
115
is
out
and
119
is
on
that
go.
113
will
move
out
of
support,
which
means
our
previous
release-
branches,
118,
117
116,
will
be
using
a
version
of
go.
A
That's
no
longer
supported
so
note
that
I
mentioned
originally
mentioned
only
118
and
117.
The
reason
for
that
is
as
we
release
as
we
release
kubernetes
119,
we
will
be
turning
off
support
for
kubernetes
116..
A
So
that's
the
reason
for
that
is
that
we're
kind
of
in
a
we've
been
in
an
elongated
release
cycle,
and
it's
just
about
at
the
one-year
boundary
for
for
116.,
so
we'll
be
saying
goodbye
there
and
yeah.
I
think
that's
that's
the
broad
overview,
some
of
the
nitty-gritty
pieces,
where
we
are
now
able
to
support
pre-releases
for
forego
within
repo
infra.
So,
if
you're
familiar
with
repo
infra,
it
has
a
set
of
basal
tools
and
definitions
that
we
use
across
the
kubernetes
orgs.
A
So
some
example
repos
would
be
kubernetes
kubernetes,
kubernetes
release,
kubernetes
test
infra
and
I
hacked
together
some
support
for
support
for
go
releases
for
go
pre-releases,
so
hopefully
moving
forward
we'll
continue
to
be
on
this
stream
of
consuming
go
more
frequently
and
yeah
yeah.
Any
questions
on
that.
A
All
right,
so
next
steps
there
is
a
bit
of
waiting.
We've
we've
essentially
moved
both
the
master
and
119
branches,
as
well
as
ci
images,
the
cubican's
ede
images,
as
well
as
the
krte,
the
kind
runtime
environment
images
to
run
with
go
115
rc1.
A
So
once
we
have
a
release
from
upstream
go,
and
I
think
that
should
be
roughly,
I
want
to
say
in
in
a
week
and
change-
maybe
I
think,
based
on
their
their
current.
The
current
release
cycles
we'll
we'll
be
ingesting
that
as
quickly
as
possible
to
set
us
up
we're.
You
know
one
one
thing
to
note:
is
that
we're
still
in
code
freeze
and
looking
at
looking
at
the
way?
A
B
Absolutely
so
119
we
delayed
code
thaw
mostly
because
we
saw
a
lot
of
critical,
urgent,
prs
and
issues
both
together
same
and
so
we
have
not
lifted
code
saw
just
yet.
B
We
are
working
on
getting
the
some
of
the
tests
cleaned
up
and
then
a
lot
of
those
pr's
and
issues
have
been
solved,
but
there
still
are
some
that
we'd
like
to
get
remedied
and
solved
at
this
time.
I
know
that
there
are
also
some
test
enhancements
that
are
coming
so
with
tests.
You
have
to
declare
resources
in
limits,
and
so
that
is
going
to
be
kind
of
the
next
iteration.
I
said:
there's
some
chatter
from
ben
on
that
front
this
morning
looks
like
they
were
debugging
some
issues
that
they
were
seeing
there.
B
I
think,
before
I
went
to
sleep
last
night,
there
were
a
couple
just
resource
infrastructure
issues
that
they're
looking
at
as
well.
So
that's
ongoing
right
now.
Otherwise,
119
is
really
coming
together,
very
excited
to
see
the
low
counts
of
critical
issues,
and
hopefully
they
vanish
soon
completely.
A
Very
nicely
done,
okay,
and
I
want
to
guess
that
this
is
tim
any
well.
First,
any
questions
on
119
what's
happening,
what's
not
happening.
C
Yeah,
I
just
wanted
to
mention
that
the
team
is
starting
to
form
and
discuss
timelines.
It's
a
complicated
fall
with
conferences
and
virtually
conferences
and
holidays,
and
the
completely
tbd
119
release
date
and
major
changes
like
go
1.15
and
the
ci
instability.
So
things
are
starting
to
happen,
they're
forecasting
what
they
might
could
should
do,
and
I
guess
if
anyone
on
the
call
or
anyone
listening
to
the
recording
is
interested
in
volunteering
for
that
release.
Team
start
paying
attention
for
the
call
for
volunteers
and
be
ready
to
raise
your
hand
for
that.
C
C
So
we
have
a
tentative
person
lined
up
to
be
the
release
lead
for
120
and
it
popped
into
my
head
that
we're
like
we're
getting
to
a
point
where
we
have
line
of
sight
potentially
on
119's
release
and
it
starts
making
sense,
then
to
start
thinking
about
getting
going
on
120,
forming
the
team
and
thinking
about
the
calendar
since
it's
complicated.
So
I
just
sent
a
dm
to
the
individual
who's
our
candidate
for
that
over
the
weekend.
Saying
hey
this
popped
into
my
head
and
they
said
yeah.
I've
been
thinking
about
that.
Why
don't?
C
I
start
getting
stuff
going
this
week,
so
the
broader
conversation
should
be
happening
in
sig
release
any
day
now
in
the
on
slack
channel
and
also
then
messages
out
to
the
mailing
list.
A
Yeah,
I
would
say
that
yeah.
I
feel
that
next
week
is
probably
a
good
time
to
start
give
us
a
little
extra
time
if
we
get
to
120.
so
but
yeah,
I'm
super
excited.
Awesome.
Individual
can't
wait
for
that
to
be
announced.
I
think
that
we
have
been
doing.
A
I
think
the
release
team
has
seated
a
bunch
of
great
candidates,
great
leaders
and
and
sig
release.
So
I'm
excited
for
the
next
wave
of
that.
C
Normally,
one
of
the
things
that
we
try
to
do
is
the
point
that
we're
getting
to
code
thaw
and
starting
to
do
cherry
picks
on
the
branch
to
have
the
next
people,
starting
to
kind
of
be
present,
to
get
some
awareness
of
how
that
happens,
because
otherwise
people
in
those
roles,
don't
necessarily
see
it
until
it's
their
turn.
Four
months
from
now,
at
which
point
the
current
people
have
started
to
to
drift
away
so.
C
Try
to
to
start
the
next
cycles
team
as
the
current
one
is
finishing
up,
and
it's
in
the
the
leads
handbook
to
start
doing
that
in
the
the
final
weeks
of
the
release,
this
release
being
an
unusual
schedule.
The
final
weeks
of
the
release
is
maybe
an
ambiguous
phrase.
I
would
sort
of
see
it
as
the
final
month
or
so
like.
C
Usually,
these
are
things
that
are
happening
around
code
freeze
and
code,
thaw
and
cherry
pick
season
on
the
release,
branch
and
figuring
out
what
we,
what
we
take
into
the
release
at
the
end
versus
defer
to
that
next
team
to
start
handling.
So
we
we
need
a
bit
of
overlap
for
that
kind
of
transition
to
happen
reasonably
with
some
planning
and
deliberate
thought.
D
Let
me
know
if
I
can
help
with
any
of
that,
once
the
person's
announced
I
mean,
that's
the
sort
of
thing
a
program
manager
would
do
help
help
everyone
contribute
to
building
that
process
and
luckily
we're
doing
a
lot
of
work
already
to
change
some
of
the
groundwork
from
this
cycle,
like
we
can
the
improvements
that
we've
identified
and
have
been
talking
about
which
I'll
get
to
later
I'll,
give
you
an
update.
A
I'm
actually
going
to
move
that
one
up
so
laura
you
want
to.
You
want
to
go
for
it.
D
Oh
sure,
let
me
which
one
did
you
move
up?
I'm.
D
So
all
right,
so
I
guess
yeah
this
last
week
we
were
having
our
regular
sessions
and
as
we
talk
on
those
monday
wednesday
friday
meetings,
we
come
up
with
spontaneous
items,
and
so
the
question
arose.
Where
do
we
put
that
stuff
and
we
didn't
really
have
a
specific
place
to
consolidate
those
questions
that
come
up
spontaneously.
D
Oh,
we
can
yeah
yeah,
so
let
me
see,
did
you
share.
D
D
So
this
is
the
I
think,
the
wednesday
meeting.
So
these
were
the
items
that
I
that
I
caught
up
with,
so
the
first
one
was
to
do
getting
a
test
in
place
that
would
have
caught
this
issue,
and
this
came
in
the
context
of
the
discussions
that
we're
going
to
be
having
like
today
and
then
also
ci
signal
sub
project.
D
D
And
then
here
I
think
this
is
messed
up.
My
didn't
mess
up
my
formatting
or
not:
okay,
yeah,
it's
a
little
bit
wonky
on
the
formatting.
It
adds
a
space,
but
the
next
item
was
actually
the
bundle
of
items
that
jordan
had
pitched,
which
again
is
in
discussion,
but
we
have
the
ci
pro
policy
changes,
so
he
created
that
proposal.
A
And
yeah,
so
I
put
I
put
it
on
the
agenda
and
we'll
we'll
go
through
it
in
more
detail.
Oh
that's,
weird.
D
Yeah
and
then
there
were
some
other
suggestions
to
formalizing
policy
and
force
going
forward.
D
A
So
this
is
something
that
we
were
already
should
have
already
been
formalized.
Okay,
that
whether
or
not
it's
being
enforced
is
a
different
there's,
a
different
story,
so
tests
that
are
on
tests
that
are
within
our
scope.
So,
basically
things
that
are
in
config
jobs,
kubernetes,
sig,
release,
release
branch
jobs-
I
think,
is
the
path
and
test
infra.
A
Those
jobs
are
supposed
to
have
contact
email
addresses
attached
to
them.
The
I
did
a
sweep,
it's
it's
a
while
back
now
and
anything
that
does
not
have
a
a
contact
address
is
listed
as
I
consider
that
to
be
a
misconfiguration
and
so
anything
that
you
see
that's
on
the
sig
release,
job
config
errors
board.
It
could
be
one
of
those
right,
so
that
is
relatively
up
to
date,
but
it'd
be
worthwhile
to
give
another
sweep.
A
We
should
also
we
have
some
enforcement
on
the
test
level,
but
the
enforcement
is
based
on
whether
or
not
a
job
is
blocking
and
what
kind
of
tabs
it
lands
in,
but
not
so
much
the
not
so
much
whether
or
not
it
has
an
email
address.
So
this
is
something
that
catherine
and
I
were
chatting
about
a
while
ago,
and
the
question
was
what's
the
point
of
having
these
enforcements.
A
If
we
don't
actually
are
the
the
warnings
right,
so
there
are
some
there's
some
tests
that
are
essentially
enforced
for
some
of
the
blocking
jobs
and
there
are
some
things
that
just
warn
for
informing
jobs.
A
So
the
question
was:
what's
the
point:
if
no
one
is
paying
attention
to
the
fact
that,
because,
like
those
just
that's
kind
of
spit
out
as
a
part
of
the
scroll
back
during
pre-submits,
when
we're
trying
to
check
for
different
things,
so
we
should
open
up
an
issue
for
if
one
doesn't
exist
already
for
for
kind
of
sweeping
those
jobs
and
making
sure
that
we're
enforcing
this,
not
just
by
policy
but
also
by
pre-submit.
D
D
Okay,
so
I've
made
the
notes
so
that
we
would
like
to
do
that
sweep
and
open
the
issue.
But
anyone
here
like
to
do
that.
D
B
A
Sounds
good
yeah,
so
whoever
has
worked
on
the
the
jobs
in
the
past
and
I
think
that
it
would
be
good
to
get
another
person
staring
at
the
way
we
do
the
configurations
for
the
jobs.
Okay,.
A
D
A
D
A
Yeah,
so
we
have
a
set
of
blocking
and
informing
jobs
right.
Okay,
so
anything
that's
not!
I
think
that
this
is
wider.
A
Wider
ci
right,
not
just
sig
release,
is
what
it
sounds
like,
because
we
sort
of
we
have
a
policy
for
this.
Enforcement
is
a
different
question.
We're
supposed
to
be
dropping
things
from
the
boards
that
are
not
that
are
consistently
failing.
C
A
A
Okay,
so
ownership
part
of
this
is
ownership
as
well
opening
issues
of
clear
owners
targeting
some
of
the
slowest
tests,
and
all
of
this
is
the
kind
of
stuff
that
I
would
love
to
see
as
the
ic
tool
project
work
on.
Okay,.
D
A
We
could,
but
the
group
is
not
formed
yet
officially
so
jorge.
Do
you
want
to
give
an
update
on
that
issue?
Yeah.
E
But
last
week
I
propose
a
draft
chart,
a
charter
which,
in
my
own
words,
I
propose
to
actually
do
to
actually
do
some
of
this
work.
The
tldr
is
to
kind
of
to
kind
of
generalize
the
ci
signal
theme
within
the
release
team
to
actually
do
the
work
that
it
is
done
on
the
latest,
not
only
for
the
latest
main,
a
minor
release
in
this
case
119,
but
to
generalize
it
to
all
into
all
the
releases
that
we
take,
that
we
take
care
of
some
of
a
lot
of
besides
doing
the
normal
cic.
E
Besides
doing
the
normal
ci
signal
works.
Some
of
the
other
work
that
I
propose
is
on
I'm
going
to
cover
a
little
bit
of
a
job
management,
a
project,
a
project
management
in
doing
the
doing
this
kind
of
thing,
formalizing,
policies
for
a
job
inclusion
and
my
dentistry
ownership
write
a
collaborating
more
with
six
to
make
sure
to
make
sure
that
these
things
are
well
known,
well
known
throughout
the
community,
and
it
isn't
just
one
of
those,
and
it
is
one
of
those
things
that
is
true.
It
becomes.
E
E
Scope
issue
essentially
there's
a
there,
then
there's
only
there's
a
little
bit
of
nuance,
and
this
has
come
up.
This
has
come
up
in
a
multi,
multiple
avenues,
so
technically
the
the
the
thing
that
is,
the
thing
that
I
think
will
be
useful,
will
be
a
full
long,
a
collaboration
with
the
with
the
rest
of
the
community.
E
There
is
a
collaboration
to
be
done
with
zig
testing
on
actually
improving
on
actually
working
with
six
to
improve
jobs,
to
make
sure
that
things
to
make
sure
that
things
from
better
but
overall,
a
job
and
testment
a
maintenance
of
the
of
the
tools
that
we
use
and
that
will
have
to
be
done
in
collaboration
with
ac
testing,
maintaining
the
actual
end-to-end,
the
actual
end-to-end
test
that
will
have
to
be
done
in
collaboration
with
the
six
and
the
and
then
may
they
may.
A
Etc,
yeah,
so
we
need
to
figure
out
how
to
end
this
discussion,
because
I
think
we're
spending
more
time
on
it
than
actually
doing
the
thing,
and
so,
when
I
had
originally
opened
this
issue,
I
did
mention
that
somewhere
that
this
was
a
brain
dump
of
ideas.
A
Right
at
the
beginning,
yeah,
this
is
more
of
a
brain
dump
than
anything
right,
so
this
was
not
intended
to.
I
think
it
was
controlled
as
overscoped
for
sig
release
right
what
what
we
ultimately
want.
The
first
point
is
to
extend
the
knowledge
of
ci
signal
beyond
an
individual
cycle
right.
A
We
want
to
make
sure
that
we're
doing
the
same
things
that
we
do
on
the
ci
signal
team
across
multiple
release,
cycles,
right
and
and
essentially
maintaining
the
same
jobs
that
we
would
be
that
we
would
be
for
all
of
the
active
release
branches
right.
That
is.
That
is
the
one
thing
that
I
want
right.
Anything
else
is
icing
on
the
cake.
So
if
we
have
to
d
scope
to
that,
I'm
fine
like
if
this
needs
to
it's
been
mentioned
that
maybe
this
should
be
a
sig
testing
sub
project.
A
Ultimately,
I
I
don't
care
outside
of
the
work
getting
done.
I
think
that,
because
sig
release
has
been
doing
the
ci
signal
work,
they
should
continue
to
do
the
ci
signal
work.
I
think
that's
where
the
expertise
is.
It
has
not
been.
A
I
think
it's
mentioned
in
this
thread
as
well
that
the
debugging
someone
else's
jobs
is
not
in
scope
for
sig
testing,
whereas
it
has
been
in
the
past
for
us
not
to
say
that
it
should
continue
to
be
in
scope
for
us.
We
should
provide
people
along
with
sig
testing
the
tools
that
they
need
to
to
work
through
job
failures
themselves,
but
that
has
been
in
scope
for
the
team
in
the
past
and
I
think
that
I
think
that
it's
fine
for
that
to
be
in
scope
temporarily
for
a
ci
signal
subproject.
A
So,
let's
at
some
point,
maybe
we
can
take
this
to
a
suggesting
meeting.
There
is
one
today,
but
we
have
we
have
the
cia
overall
to
discuss.
So
that
is
jordan's
proposal
which
we'll
get
into
shortly.
D
D
I
have
a
suggestion,
so
I
mean
you're
sort
of
doing
like
a
team
building
exercise
or
trying
to
figure
out
the
roles
of
the
different
cigs
in
the
ci
signal
subproject.
So
what
about
trying
to
sketch
the
basic
boundaries
details
about
the
charter
like
who
spinning
up
like
who
does
who
might
do
what
you
know?
D
What
is
the
ownership
of
what
we
want
the
subproject
to
achieve
and
trying
to
just
sketch
out
us
a
plan
for
that,
inviting
members
of
cygnode
testing
just
to
start
with
just
to
put
some
meat
on
the
bones
of
the
idea
and
then
also
like
what
is
not
in
scope
and
then
trying
to
define
some
of
the
interfaces
between
those
things
at
least
the
types
of
interfaces
that
will
need
to
be
thought
of
as
the
same
sub-project
gets
going
like,
who?
How
would
the?
E
A
A
Yeah,
I
I
think
that
we've
had
more
than
enough
discussion
on
this.
Maybe
we
need
to
take
it
to
a
sig
testing
meeting,
but
I
also
don't
believe
that
a
as
long
as
as
long
as
we
develop
a
subproject
that
is
out
of
scope
for
another
sig,
I
don't
believe
another
sig
should
dictate
the
formation
of
a
subproject.
D
No,
no
that's
why
it
would
be
a
collaborative
discussion.
Yeah
getting
the
foundational
part
sorted
then
agreed
upon
by
the
main
cigs
that
would
be
contributing
and
driving
this
effort.
To
start
with,
I
mean,
ideally,
you
want
to
have
this
ci
awareness
and
all
the
sigs,
but
you'll
have
a
core
group
at
first.
A
E
The
main
comments,
the
ben,
so
I
can
summarize
in
the
state
the
state
of
the
discussion
and
I
might
be
missing
some
details,
but
the
first
couple
of
comments
from
the
sig
testing
areas
are
a
way
in
the
comments
we
were
proposing
to
actually
take
take
some
of
the
work
that
is
owned
by
sig
testing,
like
ownership
of
how
to
actually
manage
some
enduentes
how
to
write
some
tooling.
E
That
was
the
first
part
that
was
the
first
part
of
the
conversation
and,
more
or
less
it
all
circled
around
of
just
discussing
what
is
actually
in
scope.
What
is
a
what
is
in
scope
from
the
proposed
charter
that
I
last
posted?
I,
I
guess
the
one
aspect
of
it
that
I
was
overreaching,
because
we
do
this.
We
do
this
every
now
and
then
in
in
a
kind
of
project,
manage
a
project
management
kind
of
kind
of
deal,
not
only
northern
actually
working
on.
E
It
is
on
a
doing
ci
signal
for
the
preset
for
the
pre-submit
test,
which
is
actually
worth
it,
where
the
people
from
seek
testing
have
a
have
actually
been
taking
photo
a
full
ownership
of
that
other
than
that
in
the
other,
double
the
other,
the
rest
of
the
charter.
It
sounds.
It
is
more
or
less
generalizing
ci
signal
to
the
rest
of
a
to
the
rest
of
the
release,
branches
and
expanding
more
collaboration
with
mostly
mostly
the
box
reaction.
A
All
right,
so,
let's
let's
go
to
them
jorge
if
you
can
find
the
next
time
that
we
can
get
time
on
the
sig
testing
schedule
and
then
we'll
just
let's
knock
this
out
in
a
meeting
sounds
good.
D
So
that
so
the
idea
is
that
take
the
handbook
or
like
some
of
the
details,
some
of
the
must
do's
for
the
subproject
to
sig
test
and
get
their
feedback
and
then.
A
A
Is
that
we've
like
taken
a
brain
dump
to
mean
this
is
the
entirety
of
the
scope
of
the
subproject
instead
of
ideas
that
we
should
be
discussing,
whether
or
not
we
want
as
part
of
the
subproject?
So
let's,
let's
do
what
we
can
to
strip
as
many
of
the
ideas
that
could
potentially
be
controversial
from
this
and
go
with
the
goal
of
formation
right.
Okay
formation
is
the
first
step.
D
A
Right
sounds
good.
B
D
Yes,
they're
on
the
items,
so
I'm
gonna
actually
delete
the
next
item
for
now,
because
I
don't
think
it's
relevant
based
on
what
we
just
said:
drafting
a
summary
or
planning
doc
with
values,
goals
and
priorities,
blockers
risks,
etc.
I
guess
this
came
up
in
some
chats
but
yeah.
We
don't
need
to
do
that
or
think
about
that
yet
because
we
might
want
to
have
a
different
approach
for
getting
this
going
and
then
I
think
yeah.
D
These
were
just
kind
of
notes
to
provide
context
for
the
conversation
where
this
was
coming
up
or
one
of
the
conversations.
D
So
I
guess
that
one's
done
ci
signal
and
then
the
next
one
was
needing
interlock
with
six
scalability.
Regarding
upgrades
and
new
go
versions.
A
So
yeah
I'll
shoot
an
email
to
them.
I
guess.
A
D
A
Yeah
no.
A
D
A
It's
a
team
team
effort,
but
but
I
don't
concretely
know
what
the
next
action
is
right
now.
Okay,
so
let
me
think
on
it
a
little
bit
and
we'll
we
can
chat
on
on
slack.
D
Yeah,
I
also
had
a
chat
yesterday,
that's
relevant
to
this
topic,
but
I'll
share
it
with
you
first
just
because
yeah,
that's
fine
all
right,
so
I
will
just
have
that
you're,
the
owner
to
drop
an
email,
basically
to
get
things
started
on
this
like
getting
conversation
started,
is
that
the
goal
of
the.
D
A
E
A
So
there
is
a
code
walkthroughs
or
something
playlist.
That
is,
I
think,
it's
maintained
by
sig
contributor
experience.
That
would
probably
be
a
reasonable
place
for
that.
I
believe
they
should
both
be
up
on
our
playlists,
though
so
so
that
should
be.
That
should
be
a
start
and
yeah.
I
think
max
has
been
reaching
out.
I
need
to
get
back
to
him
about
a
go
update,
blog
post,
maybe.
E
A
The
release
so
I'll
see,
if
I
kind
of
I
kind
of
want
to
sit
down
with
it
for
a
bit.
Now
that
I
mean
we've
every
every
go
update
is
slightly
different.
So
now
that
I
have
a
little
bit
more
details
than
I
did
when
I
initially
recorded
those,
I
probably
want
to
layer
some
more
stuff
on
before
I
write
a
post
but
yeah,
I
would
say
code
walkthrough
lists
the
and
a
blog
post
is
probably
it's
probably
sufficient.
D
A
It's
going
to
be
documentation
honestly,
I
started
a
doc
for
doing
the
updates
and
I
want
to
make
sure
that
that
is
done
before
we
hype
before
any
hype
happens,
and
my
mindset
has
changed
a
little
bit
about
how
I
was
going
to
write
the
doc
so
now
that
the
bazel
stuff
is,
I
understand
more
of
it
than
I
did
before
so.
D
It,
okay
so
finishing
that
and
then
dealing
with
the
posting
later.
D
And
that
could
also
be
maybe
like
provide
the
primary
substance
for
your
blog
post.
That's.
D
Cool-
and
the
last
item
was
veronica's
basil
notes
like
what
to
do
with
those.
So
I
haven't
heard
back
from
her
on
this
issue,
so
we
just
reach
out
and
see
what
her
plans
are.
I
think
she
was
at
that
meeting
and
it
came
up.
D
D
Okay,
so
that
was
that
was
from
the
last
meeting
and
I
missed
a
couple
because
of
how
searches
and
other
things
was,
is
there
anything
that
anyone
here
believes
is
missing
from
the
picture
from
the
past
few
meetings?
I
can
comb
the
notes
from
the
agendas
as
well
and
see
if
anything
is
an
action
item
that
should
be
tracked,
but.
D
A
Because
the
yeah
we've
played
with
the
schedule
this
this
this
cycle,
you
know
there
were
initially
we
had
set
a
schedule
and
or
proposed
an
update
to
the
119
schedule
and
we
kind
of
drifted
towards
a
slightly
different
schedule
and
then
towards
the
end
of
the
cycle.
We've
drifted
back
essentially
to
what
was
initially
proposed.
So
I
think
I
think
part
of
that
tail
end
of
where
we're
moving
into
the
or
soon
be
moving
we'll
soon
be
moving
into
that
kubecon
blackout
period
kind
of
part
of
the
schedule.
A
We
should
think
deeply
about
what
code
thought
means
right,
because
we're
right
now
we're
we've
got
these
questions
open
that
are
when,
when
how
what's
you
know
a
good
point
to
him
to
mention
the
criteria,
because
I
think
we're,
I
think,
we're
playing
it
by
ear
this
cycle,
a
lot
of
it
has
been
and
and
the
you
know,
to
to
an
extent
that
happens
every
cycle
we
just
make
it
look
good.
A
I
guess
the
the
release
date
that
we
publish
is
always
a
tentative
release
date
and
we
try
to
make
sure
that
we
say
tentative
in
our
announcements,
because,
ultimately
we
don't
know
what
can
happen
and
a
lot
of
things
do
happen,
and
this
is
a
cycle
that
a
lot
of
things
have
happened.
So
I
think,
with
the
the
go
115
updates
with
the
kind
of
rockiness
in
nci,
I
think
it's
important
to
we're
having
a
discussion
yesterday
with
aaron.
D
Sorry,
the
pride,
the
priorities-
yeah,
okay
yeah-
got
it
sure,
just
an
update,
because
a
lot
of
folks
here
were
attended.
The
prioritization
breakouts
that
we
had
a
few
years
ago.
It
just
seems-
but
I
guess
around
four
to
six
weeks
ago.
I
just
wanted
to
let
you
know
that
there
are
efforts
underway
to
organize
the
work
that
you
had
highlighted
as
top
priorities.
D
All
of
it
will
be
shared
with
you,
basically
stephen
tim,
jorge
and
sasha,
and
I
got
together
yesterday
and
we'll
get
together
one
more
time
to
take
a
sweep
of
the
many
different
release.
Team
related
backlogs.
So
a
lot
of
the
items
that
all
of
you
who
attended
those
breakouts
were
looking
at
plus
some
other
stuff
that
was
here
and
there
we're
basically
trying
to
get
rid
of
the
noise
and
delegate
items
that
the
release
team
shouldn't
be
owning
or
the
releasing.
D
So
so
yeah.
So
there's
one
thread
of
work
around
going
through
a
lot
of
the
crud
plus
many
of
the
breakout
topics
again,
but
with
that
particular
group
of
four
individuals-
and
you
know
getting
some
structure
around
that
and
then
also
some
of
the
items
that
we
covered
in
those
breakouts
are
being
dealt
with
in
smaller
batches.
D
Like
so
one
example
is
that
we
had
a
lot
of
enthusiasm
around
making
the
release
team
more
asynchronous,
and
so
we
met
it
was
tim
and
nabarro,
and
I
met
yesterday
just
to
talk
about
inclusivity
as
they
value
in
their
releasing
and
in
a
team.
And
as
we
were
talking,
the
async
team
concept
came
up,
because,
obviously
we
want
to
include
all
the
members
of
the
team
regardless
of
time
zone
and
then
from
there.
We
also
touched
upon
some
of
the
onboarding
needs
that
we
have
talked
about
in
the
past.
D
How
do
the
team
members
check
in
with
their
leads
and
other
members
of
the
team
to
give
some
input
about
how
they
think
the
process
is
going?
How
they're
feeling
about
things
do
they
need
anything?
So
we
we
talked
about
a
lot
of
these,
and,
and
none
of
this
was
really
new.
It
was
all
covered
in
past
github
issues
and
some
chats
and
some
documents
that,
like
again
we've
covered
in
prioritization
sessions,
they've
been
some
of
these
items
have
been
hanging
around
for
a
while.
D
The
async
time
zone
issue
and
making
sure
people
can
attend
meetings
and
figuring
out
the
way
to
to
help
them
participate
across
around
the
world
and
then
just
overall,
like
collecting
feedback
about
how
inclusive
we
are.
So
what
I'll
do
is
I'll
draft
the
notes
from
yesterday
and
some
of
the
items
from
our
priorities
and
the
prioritization
session
spreadsheets
and
put
it
all
together
and
then
share
it
with
you,
and
then
you
can
offer
feedback.
D
So
we
started
with
this
one
because
there's
there
was
a
lot
of
interest
in
the
async
team
topic
and
then
I've
also
reached
out
to
david
mckay,
because
he
was
a
former
release
team
member
and
he
wanted
to
get
back
into
the
sig
and
start
contributing.
And
I
reached
out
to
him.
He
was
the
person
who
actually
filed
the
original
github
issue
that
spurred
a
long
discussion
about
how
we
should
be
more
asynchronous,
and
he
made
some
comments
on
my
notes
that
I'll
use
to
prepare
the
draft
document
for
all
of
you.
D
So
it
would
be
great
to
have
you
know
an
owner
for
that
topic,
because
it's
hugely
important
and
then
we
might
need
other
owners
for,
like
the
onboarding
part
and
the
feedback
collection.
Part.
C
A
Sounds
great,
thank
you,
lori
for
working
on
that
thanks
and
shout
out
to
david
for
opening
that
issue
back
in
the
day
it's
been
a
few
releases,
so
it's
it's
nice
to
see
things
moving
along.
A
Last
up,
so
there
is
a
there
is
a
sig
testing
meeting
later
today.
The
proposal
that
we
had
mentioned
policies
to
improve
kubernetes
ci
will
be
discussed
there.
A
A
So
some
top
level
concerned
cares
objectives
to
reduce
the
infrastructure,
ci
failures.
If
you
have
pushed
a
pr
to
kubernetes
kubernetes
or
had
to
improve
one,
you
have
noticed
that
things
have
been
slow.
Things
have
been
slow
in
terms
of
the
the
the
tide
queue
the
amount
of
pre-summit
failures.
A
The
fact
that
some
of
those
failures
have
been
pod
pending
time
out
are
scheduling
issues
for
for
prow.
So
the
overall
proposal
is
around
like
what
can
we
do?
What
can
we
do?
How
can
we
do
this,
and
the
discussion
that
we
were
having
yesterday
between
the
sig
release,
leads
and
and
and
aaron
essentially
amounted
to
like
what
does
again?
What
does
code
thaw
look
like
right
when
when
should
or
shouldn't,
we
do
this
and
the
initial
you
know
the
initial
goal
of
elongating.
A
The
119
release
cycle
was
to
give
people
time
to
catch
their
breath
right,
but
also
give
some
time
to
focus
instead
of
focusing
on
future
work,
focusing
on
planning
right,
focusing
on
planning
focusing
on
stability
overall
right.
So,
like
the
the
code
freeze
period
was
you
know
the
the
hope
is
that
more
people
would
be
working
on
on
stability
effort
so
coming.
You
know
now
that
we're
within
it
and
and
considering
exiting
it,
we're
thinking.
A
Do
we
exit
now
do
exit
now
or
do
we
try
to
solve
some
of
these
problems
while
we're
in
a
period
where
the
code
is
moving
a
little
slower?
A
So
take
a
look
at
this
proposal.
The
if
you
join
the
sig
kubernetes
hyphen
sig
hyphen
testing
at
google
groups.com
mailing
list.
You
will
get
an
invite
for
that
meeting
if
you're
interested
in
attending.
I
would
love
to
see
people
who
are
interested
in
ci
signal
jump
into
that
meeting.
I
will
be
there
tim,
I'm
not
sure
if
you
can
can
also
make
that
time
slot.
I'm.
A
A
Okay,
just
a
few
seconds
to
spare
so
always
lovely
hanging
with
you
all.
I
will
catch
you
if
you're
on
the
release
team
I'll
catch
you
at
one
of
the
next
meetings,
if
not
we'll
catch
you
for
the
sig,
yes
laurie.
One
question.