►
From YouTube: Kubernetes SIG Release - 2019-04-23
Description
A
B
B
A
So
it's
four
past:
let's
go
ahead
and
get
the
get
the
party
started.
This
is
sig
released
by
weekly
meeting
for
April
23rd
2019.
This
is
a
recorded
community
meeting.
We
will
publish
the
video
to
YouTube
for
the
historical
record
for
all
to
see.
Please
abide
by
the
community
code
of
conduct.
We
have
our
standing
agenda
document.
I'll
drop
it
in
the
zoom
link
for
reference.
There's
a
couple
things
on
there.
So
first
I
do
want
to
double
check.
Claire
did
we
cover
everything
from
the
what
retrospective
for
114
that
needed
covered?
I?
C
A
Feel
like
there
weren't
there
were
either
there
were
a
few
specific
things.
It
definitely
translated
into
issues
and
there
were
some
some
things
that
people
did
in
terms
of
small
changes
to
role
handbooks
and
Docs
and
things
that
did
feed
into
the
the
plan
is
in
terms
of
the
schedule
so
I
know
we
took
some
specific
things
away
that
we're
aiming
to
do
but
yeah
there
weren't
there
were
dramatic
changes
being
proposed.
So.
A
B
Yeah,
so
what
we'll
do
is
we'll
take
a
I'll
take
a
read
through
this
document
again
I
just
make
sure
that
we
actually
have
all
that
stuff
captured
as
action
items
within
the
cig
release
repo,
but
I
think
that
we
I
think
that
the
release
team,
the
114,
released
him,
at
least
as
a
team,
made
sure
that
a
lot
of
that
stuff
was
documented
already.
So
this
will
just
be
a
gut
check.
A
C
Yes,
at
least
part
of
carry
over
from
psych
p.m.
yeah
we'd
been
talking
in
cig
p.m.
earlier
about
some
of
the
out
of
tree
questions
that
were
raised
a
couple
of
released
he
meetings
ago,
I
had
a
specific
question
around
tracking
ecosystem
projects
that
have
some
type
of
dependency
with
the
release
cycle.
So
there's
an
item
in
the
release
lead
handbook
around
making
sure
to
sync
up
with
those
different
projects.
Project
leads.
C
It
specifically
calls
out
cuvee
diem,
but
it
mentions
that
there
might
be
others
and
I
reached
out
to
Aaron
who
didn't
have
any
full
list
of
who
all
those
other
ecosystem
projects
were
so
yeah
I
raised
it
in
sig
p.m.
and
it
sounds
like
it
is
something
that
is
more
of
a
release:
team
release,
team
related
coordination
that
might
indeed
fall
on
the
release
lead
to
coordinate
with
these
different
groups,
but
yeah
raising
it
here
for
further
discussion.
C
B
Good
yeah,
so
what
I
mentioned
for
sick
gam
was
that
if
we
are
going
to
essentially
task
the
release
lead
or
the
release
team
with
something
to
track
kind
of
like
ecosystem
dependencies,
then
we
should
be
be
sure
to
enumerate
them.
If
we
feel
like
we
can't
enumerate
them,
then
we
don't
need
to
track
them
or
we
shouldn't
track
them.
Cube.
B
Anything
else
I
mean
I
can
see,
potentially
the
the
entry
cloud
providers
currently
as
another
as
another
target,
but
I
think
that
sig
cloud
provider
over
I
think
sig
cluster
lifecycle
and
sig
cloud
provider
are
exemplars
of
of
how
to
of
how
to
one
make
sure
your
things
are
in
on
time
and
have
a
and
have
a
decent
feedback
loop
with
sig
release.
So
I
don't
think
that
there
are
problems
if
there
are,
if
there
are
other
ones
that
we
need
to
be
concerned
about,
like
when
we
say
ecosystem
like
what
like.
B
A
The
the
one
specific
thing
with
cubed
iam
at
the
point
that
they
commit
code
that
prefers
the
new
release
or
in
and
I,
don't
know,
Lumiere
I
guess
you
could
tell
us
if
this
is
still
the
case.
Do
you
commit
code
that
prefers
the
new
rpms,
but
fate
then
fest
tests
start
failing
until
the
new
rpms
are
actually
built
in
published,
or
is
that
was
that
something
that's
been
changed
now?
Oh.
A
Under
the
impression
that,
like
for
upgrade
tests,
your
pre-release
qadian
would
be
trying
to
upgrade
to
whatever
pre-release
code
was
somewhere
and
at
the
point
that
the
release
was
actually
going
to
be
cut.
Since
it
includes
cube
a
DM,
cube,
ADM
needed
to
be
told
to
prefer
say
in
this
case,
1.15
dot
o.
But
since
that
doesn't
exist.
Yet
the
test
that
we're
using
that
code
path
would
fail.
But
I
don't
have
a
clear
recollection
of
what
this
is
and
I
thought
that
it
had
maybe
changed
to
be
more
dynamic.
A
D
D
A
A
A
B
C
Think
in
terms
of
115
I'm,
personally,
more
inclined
to
figure
it
out
sooner
rather
than
later,
so,
there's
no
surprises,
given
any
slipping
in
our
release.
Date
lead
leaks
into
coupon
Shanghai,
so
I
don't
mind
in
terms
of
115,
doing
some
investigation
and
then
documenting.
Those
notes
in
my
role,
handbook
for
whoever
my
successor
is
so
I
might
need
some
help
in
getting
pointed
in
the
right
direction
of
who
to
start
investigating.
A
B
A
I
know
this
is
a
easy
way
to
kind
of
start
a
bike
shed
on
it,
but
I've
felt
for
a
while
that
this
is
deserving
of
a
cap.
Somebody
to
articulate
the
problem
space
and
lay
out
one
or
more
potential
proposal
solutions
on
how
we
could
collect
the
core
dependency
set
in
a
centralized
machine,
readable
way.
Yeah.
D
Made
this
proposal
like
last
cycle
but
I'm,
sorry
I,
really
don't
have
the
time
to
create
such
a
proposal
right
now,
too
busy
with
other
stuff.
But
if
somebody
has
the
time
please
go
ahead,
the
idea
was
to
create
machine,
readable
objects
that
authorize
the
dependencies
of
the
current
kubernetes
release,
and
this
should
map
to
a
branch.
D
D
This
is
the
made
this
image
for
maybe
that's
the
latest
dependency
that
we
have,
and
there
was
another
proposal,
but
by
Mike
from
say,
release
called
the
release
tow
to
basically
use
some
sort
of
a
label
and
a
another
release
mode
type
of
field
in
the
PR,
where
people
can
basically
say
that
hey
I'm
bummed
in
a
dependency
but
like
all
the
solutions,
have
problems
one
way
or
the
other.
Oh
yeah,
probably
a
Kip
is
needed
and
to
propose
all
the
available
options
and
like
see
what
people
think
about
it.
A
That's
that's
fine,
I
think
by
normal.
This
was
it
I
definitely
found
it
in
the
1:14
retrospective
and
we
did
not
open
an
issue
on
it
and
I'm.
Recalling
now
is
sort
of
chatting
back
and
forth
and
thinking
that
we
would
start
drafting
a
cap,
but
it
did
fall
by
the
wayside.
So,
let's,
let's
at
least
log
an
issue,
please
Stephen.
What
do
you
think
about
logging
this
and
assigning
it
to
us
versus
the
release
team
like
I
I
would
rather
enable
the
release
team
versus
saddling
them
with
establishing
this
a
thing.
B
That
doesn't
have
a
clear
boundary
or
anything
yeah.
That's
fine
yeah
so
additionally,
like
with
regards
to
the
the
tracking
not
just
dependencies
but
also
enhancements
I,
know
I,
know
Luba
Murai
put
something
out
recent,
not
recently
at
this
point,
maybe
a
month
and
a
half
two
months
ago,
an
issue
that
kind
of
detailed,
like
enhancement
tracking,
which
was
various
and
I,
had
mentioned
that
it
was
like
very
similar
to
something
that
we
had
planned
essentially
to
drain
the
queue
of
enhancements
of
like
currently
opened
enhancements
issues.
B
So
the
idea
there-
and
there
were
some
tooling
that
Caleb
wrote-
that
is
in
flux
right
now,
so
I
don't
know
how
we
bring
it
back
into
the
picture
just
yet,
but
hopefully
soon
will
have
an
answer
on
that.
Essentially,
the
idea
being
we
drained
the
queue
of
enhancements
issues
right
and
for
each
release.
The
same
way,
we
create
a
release
directory
right
within
sig
release,
sig
release
releases,
114,
release
115,
so
on
and
so
forth.
We
do
the
same
for
the
enhancements.
Repo
right
and
the
enhancement.
B
Issues
instead
become
receipts,
write
receipts
that
are
some
machine,
readable,
probably
ammo.
Right.
That
essentially
say
like
this
is
the
links
of
the
capital
Docs,
the
this
is
like
the
statement
of
intent
right,
the
the
stage
that
the
thing
is
moving
into
right
and
those
go
into
a
enhancements
releases,
the
you
know,
release
115,
116
right
and
go
into
a
proposed
folder
right
and
then
from
the
pro
this
folder.
Some
automation
takes
over
like
the
people
who
are
allowed
to
merge
it,
which
would
be
like
the
enhancements
leave.
B
The
release
team
lead
the
the
cig
release
in
cig
PM
people,
the
people
who
have
the
the
ability
to
merge
that
merge
in
to
propose
write.
Some
automation
takes
over
and
carries
proposed
into
accepted
right
because
it's
been
approved
by
the
relevant
people
that
would
would
need
to
approve
it
and
then
from
there
you
have
this
readout
of
you
know.
Then
we
can
consume.
B
That
presume
that
any
way
we
want
pretty-pretty
contributor
site
or
something
like
that
right,
then
you
have
this
readout
of
the
things
that
are
promised
for
this
really
promised
rate
for
this
release,
as
opposed
to
tracking
on
a
spreadsheet
right.
You've
already
had
that
statement
of
intent
within
the
repo
right
and
it's
committed
to
memory.
It's
committed
to
get
history
and
then
the
the
same
would
happen
for
the
the
exceptions
process
right.
B
B
This
release
engineering
sub
project-
and
you
know,
and
the
the
you
know
over
the
last
few
months,
the
the
Cates
infra
team
has
spun
up
to
so
like
that
will
come
up
later
because
we're
going
to
be
talking
about
packaging
and
all
this
good
stuff,
but
I
think
that
we're
getting
to
the
point
where,
like
we've,
we've
taken
the
concepts-
and
we
understand
like
where
we
need
to
carry
these
things
forward,
and
we
have
some
of
the
people
that
we
know
can
execute
on
this
stuff.
So
now
we
we
just
have
to
do
it
right.
D
D
B
So
I'm
thinking
that
I
haven't
been
able
to
find
it,
so
we
must
have
chatted
about
it
and
in
public
there
were
some
legalities
to
the
tool,
which
is
why
it
was
probably
discussed
in
private.
But
it's
also
why
I
held
up
on
responding
to
that
to
your
issue,
because
I
didn't
have
a
good
answer
just
yet
so
I'll
double
back
on
that
stuff!
Apologies
for
that
not
being
in
public.
D
I
was
interested
like
because
I
don't
understand,
understand
the
whole
picture
with
the
implementation
details
like,
for
instance,
if
I,
if
I
have
a
receipt,
or
rather,
if
I
have
a
feature
that
is
marked
as
alpha
or
marked
as
beta.
But
there
is
a
mistake:
I
have
to
remove
the
beta
state
to
and
change
it
to
alpha
a
should
I
file,
a
PR
against
the
repo,
the
enhancement
repo
I
mean
how.
B
B
B
So
there's
actually
a
let
me
see
if
I
can
find
it
on
the
fly.
Do
ya
so
Jason
I
presented
at
Q
Khan
last
year.
D
B
How
how
frequently
are
they
making
changes
as
the
receipt
is
requesting?
I
want
to
link
to
your
cap.
I
want
to
link
to
to
know
where
your
docks
are.
I
want
to
know
what
the
state
of
it's
going
to
be
by
the
end
of
this
release
like,
if
that's
only
happening
through
the
enhancement
cycle
right,
which
is
essentially
when
we're
collecting
enhancements
anyway
right,
and
that
goes
down
right.
So.
D
B
So
we're
the
list
of
PR
should
actually
be
is
in
the
implementation
history
of
your
cap.
That's
exactly
what
that
that
place
is
for
I
kept.
The
cap
isn't
meant
to
be
the
steel
thread
that
ties
all
these
things
together.
Right
I
should
be
able
to
look
at
the
cap
and
have
the
grand
vision
of
what
that
enhancements
doing
and
what
the
state
of
it
is
I
see.
So
so
the
PRS
should
be
listed
in
the
cap
yep
in
the
implementation
history.
A
B
B
B
A
On
this,
oh
yeah,
but
I
think
now
would
be
a
time
to
say
like
okay,
so
like
like
Kluber
merced,
so
I
get
asked.
Where
are
my
PR
is
and
Oh
like
implicit?
In
that
conversation,
I
heard,
oh
I
was
supposed
to
put
that
in
the
kept
I
didn't
I
wasn't
supposed
to
just
make
the
BR
I
was
supposed
to
also
make
a
PR
against
the
kept
so
like.
How
could
we
at
that
point
once
we've
got
the
process
rolling?
How
do
we
nudge
the
people
yeah
towards
that
last
sit.
B
So
I
think
that
we
can
to
a
good
suggestion
that
Lockheed
made
I
think
a
few
weeks
ago
at
a
sig
cam
meeting
was
that
a1
cheater
would
be
useful
right,
so
we
can
expand
on
the
FAQ.
I
was
like
how
to
submit
a
cap
in
general
right
I
think
that
some
of
that
stuff
is
out
of
date
and
if
it
said
like
hey
here,
all
the
things
like.
Are
you
running
into
a
release
cycle
here?
All
the
things
you
need
to
know
are
your
blah
in
this
place.
Are
your
things
in
blah?
B
D
B
If
you
have
committed
to
like,
if
everyone
has
committed
to
making
sure
that
stuff
is
part
of
their
cap
in
implementation
history,
then
we
can
come
to
the
cap
whenever
we
want.
So
the
the
the
the
review
and
approval
cycle
of
that
is
is
entirely
disconnected
from
the
release.
Name
right.
If
we're
saying
we
so
like.
Basically,
I
want
to
derive
the
value
of
having
the
release
team
track.
All
of
those
PRS
right.
D
B
So
I
mean
so
I
think
the
let's
ask
this
question:
if
I
wanted
to
get
details
about
what
an
enhancement
was
doing,
how
much
of
the
picture
would
I
want
to
see?
Would
I
want
to
see
the
full
picture?
If
that's
the
case,
then
yes,
you
should
be.
You
should
be
keeping
it
in
your
implementation.
History,
if
you
want
to
craft
the
picture
that
you
want
people
to
see
again,
knowing
that
this
is
going
to
be
the
steel
thread
for
that
enhancement.
How
what
do
you
want
that
picture?
To
look
like
that's
the
question?
D
I'm,
basically,
okay,
with
whatever
solution
we
have
like
something
that
is
probably
better
than
what
we
have
at
the
moment.
Only
my
oh
so
maintainers
can
updated
issue
@k
enhancements
people
get
out
of
touch,
nobody
updates
them.
Basically,
there's
discussions
like
what
is
the
state
with
the
release
team
yeah?
The
process
can
be
improved.
Do.
B
Not
yet
not
yet,
but
coming
soon,
I
think
that
you
know
so
we,
for
those
of
you
who
are
aware
we
have
just
changed,
are
partially
changed
our
sig
PM
leadership.
So
it's
myself,
myself,
chase,
Kaleb
and
you're
now
so
now
that
we
have
a
full
team
of
people
who
have
been
doing
the
work
more
frequently
and
we're
we're
kind
of
getting
unburdened
by
a
few
things
that
we
can,
we
can
start
driving
a
road
map,
but
to
bull.
It
will
take
a
little
bit.
B
B
G
So
this
the
idea
of
how
this
kind
of
topic
got
started
was
doing
the
115
enhancement
collection
going
through
the
process.
There
were
I
believe
when
I
started,
there
were
130
open
issues
going
through
figuring
out
which
people
or
which
issues
were
being
on
milestones
was
great
started
to
track
them,
and
it
right
now
we're
sitting
around
I.
Think
like
36
37
tracked
issues,
that's
out
of
130.
Keep
that
in
mind.
So
you've
got
this.
G
There's
other
hundred
issues
that
I've
commented
on
all
of
them
asking
for
some
sense
of
what's
going
on
is
this
can
be
included
or
not?
We've
probably
had
about
20
to
30
responses.
That
says
you
know
this
is
not
gonna
happen
in
115.
Well,
what's
gonna
stay
in
theta,
whatever
it's
gonna
be,
so
then
we've
got
at
this
point.
Another
70
responses
that
it's
just
generic
who
knows
I,
don't
know
like
it's
just
all
up
in
the
air,
so
this
is
when
I
had
talked
to
Stephen
in
sig
p.m.
G
B
So
so,
my
response
to
to
all
of
that
is
again
like
I
think
that
everything
that
we
should
do
in
people
and
process
and
building
automation
for
all
these
things
are
to
to
minimize
the
workload
for
the
release.
Team
right,
I
think
that
you
know
it's
unfair
for
there
to
be
an
expectation
to
consistently
consistently
like
dry
track
people
down
for
for
answers
to
code
that
they
own
right.
B
At
the
end
of
the
day,
code
ownership
belongs
to
sub-project
and
by
you
know,
by
extension,
if
that
belongs
the
cigs,
the
cigs
should
feel
responsible
for
keeping
these
enhancements
up
to
date.
If
enhancements
go
stale,
that's
that's
not!
That
should
not
be
our
problem
specifically
right.
If
the
so
I
was
mentioning
that,
like
specifically
for
for
kubernetes
enhancements,
the
fader
bot
is
one
on
and
two
there
there's
some
extra
magic
there
to
make
sure
that
something
is
never
marked
as
life
cycle
frozen.
B
The
reason
for
that
being
life
cycle,
like
a
life
cycle,
stale
only
kicks
in
after
what
is
it
ninety
days
or
something
like
that,
which
is
a
scope
of
a
release
cycle
right.
If
someone
is
unable
to
update
their
like
an
enhancement
issue
once
within
the
span
of
a
release
cycle,
it
should
go
stale
it
should.
It
should
wither
away
here
that
says:
you're,
not
tracking
it
right,
and
that
says
we
should
not
track
it.
A
A
A
Think
I'm
hearing,
can
you
say
that
like
if
this
is
something
that's
sat
there
at
a
really
raw
state
for
a
really
long
time,
should
we
actually
do
housekeeping
and
push
on
the
SIG's
to
say
just
as
soon
as
we
say,
like
hey
SIG's,
are
you
working
to
to
bring
this
forward
in
this
cycle?
Hey
sig?
Should
you
actually
visit
us
at
here
forever?
Should
you
go
ahead
and
subtract
it
from
the
repo
so.
B
I
think
I
think
I'm
not
entirely
tangential
to
that.
The
next
thing
that
came
up
was,
we
don't
have
a
real
concept
of
as
great
the
dentist's
here
we
don't
have
a
real
concept
of
unified
at
graduation
criteria
for
the
project
period.
Alright,
so
anyone
who
writes
a
cap
or
has
an
has
the
expectation
of
bringing
Enhancement
forward
great
the
they
have
to
imagine
the
they
have
to
imagine
what
graduation
criteria
is,
because
we
have
not
defined
it
right.
We
have
deprecation
policies.
B
B
Thus
it
has
to
be
kicked
out
right
and
and
again
like
the
the
the
the
responsibility
should
still
be
on
SIG's
to
to
handle
that
ejection
process,
but
the
there's
also
a
responsibility
for
a
cig
architecture
to
create
this
criteria,
so
I
think
it's
a
shared
responsibility
with
cig
architecture,
in
the
driver,
seat
and
and
p.m.
release
and
testing
participating
and
docs
test.
All
of
those
participating,
so
everything
that
we
require
within
the
release
the
release,
sign-off
checklist
within
a
kept
all
of
those
teams
should
be
involved
with,
with
with
architecture
driving
that
board.
B
I
know
that
I
mean,
like
I'm,
glad
I'm
glad
you're
on
the
call,
because
I
realize
I
I
have
all
of
the
people
who
need
to
be
on
all
the
calls
at
the
same
time
or
not
are
not
there.
So
I
talked
about
it
on
I
talked
about
on
the
PM
calls
and
I
realize
I'm
like
there
are
no
architecture.
People
here
so
I'd
mentioned
it
in
the
architecture.
I'd
mentioned
it
in
the
architecture
face-to-face
for
cube
con
towards
the
end
and
Jase
came
up
to
me
later
and
he's
like
you
know.
H
A
I
appreciate
you
bringing
this
up
Kenya,
it's
something
that
had
kind
of
caused
me
some
confusion
or
consternation
last
year,
looking
at
this,
this
huge
set
of
stuff
that
was
just
sitting
there
and
somehow
we
pulled
some
out
on
fuzzy
criteria
and
there
is
definitely
a
wonder.
Why
is
the
majority
of
the
stuff
just
kind
of
floating
out
there
yeah.
G
Like
my,
my
concern
was
exactly
with
that.
Like
yeah,
the
bots
might
close
all
these
issues
and
then
that's
it,
but
there's
nothing.
That's
gonna
reconcile
and
take
out
code
with
inside
of
KK
that
could
just
be
blowed.
At
this
point
we
have
no
idea
what
some
sort
of
alpha
implemented
feature
is
just
hanging
around
with
inside
there,
which
you
know
could
all
right.
B
G
B
Yeah
I
totally
agree.
I
think
that
there
is
also
I
think
we're
we're
continually
in
this,
like
state
of
trying
to
find
balance
of
like
what
are
the
things
that
we
try
to
attack
and
for
the
most
part
we
try
to
attack
the
active
things
right.
So
it's
easy
to
see
this
falling
by
the
wayside,
because
people
would
prefer
to
attack
the
things
that
have
velocity
as
opposed
to
the
things
that
don't
right
all.
H
B
A
It's
an
important
thing
to
do.
I
think
for
coat
hygiene
and
overall
health
and
performance
because,
like
the
the
sort
of
thing
is
why
we
still
have
floppy
drivers
and
in
the
BIOS
emulated
and
long
multi.
Second
pauses
as
machine
boots
up
to
to
check.
If
there's
a
floppy
disk
inserted
when
there's
not
because
when
the
cloud
runs
for
the
sake
of
a
container
to
start
so.
B
I
am
I'm
loving.
This
I
think
that
we
have
some
and
I
appreciate
everyone
who
has
brought
topics
forth
for
a
discussion.
I
think
that
I
think
that
we
probably
should
have
left
a
half
an
hour
or
more
for
the
next
topic,
but
we
should
at
least
broach
it,
because
it's
it's
been
coming
up
as
a
pressing
need.
So
that
said,
Tim
do
you
want
to
take
away
release
engineering
needs
and
planning
sure
this.
A
Is
such
a
broad
topic?
I,
don't
I
struggle
it
where
to
even
start
so
there's
a
little
bit
of
a
dock
there
that
just
kind
of
visually
describes
what
we
have
and
why
it's
problematic
and
where
we
might
try
to
go
to
improve
and
we're
talking
about
setting
up
a
sub
project.
But
in
a
lot
of
ways
the
implementation
details
have
felt
gated
and
it's
been
hard
for
newcomers
to
really
get
involved
in
trying
to
make
code
changes
because
a
lot
of
the
existing
process.
A
There
are
steps
that
are
slightly
opaque,
especially
historically
they're
things
that
were
only
running
inside
Google
Google
by
Googlers,
and
that
is
that
that
has
broadened
out
and
had
more
visibility.
But
then
a
portion
of
that
was
oh
look
at
this
code.
It's
maybe
not
what
I
would
have
designed
and
and
that
sort
of
turns
people
away,
but
it's
there
and
it
works
and
it
works
for
the
people
who
run
it.
A
So
you
have
this
weird
inertia
where
people
are
wanting
to
help
modernize
the
process,
but
it's
difficult
an
awkward
parallel
to
that
there's
the
whole
workgroup
kate's
infra,
that's
that
is
shifting.
You
know.
There's
been
this
formal
pledge
of
support
to
make
the
test
infrastructure
happen
under
a
neutral
body
with
via
the
C
and
C
F
and
infrastructure.
A
In
response
to
that,
because
I
feel
like
we
need
a
solid
into
end
pipeline
articulated
what
we
want
the
design
to
be
again
kind
of
what
what
Steven
mentioned
earlier
I
heard
they're
in
my
career
I
was
really
taught
to
focus
on
what
is
it
that
people
do
what's
the
desired
outcome?
What
is
the
use
case
and
based
on
that
define
the
processes
that
are
gonna
support,
that
document
them
and
then
work
to
turn
that
from
a
more
manual
process
to
an
automated
process
via
tooling,
so
people
process
tooling
in
that
order?
A
Otherwise
you,
micro
optimize
you.
We
start
writing
the
tools
and
we've
got
people
jumping
in
right
now
who
are
like.
Oh,
these
tools
are
really
weird:
I
want
to
go
straight
in
the
tools
up,
but
the
tools
don't
exist
in
isolation.
They're
part
of
this
broader,
develop,
build
test,
release,
support
iterative
spectrum
of
needs,
so
we've
got
a
lot
that
could
be
improved
here.
We
don't
have
what
is
by
any
means
of
an
industry,
best
practices
build
and
release
pipeline
and
the
those
are
industry
best
practices.
A
So
there's
lots
of
practitioners
out
there
who
can
look
at
it
and
see
what
work
needs
done,
but
we
need
to
figure
out
how
to
clearly
articulate
that
road.
First,
the
vision,
the
roadmap
of
where
we
want
to
get
there
and
break
it
down
into
a
backlog
of
work
that
people
can
actually
contribute
to.
So
it's
kind
of
with
that
introduction,
I'm
curious
what
people
think
and
maybe
dims
to
hear
a
little
bit
more.
What
progress
has
happened
just
lately
on
the
emphasize
right.
I
H
The
main
thing
that
we've
been
focused
on
on
the
infra
said
is
the
container
images
stuff.
You
know,
we
don't
have
it's
like
the
cloud
providers
or
the
cluster
AP
providers
or
the
CSI
providers.
All
of
them
have
run
their
own
repositories
and
docker
or
somewhere.
You
know
docker
hub
or
somewhere
else,
and
you
know
there
is
varying
levels
of
you
know
who
has
access
to
what
and
things
like
that,
and
so
that
was
the
first
problem
that
we
wanted
to
tackle
and
good
progress
has
been
made.
H
H
So
the
idea,
the
idea
is
that
each
group
of
people,
whether
it
is
a
cluster
API
or
the
cloud
providers
or
you
know,
CSI
folks,
they
will
have
their
own
GCR
repository
where
a
limited
number
of
people,
including
their
leads,
see
the
sub
project
leads
and
whoever
else,
but
a
limited
set
of
people
in
that
area
will
be
given
access
to
their
own
repository.
So
so
they
would
be
able
to
push,
for
example,
the
CSI
provider
for
something
port
works
or
whatever
right.
They
should
be
able
to
push
image
to
their
own
repository.
H
Do
certain
amount
of
testing
and
kick
the
tires
and
things
like
that
right
and
then
they
would
be
able
to
promote
from
that
repository
to
the
main
repository
and
would
go
through
an
approval
process
where
they
would
have
to
enter
the
SHA.
Whatever
the
image
ID
in
a
ml
file,
and
one
of
us
has
to
approve
it
and
that's
the
way
we
would
promote
so
B
would
have
a
record
of
where
did
we
get
them
image
from
way?
Did
we
copy-
and
you
know
who
requested
the
change
and
things
like
that
who.
H
At
this
point
right
now,
that's
where
it
is
and
then
B
so
basically
we
would
be
kind
of
defined
the
technical
side
of
this
stuff,
and
then
we
would
give
it
over
to
we'll
talk
it
with
sick
country
backs
or
whoever
wants
to
take
care
of
this
process.
We
would
end
up
delegating
to
them.
Could
it
it
could
be
the
cig
release
team.
B
H
Know
we
could
even
do
owners
files
and
certain
owners
within
specific
sub
directories
should
be
able
to
do
that.
Okay,
this
I
was
talking
about
the
five
people
for
the
main
owners
directly.
We
would
definitely
have
a
directory
structure
hierarchy
and
we
would
have
the
owners
files
in
each
of
the
things.
So
that's
something
that
we
need
to
work
on.
H
H
That's
where
we
wanted
to
be
so
that's
the
first
thing
that
we
wanted
to
do
and
we
made
good
progress
there
now.
The
second
thing
that
I'm,
hoping
that
we
all
agree
on
would
be.
How
do
we
put?
How
do
we
create
a
repository
for
the
RPMs
and
depths?
So
that's
where
I
think
we
need
to
find
some
people
who
are
interested
in
this
problem,
so
we
can
prototype
a
directory
structure
for
the
rpms
and
the
labs
and
go
from
there
and
say.
B
H
To
dedicate
to
this
so
okay
I
need
at
least
one
or
two
people
who
are
willing
to
carry
the
torch
because
the
image
promoter
we
made
it
happen
because
Linus
was
there
and
Linus
was
trying
to
coordinate
everything
and
he
wrote
a
bunch
of
the
code
and
things
like
that.
Yes,
we
need
there's
a
lot
of
us
who,
like
work
little
bit,
see
a
little
bits
there.
We
needed
like
at
least
one
or
two
dedicated
people
who
want
to
do
this.
Yeah.
B
A
I
miss
moused
in
the
window.
I
am
interested.
Hanna's
Horrell
is
interested.
We've
both
been
talking
in
hashing
some
out
some
things
out.
There
have
been
a
variety
of
keps,
it's
the
the
way
we're
doing
this
is
sub-optimal
at
the
moment,
but
again
as
part
of
a
pipeline.
So
initially
we
did
end
up
talking
about
how
we
fix
this
and
we
we
do
kind
of
devolved
into.
Let's
have
a
kept
on
how
we
build
packages
and
it
kept
on
how
we
publish
packages.
A
B
I
think
that
it's
also
funny
that
I
believe
we
had
an
issue
open
at
some
point
for
someone
requesting
an
understanding
of
what
the
the
kubernetes
CNI
package
packaging
process
was,
and
it
might
have
gone
stale.
It's
like
right
before
the
release
hit
so
I
think
it's
kind
of
like.
Maybe
it's
not
funny.
H
B
H
H
B
We've
got
multiple
people,
so
we're
ready
to
do
this.
I
think
you
know
from
what
I
said
on
that
call
was
like
between
Tim
and
I.
We
need
to
sit
down
and
what
we
need
to
do
like
outside
of
the
Katyn
for
team
is
actually
sit
down
and
say
one
we
need
to
consolidate,
consolidate
but
put
them
in
the
same
location.
B
All
the
caps
that
exist
for
packaging
things
right
now
make
sure
they're
in
the
same
location
and
make
sure
there's,
maybe
an
omni
cap
that
describes
some
of
this
flow
and
maybe
breaks
out
so
those
sub
caps,
but
also
define
what
what
the
cig
release
vision
is
right.
So
now
that
we've
we
issued
a
charter,
it's
it's!
H
All
that,
but
from
a
practical
point
of
view,
I
want
to
get
a
nightly
job
working
and
then,
when
we
hit
a
milestone,
we
should
be
able
to
publish
the
milestone
artifacts
and
then,
when
we
go
to
the
alpha
and
beta,
you
know
those
should
go
in
there
as
well
and
at
any
given
point
in
time.
We
should
be
able
to
point
either
jobs
or
tools
to
be
able
to
pick
up
the
artifacts
from
there.
H
H
A
I'm
happy
to
do
that
now.
One
specific
question,
though:
the
way
things
are
being
set
up
right
now,
relative
to
the
new
infra,
so
like
some
of
the
things
that
I've
started,
trying
to
split
apart
in
the
packaging
and
and
I
I,
don't
have
a
big
background
on
Debian
packaging,
but
I
know
rpms
and
rpm
spec
files
well
and
Hannes
is
the
opposite.
He's
got
the
deb
side,
so
we've
sort
of
been
bouncing
ideas
back
and
forth
off
each
other
and
in
both
groan,
yeah
I
can
implement
that
this
half
of
it.
H
A
H
B
Not
executing
yeah
yeah,
so
I
think
like
great
chat.
I
think
this
is
super
fun
I
think
we're
moving
in
the
right
direction.
Well,
we'll
all
probably
have
to
jump
around
between
the
working
group
Kate's
in
for
meetings
and
sig
release
meetings
to
really
drive
this
down.
But
thank
you
everyone
for
for
showing
up
today
and
for
the
lively
debate
we
will
catch
you
on
the
flip
side,.