►
Description
Kubernetes Monthly Public Steering Committee Meeting for 20220110
A
A
B
C
A
Time
how
many
eyes
can
one
word
have
in
a
row
before
you
hit
a
consonant,
come
on
all
right,
jumping
down
to
our
topics?
We
had
a
couple
really
brief
ones
up
at
the
top
of
the
list.
One
follow-up
from
last
meeting
we
had
talked
about
having
setting
up
a
sync
with
the
code
of
conduct.
Folks-
and
there
were
there-
was
a
charter
update
pending
from
them
that
I
think
we
wanted
to
talk
about
in
person,
but
I
don't
think
anyone
actually
took
the
ai
to
figure
out
a
date.
C
A
F
Missed
the
item
right
after
that's
on
me
as
well,
I
actually
pushed
this
to
its
own
topic
on
the
agenda.
The
the
deduplication
that
had
been
asked
for
is
straightforward
enough
in
theory,
but
it
leads
to
some
other
questions
that
I
think
we
should
discuss
in
public.
So
that's
at
the
very
end
of
the
agenda
and
we'll
see
if
we
get
to
it
but
I'll.
Oh,
I
want
to
wait
on
that
for
now
and
if
we
don't
I'll
I'll
start
a
thread
in
the
issue
on
github.
H
I
I
We
currently
have
seven
one
is
stepping
down
and
we
have
three
associates
and
I
think
we
do
try
to
limit
our
associates
to
three
and
we
just
have
had
enough
issues
come
up,
not
not
anything
major,
but
just
enough
work
come
up
intending
to
to
reports
and
following
through
on
that
that
it'd
be
everyone
felt.
It
would
be
nice
to
have
a
few
extra
folks
and
rotate
on
our
associates
have
been
on
as
associates
for
a
while.
I
We
just
haven't
had
openings,
so
we
wanted
to
just
increase
the
size
from
the
minimum
seven,
and
so
I
just
wanted
to
give
everyone
here.
A
heads
up
answer
any
questions.
Anyone
had
another
motivation
was
just
at
least
one
or
two
folks
currently
on.
The
committee
would
like
to
rotate
off
at
some
point
this
year,
but
we
didn't
want
to
leave
everyone
short-handed,
so
we
wanted
to
to
just
increase
the
size
to
have
some
continuity
and
carry
over
while
we
transition
to
people
on.
I
C
I
Yeah
we
we
have
a,
we
do
have
a
process.
It's
I
think
it's
just
specified
as
a
minimum
of
a
three
month
that
it's
functioning
as
an
associate
and
our
associate
level
tasks
are
defined
as
handling
issues
that
are
already
public
or
low-level
security
issues
that
are
technically
security
issues,
but
can
be
handled
in
public
without
without
any
major
concern.
I
J
Yeah,
I
just
wanted
to
ask
to
ask
the
question
like
from
a
from
that
from
a
sustainability
perspective.
Is
there
a
good
pipeline
of
folks
coming
in?
I
know,
like
the
security
response
committee,
is
a
like.
It's
a
fairly
trusted
role
to
bring
people
into
is
there
interest?
Is
there
like
a
solid
pipeline
of
people
that
are
interested
and
are
working
at
building
that
that
trust
to
bring
into
the
security
responsibility?
Are
there
any
concerns
about
like
future
sustainability?
There.
I
Yeah,
I
don't
not
not
from
anyone
that
I've
talked
to
not
on
the
psc.
I
think
we
actually
part
of
this
is
to
open
up
more
slots
as
associates,
because
there's
just
not
that
much
associate
work.
So
we
we
have
other
people
we
that
that
we
want
to
nominate
to
be
associates
and
we
want
to
give
them
the
opportunity
to
actually
do
something
so
that
part
of
that
is
promoting
our
current
associates
and
then
opening
those
opportunities.
A
I
Some
other
this
isn't
kind
of
oversighty,
but
just
there.
I
have
some
thoughts
that
I'm
I've
been
meaning
to
type
up
and
can
send
to
the
send
to
steering
just
nothing
majors
majorly
concerning
but
just
to
add,
more
add
more
a
little
more
accountability
to
the
psc
in
terms
of
just
making
sure
we're
handling
issues
well-
and
I
think
that
talking
about
about
for
myself
as
well
as
just
the
ps4
more
broadly,
it's
a
you
know.
A
I
E
Yeah
bob
said
half
of
mine,
which
was
the
transparency
report,
but
also
the
annual
report
too.
We
could
cut.
We
should
take
this
offline
and
figure
out
how
we
can
help
with
that,
because
I
mean
we
have
two
major
reporting
vessels,
so
I
think
that
would
be
great
places
for
it.
Like
the
annual
report
and
the
transparency
reports.
I
The
liaison
trio
so
great
awesome,
yeah.
I
I
think
the
annual
report
makes
a
ton
of
sense,
maybe
something
even
quarterly
just
so
that
we
have
more
accountability
for
ourselves,
external
good
external
motivation,
because
I
think
right
now,
it's
most
our
motive.
Most
of
our
motivation
is
just
intrinsic,
which
is
good.
We're
mostly
we're
motivated
people,
but
I
think,
having
some
good
external
pressure
could
be
a
positive
thing.
Yeah,
I'd
love
to
talk
about
that.
A
A
I
think
we've
had
a
few
iterations
on
this
and
I
think,
what's
there
is
probably
a
reasonable
place
for
this
year's
template.
It's
not
quite
as
automated
as
I
had
hoped,
but
it
I
think
it's
a
lot
more
targeted
and
actionable
than
than
what
we
had
last
year,
folding
in
some
of
the
feedback
on
like
specific
questions
and
crisp
questions
with
numbers
that
are
pretty
easy
to
compute.
A
A
So
that
takes
us
to
chris
stuff,
so
the
the
workflow
we
were
envisioning
was
we'd,
have
these
templates
and
then
there
would
be
a
generator
that
would
take
that
template
and
stamp
out
a
file
in
each
sig
and
working
group.
Folder,
ideally
pulling
in
some
calculated,
stop
regenerating
links
based
on
six.
So
kristoff.
Do
you
want
to
talk
through
where
the
generators
have.
J
Yeah
I
we
have
the
generator
from
last
year.
There
have
been
some
stuff
that
I
need.
Basically,
I
need
to
do
a
rebase
and
that
rebase
is
done.
I've
got
it
in
like
a
local
branch.
The
the
next
kind
of
step
is
taking
the
template.
Once
the
template
is
merged
and
and
making
a
like
a
go
text,
template
version
of
it,
which
should
be
fairly
straightforward
and
then
updating
the
pr.
J
I
don't
have
tests
written
for
it,
but
I
I
think
we
could
probably
do
those
in
a
in
a
follow
up,
but
yeah
it
should
be,
should
be
fairly
straightforward
and-
and
we
can
get
that
done-
you
know
in
the
next
few
days
when
we
get
the
the
actual
working
group,
template
and
stuff
all
immersion.
So
you
know
no
problems.
There.
A
A
Up
in
the
evening,
tuesday
and
thursday,
okay,
so
we
can
give
people
a
heads
up
tomorrow
and
hopefully
have
it
ready
thursday
and
then
start
outreach.
So
the
next
item
I
just
included
for
reference
like
once
the
templates
are
there
we'll
do
an
announcement.
Paris
had
mentioned
doing
that
and
then
the
liaisons
can
reach
out
to
their
individual
groups.
A
E
I
can
yeah
I
can
do
any
of
the
above,
so
just
for
the
sake
of
time,
we
can
just
do
it
offline
if
y'all
are
cool
with
that.
Okay,
just
read,
it
leave,
leave
comments
in
the
doc,
because
this
is
sort
of
the
baseline
for
conversations
that
you
should
have
for
annual
reports.
I
tried
to
make
it
as
like
either
what
we
already
do
or
stuff
that
we've
discussed,
that
we
need
to
do
and
left
like.
You
know
a
lot
of
my
wild
ideas
out
for
this
go
anyway.
E
A
A
H
Sounds
good,
I
think
we
have
do.
We
have
ango
as
well
yeah.
We
have
our
levels
yeah.
So
for
quite
a
few
time,
lots
of
batch
related
issues
was
coming
to
six
scheduling.
The
the
issue
here
is
that
some
of
these
requests
were
actually
cross
seg,
and
so
we
thought
that
this,
like
having
a
working
group
that
engages
leads
from
cigarettes,
signaled
and
six
scheduling,
would
serve
better
these
types
of
workloads.
H
It
seems
that
we
are
the
point
where
the
project
is
mature
enough
to
consider
batch
more
seriously
so
to
speak,
and
so
the
goal
here
is
to
try
to
improve
the
batch
experience
in
core
kubernetes,
not
just
trying
to
build
something
on
top
of
kubernetes,
and
the
idea
is
to
improve
the
job
like
focus
on
things
like
the
job
api
and
have
discussions
around.
How
can
we
implement
job
queueing
properly,
whether
that
those
apis
are
going
to
end
up
in
core
kubernetes
or
not?
H
Maybe
is
not
the
issue
as
much
as
we
want
them
to
work
well
with
the
rest
of
the
kubernetes
ecos
like
core
components
like
the
scheduler
cube
controller
manager,
we
are
trying
to
make
sure
that
we
have
an
ecosystem
that
reduces
duplication
as
much
as
possible.
I
can
give
one
example
here
again
the
job
api
like
it
is
really
sad
that,
like
every
new,
you
know
batch
framework
that
builds
on
top
of
kubernetes.
H
A
Yeah
thanks
thanks
for
the
overview,
so
I
guess
open
it
up
to
questions
from
steering
folks
and
also
from
community
folks.
I
don't
know
if
they're
representatives
from
any
of
the
stakeholder
sigs,
I
know
abdullah
and
although
you
are
scheduling
so
that's
great,
but
apps,
autoscaling
node
there's
been
some
discussion
on
the
the
pr
and
then
the
thread
that
led
to
the
pr.
But
I
didn't
know
if
there
were
questions
or
other
things,
that
folks
from
the
other
cigs
wanted
to
bring
up.
C
C
H
I
tried
personally
to
get
people
from
sick
apps
and
not
engaged
as
well,
and
I
I
made
an
explicit
effort
and
I
nominated
magic
from
sick
abs.
I
didn't
want
only
people
from
six
kilos,
because
initially
only
people
from
six
kids
were
in
graduated
and
I
that
defeat
for
pepper.
So
so
I
mean
at
this
point
it
it's
that
people
know
me
as
myself
way,
I'm
from
google
way
from
ibm
and
and
magic
from
red
hat
and
sig
abs.
H
C
Yeah,
so
I
yeah,
so
I
don't
believe
that
our
I
don't
feel
that
we
have
documented
anywhere
that
you
know
it
that
needs
to
preclude
anyone
from
participation
in
the
working
group.
Anyone
should
be
able
and
empowered
to
participate
in
the
working
group.
I
think
you
know
just
making
sure
that
we
have
a
reasonable
set
of
organizers,
is
important
to
make
sure
that
the
working
group
actually
functions
right.
So.
H
C
C
So
yeah,
so
paris
is
kind
of
nailing
it
in
the
chat
right
so
like
organizer
means
organizer,
not
maintainer.
Those
people
should
be
involved
in
the
group,
not
necessarily
around
the
meetings
right.
So
the
people
who
are
organizers
leads
for
the
working
group
would
be
responsible
for
the
kind
of
administrivia
right,
not
necessarily
they
can
they
can
bring.
You
know
the
technical
know-how
to
the
group,
but
they
don't
necessarily
need
to
be
the
primary
contributors
maintainers
of
of
work
product
from
the
group
right.
H
B
Oh
and
jim
says
his
hand
up,
yeah,
sorry,
yeah,
hi
abdullah,
thanks
for
the
discussion
about
daniel
and
I
plus
one
all
the
things
that
was
said
by
folks.
So
the
one
question
I
had
was
there
seemed
to
be
a
strong
contingent
of
people
who
chimed
in
on
the
discussion
but
wanted
to
do
things
elsewhere.
So
how?
How
did
that
end
in
terms
of
like?
Will
they
still
be
engaged
with
us
or
are
they
are
we
trying?
H
C
H
H
It's
where
this
is,
that
was
being
discussed
to
present
our
charter
to
them
and
again
to
encourage
them
to
contribute
to
our
working
group
and
the
and
the
proposal
here
is
that
we
want
to
build
poor
features
that
can
basically
help
them,
reduce
that
duplication,
that
that
is
the
the
goal
and
the
best
place
to
do.
This
is
called
kubernetes
because
the
dependency
goes
from
them
to
us,
not
the
other
way
around.
H
I
can't
have
a
dependency
from
core
kubernetes,
like
as
a
crd
to
the
outside,
like
to
some
outside
project
and
so
yeah.
I
guess
that
is.
That
is
the
way
that
I,
that
I
look
at
it
and
that's
how
I
try
to
argue
about
any
proposal
that's
being
presented
from
outside
kubernetes.
If
this
is
something
that
we
can
convince
the
community
to
have
supported
in
core
kubernetes,
then
that's
the
best
place
for
it,
because
the
dependency
is
on
kubernetes.
H
A
Just
to
follow
up
on
tim's
question,
I
think
that
gold
makes
sense
specifically
to
get
the
people
who
are
wanting
to
build
things
externally
engaged
so
that
you
have
good
evidence
about
what
would
be
good
to
support
like
what
primitives
would
help
support
with
that.
I
don't
know
if
that
makes
sense
to
call
out
in
the
charter
like
yeah
collaborative
lectures
that
might
be
helpful.
Paris,
just
paris
just
said
exactly
the
same
thing.
H
You
know
discussions
to
say:
okay,
if
you're
building,
for
example,
an
mpr
operator,
let's
try
to
find
the
shortcomings
in
the
job
api
that
allows
you
to
depend
on
it
rather
than
you
building.
You
know
your
own
internal
api,
for
example,
so
that
it
is
something
actually
we
did
before.
That's
what
I'm
trying
to
say
and
I
think
okay,
we
would
try
to
do
it
again
at
the
higher
level,
for
example,
with
frameworks
that
tries
to
build
like
more
complex
frameworks
out
there.
F
It's
that's
going
to
take
a
lot
of
activation
and
effort
to
keep
things
moving
forward
and
then
the
the
only
other
comment
that
I
have
really
for
for
the
charter
as
it
stands.
Right
now
is
kind
of
again
along
those
lines,
the
the
timelines
and
disbanding
part
at
the
end,
it's
sort
of
a
shrug
which
is
a
normal
starting
point,
but
to
to
have
some
vision
for
what
is
going
to
be
sufficiency
in
both
a
success
or
okay.
F
H
H
Head
licking
my
lips,
sorry,
okay,
because,
like
it
looks
to
me
then
okay
and
so
actually
like
one
of
the
things
that
we
are
considering
as
a
as
a
potential
interval,
is
converting
this
into
a
sick.
I
don't
know
if
that
will
happen
or
not,
but
it
it
might
like.
If,
for
example,
we
come
up
with
a
new
controller
that
does
queuing
who's
gonna
own,
that
that
could
serve,
as
you
know,
let's
say
more
mass,
like
bigger
mass
of
code
ownership.
H
A
Is
your
roadmap
still
on
track
like
what
is
your
road
map?
And
so
I'm
looking
at
this
as
a
new
working
group?
Thinking
like
what?
What
is
the
road
and
there's
a
lot
of
possibilities
there,
but
it
seems
like
a
first
step
should
be
to
get
the
road
map
clearer.
So
maybe
explicitly
saying
we
want
to
clarify
the
roadmap
as
one
of
the
first
things
we
do
would
be
helpful.
I.
F
Think
sorry
about
abdullah,
you
described
a
number
of
interesting
potential
outcomes,
maybe
for
a
year
plus
from
now
put
those
and
put
a
a
milestone
sometime
during
the
year
to
to
reflect
on
on
which
path
it
feels
like.
Is
it's
trending
towards
it's?
You
can't
have
a
road
map
that
goes
a
year
or
two
out
with
any
actual
reality,
but
to
note
your
vision
of
the
possible
kind
of
vector
space
of
the
road
maps
that
might
play
out
and
set
some
some
timelines
for
deciding
which
one
it
feels
like
is
viable.
J
J
This
is
the
one
true
way
to
do
a
thing
unless
that
really
is
the
only
one
true
way
to
do
it
and
there's
there's
significant
risks
in
splintering
things.
So
I'd
be
very
interested
in
like
what
are
the
problems
that
are
solved
today,
that
we
can
only
solve
by
kind
of
collaborating
in
in
this
fashion,
as
opposed
to
what
we
have
typically
like
to
do,
which
is
enable
the
ecosystem
to
like
develop
things.
J
So
that
there
may
not
necessarily
be
one
true
way
to
do
things
so
understanding,
like
figuring
out
those
problems
which
again
we're
still
very
early
in
that
process
and
the
charter
kind
of
reflects
that,
like
there's
still
a
lot
of
like
research
and
talking
to
be
done
there
but
yeah,
the
thought
there
is
just
making
sure
that
we
don't
necessarily
king
make
that
this
is
the
one
true
way
to
do
it.
Unless
that
is
there
like.
There
is
a
very
strong
reasoning
behind
that.
J
The
second
comment
that
I
had
was
around
component
ownership
and
like
again
going
to
timelines
for
the
working
group.
Typically,
when
we
create
new
components,
if
there,
if
there
is
like
code
bases
or
definitions
and
that
kind
of
stuff
making
sure
that
the
working
group
is
very
much
engaged
constantly
with
its
sponsoring
sigs,
because
ultimately,
the
sig
is
where
the
the
resultant
work
from
this
would
be
owned.
J
So
if,
like
code
is
being
created
or
long-lived,
definitions
are
being
created,
though
the
sig's
ultimately
responsible
for
that,
in
this
case,
like
apps
or
scheduling
or
stuff,
like
that,
they
would
need
to
be
on
board.
As
far
as
like
yes,
we
understand
this
and
are
going
to
take
ownership
of
those
those
pieces
yeah,
I
think
that's
all
I
had
thank
you.
H
So
quickly,
for
the
the
first
point,
I
think
this
applies
to
even
services
as
well.
We
have
been
trying,
for
example,
to
implement
multi-cluster
service
discovery
and,
like
different
frameworks,
try
to
do
it
their
own
way,
and
then
we
managed
to
come
up
with
an
api
that
somehow
provides
some
unification
around
the
sensible
approach
like
that
is,
I
guess
one
guiding
example
like
I.
H
So
I
guess
my
point
here
is
that
there's
a
ton
of
history
and
examples
that
we
have
that
we
can
try
to
draw
comparisons
with
and
and
guide
us
in
the
way
that
we
try
to
propose
new
features
that
does
not
block
people
into
specific
approaches,
but
simplify
things
that
are
clearly
common
and
doesn't
need
to
be
replicated
and
another
general
comment
regarding
batch.
It's
an
extremely
fragmented
ecosystem.
H
H
We've
heard
that
from
our
customers
over
and
over
and
over
again,
there
is
no
approach
to
do
that
in
kubernetes
and
the
existing
systems
they
try
to
retrofit
existing
platforms
on
top
of
kubernetes,
and
there
are
a
ton
of
problems
around
that.
So
we
want
to
define
some
approach
there.
I
don't
think
we
are
trying
to
force
something
as
much
as
bring
people
together
to
discuss
those
things
and
define
and
approach
the
unified
ecosystem.
A
C
So
yeah
so
re
charter
updates.
I
think
you
know
what
I
I
have
done
at
least
in
the
past
and
and
working
group
formation
is,
is
lay
out
something
that
is
kind
of
like
a
rough
draft.
To
kind
of
you
know,
paint
the
picture
and
and
and
as
tim
mentioned,
making
that
first
action
to
come
back
to
to
the
charter
and
and
work
on
refining
those
re,
the
the
the
king
making
stuff.
I
I'm
not
too
worried
about
that.
C
I
think
I
think
you
know,
at
least
from
the
perspective
of
the
kubernetes
community.
I
think
you
know
the
the
work
product
that
we
have
is
intended
to
be
core
for
the
the
project
that
we're
delivering
day
to
day
right,
so
I
mean
I
I
I
have
more
concerns
about
that
on
the
on
the
cncf
level
than
I
would
within
the
project.
B
One
of
the
reasons
for
splintering
earlier
that
I
kind
of
gleaned
reading
between
the
lines
was
that
hey
it's
more
difficult
to
get
things
through
in
kubernetes.
There
is
more
steps
that
you
need
to
take
and
it's
easier
for
us
to
just
grab
whatever
we
can
and
like
change
it.
However,
we
want
it
to
be.
You
know
that's
how
in
a
clone
and
do
whatever
they
want
at
whatever
time
period
that
they
want
to
do.
B
H
Again.
I
keep
coming
back
to
the
services
example.
There's
a
ton
of
momentum
there,
because
a
ton
of
people
invested
in
in
there
and
and
willing
to
have
a
discussion
around
how
to
implement
things
properly
and
and
and
whatnot.
We
do
not
have
that
weight
for
batch,
at
least
at
least
from
my
like
from
the
like.
I
don't
know,
past
four
years
I've
been
engaged
with
the
project
that
did
not
exist.
H
F
Really
quickly,
just
again
on
the
the
leadership
side,
I
I
know
that
there
are.
This
is
a
really
really
common
pattern
and
I
know
that
there
are
a
number
of
quite
opinionated
people
in
the
the
user
space
side
of
this.
So
this
fragment
instead
of
frameworks
like
from
an
engineering
principles
perspective.
I
totally
get
what
you're
saying
but
possibly
those
other
entities
the
folks
are
going
to
think.
Well,
that's
actually
our
unique
value
ad
we've
taken
this
thing.
F
That's
not
great
and
we've
made
it
better
in
our
special
sauce,
so
they
may
hear
colonizing
and
unifying
as
lowest
common
denominating
and
not
like
it.
So
again,
like
the
the
leads
of
the
working
group
are
really
going
to
have
to
have
a
strong
bridge
building
mindset,
because
just
making
the
work
group
doesn't
mean
that
people
are
going
to
come
you're
going
to
have
to
pull
some
and
really
convince
them
that
you
are
making
something
good
for
them
that
they
want
to
embrace.
A
All
right,
so
a
few
ais,
I
think,
incorporating
feedback
from
this
discussion
into
the
pr
finalizing.
The
leads
selection
based
on
some
of
the
feedback
here
as
well,
and
then
getting
acts
from
the
sponsoring
sigs
and
then
sending
it
back
to
steering.
Does
that
make
sense
to
everyone,
or
there
are
other
ais
to
include.
A
E
C
A
G
Yes,
hi
everyone,
so,
as
you
know,
kids
are
responsible
for
the
job
migration
to
from
google
to
the
community
infrastructure
and
over
time
we
succeed
to
basically
migrate
the
emerging
block,
jobs
and
the
master
informing
jobs.
But
the
progress
about
this
migration
is
very
slow,
because
not
everyone
have
time
to
fully
work
on
that
or
get
surprised
and
their
staff
for
the
what
for
the
backlog.
G
C
G
A
G
G
Because,
right
now
we
basically
I
mean
we
have
a
pretty
good
list
on
job
running
on
on
community
infrastructure,
but
there's
still
a
lot
of
job
running
inside
google
and
they
are
basically
owned
by
all
the
six.
So
the
request
is
basically
say
to
the
six
to:
basically
they
have
to
make
sure
all
their
jobs
run
on
cuba,
on
community
infrastructure.
J
So
having
a
checklist
or
a
very
defined
list
is
important,
because
we
have
to
remember
the
sig
chair
who
is
likely
the
person
who's
going
to
get
pinged
on.
This
will
not
necessarily
have
the
technical
expertise
like
there
that
will
not
be
universal
across
the
board.
They
may
have
it.
They
may
not
have
it
and
they
need
to
know.
Okay.
Who
do
I
need
to
talk
to
what
kind
of
skill
set
and
background?
Am
I
going
to
need
for
my
sig
for
whoever
like
takes
ownership
of
this?
J
A
J
A
Agree
I
and
it
sounds
like
bob
that
was
echoing
what
bob
was
going
to
say
as
well
arno,
I
think
for
like
the
steering
liaisons
like
our
goal,
is
really
to
distribute
work
and
have
sort
of
these
sig
to
sig
interactions
not
require
us
as
a
middleman.
So
if
you're,
if
you
have
these
detailed
requests
like
per
sig
and
are
not
getting
traction,
that's
a
helpful
thing
to
bring
up
yeah
like
in
the
leads
meeting
rather
than
like
pulling
us
in.
A
G
F
E
Yeah
I
mean
even
I
I
definitely
agree.
We
need
to
like
break
this
down
because,
like
even
as
a
even
if
you
get
to
the
point
of
hey
the
the
chair,
isn't
talking
to
me,
we
still
need
to
know
like
what
exactly
they
aren't
talking
to
you
about
like,
instead
of
like
the
ginormous,
the
the
ginormous
erin
issue,.
C
I
I
I
do
want
to
point
out,
at
least
for
I
mean
just
to
to
kate's
in
first
credit,
but
they
do
do
quite
a
bit
of
documentation,
work,
and
I
think
that
you
know
if
the
you
know,
one
of
the
examples
like
migrate
away
from
from
gs,
cop
ci
right
that
is
well
detailed
right.
So
I
think
I
I
think
a
lot
of
the
work
may
already
be
there
just
getting
it
into
that
that
large
umbrella
issue
and
saying
who
it
belongs
to
right.
C
If
it's
you
know
it's
sync
cluster,
you
know
cluster
life
cycle
or
what
have
you
making
sure
it's?
It's
just
like.
I
know
who
owns
it
right
that
way
like
these
mini
umbrella
issues
we
can
assign
to
people
our
case
and
freaking
assigned
to
people
right.
I
I
think
most
of
I
think
most
of
the
details
are
there.
It's
just
not
immediately
clear
from
the
way
that
the
the
larger
issue
is
structured.
G
B
G
B
Yeah,
if
I
remember
right,
we
blew
the
budget
on
this
one
of
the
scalability
job
that
was
running
beyond
its
lifetime
right.
So
that
is
something
that
we
need
to
think
of
a
little
bit
more
in
case
infra
on
how
how
to
do
this
gradually.
So
when
we
bump
the
ceiling,
then
we
should
kind
of
like
hey
stop,
because
we
won't
have
the
budget
to
run
everything.
G
Budget
is
not
directly
related
to
the
pro
jobs
is
basically
an
underlying
issue
related
to
artifact
distribution
and
lucky
things.
Paris
sent
some
help.
So
I'm
supposed
to
talk
to
someone
about
this
okay,
but
in
general
the
pro
job,
I'm
not
the
another.
One
thing
I
would
say
we
need
to
care
if
we
from
a
virtual
perspective,
because
we
can
optimize
that
over
time,
but
in
order
to
optimize
that
we
need
to
have
the
full,
basically,
all
the
pro
jobs
running
inside
the
community
infrastructure.
A
All
right
we're
out
of
time,
so
I'm
going
to
call
it
there.
There
was
one
item
about
kubecon
eu
that
we
can
take
to
slack,
and
then
the
liaison
issue
actually
got
mentioned
earlier
with
the
draft,
that's
ready
for
review
and
then
I'll
just
make
a
plug
for
if
you're
taking
issues
and
working
on
them
put
them
in
the
in
progress
column
in
the
project
board.
I
saw
steven
doing
that
on
a
few
things
anyway.