►
From YouTube: SIG Release Weekly Meeting 20200825
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
august
25th.
This
is
a
sig
release
meeting
one
of
our
bi-weekly
meetings.
This
is
a
meeting
that
is
recorded
and
available
on
the
internet
are
will
be
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
Note
that
I
said
tomorrow
and
not
today,
so
I
think
the
first
item
from
let's
get
updates
from
the
release
team,
so
I'll,
let
I'll
let
taylor
kick
it
off
and
then
I'll
kick
it
over
to
dan
and
rob
for
some
ci
signal
updates.
B
Howdy
everybody,
so
as
you
can,
as
you
heard
from
steven,
we
are
targeting
release
for
tomorrow.
Instead
of
today,
I
sent
out
some
updates
yesterday
evening,
pacific
time
we
are
going
to
be
pushing
that
forward
by
at
least
24
hours.
Just
give
some.
We
did
get
some
prs
and
some
fixes
in
yesterday,
and
so
we
wanted
those
tests
to
soak
for
a
little
bit
and
get
a
little
bit
more
signal.
Make
sure
we
have
everything
covered
so
currently
we're
on
track
for
wednesday.
B
As
our
release,
I
did
want
to
kind
of
talk
through
the
flakes
and
everything
else
that
we
saw
this
morning
and
get
a
good
sense
of
that,
but
obviously
we'll
turn
over
to
dan
and
rob
on
that
front
with
the
community
meeting
as
well
looking
at
pushing
that
out
to
next
week,
potentially
as
well,
you
know,
barring
just
when
we
release
and
what
that
looks
like
just
to
give
some
some
give
people
some
time
to
think
of
any
other
feedback
or
things
on
that
nature,
but
wanted
to
check
in
a
little
bit
with
this
team
and
then
we'll
be
checking
with
the
release
team
as
well.
B
To
see
what
everyone
thinks
of
that
other
than
that,
I
don't
have
any
updates,
but
thank
you
so
much
for
all
the
help
on
119.
it's
been
a
marathon
release.
I
can't
wait
to
share
the
mascot
out
with
everyone
and
the
release
theme
has
dropped.
It's
called
accentuate
the
paw
positive,
so
that
gives
you
some
clue
as
to
what
you
might
see
for
the
release
logo,
but
thank
you
again
so
much.
D
Yeah
for
sure,
so
we
had
a
few
things
land
yesterday.
The
the
major
thing
that
we
talked
about
at
the
burn
down
meeting
was
that
the
integration
job
and
verify
jobs
for
mastering
1.19
were
flaking
super
hard
that
was
related
to
an
infrastructure
change
that
was
made
at
the
end
of
last
week
and
we
ended
up
reverting
that
for
now
and
those
have
gotten
a
lot
more
healthy.
In
fact,
I
don't
think
we've
seen
a
failure
on
either
one
of
those
since
that
revert.
D
So
that
was
great
for
a
little
more
context
for
folks
who
weren't
following
the
conversation
along
delaying
the
release
24
hours.
That
was
primarily
because
we
had
a
few
pr's
merge
kind
of
late
yesterday
that
we
wanted
to
get
some
of
the
scalability
tests
I'm
running
on.
D
So
we
wanted
to
delay
those
to
to
see
that
those
soak
a
little
bit
and
we're
looking
pretty
good.
I
think
the
primary
update
from
a
signal
perspective
is
we
had
a
few
flakes
which
have
kind
of
popped
up
in
the
last
24
hours,
which
is
pretty
normal.
It's
pretty
normal
to
see
a
few
flakes
every
day
and
we've
logged
issues
for
those
each
of
those
right.
D
Now
from
what
I
can
tell
looks
like
test
only
issues
so
things
that
are
just
you
know
related
to
how
we're
running
the
test,
rather
than
actual
the
the
code
quality
of
the
code
that
would
be
in
the
release.
So
those
are
not
a
major
concern.
That
being
said,
we
would
like
to
get
folks
from
each
of
the
cigs
that
are
responsible
for
those
tests
to
kind
of
like
take
at
least
a
quick
pass
through
and
actually
just
looks
like.
D
I
just
got
a
message
from
signo
that
they're
taking
a
look
now
so
we'd
like
for
them
to
take
a
quick
look
and
just
verify.
You
know
that
those
aren't
critical
things
and
and
that
they
are
test
only
in
which
case
we're
comfortable
shifting
to
fixing
those
after
the
release,
but
in
general,
as
you'd
measure,
you
know
like
go
or
no
go,
we'd
definitely
be
go
right
now,
just
a
few
of
the
jobs
have
one
or
two
flakes
in
the
last
10
or
so
runs
so
we're
looking
pretty
good.
D
Yes,
rob
has
logged
in
issue,
one
other
person
and
ci
signal
has
logged
them.
We
have
tagged
the
appropriate
groups
on
those
as
well
as
reached
out
in
slack,
so
we
are
looking
pretty
good
on
that
front
and
if
you
know
in
a
few
hours
we
haven't
heard
on
one
of
them,
then
we'll
follow
up
again
and
see.
If
there's
someone
else
in
the
sig
who
who
can
take
a.
A
A
So
dan,
this
looks
like
this
mirror
pod.
With
grace
period,
one
looks
directly
related
to
what
we
just
merged.
D
Yes,
I
think
it
is
related,
but
I'm
not
sure
that
it
is
effect
like
it
is
the
same
area.
It
touches
the
same
area
right,
but
I'm
not
sure
that
it's
related
to
the
actual
change
we
made.
But
we
do
have
someone
taking
a
look
at
that.
So
we
will
see
okay,
because
it's
it's
basically,
the
issue
is
the
pod
is
not
being
found
and
we're
using
kind
of
a
long
generation
strategy
on
the
names
of
those
pods.
D
So
I'm
wondering
if
we
have
a
mismatch
somewhere
in
the
test,
but
that
is
the
one
that
I
just
got
pain
that
they're
taking
a
look
at
so
I'll,
make
sure.
A
Okay,
perfect,
perfect
yeah.
I
see
seth
just
assigned
himself
to
that
suite.
Okay,
any
questions
for
ci
signal
release,
team.
A
Okay,
so
with
regards
to
the
120
release,
two
updates,
one
you're-
probably
already
familiar
with.
If
you're
on
this
call
us
that
jeremy
rickard
has
been
selected
as
the
120
release
team
lead.
I
think
jeremy
is
going
to
do
an
awesome
job,
so
I'm
super
excited
for
that.
A
We
have
also
selected
all
of
the
roll
leads
for
the
120
release,
so
hats
off
to
everyone
for
a
quick
selection.
Congrats
to
all
of
the
new
role
leads
again.
I
know
you're
going
to
do
phenomenal
jobs.
A
So
the
next
thing
that
we
have
to
focus
on
will
be
building
building
the
rest
of
the
team
building
the
shadows,
and
that
means
that
there
will
be
a
shadow
application
inbound
soon,
so
stay
tuned.
If
you
have
people
who
are
interested
in
the
release,
team
tell
them
to
follow
the
issue,
the
issue
for
assembling
the
release
team
and
we
will
post
as
well
as
making
sure
they're
subscribed
to
kubernetes
dev,
and
we
will
post
the
shadow
application
when
it's
ready
in
both
locations.
A
E
B
A
On
okie
doke,
all
right,
so
next
up
is
release
engineering.
So
I
have
a
few
updates
on
that,
and
first
off
is
that
the
final
116
patch
will
be
happening.
We
initially
were
going
to
have
one
1614,
be
the
the
final
release
for
one.
A
The
116
branch,
but
there
are
a
few
things
in
the
queue
jordan
had
mentioned,
would
be
nice
to
train
before
we
officially
shut
down,
and
given
that
we
usually
cut
that
final
release
post
the
n
plus
three
release
right
so
that
one
that
119
release
we
decided
to
keep
with
tradition
for
for
now,
so
116
15
is
targeted
to
be
released
soon
after
the
119
zero
release.
A
A
There
was
an
email
that
was
sent
out
pr
merged
by
carlos
yesterday
and
an
email
sent
out
to
the
community
yesterday
early
this
morning,
yeah
the
so
some
of
the
stuff
that
I've
been
working
on.
I've
been
largely
focused
on
going
and
base
image
updates
and
all
those
fun
things
for
the
cycle
outside
of
the
usual
administrivia.
A
In
doing
a
lot
of
these
updates
and
and
starting
to
move
so
one
at
the
beginning
of
the
cycle,
we
essentially
moved
ownership
from
the
from
kubernetes
kubernetes
migrated
the
code
for
image,
building
from
kubernetes
kubernetes
into
kubernetes
release.
The
reason
for
this
is
that
it's
just
better,
faster,
harder,
better,
faster,
stronger.
A
The
the
big
reason
for
this
is
speed
of
iteration
over
base
image
changes
right,
dealing
with
flaky
flaky
pre-resubmits
are
failing.
Pre-Submits
on
on
code
that
is
not
actually
being
tested
in
those
pre-submits
is
a
little
frustrating
and
it's
not
necessarily
a
route
that
we
want
to
deal
with
when
we're
having
to
patch
cvs
for
these
base
images
right
so
kind
of
made
the
decision
there.
That
would
be
they
would
be
better
suited
in
a
repair
that
we
could
iterate
over
faster.
A
So
I've
been
doing
that
over
the
past
cycle,
the
most
recent
one,
because
we've
been
doing
so
many,
it's
gotten
to
the
point
where
I
don't
necessarily
always
know.
What's
inside
of
the
next
image
that
we
roll,
which
is
not
great,
so
we
extended
the
debian
base
images
to
support
two
streams.
A
A
Sorry
and
then
buster
is
debian
10,
so
the
newer
images
or
the
v2
series
of
the
devin
base
images
are
based
on
debbie
and
buster,
but
there's
no
way
to
know
that
by
just
looking
at
the
tags,
so
I
kind
of
changed
the
tag
format
moving
forward.
A
The
tag
format
will
be
os,
codename
dash,
v
x,
dot
y
dot,
z
right.
So,
if
you're
dealing
with
a
new
debian,
a
new
buster
image,
you
may
see
something
like
image:
debian
base,
you
know
kate's
keys.gcr,
dot,
io
slash,
you
know,
slash,
build
image,
slash,
debian
base
colon
buster
dash
v,
two
zero
zero
right,
and
that
will
give
you
an
indicator
at
least
that
we
know
what's
inside
of
it,
that
it's
buster.
A
We
do
need
to
work
on
surfacing
exactly
what
images
have
changed.
What
things
have
changed
within
an
image
from
update
to
update
so
we'll
work
on
that
for
120.
A
And
sorry,
I'm
having
a
bit
of
a
coughing
fit
that's
fun,
so
we
did
something
similar
for
the
go
runner
image.
The
go
runner
image
is
essentially
a
in
addition
to
it's:
it's
essentially
digitalist
plus
plus
right.
So
it's
a
few
things
that
we've
built
into
the
distro-less
static
image
to
allow
us
to
do
some
exacting
for
instances
where
we
require
a
shell
as
well
as
aggregating
logs,
in
the
way
that
we're
used
to
doing
for
core
images.
A
So
the
gowramer
image
is
used
for
starting
in
119
the
go
runner
image
is
used
for
several
of
the
core
images,
so
think:
api
server,
controller
manager
scheduler
that
we
publish
as
release
artifacts.
So
we've
been
watching
over
the
cycle,
how
those
images
perform
and
are
generally
happy.
A
A
There
is
an
overarching
effort
to
move
images
to
additionalists
or
to
have
digital
spaces.
That's
been
worked
over
the
last
two
three
cycles
at
this
point,
so
we're
making
some
good
headway.
That
work
will
continue
in
and
120
and
I
hope
to
teach
a
few
of
you
how
to
roll
the
images
so
that
I
can
do
less
of
it.
What.
A
I
think
it's
I,
I
think
what
we've
done
over
the
last
few
cycles
is:
it's
been
kind
of
go,
go,
go
and
execution
as
opposed
to
stepping
back
and
being
able
to
strategize
about
certain
things
and
when
you're
making
the
decision
around.
Do
I
patch
a
cv,
or
do
I
teach
someone
how
to
do
this
thing
right?
It
becomes
you
the
the
priority
leans
towards
let's
patch
the
cv,
because
it's
it's
very
important.
A
So
I
think
you
know
I
want
to
do
something
similar
to
what
we
did
for
the
golang
updates,
which
is
record
a
nice
long
session
of
how
to
do
this
stuff,
but
also
given
that
we've
seen
a
bit
of
a
trail
off
fingers
crossed
on
cv
activity
for
for
the
year.
That
that'll
give
some
time
to
step
back
and
and
write
more
documentation
and
build
policies
around
the
process,
so
documentation
on
execution
policies
on
the
process,
as
well
as
video
training
and
answering
any
questions
you
all
may
have.
A
A
These
were
images
that
previously
had
been
under
google's
purview,
so
there
was
a
bit
of
learning
before
actually
doing
and
now
doing
and
and
now
stepping
back
to
teach
right.
So
I
think
I
think
that
overall,
that
should
work.
If
that
sounds
good
to
y'all,.
A
It's
not
that
bad,
it's
you
know
like
yeah,
10
minutes
or
so
right,
given
that
we
have
multiple
variants
of
of
the
image,
it's
you
know
times
as
many
variants,
but
the
variants
are
running
concurrently
right.
That
is
simply
to
build
the
image.
The
fun
part.
The
fun
part
comes
in
with
the
fact
that
some
of
these
images
are
based
on
each
other
right
so
debbie
and
ip
tables,
and
there
so
the
debian
base
is
the
base.
A
Debian
base
image
and
w9p
tables
is
usually
the
next
one
that
gets
built.
Wnip
tables
is
based
on
debian
base,
and
then
there
is
for
previous
branches.
A
There
is
the
debian
hypercube
base
image
that
one
is
based
on
the
debian
ip
tables
image
right,
so
there
is
kind
of
a
lovely
cycle
of
building
the
debian
base
image,
promoting
it
coming
back
to
build
the
wniv
tables
image,
promoting
that
coming
back
to
build
a
debian,
hypercube
image,
promoting
that
and
then
issuing
a
pr
to
kubernetes
kubernetes
to
update
the
actual
images
that
are
in
use.
So
so
it's
not
it's
not
too
involved
it's
more
mechanical
than
anything
else.
A
There
are
steps
that
that
need
to
be
repeated,
and
I
do
want
to
teach
people
how
to
do
these
steps
before
we,
because
I
know
someone's
about
to
say
it
and
I've
been
thinking
about
it
like
how
do
we
automate
this
soon
we
need
to.
I
think
we
need
to
have
a
clear
understanding.
That's
not
just
in
my
head
of
how
to
do
it
before
we.
We
start
automating
everything
away,
cool.
A
Going
into
120,
we
will
have
so
lori
myself
in
the
leads
we're
working
on
kind
of
what
stability
looks
like
like
what
are
our
common
themes
for
stability
and
lori
I'll?
Let
you
talk
about
that
a
little
later,
but
it's
in
the
cards
it's
in
the
cards.
We
just
want
to
make
sure
that
we
target
the
most
important
things
given
that
we
have
such
a
short
cycle
coming
up.
A
Okay,
all
right
so
next
up
we
did
some
migration
of
the
well.
I
mentioned
that
the
go
runner
image
too,
to
kubernetes
release
the
it
also
follows
that
format
now
that
image
tag
format,
so
os
code
name
dash
version
number.
The
reason
for
that.
A
I
got
a
few
questions
about
white
in
code,
the
os
code
name,
digitalis
images
are
built
on
built
on
debian,
so
it's
important
to
know
that
when
we're
when
we're
building
them-
and
it's
also
important
to
encode
that
information
into
the
build,
there
are
two
streams
of
disholous
images
for
static,
specifically
so
static
static,
debian,
10
and
static
debian
9..
Initially,
by
default
we
were
people
who
were
pulling
static
images.
A
A
A
So
information
about
moving
forward
information
about
both
the
go
version
that
is
in
use
during
the
google
cloud,
build
as
well
as
the
os
code
name
are,
are
part
of
the
are
part
of
the
tags
that
you
can
look
up
on
on
google
cloud
build
the
all
right,
so
kubernetes
release
currently
has
a
merge,
blocker
applied
to
it.
So
if
you
are
seeing
any
troubles
with
getting
things
merged
into
kubernetes
release,
that
is
why
this
is
a
good
time.
A
There
are
a
lot
of
pr's
that
are
inbound
that
are
so
thank
you
to
sasha
adolfo
carlos
a
few
others.
There
are
multiple
prs
that
are
inbound
that
are
changing
inaugural
changing
some
some
key
things
as
we
start
to
move
into
this.
Let's
kill
anago
entirely
path
for
the
hopefully
for
the
end
of
the
year,
and
those
will
potentially
affect
how
we
do
releases
so
I'll
make
sure
they
don't
go
in
until
after
the
119.0
release.
A
Just
to
just
to
minimize
the
variance
that
we
have
and
the
tooling
and
everything
else
that's
going
on,
so
thank
you
for
being
patient.
While
those
things
are
frozen,
we
should
see
them
released
at
the
end
of
day,
wednesday.
A
There,
okay,
all
right,
so
let's
do
two
things:
let's
review
any
new
kubernetes
kubernetes
issues
that
are
tagged
for
sig
release
and
then
lori.
I
will
kick
it
over
to
you
for
board.
E
G
E
A
A
So
do
we
want
to
go
over
net
new
things?
There
are
some
of
these
issues
that
I've
already
looked
at
that
way.
Maybe
you
don't
need
to
go
in
over
during
the
call.
C
A
A
This
is
a
good
opportunity.
I
think
this
is
both
sig
release
and
testing
to
try
to
root
out
ish
images
that
are
being
used
on
docker
hub.
A
I
will
say
ideally
we
want
all
of
our
images
to
be
sourced
from
gcr,
since
we
have
the
staging
infrastructure
and
the
image
promotion
policy
built
around
gcr,
but
I
think
a
lot
of
it
is
really
about
rooting
out
images
that
may
potentially
be
from.
You
know
someone's
personal
test
bed
right
where
this
is
a
less
an
us
problem
and
more
so
just
making
sure
that
I
think,
between
release,
testing
and
kate's
infrared
that
people
are
aware
that
staging
staging
repositories
are
available
to
them
to
build
out
and
paid
for.
A
More
importantly,
so
so
this
is
more
of
a
documentation
task.
This
is
more
of
a
I
think,
searching
through
searching
through
hound
and
trying
to
check
out
what
images
are
targeting
which
which
image
repositories.
A
You
we
yeah,
so
we
shouldn't
have
to
buy
ourselves
time
if
we're
using
the
staging
repositories
and
most
critical
processes
already
are
so.
This
is
more
about
finding
and
helping
out
then
process
improvement
directly.
Completing.
C
A
So
there's
some
updates
to
the
build
readme
coming
for
120,
probably
a
redo
to
remote,
remove
mentions
of
docker
machine
since
it's
a
project,
that's
in
maintenance
mode,
and
we
we're
also
going
to
look
at
assessing
some
of
the
remote
build
and
docker
machine
logic.
That
may
still
exist,
as
well
as
the
rsync
containers.
A
Fun
thing
that
we
do
to
basically
build
in
a
container
or
sink
or
sink
the
artifacts
out
of
it
and
and
then
push
those
around
gcs
buckets
during
the
release
process.
A
Okay,
that's
a
triage
thing.
Don't
need
to
look
at
this
now
interesting
thing.
A
Gcr
google
containers
instead
of
kates.gcr.io,
that's
the
inherent
problem
with
this
issue
that
they're
referencing
the
the
backing
registries,
instead
of
instead
of
the
the
vanity
endpoint.
Some
quick
glance,
things
that
I'm
noticing
here
is
one
don't
reference.
The
backing
registry.
A
There
is
a.
There,
are
geographic
endpoints
for
each
of
these,
so
this
would
be
us.
Gcr.Io
would
not
work
for
the
new
one,
it
would
be
us.gcr.io
or
asia.gcr.io
or
eu.gcr.io
for
those
endpoints.
A
But
the
real
reason
I
asked
for
this
to
be
filed
is
around
documentation.
We
did
send
out
notifications
to
the
community
on
a
few
occasions
that
this
was
happening
and
then
that
this
was
done,
but
that
does
not
necessarily
hit
all
of
our
consumers.
A
One
piece
of
feedback
that
we
got
from
this-
and
I
hear
occasionally,
is
that
what
what
I
look
for
is
what
the
release
notes
right.
I
assume
the
release
notes
to
be
law.
This
is
speaking
from
the
context
of
you
know,
consumer.
I
assume
the
release
notes
are
law.
I
I
look
at
the
release
notes
and
I
get
I
get
ideas
of
what
I
need
to
do
there
right.
A
So
that
said,
we
what
I
would
like
folks,
who
are
looking
at
and
and
maintaining
the
release,
notes
tools
overall
to
take
a
look
at
for
this
cycle
and
I'll.
I
can
file
an
issue
before.
A
Before
the
week
is
out
that
we
want
to,
we
want
to
take
a
look
at
what
I
think
this
is
two
pronged
one
is
probably
a
new
label
for
kubernetes
kubernetes
and
two
is
a
section
in
the
release
notes
for
bubbling
these
issues
up
right
when
infrastructure
changes
happen
right.
We
if
we
consider
we
consider
infrastructure,
at
least
with
the
labels
that
we
have
today
and
the
way
the
labels
are
scraped.
We
consider
infrastructure
changes
to
not
be
features
right.
They
don't
fall
so
for
kubernetes
release.
A
That
is
not
necessarily
true
right
for
anything
that
is
potentially
changing
infrastructure.
I
consider
that
to
be
a
feature,
a
bug
fix,
so
we
have
kind
of
a
different
grading
system
for
kubernetes
release
than
we
do
for
kubernetes
kubernetes
right.
But
if
we
change
a
base
image,
if
we
change,
if
we
change
backing
endpoints
so
on
and
so
forth,
how
do
people
know
right
and
can
we
truly
categorize
it?
As
a
feature?
A
Are
a
bug
fix?
It
depends
right
if
it's
not
actually,
if
it's
touching
harnesses,
as
opposed
to
like
kubernetes
court
code,
can
we
you
know
we
have.
We
have
kind
of
like
a
hand
wavy.
A
What's
what's
the
feature
like
what
you
know
or
where's
the
line
where
we
would
write
a
release
note
for
this
right,
so
I
think
that,
with
with
a
new
label,
I
don't
know
what
we
would
call
this
label
kind
infra
and
I'd
release
infra
something
right
that
we'd
be
able
to
target
against
and
say,
like
hey
here,
are
all
the
infrastructure
changes
that
we
made
for
for
this
release
that
you
might
need
to
be
aware
of
right.
G
I
have
one
so
we
were
we're
about
to
add
a
couple
of
sections
to
the
release
notes,
most
importantly,
the
cv
information.
G
So
it's
time,
as
you
said,
we
can
add
categorize
the
issue
as
as
with
a
new
label,
but
probably
it's
a
good
a
good
time
to
think.
If
someone
thinks
that
there
are
other
issues
that
the
other
sections
to
the
release
notes
that
have
to
be
added,
because
we
have
to
add
that
those
to
the
template
and
then
we
have
to
think
of
a
way
of
publishing
those
same
sections
in
the
website.
G
So
if
it
would
be
good
to
consider,
if
other
people
would
like
to
see
other
information
being
reflected
on
the
release
notes,
probably
it
would
be
a
good
time
to
to
at
least
foresee
what
they
would
like
to
be
to
see.
They're
included
that
to
just
to
plan
ahead
the
way
we're
going
to
do
it.
We
can,
we
can
add
the
the
infra
modifications
rather
easily,
but
if
there
are,
if
there's
have
more
modifications
at
what
people
would
like
to
see,
it's
a
good
time
to
hear
them.
A
For
sure
so,
yeah
the
the
cv
thing
is
exactly
what
came
to
mind
where
you're
making
a
change.
Maybe
it's
like
a
secret
change
or
maybe
it's
a
change
that
is
not
within
the
context
of
fitting
neatly
into
a
a
release,
note
or
fitting
neatly
into
the
scope
of
a
release
itself
right.
Maybe
it's
a
change
that
you've
made.
You
know,
for
example,
dan
with
the
infrastructure
change.
That's
happened
that
affected
the
integration
tests
right.
A
A
Maybe
there
is
a
separate
place
that
we
bubble
those
kinds
of
issues
up,
but
I
think
it
would
be
cool
if
you
know
anyone
who's
working
on
release,
notes
so
adolfo
you
sasha
sit
down
and
maybe
generate
some
questions,
you'd
like
to
ask
the
community-
and
we
can
do
a
survey
on
that
for
release,
notes,
improvements
for
sure.
F
C
I
can
help
you
with
that,
because
I
like
to
do
a
survey
like
brainstorm
the
questions
with
teams,
so
I'm
happy
to
help.
F
So
so,
basically,
from
a
high
level
point
of
view,
we're
making
a
customer
impactful
change
that
isn't
associated
with
a
set
of
new
features,
but
does
have
a
customer
impact,
and-
and
so
so
the
question
is:
where
do
we
document
that
and
a
good
question
and
the
one
immediate
bit
of
feedback
I'd
have?
F
Is
that
if
we
were
thinking
about
labeling
it
and
from
our
point
of
view,
we
would
see
this
as
an
infrastructural
change,
but
from
a
customer
point
of
view,
they
wouldn't
necessarily
see
it
as
an
infrastructural
change,
even
though,
if
you
explain
it
to
them,
they
go
oh
yeah.
Okay,
we
have
there's
a
new
domain.
Your
hosting
image
is
in
the
new
place.
F
F
Alluding
to
yeah,
so
so
from
the
point
of
view
of
labeling
and
trying
to
capture
this
I'd,
suggest
trying
to
take
a
customer.
Choose
a
customer,
an
end
user
type,
central
category,
yeah.
E
F
In
addition,
I'd
also
say
it's
valid
for
us
to
label
us
as
an
infrastructure
change,
but
we
could
also
additionally
label
it
as
customer
impacting
or
yeah
and
I'll
come
back
to
you
in
three
or
four
days
with
better
names
but
yeah,
but
I'd
be.
I
I'd
suggest
that
that
yeah,
you
cut
multiple
labels
from
multiple
stakeholders.
Point
of
view,
points
of
view.
A
And-
and
I
would
I
would
say
that,
in
addition
to
all
of
that,
we
need
to
think
about
a
better
process
for
the
late
stage.
Releasing
late
stage,
release
notes
things
that
may
turn
into
deprecations
are
fairly
easy.
We
have
you
know
we
have
labels
for
that,
but
something
that
is
a
major
theme
considered
to
be
a
major
theme,
part
of
a
major
theme
right.
A
We
should
have
less
because
I've
seen
some
of
the
conversation
going
back
and
forth
and
adolfo
thanks
for
staying
on
top
of
that
stuff,
but
essentially
like
thinking
about
what
are
major
themes.
How
do
we
categorize
some
of
these
things?
We
shouldn't
necessarily
have
to
rely
on
rely
on
getting
feedback
directly
from
from
some.
You
know,
google
doc
and
then
you
know
hand
scribing
this
into
another
location
kind
of
thing,
working
on
something.
G
For
that,
actually
this
this
version
is
based
on
the
process
that
I
wrote
that
didn't
actually
fit
the
because
it
doesn't
fit
with
the
embargo
process
and
we're
going
to
add
some
of
that
to
the
retro
to
discuss
during
that.
Okay.
A
And
then
also
the
there's
something
related
that's
gone
from
my
mind
now,
but
but
I
would
say
if,
as
we're
iterating
through
this,
because
release
notes
changes
fairly
frequently
across
the
cycle,
please,
I
know
that
there
is
a
pr
open
already,
but
please
head
back
to
that
pr
for
the
kep
update
and
update
it
with
current
plans.
A
A
I
say
that
to
say
that
on
any
one
day,
I'm
not
sure
how
to
do
release
notes,
and
I
want
to
make
sure
that
that's
incredibly
clear
for
the
community
as
we
move
through
these
improvements.
C
F
Is
that
fair?
Do
you
think
yeah?
So
so,
traditionally,
a
set
of
release,
notes,
delineates,
a
list
of
new
features
and
new
bug
fixes
associated
with
an
application,
but
because
this
is,
you
know,
a
cloud-based
application,
we're
talking
about
a
change
that
doesn't
neatly
fit
into
the
release.
F
Notes
at
all,
although
release
notes
is
a
reasonable
place
to
make
such
an
announcement,
but
in
addition
to
that,
there
almost
needs
to
be
a
separate
communications
channel
to
make
such
important
announcements,
because,
ultimately,
an
announcement
like
this
could
break
an
end
user
and
how
to
manage
that
communication
stream
out
to
customers.
F
There's
a
part
of
me
thinking
that,
in
terms
of
responsibility,
this
is
this
is
something
that
would
lie
with
vendors.
A
I
think
that-
and
we
had
talked
about
this
in
previous
release
cycles
too,
and
I
completely
agree
there
needs
to
be
another
place
for
information
to
surface
about,
because
not
everyone
reads:
release
notes
right,
nor
should
release
notes,
be
your
your
only
source
of
information,
especially
with
a
project.
That's
big!
It
ties
into
the
whole.
The
release
train
is
coming
right.
Everybody
get
on
board.
If
you
want
to
be
a
part
of
that
train,
we
expect
things
to
happen
at
a
certain
time
right.
A
We
expect
you
to
get
your
notes
and
at
certain
time
we
expect
you
to
merge
your
prs
at
a
certain
time
and
that's
to
all
to
a
lot
of
that
is
around.
I
mean
not
just
fitness
of
the
release,
but
also
the
communications
that
we
go
through
right.
So,
if
you're
not
in
the
release,
if
you're
not
in
the
release
notes,
you
may
not
get
mentioned
on
the
cncf
webinar
that
happens
right
or
you
might
not
get
mentioned
in
the
blog
posts
and
stuff
like
that
right
and
that's
important
to
sigs.
A
I
think
that's
the
really
should
not
be
the
be
all
and
all
communications
mechanism
for
that.
I
think
that
we
can
maybe
brainstorm
a
little
with
with
the
contributor
experience
with
docs
as
we're
moving
through
seeing
some
of
these
improvements
like
the
contributor
site.
That
is
now
up
the
the
fact
that
we
have
an
upstream
marketing
team.
The
fact
that
we
have
a
com,
sub
team
in
the
release
team.
A
We
should
have
a
little
tighter
intel,
interlock
there
and
do
some
brainstorming
on
what
we
can
do
to
improve
that
communications
process.
I
think
that's
what
I
would
eventually
like
to
see
is
you
know
there
was
a
mention
of
a
releases
page
for.
E
A
Yeah
that
docs
is
working
on
right
now
there
are
a
few
pr's
up
and
and
some
tracking
issues.
If
anyone
knows
those
off
of
the
top
of
their
head
and
wants
to
link
them.
A
Be
appreciated,
there's
also
downloading
kubernetes.com,
which
is
a
repo
that
we're
working
on
donating
in.
That
is
pretty
it's
pretty
slick,
it's
it's
slick,
but
it's
simple
basically
gives
you
links
to
download
various
aspects
of
kubernetes
across
multiple
versions
across
multiple
architectures,
so
kind
of
the
front
end
to
our
it's
more
of
an
extended.
A
If
you
think
an
extended
kind
of
gcs
web
right
extended
front
end
to
our
our
gcs
buckets
for
releases,
so
I
thought
it
would
be
cool
to
see
if
we
could
donate
that
and
chuck
had
agreed
that
was
yesterday
so
donation
in
progress,
and
hopefully
that
can
all
dovetail
with
with
the
releases
and
k
website
work
as
well.
A
But
I
see
the
release
notes
what
I
would
see
the
release
notes
as
when
I
started
to
think
of
of
that
releases
page
is
if
the
release
notes
ends
up
having
the
the
various
change
logs
end
up
having
front
front
matter,
yaml
front
matter
for
for
the
website.
That
means
that
we
can
build
pages
off
of.
A
A
If
you
want
to
hear
about
the
things
that
release
did
across
the
release,
check
out
blah
right
or
you
know,
for
up-to-date,
you
know
for
up-to-date
information
on
the
process
to
do
foo
go
check
out
the
contributor
site
right
and
if
I
think
I
think,
if
we
have
that,
you
know
even
ahead
of
the
major
themes
that
gives
people
starts
to
give
people
an
indicator
that,
like
release
notes,
are
not
the
only
place
to
go
for
information
for
those
people
who
only
use
release
notes
for
that
information.
A
Okay,
I
we
deeply
ate
into
the
the
board
walking
time,
but
I
think
that
this
is
important,
something
that
I'd
love
to
see
tackled
for
for
120,
especially
every.
F
Now
and
again
I
think,
I
think
also
we
didn't
really
answer
laurie's
question,
but
it's
in
terms
of
giving
it
an
impactful
title
for
this
work,
but
I
think
between
myself
and
stephen,
we'll
give
it
a
we'll
give
it
a
headline
that
that
larry
can
can
use
to
track
it.
C
C
F
C
A
That
this
is
something
that
we're
going
to
complete
for
120.
It's
something
I'd
like
to
see,
but
I
think
that
will
be
a
little
clearer
once
we
once
we
aggregate
like
the
true
stability
goals
for.
A
120
and
decide
on
decide
on
a
few
key
themes.
C
And
so
yeah
I
mean
it's
basically
like,
and
also
how
do
you
scope
the
goal
to
be
able
to
still
achieve
something
in
the
time
frame
that
you're
working
with?
So
if,
for
example,
if
this
issue
is
so
potentially
broad
that
it's
hard
to
put
a
name
on
it
right
away,
then
through
the
discussion
work,
you
can
find
an
angle
on
that
like
a
milestone.
That
would
be
smaller
and
more
achievable,
like
your.
A
C
There
might
be
future
wins,
but
I
don't
wanna.
I
don't
think
we're
gonna
resolve
that
right
now.
So
I
think,
with
the
six
minutes
we
have
left,
we
can
go
through
some
of
the
board
and
see
what
other
goals
we've
had
and
if
we
still
want
to
have
them
as
close,
because
maybe
maybe
we
don't
so
if
we
go
through
the
in
progress
column,
actually
I'll
share
my
screen,
so
this
should
be
more
helpful.
C
I'm
sharing,
I
think,
I'm
sharing
I'm
trying
to
share
here.
We
go
all
right.
So
first
we
have
this
updating,
ci
signal
issue
and
I
can't
actually
see
it.
So
this
is
from
dan.
It's
a
documentation,
need
updating
the
issue,
title
format.
D
Yeah,
there's
a
pr
open
for
this
one
there's
some
discussion
on
it.
I
know
jorge
pinged
me
for
an
update
here.
There
was
some
conversation
and
I
didn't
feel
like
it
was
totally
resolved,
but
I
I
think
I
could
make
an
update
and
kind
of
ping
folks
again
to
run
back
through
it.
I
think
the
final
decision
is
like
we
want
a
bit
of
a
decision
tree
so.
E
D
D
It's
had
feedback,
I
don't
think
it's
conclusive,
but
I
think
some
of
the
people
who
gave
feedback
thinks
it
think
it
is
so
I
I
think
I'm
going
to
give
it
another
pass
at
updating
and
then
see
if
it
matches
what
they
okay,
they're
thinking.
A
Yeah,
so
my
my
broad
strokes
on
this
one
is
is
that
yes,
I
agree
that
there
are
two
probably
decisions
that
we
would
need
to
make
if
it's
something
that
is,
if
it
is
something
that
is
primarily
stig
related,
we
should
label
it
as
such
right
if
it's
a
test
that,
if
it's
a
test
that
cuts
across
multiple
sigs
or
is
you
know
relevant
in
multiple
tests,
we
may
want
to
label
it.
We
may
want
to
do
it
job
specific
or
we
may
want
to
do
specific.
A
I
think
it
it
depends.
Is
the
answer
so
having
having
multiple
options,
for
that
would
be
good.
A
The
automated
base
images
updates-
this
is
kind
of
what
I
was
talking
about
earlier.
I
think
from
the
scope
of
the
original
request,
we're.
A
We
want
to
net,
we
want
to
next
solve
the
original
request.
What
this
turned
into
was
solving
for
even
having
control
over
building
the
images
right
which
we
have
done.
So
I
think
what
I'm
going
to
end
up
doing
is
saying
that
this
one
is
closed
and
opening
a
new
one
in
k,
release
to
talk
about
how
we
do
auto
bumping.
A
Same
thing
it's
tied
to
cap,
I
think
we
need
cap
update.
You
can
see
that
these
are
all
related
tasks,
so
yeah
cap
update
coming
in
for
120.
C
D
C
C
A
Yeah,
I
think
that's
what
has
changed
since
we
were
initially
thinking
about.
This
is
the
fact
that
we
have
more
people
on
the
leadership
team
and
we
had
been
talking
about
it
for
a
while,
but
I
think
this
leads
into
the
sig
release
charter
update
because
it's
been
a
bit
since
we've
done
a
charter
update.
I
think
some
things
have
changed.
A
I
think
the
instantiation
of
discussion,
four
sub-projects
should
happen
across
the
sig
instantiation
of
a
sub-project
is
the
responsibility
or
should
be
the
responsibility
of
a
technical
lead,
and
now
we
actually
have
technical
leads.
So
I
think
that
we
should
solidify
some
of
that
stuff.
I
think
we've
been
doing
it
a
little
hand
wavy
finger
in
the
air
this.
This
probably
looks
good
to
everyone.
Let's
do
it,
but
moving
forward.
We
should
probably
do
something
a
little
bit
more
official,
but
yes,
that
one
owes
a
response.
C
A
D
A
C
Okay,
so
what's
the
next
step,
then,
for
this,
what
we
wait
till
next
week
until
to
do
something.
C
Okay,
I'm
gonna
skip
this
one
for
a
sec.
A
Yeah,
so
so
for
those
who
are
working
on
triage
party,
there
is
a
new
version
out
and
looks
like
thomas
beat
me
to
the
the
comment,
but
I
saw
the
the
release
go
out
yesterday.
So
130
I
believe,
is
available
now
and
I
think
what
we
probably
want
to
do
next
is
update
our
our
deployment
of
triage
party
to
use
one
three.
E
A
So
I
see
veronica
marco
work
with
arno
to
get
an
understanding
of
the
config.
If
that's
something
you
all
want
to
continue
working
on
and
yeah
get
it
updated,
and
I
think
the
after
that
we
need
to
turn
this
issue
into
something.
A
Actionable
investigation
is
a
little
vague
and
we
should
say:
okay,
we
want
to
use
triage
party.
Let's
start
doing
it
figuring
out
how
to.
C
A
C
A
Okay,
perfect
all
right,
so
we
are
two
minutes
over
time,
so
it
has
been
a
pleasure
hanging
out
with
all
of
y'all
and
chatting.
We
will
catch
you
at
the
next
one
for
everyone
on
the
release
team.
Thank
you
for
your
hard
work.
Good
luck
coming
into
tomorrow.