►
From YouTube: Kubernetes SIG Release Meeting 20200811
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
11th.
This
is
a
one
of
the
bi-weekly
sig
release
meetings.
This
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
So
we
are
going
to
do
a
something
a
little
different
today,
which
is
actually
follow
the
agenda
template
of
the
meeting
so
we're
going
to
run
through
some
sub-project
updates.
We
kind
of
generally
do
this,
but
we
do
this
in
kind
of
a
more
haphazard
way,
so
we're
going
to
run
through
the
project
updates.
A
The
sub
project
updates
we're
going
to
hit
kubernetes
kubernetes
to
see
if
there
are
any
new
issues
to
review
for
sig
release
and
then
we're
going
to
kick
it
over
to
lori
for
some
project
board
review
and
then
again
we
if
there's
anything
that
you
want
to
discuss
that
is
mchale.
If
you
don't
mind
putting
that
in
the
open
discussion,
the
docs
piece.
A
So
away
we
go
first
up
licensing.
There
is
no
update
for
licensing.
I
think
this
has
kind
of
been
quiet
for
some
time
now,
but
there
are
one
or
two
issues
on
that
board
that
we
probably
want
to
take
a
look
at
so
moving
into
120
be
happy
to
take
some
volunteers.
A
If
people
are
interested
in
working
on
some
of
the
licensing
issues,
there
are
not
a
lot
of
things
to
the
point
where
I'm
not
sure
that
it
would
make
sense
to
spin
up
a
licensing
sub-project
meeting.
I
figure
that
we
can
just
do
licensing
updates
within
this
meeting
so,
but
if
anyone
is
in
generally
interested
in
talking
about
licensing
learning
about
licensing
working
on
some
of
the
licensing
things
to
tackle
within
the
the
project,
let
us
know
cool
all
right.
Next
up
is
release
engineering,
so
first
things.
A
First,
we
cut
a
new
release
of
the
kubernetes
release,
repo
and,
as
I
put
on
the
notes
it
chunky
has
been
quite
some
time
since
we
cut
the
last
release.
So
that
is,
we
moved
from
the
zero
three
four
patch
up
to
zero
four
zero
zero.
Four
zero
includes
a
few
things:
lots
of
new
image
builds
for
debian
based
images,
the
cube
cross
images,
lots
of
improvements
to
krell
overall,
on
the
release
note
side.
So
thank
you
to
adolfo
and
sasha
everybody
else.
Who's
been
working
on
the
release.
A
Note
stuff
on
krell
overall,
the
the
release,
libraries
and
some
nice
updates
to
our
overall
port
of
the
of
the
libraries
that
we
use
into
from
the
bash
libraries
over
to
go
so
that
is
moving
along
nicely.
I
think
that
we
will.
A
We
had
projected
to
see
a
replacement
of
anago
by
the
end
of
the
year
and
I
think
that's
based
on
the
pace
that
we're
keeping
right
now.
We
should
still
be
good
to
go
on
that
fingers
crossed
so
again.
Thank
you.
Everyone
who's
been
working
on
that
and
kind
of
allowing
me
to
work
on
other
things
as
a
result
of
that.
So
any
questions
on
krell
k,
release
image,
builds.
A
Sweet
all
right
so
specifically
for
the
image
builds.
There
are
some
new
ones
on
the
debian
base
image
side.
So
you
may
know
that
overall,
we're
working
on
moving
to
distro-less
images
for
a
lot
of
the
components
that
live
in
kubernetes
kubernetes.
A
However,
so
there
is
a
new
image
that
exists
called
go
runner
go.
Runner
is
just
a
little
sugar
on
top
of
the
on
top
of
the
distrolus
static
image,
and
that's
meant
to
provide
us
the
harness
that
we
need
to
to
drop
the
core
components:
core
kubernetes
components.
So,
like
the
api,
server
controller
manager,
scheduler
cube
proxy,
and
what
have
you
into
images
and
have
them
be
more
lightweight
images,
so,
starting
in
119?
A
We
should
see
images
built
with
that.
Instead,
I
believe,
all
of
our
images
are
up
to
date
at
this
point
are
using
using
go
runner
from
from
119
forward
for
the
core
components.
The
reason
that
we
maintain
the
debian
base
images
is
for
previous
releases
right,
so
we
have
118,
117
and
116
which
are
currently
in
support,
and
we
need
to
continue
providing
updates
to
them.
A
So
the
debian
base
images
are
currently
on
buster,
debian
buster,
and
we've
done
some
incremental
updates
to
those
mostly
to
pull
in
security
updates.
So
there
were
some
there's
the
cv
for
apt
that
was
recently
handled.
There
was
a
cv
for
pearl,
which
we
don't
directly
use
but
having
it
in
the
image
opens
us
up
to
that
possibility.
A
So
those
were
patched
over
the
last
week
and
a
half
and
those
images
are
built.
I
still
I'm
still
rolling
prs
for
updates
to
the
previous
branches,
so
that
should
be
done
before
the
end
of
the
week
should
be
soon
the
overall.
I
would
like
to
move
to
thinking
about
a
system
for
automated
debian
based
image,
updates
and
honestly
automated
everything
right.
Let
the
bots
handle
this,
so
I
have
some
ideas
rattling
around
in
my
mind.
A
I
would
like
to
turn
them
into
something
cohesive
before
going
too
crazy
with
discussion,
but
essentially
would
be
leveraging
the
same
mechanism.
That's
that
test
infra
uses
today
to
update
their
images,
so
that
would
involve
some
work
in
making
making
the
what's
called
the
auto
bumper,
as
well
as
like
the
gcb
builder,
within
test
infra.
A
Reusable
across
multiple
repos,
I
think
that
if
this
is,
I
think
that,
if
we
can
prove
out
this
pattern,
it's
something
that's
generally
useful
to
the
entire
community,
because
everyone's
doing
image
building
everyone
is
somewhat
concerned
about
keeping
their
images
up
to
date.
A
A
A
Yeah,
okay,
all
right
so
last,
one
from
me,
I
think,
on
the
rolling
side,
is
around
golang
updates.
So,
as
you
may
know,
we're
targeting
go
115
0
for
for
kubernetes
119.,
the
master
and
release
119
branches
are
already
on
were
already
on
go
rc1.
A
As
of
sunday.
I
believe
the
pr
emerged
to
update
that
to
rc2
so
go
rc2
came
out
on
thursday
or
friday.
I
believe-
and
I
rolled
some
prs
to
to
get
that
updated,
so
we're
we're
tracking
well
for
for
staying
close
to
going
upstream,
which
is
great,
I'm
excited
about
it.
It
seems
like
there's
been
low,
friction
outside
of
just
the
mechanics
of
doing
a
go
update
in
general.
A
So
I
don't
imagine,
I
think
one
of
the
big
things
that
we're
waiting
for
and
we'll
talk
more
about
that
in
the
release.
Team
section
is
that
the
release
is
essentially
gated
on
go
115
going
going
live,
so
I
think
target
dates
wise.
We
should
be
looking
at
a
go
115
release
soon,
which
means
we
will
ingest
it
soon,
and
we
should
be
clear
for
the
release
on
on
august
25th.
A
A
Okay,
laurie,
you
have
some
updates
on
process.
C
E
E
B
Okay,
so
maybe
I
should
just
go
and
he'll
figure
out
his
sound.
So
basically
what
I
did
was
I
looked
at
the
release
engineering
board
and
went
through
some
of
the
issues
that
were
in
the
in
progress
column.
There
were
a
lot
more
at
the
time.
I've
split
the
in
progress
column
to
have
this
other
column,
which
is
called
in
progress,
but
no
action
in
more
than
or
equal
to
14
days.
So
I'm
going
to
spend
some
time
at
the
release
engineering
meeting
going
through
these
issues
with
you
who
join
those
meetings.
B
B
You
know
whatever
whatever
you
would
like
to
do
like
you,
can
reach
out
and
talk
to
me
and
we'll
figure
out
a
plan
b
so
and
if
you
also
want
to
bring
back
the
work
that
you
that
you
were
doing
to
focus
on
that,
that's
also
cool,
but
I'm
just
trying
to
get
a
sense
of
like
what
are
we
actually
doing
right
now
and
are
you
getting
work
across
the
finish
line?
Are
you
facing
any
issues
along
the
way?
Do
you
need
docs?
Do
you
need
reviews
whatever
you
need?
Just
just.
B
Let
me
know
and
we'll
work
that
out,
and
we
also
took
a
look
at
so
sasha,
jorge
steven
and
tim,
and
I
look
took
a
look
at
these
items
in
closer
detail
and
spitballed,
a
prioritization
structure
for
them,
and
we
identified
some
themes,
and
so
steven
has
just
talked
about
two
of
them:
the
base
images
and
the
golden
updates.
We
also
have
some
items
around
krell
that
we
want
to
get
going
for
120
and
there
might
be
other
themes
in
this
pile
as
well.
B
One
related
topic
that
I'm
looking
at
so
I'm
actually
going
to
take
some
of
those
themes
and
some
of
the
work
and
release
engineering
board
and
draft
a
roadmap
around
this
topic,
which
is
planning
a
short
cycle
stability
release.
A
short
discussion
came
up
on
this
topic
like
end
of
last
week.
Obviously
we
have
been
working
on
stability,
especially
through
the
ci
policy
improvements
and
the
work
steven's
doing
the
work
that
many
of
you
are
also
doing
on
that
on
those
or
other
initiatives.
B
But
how
can
we
actually
keep
going
in
a
coherent
way
so
like
having
an
actual
direction
focused
because
the
end
goal
is
to
never
have
a
scheduled
stability
release
at
all,
but
actually
to
have
stability
happening
continuously?
So
how
can
we
actually
get
there
and
that
might
require
some
process?
And
it's
also
going
to
require
handling
some
of
these
technical
issues
that
are
more
tactical.
B
So
that's
basically
it
and
I'm
just
going
to
keep
working
on
this
board,
and
I
have
a
session
with
a
few
of
you
after
this,
where
we
will
go
into
the
process
of
release
engineering
and
so
that
I'm
not
running
that
meeting
in
that
process,
so
that
many
of
you
can
actually
do
that.
Instead,
so
does
anybody
have
any
questions.
B
All
right,
I'm
just
I
guess
one
one
thing
I
just
remembered
is
that
sig
testing
is
meeting
tonight
and
they
will
be
talking
about
this
work
on
ci
policy
improvements.
So
what's
been
done
and
then
what
comes
next-
and
I
know
some
of
you
are
involved
there
or
want
to
get
involved,
so
you
might
want
to
join.
A
I
so
at
some
point
my
headphones
just
dropped
out,
and
that
is
like.
I
think
I
missed
the
first
half
of
what
we
have
been
discussing
in
the
background
anyway.
So
so
thank
you
for
all
of
the
improvements
that
you've
you've
been
doing.
You've
been
doing
some
really
awesome
work
and
I
think
it's
been
been
felt
not
just
in
the
sig
but
across
the
community.
A
Alrighty,
so
next
up
we're
going
to
float
into
the
release
team
subproject
updates,
I'm
going
to
start
really
quickly,
because
this
came
up
on
the
channel.
It
has
come
up
on
the
channel
a
few
times,
so
we
should
set
the
record
straight
and
communicate
to
the
community
appropriately.
A
So
a
few
things,
timing
for
the
cycle,
nothing
has
changed.
We
are
still
as
always
a
release
when
we,
when
we
name
a
date,
it
is
a
tentative
date.
It
is
you
know
it
is
at
the
mercy
of
the
whims
of
the
various
things
that
happen
throughout
the
the
release
cycle
and-
and
this
one
has
been
a
particularly
interesting
one.
So
I
appreciate
everyone
hanging
tough
and
continuing
to
deliver
the
high
quality
that
you
usually
do
so
we're
still
on
target
for
8.25.
A
We
are
moving
into
a
kubecon
blackout
period
break.
There
is
about
a
week
in
change,
I
think
up
till
until
kubecon
eu,
and
we
want
to
make
sure
that
people
have
the
appropriate
time
to
kind
of
just
decompress
prepare
for
talks
prepare
to
attend
talks
if
they
need
an
overall
break.
That's
that's
what
this
period
is
for.
A
Following
that
period,
we
will
be
releasing
soon
afterwards,
assuming
everything
still
looks
good
with
regards
to
code
thaw,
as
laurie
mentioned,
there
are
some
ci
policy
improvements
that
have
been
happening
on
a
joint
effort
between
sig
testing
and
sig
release,
and
that's
been
going
well.
It
seems
like
it's
been
going
pretty
well,
thank
you
to
everyone.
A
Who's
been
working
on
that
it's
a
tremendous
effort
to
take
on,
and
it's
something
that
frankly
gets
overlooked
when
we're
kind
of
going
through
the
motions
of
being
excited
about
feature
enhancement
work.
So
I
do
appreciate
everyone
taking
the
time
to
slow
down
and
step
back
from
that
work
to
to
think
deeply
about
stability
overall.
So
this
goes
into
the
planning,
a
short
stability
cycle.
It's
you
know
in.
In
my
opinion,
we
should,
as
laurie
was
mentioning.
We
should
never
need
a
stability
release
right.
A
Every
release
should
be
stable,
so
if
it
means
pumping
the
brakes
for
a
few
weeks
during
a
release,
I'm
heavily
in
support
of
that
tim
as
well
and
the
general
consensus
from
testing
is.
They
would
prefer
more
stable
than
less.
They
will
so
code,
though
right
so
with
regards
to
code,
though
we
have
extended
code
thaw
to
some
indefinite.
A
Rather
we've
extended
code
freeze
and
pushed
out
code
thaw
to
some
indefinite
period.
This
was
initially
discussed.
A
This
was
initially
discussed
in
the
first
draft
of
the
updated
of
the
updated
release
schedule
and
the
initial
idea
that
I
had
was
we
just
don't
thaw.
A
Rather
we
we
don't
thaw
until
the
release
is
released
and
it
looks
like
we're
moving
towards
that
point.
I
I
think
I
would
prefer
and
talking
over
with
the
release
team.
I
think
I
would
prefer
making
the
decision
to
just
not
fall
until
the
end
of
the
cycle
as
opposed
to
continuing
with
some
vague
will.
They
won't
they
uncertainties
around
when
code
thought
is
going
to
happen.
So,
let's
release
team
leads.
A
Let's
discuss
today
make
a
final
decision
on
that
and
I
will
be
preparing
a
note
to
the
community
as
well
any
concerns
about
extending
kothal
until
the
end
of
the
cycle.
H
I
think
we'll
probably
touch
more
on
this
during
the
retro
but
I'll
say
for
the
rest
of
the
sort
of
development
community.
That's
not
on
not
attending
the
regular
release.
Team
meetings.
What's
going
on
with
codethon
code
freeze
has
been
kind
of
a
mystery.
H
I
I
think,
on
that
front,
I'd
absolutely
hear
you
in
terms
of
gaining
like,
like
like,
like
we
had
talked
about
just
you
know,
getting
more
information
out
on
that
front.
When
we
went
to
delay
code
thaw,
we
we
sent
something
out
to
k-dev
as
well.
Just
saying
hey,
this
is
indefinitely
blocked.
Nothing
has
changed
within
those
three
weeks
too,
but
you
know,
like
you
said
it,
you
know.
More
clarity
is
always
better.
I
More
messaging
is
always
better,
and
so
we
should
have
something
out
today
on
that
front,
so
the
community's
aware
of
what's
going
on
and
then
again
I
think,
weekly
updates
are
just
kind
of
like
you
know.
Here's
here's!
What
happened
this
week
with
sig
release
makes
a
lot
of
sense
or
that
the
release
team
sub
project,
I'm
sorry.
B
B
A
That's
yeah.
I
think
that
the
the
meeting
updates
are
close
to
what
we
might
want
to
send
out
a
stripped
stripped
down
version
of
that.
That
is,
I
think
that
was
the
initial
intention
of
of
that
update.
Actually
so
we'll
we'll
get
back
to
doing
that,
but
yeah
they're
outside
of
the
indefinite
phrase
and
the
additional
rcs
that
we've
been
adding
to
to
allow
people
to
test
rcs.
We
have
not
been
shifting
around
the
schedule
or
anything
like
that,
but
totally
totally
right
in
saying
that
there
should
be
more
clarity.
B
B
A
B
D
A
Just
the
you
know,
the
the
release
team
lead
does
occasionally
send
out
notes
to
kdev
to
inform
them
of
upcoming
dates,
and
we
usually
do
that
around
the
as
we're
coming
up
on
those
milestones.
F
H
B
I
think
it's
interesting
to
see
what
what
formats
communication
formats
we
we
feel
like
we
have
the
highest
readership
around
like
is
it
email?
Is
it
slack?
I.
I
There's
a
little
bit
of
discussion
too.
I
can't
remember
which
meeting
it
was
at.
It
might
have
been
a
release,
leads
and
and
technical
lead
meeting,
but
they
had
talked
about
some.
Some
sigs
are
using
github
capturing
meeting
notes
in
there
and
then
you
have
that
search
ability.
So
maybe
that's
another
potential
option
to
keep
moving
in
there.
A
Yeah
so
I'd
mentioned
to
tim
that
we
I
I
think
I
would
be
happy
to
guinea
pig,
doing
hack,
md
notes
for
sig
release
instead
and
then
moving
those
into
you
know
moving
those
into
github
on
a
weekly
basis
right,
so
that
search
ability
is
pretty
awesome
and
then
dims
with
the
the
hound
code
search
tool.
That
makes
it
really
easy
to
to
jump
in
and
see
what
you
need
to
for
the
release,
but
yeah,
I'm,
I
don't
know
who
just
mentioned
it
around
leadership.
A
Well,
that's
a
really
good
point.
These
notes
should
probably
also
go
out
to
the
sig
leads
list.
The
expectation
is
that
if
you
are
a
lead
for
sig
sub
project,.
H
A
A
H
Yeah
yeah,
I
just
you
know
I
I
wanted.
I
wanted
to
ask,
and
I
wanted
to
get
that
in
our
notes,
because
I
don't
have
any
insight
into
those
release
processes
so.
J
I
think
they
also
have
a
an
issue
on
the
go
repo
that
is,
that
is
kind
of
an
umbrella
issue
where
they
explicitly
list
all
the
things
are
blocking
the
release
and
they
have
so
much
automation
that
that
thing
is
actually
like
update
right
down
to
the
second
one
that
things
are.
They
are
waiting
for
the
next
release
to
comment,
but
don't
quote
me
on.
A
That,
please
yeah,
so
they
have
a
release.
They
have.
They
have
a
release,
milestone
and
set
of
issues
to
aggregate
so
across,
like
release
notes
remaining
blocking
issues,
things
like
that,
they
don't
directly
dictate
timing.
A
A
I
Hey
hello,
everyone
so
very
excited
to
be
here
with
you
this
morning,
even
more
excited
to
announce
that
we
have
a
120
release
lead
and
that
person
is
on
the
call,
and
that
is.
E
I
Actually
hold
for
two
seconds:
I'm
going
to
tweet
that
out.
That's
that's
out
in
the
interwebs,
so
congratulations,
jeremy.
I
know
you're
gonna
make
a
fantastic
lead
and
yeah
you're.
We
love
you
you're
awesome!
Thank
you.
I
Should
be
fun,
it
should
be
the
fun
last
release
here
of
2020..
Speaking
of
119,
we
have
seven
open
prs.
Only
one
is
critical,
urgent
and
looks
like
that's
getting
worked
on
now.
We
have
15
open
issues
for
119.
Still
six
of
those
are
critical,
urgent
and
then
some
need
assignments
in
terms
of
that
that
level.
I
So
I
know
the
team's
looking
at
that
we
went
into
so
we
are
on
a
break
for
kubecon
cloud
native
con
the
week
leading
up
to,
and
then
week
of
so
I
hope
that
everyone's
able
to
get
some
rest
and
relaxation
time
in
this
period,
but
again
we're
going
to
be
kicking
those
meetings
back
off
on
monday
august
24th
the
day
before
our
targeted
release,
which
is
august
25th.
I
So
as
of
right
now
I
do
we
mostly
look
good
I'd,
say
confidence
is
high,
like
in
the
90
percent
or
higher
in
terms
of
going
live.
As
of
right.
Now
I
haven't
you
know.
I
I've
been
on
previous
releases
where
we've
gotten
something
a
day
or
two
before
and
that's
impacted
the
release
date.
So
anything
can
happen,
but
as
of
right
now
we're
looking
pretty
good
and
then
there
have
been
a
lot
of
items
put
into
the
retro
already,
but
as
always,
encourage
everyone
to
check
that
out.
I
Please
drop
in
anything
that
you
think
is
relevant
into
that
release
retro,
so
we
can
get
better.
This
release
again
has
been
absolutely
quite
different
from
most
releases,
especially
around
timing,
especially
around
communication,
especially
around
process
improvements
and
subgroups,
and
efforts
that
are
getting
kicked
off,
so
all
of
which
are
making
the
project
are
going
to
make
the
project
a
lot
better.
But
you
know
with
with
more
people
and
projects
and
focuses,
comes
more
communication
and
and
that's
always
hard
to
get
right,
the
first
time
out
so
more
than
welcome
your
feedback.
I
Somebody
once
told
me:
it's
always
dns
and
it
absolutely
has
its
communication.
Problems
are
mostly
the
cause
of
most
things.
So
thank
you
for
the
feedback
thus
far,
and
if
you
have
anything
to
put
in
the
retro
would
be
must
appreciate
it.
Any
questions
on
119
kubecon
break
anything
of
that
sort.
I
will
be
scheduling
those
meetings
for
the
24th
and
the
25th.
A
Hello
again
so
ci
signal
new,
pending
subproject
we're
targeting
formation
for
this
this
week.
That
issue
has
been
open
for
quite
some
time.
I
think
that
the
I
think
that
the
discussion
between
ourselves
and
sig
testing
has
been
essentially
solved
in
terms
of
scope,
so
we
just
need
to
coalesce
all
of
the
thoughts
into
a
nice
little
mission
statement.
A
Essentially
what
that
is
the
the
one
sentence
is
do
exactly
what
the
ci
signal
team
on
the
release
team
does
today,
but
for
all
of
the
release
branches
right.
I
think
that
that
is
the
first
start
and
I
think
for
people
who
have
spent
some
time
in
sig
release
in
and
around
the
release
team
you'll
see
that
a
lot
of
our
sub
teams
for
the
release
team
are
extensions
of
other
groups
right
across
the
project.
A
Right,
so
enhancements
has
a
has
a
correlation
same
with
ci
signal
and
formerly
test
infra
release
engineering
stuff
comms.
What
have
you
so
ci
signal
very
clearly
has
a
close
relationship
with
with
sig
testing,
and
it's
been
really
nice
to
see
the
collaboration
around
the
ci
improvement
and
stability
tasks
over
the
last
few
weeks.
A
Move
forward,
so
everybody
keep
it
up,
give
it
up
keep
pushing.
We
will
have
an
official
place
for
that
stuff
soon,
at
least
from
the
the
release
perspective,
so
we're
again
focusing
on
release
blocking
release
and
forming
items.
This
sub
project
would
also
be
responsible
for
defining
what
release
blocking
and
informing
looks
like,
given
that
we
have
two
wonderful
new
technical
leads.
Our
recently
appointed
technical
leads
sasha
and
jorge.
A
I
wanted
to
make
sure
we
align
them
with
the
the
focuses
that
they've
they've
had
over
the
multiple
multiple
cycles.
At
this
point,
so
sasha
has
been
focusing
deeply
on
the
release.
Engineering
side,
improvements
around
krell
and
destroying
a
nago,
and
all
that
good,
stuff
and
and
jorge
has
has
been
a
release.
A
Team
lead
has
done
lots
of
lots
of
work
on
sea
ice
signal
in
general
across
multiple
cycles,
so
so
jorge
is
going
to
be
taking
point
on
formation
of
the
ci
signal,
sub
project
and
execution
day
to
day,
along
with
surprise
dan,
I'm
going
to
be
appointing
you
as
a
sub
project
owner
as
well.
You
have
been
doing
some
phenomenal
work
both
on
the
release,
engineering
side
and
the
ci
signal.
Subproject
side
are
the
soon
to
be
a
ci
signal,
subreddit
project
side.
A
Too
cool
so
now,
dan
and
jorge,
will
give
you
some
updates
on
what
we've
been
doing
around
ci
improvements.
D
All
right,
I
don't
know
if,
if
you
want
to
start,
but
I
can
give
a
a
general
update,
go.
J
D
You're
more
up
to
date
on
the
on
all
the
things
cool
all
right.
So,
as
we've
mentioned
a
few
times
at
this
meeting,
meeting,
adding
the
the
limits
and
resource
requests
has
increased
the
amount
of
flakes
and
stuff
we've
seen,
but
that's
slowly,
starting
to
turn
into
less
flakes,
because
we
know
how
things
are
scheduled
now.
D
So
when
we
see
issues,
we
know
how
to
address
them
rather
than
it
looks
like
there's
resource
contention
here
so
specifically,
which
this
is
somewhat
has
been
in
the
past
outside
the
scope
of
of
ci
signal
work
on
the
pre-submits,
especially
is
where
we've
seen
some
improvement.
For
instance,
on
the
verify
pre-submit
we
we
saw
some
out-of-memory
errors
which
we're
starting
to
see
those
more
frequently
because
we
obviously
have
limits
now
on
memory.
D
But
those
are
good
things
because
we
can
now
address
that
and
look
at
why
that's
happening
and
correct
those
specific
jobs
rather
than
just
you
know,
scaling
the
cluster
or
something
like
that.
So
overall,
I
think
that,
on
all
of
the
release
blocking
jobs,
we
now
have
limits
and
requests
set.
So
that
is
very
good
and
then,
in
regards
to
1.19
stuff,
we've
mostly
just
been
cleaning
up
some
flakes
and
actually
the
cigs
have
been
super
responsive
on
that.
D
So
I
think
that's
somewhat
of
a
testament
to
keeping
code
freeze
around
for
longer,
because
if
folks
want
to
move
forward,
they
they
need
to
fix
things.
So
I
think
that's
in
support
of
kind
of
the
strategy
we've
taken
here
so
overall
making
a
lot
of
changes
that
are
going
to
not
only
make
improvements
right
now,
but
less
into
the
future,
so
exciting
to
see.
B
B
D
Was
mentioning
so
I
don't
think
we
have
limits
in
place
on
all
of
those,
yet
I
need
to
check
in
at
the
checklist
again,
but
we,
as
I
mentioned
there,
are
some
that
have
been
introduced
on
a
number
of
those,
but
obviously
the
the
ramifications
of
that
are
a
little
bit
bigger
because
you
know
if
something's
consistently
failing
and
we
can't
merge
anything,
that's
a
bigger
problem
than
a
periodic
job.
D
Failing
so
continue
to
push
forward
on
that,
as
I
mentioned,
I
think
there's
actually
a
comment
on
the
ci
signal
sub
project
issue.
Typically,
the
pre-submits
have
been
out
of
scope
for
for
ci
signal.
However,
this
has
kind
of
been,
as
mentioned
already
more,
of
a
joint
effort,
so,
as
we've
been
adding
to
the
periodic
jobs
we've
kind
of
jumped
in
there
as
well
so
working
alongside
sig
testing
has
probably
been
a
a
good
experience
in
regards
to
how
the
sub-party
is
going
to
need
to
collaborate
between
the
two
sigs
in
the
future.
A
Hey
josh,
so
one
thank
you
dan
for
the
update
josh.
Are
you
sure
you
want
to
defer
or.
H
Okay,
well,
this
is
this
is
just
real
quick,
which
is.
I
don't
know
that
anybody's
communicated
this
back
to
sig
release,
but
we
had
a
discussion
in
the
lts
working
group
and
one
of
the
things
that
we
decided
is
not
going
to
be
up
to
wglts
because
it
wasn't
part
of
original
mandate
is
deciding
what
the
length
of
patch
support
is
for
117
and
118.
H
the
given
the
119
release
schedule.
That
might
be
a
moot
point,
but
I
just
wanted
to
put
an
item
here
to
basically
officially
punt
that
back
to
sig
release
to
say
you
know:
hey,
it's
really
up
to
sig
release
to
decide
how
long
patches
for
117
and
118
are
going
to
be
released.
The
official
change
in
policy
takes
effect
for
119.
A
H
The
movement
was
retroactive,
support
is
not
part
of
the
lts
cap
so
and
that's
117
and
118
are
the
retroactive
support
right.
So.
H
H
A
Cool
cool,
so
I
think
what
would
be
great
is
kind
of
a
debrief
before
we
move
into
disbandment.
If
y'all
could
schedule
some
time
to
come
to
one
of
the
sig
release
meetings-
and
maybe
I
don't
know,
work
with
lori
if
to
to
figure
out
a
good
time
and
what
we
should
and
shouldn't
talk
about,
maybe
run
through
the
cap
one
final
time
and
and
see
what
we
did
and
didn't
do.
G
A
Lori,
I'm
going
to
kick
it
over
to
you.
We
can
either
choose
to
walk
through
the
board
or
we
can
run
through
some
kubernetes
kubernetes
issues.
B
B
B
A
So
the
closest
one
that
I'm
familiar
with
is
the
automated
debian
base
images
that
is
actively
being
being
worked.
I
think
the
initial
request
is
done
from
the
perspective
of
we've
moved
the.
As
of
last
week,
we've
moved
all
of
the
debian
base
image,
building
into
kubernetes
release
it
triggers
on
a
human
changing
the
tag
the
post
submits
happen
as
a
result
of
well,
the
postmates
trigger
a
a
build,
and
so
I
think
we're
a
lot
farther
than
we
were
before.
B
B
Yeah,
I
think
so
too,
but
it'd
be
good
to
check,
yeah
and
then
yeah,
so
anything
else
from
a
year
or
more
ago.
I
would
say
we
should
do
something
about
that.
Yeah.
Just
generally.
A
Yeah
I'm
seeing
some
stuff
that
might
be
complete
switching
gold
scripts
to
using
go
modules.
That's
probably
done.
I
don't
know
if
dims
is
still
here.
Maybe
you
know
dimms.
He
was
yeah.
A
The
switching
build
scripts
to
use,
go
modules
and
stop
requiring
gopath.
That
might
already
be
done
right.
B
G
A
A
A
A
So
sig
cli
is
looking
at
that.
Essentially,
there
are
a
bunch
of
interesting
things
with
the
way
that
the
virgin
version
markers
are
being
utilized,
and
these
are
essentially
tests
that,
I
believe,
should
not
be
man-made.
They
should
be
generated
because
of
the
way
the
because
of
the
way
that
you
need
to
do
the
marker
extraction
right,
it's
prone
to
error,
which
is
why
some
of
these
tests
are
failing
and
daniel
is
probably
going
to
say
something
similar.
D
Yeah,
yeah
and
and
the
version
markers
are
now
being
published
correctly.
However,
the
the
periodic
build
jobs,
they
don't
publish
version
markers
if
the
build
already
exists.
So
if
you
look
at
like
the
the
duration
minutes,
for
instance-
and
I
just
added
a
comment
to
this
effect
on
this
issue
today-
the
you
know
typically
the
it
just
checks
and
says:
oh,
this
builder
exists
exit.
You
know
it's
very
short
job,
but
if
the
build
doesn't
exist,
then
it
will
build
it
and
push
it
and
push
the
extra
version
markers.
D
So
unless
the
build
doesn't
exist,
then
those
version
markers
are
not
getting
updated,
so
the
other
jobs
that
instead
are
building
those
versions.
I
don't
know
if
we
want
those
to
also
be
updating
the
version
markers.
I
would
think
yes
can.
B
B
So
so
yeah
that
looks
like
a
sidebar
conversation
and
we
can
get
some
resolution
tims.
A
We
need
to,
I
think
we
need
to
update
the
title
on
this
one.
It
sounds
like
that.
We're
going
to
continue
with
the
s390x
support
that
people
are
actively
working
on
it.
G
This
is
the
stick.
I
need
the
stick,
so
leave
it
open,
please
and
then
so
it's
pending
one
more
whip
dock
that
we
are
adding
in
cigars.
G
So
there's
at
least
two
distinguished
engineers
from
ibm
showed
up
here.
So
I
would
like
to
wait.
Wait.
B
G
Once
the
cigar
guidance
passes,
and
we
determine
that-
you
know
this
s390x
folks
haven't
done
much
for
a
period
of
time.
What
we
would
then
do
is
stop
releasing
the
s390x
artifacts
by
default,
which
we
are
doing
right
now.
So,
okay,
it
release
has
to
stop
doing
that.
Okay,.
B
Right,
I
also
have
two
ears,
but
they
seem
to
be
broken:
okay,
moving
on
to
go
115
0.
This
item.
A
B
A
After
ben's
update,
we
updated
kubernetes
kubernetes
as
well,
so
that
one's
already
assigned
to
legit
and
myself,
so
we
should
be
good
there.
Okay,.
B
This
action
items
umbrella
issue,
so
I'm
actually
thinking
the
format
of
this
is
eh
like.
I
don't
think
this.
I
could
see
this
getting
bloated
and
also
not
being
looked
at,
so
I
think
we
should
abandon
this
experiment,
but
there
are
some
items
here
that
we
should
take
a
look
at.
I
would
make
separate
issues
going
forward.
A
So
so
I
would
say
this.
I
think
part
of
the
reason
for
the
attention
is
that
we
tend
to
spend
more
time.
As
for
non-issue
bug,
triage
ci
signal
people,
we
spend
tend
to
spend
a
little
bit
more
time
in
our
repos,
as
opposed
to
kubernetes
kubernetes
directly.
I
would
say
if
this
issue
was
in
kubernetes,
it
was
in
sig
release,
as
opposed
to
as
opposed
to
kk
would
get
more
attention,
so
I'm
just
going
to
move
it.
There.
B
A
So
maybe
what
we
can
do
is
both
approaches
right.
The
an
umbrella
item
would
get
assigned
to
you
instead
and
you
can
and
you
can
work
on
chasing
people
down
for
the
individual
items.
B
Okay,
but
basically
we
have
here-
this
was
one
thing
that
I'm
not
sure
we
should
follow
now
to
formalize
in
policy
and
force
going
forward.
We
were
going
to
collect
contact
information.
It
was
carlos
stan,
adolfo
and
jorge.
A
B
Is
that
a
dolphin?
It
was
a
dolphin.
B
So
we
can
just
reduce
the
number
of
owners,
then
to
carlos
I'll
edit
it
on
my
other
browser,
which
has
my
github
open
after
the
meeting.
B
Okay
and
then
these
things
we've
actually
talked
about
fostering
the
bond
with
scalability
and
then
there's
the
content
related
to
go
upgrades,
which
is
a
documentation
job.
How
are
you
doing
with
that?.
A
It
changes
every
time
I
do
it.
Okay,
so
once
once
we've
landed
the
go.
115
update,
I'm
going
to
come
back
to
the
documentation,
but.
A
I
think
it's
it's
a
novel
experiment.
Every
time
we
do
it.
B
Right
and
there's
changes
so
it's
harder
to
yeah
and
then
what
about
veronica's
basil
notes?
That's
related,
but
you
know
different.
L
And
non-hardware
sorry
yeah.
Well,
I
I
wanted
to
discuss
that
with
you
in
our
next
meeting,
like
for
a
plan
yeah.
Okay.
Currently
my
plan
is
working
on
it
and
I'm
currently
working
on
it,
but
like
obviously,
I
need
to
set
it
more
like
in
a
concrete.
L
B
Okay,
so
then,
moving
on
to
the
pre-submit
tests
for
windows.
A
B
Yes,
yeah
for
sure
cool
can
we
set
like
maybe
half
the
meeting.
A
Yes,
assuming
assuming
we
have
the
assuming,
we
have
less
updates
from
the
various
sub-projects,
because
I
think
the
boards
can
very
easily
get.
The
hope
is
that
we
can
do
more
of
the
triage
during
the
sub
project
level
stuff
and
those
updates
can
filter
up
to
the
sig
release
meeting
instead,.
F
A
I
will
say
for
the
one
that
is
next
on
the
list:
that's
related
to
cve
and
that
has
already
been
addressed.
I
just
need
to
shoot
some
pr's
out
for
it.