►
From YouTube: Kubernetes SIG Release - 2019-02-12
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
All
right
AC,
we
have
a
few
folks
joining
so
hello,
everyone.
This
is
the
February
12
edition
of
cig
release.
This
is
a
meeting
that
will
be
recorded
and
available
on
YouTube.
So
we
please
be
mindful
of
everything
that
you
say
and
be
sure
to
adhere
to
the
CN,
CF
and
kubernetes
code
of
conduct.
The
first
first
thing
we've
got
up
is
the
we
recently
did
a
cig
update
for
the
community
meeting.
Tim
pepper
took
care
of
that
so
Tim.
If
you
want
to
give
some
highlights
of
that,
that
update.
B
It
was
mostly
just
kind
of
run
down.
The
slides
were
linked
there,
but
kind
of
a
rundown
of
what
we
did
and
the
prior
quarter.
What's
going
on,
and
this
quarter
there's
for
folks
who
haven't
been
attending
the
community
meeting.
Maybe
it's
only
been
in
the
last
little
while
that
they've
kind
of
established
a
bit
of
a
template,
so
there's
kind
of
getting
to
be
a
cadence
of
content
and
commonality
across
the
SIG's
as
they
present.
A
So
yeah
so
I
think
a
broad
overview
is
the
the
spin
up
of
our
new
sub
projects,
so,
namely
firming
firming
up
some
of
the
process
around
the
release
team,
which
is
has
been
well
well
established,
but
you
know
we're
constantly
iterating
over
that
process.
Every
release
cycle,
the
release
engineering
team,
which
is
an
amalgam
of
the
the
processes
and
tools
and
the
people
that
are
involved
in
cutting
a
kubernetes
kubernetes
release.
A
So
those
are
the
the
patch
release
management
team,
the
branch
managers
and
everyone
who
has
their
hands
on
kubernetes
slash
release.
So
if
you've
never
seen
that
repo
or
read
up
on
that
I'll
post
links
in
the
chat
in
a
second
and
then
finally,
the
the
licensing
sub
project,
that
is,
that
is
myself:
Nikita
dam
and
Steve
Winslow
from
the
Linux
Foundation,
so
that
project
is
kind
of
centered
around
making
sure
that
kubernetes.
Although
all
the
repos
and
projects
that
live
within
the
kubernetes
orgs,
are
license
compliant
for
an
open-source
project.
A
So,
building
process
around
that,
as
well
as
doing
licensing
scans
and
things
of
that
sort
and
reporting
reporting
things
that
are
out
of
compliance,
so
that
so
those
both
the
release,
engineering
and
licensing
sub
projects
are
slowly
kicking
off.
If
you
are
interested
in
either
of
those
efforts,
please
let
me
know
let
myself
Tim
or
Caleb
know
and
we'll
figure
out
ways
to
plug
you
in
any
questions.
There.
A
You
all
right,
so
one
of
the
bigger
things
that
was
was
also
covered
on
the
slide
deck
and
came
up.
This
release
cycle
is
that
we
made
it
mandatory
to
have
caps
for
each
of
for
each
of
the
features
or
enhancements
that
were
coming
into
the
1:14
release
cycle
for
kubernetes
kubernetes.
So
there
was
a
quite
a.
C
A
Friction
around
that,
so
new
process
that's
to
be
expected,
but
I
think
we
had
a
lot
of
good
takeaways
and
you
know
the
the
end
result
of
that
was
having
a
an
updated,
kept
template
and
lots
of
action
items
around
that
template
and
how
to
improve
the
documentation.
So
I
mentioned
this
in
the
sig
p.m.
meeting
earlier
today,
but
the
plan
is
to
have
a
retrospective
around
the
enhancements
freeze
process,
specifically
within
the
one
of
the
sig
p.m.
A
time
slots
to
kind
of
just
go
over
what
we
could
have
done
better
when
we're
interest
introducing
new
process
changes
like
that,
and
so
anyone
who
is
that's
to
be
scheduled.
But
anyone
who
is
interested
in
attending
that
as
well
feel
free
to
reach
out
to
me
and
I'll
make
sure
that
it's
on
your
calendar,
any
questions
around
that
stuff.
A
D
Good
for
him,
yes
seriously,
yeah,
so
we're
in
the
process
of
cleaning
up
all
of
the
tested
boards
for
the
release
tests.
So
far,
what
we've
done
all
the
work
has
four
I
focused
on
sig
release
master.
What
we've
done
so
far
is
to
split
that
into
locking
and
informing
based
on
the
blocking
criteria,
I
PR
passed
by
Aaron
in
December
in
terms
of
blocking
criteria.
So
we
split
into
blocking
and
informing.
D
We
moved
several
things
to
informing
since
then.
Some
of
those
are
being
moved
to
other
SIG's
because
they
really
belong
to
other
things,
and
we
don't
care
about
them
from
at
least
perspective
like
I,
have
a
PR
open
to
all
of
the
coop
control.
Skew
tests,
which
are
really
belong
to
six
CLI,
are
moving
to
their
test
grid
and
we
even
look
at
them
anymore,
not
that
we're
looking
at
them
in
the
first
place,
the,
and
so
once
that
happens.
D
The
one
other
remaining
thing
to
do
is
that
Aaron
has
an
effort
open
to
identify
owning
teams
for
all
of
the
jobs
and
if
a
job
is
defined
as
really
genuinely
not
having
an
owning
team.
That
one
is
also
going
to
at
least
come
off
blocking,
if
not
the
grid
entirely,
because
if
we
no
one
owns
that
we
can't
fix
it.
If
we
can't
fix
it,
why
run
it?
The
M
and
that's
open,
has
been
a
bit
of
a
slog
for
for
an
effort.
One
of
the
questions
for
this
group.
D
Those
are
gonna
have
the
same
set
of
tests
that
sig
release
master
has
not
the
set
of
tests
that
we've
had
for
previous
release
versions.
One
question
is:
do
we
want
to
make
the
previous
release
versions
set
of
jobs
match
what
we
consider
the
current
jobs,
or
we
just
want
to
leave
them
the
way
they
are.
E
D
E
D
A
Right,
any
any
other
thoughts
on
that
burning,
move
on
all
right,
we're
speeding
through
this,
so
the
the
last
one
that's
on
the
agenda
for
today
is
the
is
the
idea
of
tracking
out
of
tree
features
and
how
that
should
be
done.
Nishi
gave
a
write-up
on
on
a
cig
release.
Issue
there's
been
a
little
discussion.
There
would
love
to
see
some
more
discussion.
Definitely
I
io
some
comments.
There
loves
to
see
the
the
other
chairs
jump
in
as
well.
Anyone
who
is
interested
in
commenting
on
that
go
go
for
it.
A
The
part
of
it
is
towards
the
end
of
the
release
cycle.
We
request
SIG's
to
supply,
release,
themes
and
I.
Don't
think
this
is
the
appropriate
place
for
release
teams
to
be
tracked.
The
changelog
should
be
changes
to
cur
Bonetti,
screw
Burnett
ease
or
kubernetes
kubernetes
processes
and
I'm
kind
of,
like
anything
that
might
be
related
to
that.
A
There
is
a
better
presentation
mechanism
that
maybe
doesn't
exist
yet,
but
we
need
to
talk
about
how
that
can
be
done
so
that
SIG's
can
have
you
know
if
it's
a
if
it's
an
L,
wkd
style
thing
or
a
contributor
style,
contributor,
site
style
thing
to
allow
SIG's
to
say
well
during
the
114
115
time
frame.
This
is
what
we
were
up
to
you
right,
but
it's
something
that
should
be
it's
something
that
should
not
be
included
in
the
kubernetes
kubernetes
change
laws.
That's
my
opinion.
That
is
not
a
few
of
sig
release.
B
B
Examples,
I
believe
so
initially,
I
hadn't
put
this
on
the
agenda,
but
I
had
seen
her
pinging
for
me
to
update
and
I've
kind
of
stayed
on
the
side
wanting
more
input
from
others,
but
that's
why
I
bring
it
up
here
to
maybe
foster
a
little
more
discussion
but
I
believe
she's
coming
at
it.
From
a
perspective
of
the
city,
I
WS
work
in
113.
B
B
Is
that
fair
and
there
wasn't
clear
documentation,
I
guess
or
the
decision
was
made
to
have
them
go
through
the
normal
process,
because
things
were
still
in
tree,
but
it
begs
a
question
of
where
we're
headed
and
then
the
other
examples
that
this
has
me
thinking
of
is
the
sig
windows,
promotion
of
Windows
containers
to
stable
GA,
one
of
the
things
that
initially
proposes
is
well.
Maybe
it
should
just
be
up
to
the
sig
to
decide
the
state
of
their
things
and
that's
kind
of
where
sig
windows
has
been
saying:
yep
we're
ready.
B
But
then
you
you
get
exactly
what's
happened
where
the
sig
believes
is
ready
and
the
broader
project
says
we'll
wait.
A
minute
we'd
like
to
see
some
slightly
different
things
and
that's
created
a
lot
a
bit
of
a
lot
of
contention
and
bad
feelings.
I
think
around
how
all
of
that's
played
out,
and
it
comes
back
to
not
having
a
documented
process
and
clear
criteria
that
people
can
understand
upfront,
so
they
they
felt
like
the
bar
was
being
moved
on
them
continually
over
the
last
nine.
A
D
I
think
specifically
about
because,
like
increasingly
everything's
moving
to
plugins
right
and
what's
appropriate
for
the
release
notes,
the
only
would
be
probably
for
release
notes
is
a
new
plug-in
being
enabled
in
a
specific
version
of
kubernetes
right
like
if
we
have
a
new,
you
know,
storage,
plug-in
or
something
that
couldn't
run
before
and
can
now
run
younggu
Bernays
version
115
and
that's
appropriately
for
the
release
notes.
But
in
the
release
announcement
it's
completely
appropriate
to
list
all
of
the
plugins
that
have
had
updates
and
new
releases
and
stuff
will
you
follow
me.
E
That
are
not
developing
kubernetes
kubernetes
that
the
idea
that
there
is
a
a
I
guess,
a
shorthand
for
a
180
kubernetes
release.
You
should
just
be
the
the
binary
once
the
parcel
lifecycle
folks
introduce
the
cluster
bundle.
It
should
now
beat
that,
and
now
we
have
an
opportunity
to
with
with
a
declarative
configuration
plate
at
ease.
This
is.
C
E
A
tremendous
release
is
because
this
is
what
can
be
used
by
tooling
to
spin
up
a
a
conformant
cluster
for
users,
so
I,
don't
think
any
smaller
definition
of
what
a
release
is
is
particularly
helpful.
I
think
the
note
that's
using
that
definition
also
allows
a
the
same
definition
to
be
used
by
the
project
itself
upstream,
but
also
vendors,
because
you
can
also,
as
a
vendor
your
your
conformance.
What
you're
checking
should
just
be
your
Europe
cluster,
so
a
EK
e
or
DC
cluster
bundle
AWS
one
ad
sphere,
180
KS
one!
E
B
Do
buddy:
how
do
we
actually
have
the
reference
implementation
day
like
I,
can
imagine
a
future
where
yeah
and
Joshua's
shaking
his
head
no
and
I'm,
throwing
it
out.
There's
a
question
because
I
know
that's
the
answer,
but
there's
been
talk
about
for
the
standard
interfaces,
making
reference
implementations
and
something
that
was
worst
case,
a
mocked
integration
but
lacking
that
to
actually
make
a
meaningful
statement
like
what
you're
describing
Caleb
I
feel
like
we
would
have
to
test
all
the
variations.
The.
E
E
C
E
You
are
selling
a
distribution
of
kubernetes
I.
Think
it's
a
totally
reasonable
bar,
but
if
you
want
to
use
the
trademark,
you
better
do
this
like.
We
have
a
specification
for
how
to
spin
up
a
a
kubernetes
cluster.
You
know
folks
have
been
working
on
that
for
a
while.
You
should
you
use
that
unless
there's
some
better
one
available
so.
D
D
E
What
I'm
arguing
for
is
that
there
is
a
core
definition,
that
is
the
cluster
bundle
that
went
through
all
of
the
blocks
in
so
you
so
today.
Unfortunately,
that
means
it's
validated
against
DCE
and
AWS
I
think
there
is
work
that
is
already
in
place
to
extract
those
components
and
replace
them
with
a
a
non
vendor
specific
bundle
that
could,
in
theory,
be
deployed
by
the
tooling.
D
It's
a
I
mean
consider
consider
a
future
where
we
have
done
our
proper,
pushing
everything
out
right.
So
the
core
storage
drivers
there's
just
CSI.
There
are
no
built-in
cloud
providers.
There
is
just
a
cloud
provider
API
at
a
certain
point
for
every
different
thing
that
kubernetes
can
do.
There
is
a
choice
of
three
to
a
dozen
different
plugins.
A
E
E
Worth
even
referring
to
that
that
previous
time,
I
think
that
if
you
look
at
release,
notes
for
a
project
like
Fedora,
that's
much
more
applicable
to
our
current
tapes,
because
there
are
sections
that
are
relevant
to
operators,
you
need
to
spit
up
a
new
kubernetes
cluster.
There
are
sections
that
are
relevant
to
downstream
vendors,
who
are
building
and
packaging
additional
products
on
top
of
kubernetes.
It
just
needs
to
be
a
better
place
than
the
changelog
md.
C
E
Is
in
cooper,
Nettie's
kubernetes,
I
think
that's
a
totally
reasonable
thing
to
solve,
for
this
group
I
think
it's
slightly
separate
from
the
what
is
a
kubernetes
release,
I
think
to
that
point
it
should
be
look
at
the
things
that
are
inside
the
you
know
the
terrible
cluster
directory.
That
is
what
went
into
the
CI
process
so
calling
anything
else
there
at
least
I,
don't
think
is
particularly
genuine.
E
C
E
E
D
D
E
A
Think
I
think
we're
like,
but
I
think
we're
stepping
away
from
like
the
actual
question
of
the
issue
and
which
is
how
do
we
track
out
of
tree
features
or
enhancements
right?
Is
that
done?
Is
that
done
within
kubernetes
kubernetes
or
is
it
done
somewhere
else?
We
haven't
I,
don't
think,
we've
answered
that
question
I.
E
D
E
A
E
A
Okay,
so
if
something
anything
that's
coming
into
the
project
right,
that
is
changing,
the
project
should
have
a
cap
right.
Well,
we
were
saying
for
the
114
release
cycle
is
that
if
it
is
not
landing
in
tree
kubernetes
kubernetes,
it's
changed.
It's
not
changing
some
code
or
process
around
kubernetes
kubernetes.
Then
we
don't
care
as
the
release
team
do
not
care
to
track
it
right.
The
cap
should
still
be
there
right.
There
should
be
a
bar
like
there
should
be
expectations
for
everything.
D
E
Think
a
anything
that
a
cig
sponsors
can
can
have
a
tech
chords
that
at
the
sink
that
says
this
process
is
supposed
to
be.
You
know
it's
supposed
to
tie
hand
in
hand
and
glove
with
the
rest
of
the
kubernetes
processes.
So
if
there's
a
sponsored
sub
projects,
that
work
is
being
done
against.
That's
great.
If
there's
a
new
sub
project
that
a
SIG's
wants
to
spin
up
and
track
work,
there
I
think
what's
also
good,
but
certainly.
C
E
F
A
quick
question
Caleb:
how
do
we
handle
stuff
that
will
end
up
getting
released
later
after
the
release
goes
out
right,
say:
people
have
to
really
make
a
release
that
will
work
with
or
140
and
their
releases
will
come
after
hours
right.
So
how
do
we?
But
we
would
like
to
say
something
about.
You
know
that
also
because
it's
related
saying
that
okay
there's
a
plan
for
this
to
be
released
soon
and
look
out
for
that
kind
of
situation
too.
I.
Don't.
F
A
Sorry,
I,
don't
think
I,
don't
think
it's
feasible
for
us
as
a
project
to
enumerate
all
the
things
that
potentially
work
with
a
project.
I
think
that
it
should
be
the
onus
should
be
if
it's
especially
if
it's
an
external
vendor
the
owner
should
be
on
them
to
provide
compatibility
specs
around
kubernetes.
We.
A
E
C
E
Be
official
community's
communication
channels
as
they
exist
because
that's
the
bar,
your
sig,
you
sponsor
this
work.
That's
great
now.
Should
we
have
a
bunch
of
vendor
specific
things.
I
have
consistently
argue
that
we
should
not.
We
should
organize
them
into
into
groups
that
are
generic,
so
they
should
in
my
mind
there
should
be
no
state,
eight
of
us,
no
sig
GCP,
no
signature,
no
state,
IB,
I'm,
glad
no
sig
being
aware.
They
should
all
be
sub
projects
or
some.
A
E
Thank
goodness
that
there
is
not,
but
if
you
are
some
project
you
know
I
think
specifically
interview
s.
Has
a
bunch
of
these
like
little
projects,
I
make
running
on
kubernetes
running
kubernetes
on
they
view
us
better
I!
Think
it's
fine
for
those
to
be
part
of
a
general
release
announcement,
given
that
they
have
met
the
technical
standards
that
exists
today
for
the
project.
So
we
may
be
kept
more
careful
about
what
cigs
we
are
allowed
to
charter.
That's
where
I
would
cut
it
and
make
these
changes
right.
E
J
E
F
E
If
they
come
like,
certainly
after
it's
simply
because
of
the
technical
limitations
of
the
release
process,
I
don't
find
any
need
to
remove
that
information,
because
it's
not
another
good
time
to
publish
it
because
there's
a
lot
of
activity
and
interest
that
goes
out
with
our
or
our
release
announcement.
So
I
think
that's
I
can
understand
the
motivations
for
one
to
be
on
that
train
and
wrong.
C
E
E
A
I
think
so
I'm
curious
like
where
the
line
is
exactly
for
for
things
that
are
out
of
tree.
That
kind
of
want
to
announce
themselves,
I
think
that
if
they
have
their
own
space
to
announce
and
they
bring
up
their
own
tentative
plans,
then
it's
not
on
us
specifically
to
capture
all
those
plans
and
do
the
trusting
and
verifying
specifically.
A
E
A
Since
it's
sorry
it's
it's
less
about
who
owns
that
process
specifically
and
the
things
that
would
be
coming
into
that
process
right.
So
if,
if
they're
failing
to
meet
that
or
we're
like
how
many,
how
many
projects
that
we
plan
on
tracking
that
are
within
kubernetes,
the
the
kubernetes
works
great,
oh.
A
A
E
Any
I
mean
it
should
be
all
of
them,
like
our
processes,
should
scale
to
track
the
work.
That's
going
on
in
the
ecosystem
that
is
targeted
at
these
individual
discrete
releases
that
it
sponsored
five.
The
things
I
think
that
is
our
responsibility
as
process
than
others,
because
that's
the
that
is
the
general
requirement
from
the
from
the
people
who
are
doing
the
work
in
the
six
like
they're.
E
E
B
I
hear
that
and
I
definitely
parts
of
me
agree
but
go
I
think
maybe
even
rapping
back
to
initiative
specific
question.
How
do
we
deal
then
with
cadence?
If,
if,
if
the
idea
is
that
these
things
split
out
of
KK
but
they're
part
of
the
Oregon,
we
have
to
track
them,
they're
split
out,
so
they
could
run
on
their
own
Cadence's.
But
then
the
release
team
would
have
to
have
some
sort
of
a
cut-off
date
by
which
we
collect
their
information
and
then
we're
determining
their
cadence.
E
B
E
B
E
No
expectation
on
us
because
it's
not
stackable
to
at
the
you
know
one
minute
before
the
release
supposed
to
go
out
be
following
up
with
like
six
stories
about
a
eight
a
plug-in.
That's
not
reasonable,
but
if
you
are,
if
you
you
know,
if
you're
ready,
when
the
train
is
departing,
I
see
no
reason
to
say
you're
not
allowed
on
the
trip.
F
C
J
E
A
C
J
A
A
D
A
A
it's
not
tying.
The
creation
of
the
kept
to
the
whole
point
of
the
part
of
the
point
of
the
cap
is
to
span
multiple
release
cycles
right.
So
it's
not
it's
not
tying
the
creation
of
the
cap
to
the
release
cycle.
It's
tying
the
expectation
that
the
the
content
of
the
cap
is
accurate
and
up
to
date
for
that
release
cycle.
Yes,.
C
E
F
E
E
E
I
think
the
sport
is,
if
you
don't
care
about
being
mentioned
in
the
official
kubernetes
announcement
and
whatever
do
whatever
you
want
spotlight.
If
you
do,
then
you
have
to
meet
the
bar
to
ride,
to
ride
on
the
release,
training
and
if
you
have
I
mean
I
guess
you
know,
I
have
a
huge
amount
of
I
guess,
empathy
for
people
who
want
to
meet
whatever
bar
they
want
and
still
be
included
in
the
in
the
official
communications
of
the
project.
I
think
that's
just
a
totally
a
wholly
unreasonable
expectation,
totally
fine
saying
that
that's.
A
A
K
A
I
I
mean
this
is
come
up
a
bunch,
especially
with
the
you
know,
especially
from
my
perspective,
I
guess
my
experience
with
release
notes
and
third-party
vendors
trying
to
get
stuff
in
there
and
I
just
would
say
that
I
am
somewhat
conservative
on
this
topic
and
I
agree
with
the
folks
that
say
like
this
is
not
a
right,
but
you
have.
This
is
a
privilege
and
that
it
is
not
unreasonable
of
us
to
either
decide
that
they
shouldn't
be
in
there
or
that
there
is
a
high
bar
for
what
goes
in
there.
I
And
then
you
must
work
with
the
tooling
that
we
specify,
and
it's
especially
kind
of
nice,
now
that
one
with
114
kind
of
requiring
enhancements
for
everything
it
creates
a
potentially
higher
quality
source
of
information
to
make
release
notes
from
so
I'm
really
excited
about
emerging
in
this
release.
Notes
tool
into
the
released
tooling
and
continuing
to
work
on
inked
like
integrating
the
enhancements
repo
into
that,
and
hopefully
just
making
enhancements
the
source
of
truths
and
making
it
less
easy
for
people
to
just
slip.
I
L
I'm
just
a
fly
on
the
wall,
man
absorbing
it
in
no
from
a
dog's
perspective,
though
I
think
that
it
helps
having
it
all
in
one
place,
kind
of
like
release,
notes
as
well.
You
know
some
features
that
nice
is
probably
a
question
for
you
know:
sig
Docs
is
you
know
what
goes
into
the
K
website?
You
know
repository
their
official
documentation
for
supported
features,
but
there's
probably
a
different
sake.
Discussion,
but
yeah.
C
L
H
C
Yeah
I
from
this
discussion,
it
I
could
derive
that
kubernetes
rulli's
as
a
1.14
wouldn't
be
just
single
software,
but
a
bundle
of
multiple
things,
multiple
sub
projects,
so
I
look
at
this
as
a
tree
where
you
know
1.14
is
the
root
node
and
then
all
other
dependencies,
etcetera
that
going
to
release
notes
or
the
talks.
They
would
contain
difference
of
different
processor
projects
and
their
versions
and
a
mapping
yeah.
This
is
how
I
see
it.
C
C
C
M
M
So
this
I
have
a
kept
in
mind,
but
I'm
pointing
this
to
the
leg
cycle,
basically,
and
also,
of
course,
educating.
The
community
is
going
to
be
hard.
We
have
to
contact
a
bunch
of
sick
chairs
and
instruct
them
to
not
accept
yars
unless
these
PRS
also
touch
this
Yama
file
and
like
one
of
the
main
targets
here,
is
going
to
be
the
cluster
directory
and
at
the
same
time,
the
question
directory
like
the
whole
topic
of
moving
moving.
This
directory
out
is
a
big
one,
but
yeah
I'm
going
to
make
this
kept
fairly.
E
Circle
up
before
you
do
so
because
it
would
be
a
shame
to
do
a
bunch
of
work
that
wouldn't
or
shouldn't
be
required.
If
everything
in
the
cluster
directory
was
itself
a
cluster
bundle,
it
should
be
in
theory,
much
easier
to
see
what
are
the
versions
everything
because,
of
course,
you
would
have
had
to
specify
the.
E
In
order
for
your
cluster
to
be
provisioned
in
the
first
place,
so
I
would
like
to
see
us
start
building
on
the
abstractions
we're
building
elsewhere
and
seeing
how
we
can
do
that,
how
we
can
improve
that
experience
using
automation.
You
see
me
looking
at
like
a
project
like
cloud
foundry.
Certainly
we
we
have
a
bunch
of
automated
release,
tooling,
that
produces
that
exact
kind
of
information,
and
you
don't
you.
E
M
E
So
today
get
some
of
that
information.
I
mean
the
way
like
you
know,
but
at
least
when
I
was
putting
together
that
section
with
her
external
dependency
information.
Since
you
had
to
go
to
test
grade
to
get
that
originally
I
did
you
could
in
fact
just
pull
it
from
the
GCS
bucket
directly
and
then
find
it
out,
but
I
think
you
could
make
much
better
progress.
E
M
G
M
M
But
yeah,
probably
probably
gonna,
write
a
dog
or
something
like
that
before
I
keep
and
see
like
what
is
the
progress
with.
That
was
the
bundle
first
yeah.
It's
I
think
it's
might
be
early
for
that.
But
again,
the
problem
here
is
that
the
released
in
this
cycle
has
to
manually
edit
stuff
in
it's
super
yeah.
E
Real
pain,
but
you
can
use
your
knowledge
and
your
of
that
tedium
to
step
into
a
role
in
the
wider
city
leaf
that
helps
improve
that
for
future
release
teams.
That
is
always
the
intention
is
once
you've
got
identified,
a
problem
from
service
on
the
relief
team
to
be
part
of
a
solution
in
the
wider
cigarettes.
So
we
can
actually
have
you
know
long-term
improvements
to
the
prophecies,
because.
A
So
a
note
there
is
that
a
cap
is
a
document
right.
So
if
we're
thinking
about
doing
something
like
this
and
you
think
that
it
might
be
too
early
I,
don't
think
it
is
we're.
It
sounds
like
we're
all
on
the
same
page
Ling,
something
down.
So
if
you
want
to
put
something
up
around
scope
and
motivation
and
general
goals
for
this
I
think
that's
valuable.
C
C
One
more
perspective
I
had
was:
if
all
the
sub
projects
have
caps
and
all
the
project,
all
the
caps
off
kubernetes
main
projects
have
kept
stand.
They
don't
we
have
too
many
caps
and
we'll
run
short
of
the
viewers,
and
our
release
cycles
will
be
under
pressure
to
get
it'll
be
enough
pressure
to
get
their
caps
out.
C
A
E
A
E
H
I
B
Feel
like
that
might
not
matter
like
people
are
becoming
aware
of
the
cadence
already
in
the
need
and
hand
or
even
say
most
things
our
core
today
and
we're
just
starting
this
process
really
of
breaking
things
out.
So
if
there's
some
awareness
here
and
you're
definitely
off
on
your
own,
but
you
want
to
get
on
the
train.
B
It
seems
like
it
would
be
natural
to
understand
that
you
need
to
pay
attention
to
the
release
cycle
and
not
back
up
a
cycle
before
that,
and
and
I
would
I
would
worry
if
we
we
ended
up
there,
because,
echoing
Caleb
and
I'm
sure
dims
eyebrows
will
go
out,
but
the
OpenStack
blueprints
process,
where
you
have
like
you,
get
backed
up
doing
definition,
work
so
far
behind
that
it
slows
velocity
on
things
potentially.
C
A
I,
don't
I,
don't
think
that
this
is
a
matter
of
too
many
caps
versus
too
little
caps.
I!
Think
it's
and
it's
also
not
a
having
process
for
process
sake
like
I.
A
Looking
at
right,
I
think
that
this
is
like
the
initial
toil
of
getting
this
done
is
going
to
like
the
net
effect
will
be,
will
be
huge
for
people,
so
so
I
don't
think
it's
a
too
little
or
too
much
thing.
I!
Think
it's
a
let's
make
sure
we
approach
it
in
the
right
way
and
drive
down
some
of
these
concerns
early
in
the
game.
A
So
we've
got
four
minutes
left
I
posted
just
now
a
so
after
finishing
the
cap
template
there
was
a
set
of
feedback
from
the
reviewers.
That
y'all
can
take
a
look
at
and
add
some
feedback
to
that
that
will
be
reincorporated
into
the
cap
template
and
the
surrounding
documentation
to
make
sure
everyone
has
eyes
on
that.
So.
B
Just
want
to
say
thank
you,
everybody
that
was
a
good
conversation.
We
we
keep
kind
of
dancing
around
this
and
that
that
gave
some
useful
focus
and
especially
Claire
like
raising
your
hand
and
saying
like
okay.
So
then,
what
is
this
actually
going
to
mean
for
the
implementation,
for
this
role?
I
think
that's
a
key
thing
not
to
lose
track
of.
A
A
So,
thank
you.
Everyone
for
showing
up
I
think
it
was
a
really
really
valuable
conversation,
lending
your
voices
to
it
and
helping
improve
the
process.
If
you
have
any
questions,
comments
concerns
right,
reach
out
to
us,
we're
on
cig
release,
there's
kubernetes
cig
release
at
Google,
Groups,
comm,
and
all
that
good
stuff.
You
should
know
the
usual
channels.
Take
it
easy.