►
From YouTube: Kubernetes Public Steering Committee Meeting 20190424
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).
C
Okay,
yeah,
so
user
group
form
governance
and
formation.
We
have
a
PR
out
it's
linked
to
the
steering
committee.
This
has
gone
through
some
discussion
already
and
a
group
of
people
who
opted
in
to
to
help
inform
the
governance
for
users
groups.
The
one
point
of
I
think
discussion
was
like
what
is
the
role
of
user
groups?
To
what
extent
are
they
purely
discussion
groups
which
anyone
can
can
use
in
any
way
or
the
group
can
decide
like
how
they're
going
to
use
the
discussion
group,
but
don't
have
a
specific
role
responsibilities
within
the
project.
C
Another
kind
of
philosophy
behind
them
was
user
groups
are,
do
have
a
role
specific
to
driving,
convey
Singh
the
work
on
the
project
with
outside
parties
and
users
and
that
sort
of
thing
and
help
drive,
feature
requests
and
that
sort
of
thing
the
I
was
all
kind
of
landed
on.
A
user
groups
are
welcome
to
to
perform
activities
which
can
result
in
driving
that
sort
of
thing,
but
that
they
don't
have
a
formal
role
per
se
or
they're,
not
tracked
in
sort
of
that
and
those
responsibilities.
C
The
some
of
the
open
topics
on
the
PR
are
about
sorry.
The
window
keeps
resizing
are
about
who
kind
of
initiates
sponsorship
of
the
user
group
does
I.
Think
Tim
you
had
a
comment
about.
Cigs
would
potentially
sponsor
these
things.
The
proposal
as
written
says
that
they
don't
require
any
sort
of
sponsorship,
but
just
send
something:
that's
there
in
committee
and
then
it
if
it
goes.
If
it
is
the
steering
committee
approving
these
I
think
there's
a
question
of
like
do.
C
D
A
D
So
I
mean
right
now,
they're
listed
as
a
top-level
entity
such
that
they
they
would
roll
up
to
steering
as
their
escalation
point
of
last
resort
and
yeah
Tim
you're
breaking
up
a
little
bit.
So
I
think
what
I
heard
you
say
is
similar
to
how
working
groups
have
stakeholder
SIG's.
You
would
like
user
groups
to
have
sponsoring
six,
and
so
it's
not
so
much
a
hierarchy
of
relationship
but
just
useful
to
know
that
the
two
entities
are
related
or
whatever
there's
a
link
between
them.
D
B
E
D
D
F
I
give
an
example
for
just
by
way
of
exploring
the
space
here
a
little
bit.
So
you
know
one
of
my
concerns
about
combining
say
jws
into
the
cloud
providers
sake
is
that
we
do
actually
have
a
reasonable
number
of
users
who
show
up
like
end-users,
who
show
up,
because
that's
a
good
place
for
them
to
kind
of
interact
with
the
community
and
get
advice,
and
so
like
AWS
user
kubernetes
on
AWS
user
group
would
seem
like
a
reasonable
thing
to
propose
and
would
pretty
clearly
fall
under
the
under
either
cloud
provider
or
Sega.
Ws.
D
So,
like
a
really
wary
of
user
groups
being
a
place
where
the
project
blesses
certain
end
users
solution,
not
sure
that
any
of
us
want
that,
and
so
I
have
concerns
that
associating
the
user
group
with
entities
that
are
in
charge
of
parts
of
the
project
code
that
belongs
in
the
project
kind
of
makes,
that
association
completely
in
favor
of
having
a
cloud
user
group
or
user
groups
for
specific
clouds.
That
seems
like
a
great
idea,
it's
unclear
to
me
like
why
we
need
to
tie
the
two
together
formally.
G
H
A
My
only
reservation
about
going
up
to
the
steering
committee
was
that
just
that
it
gets
addressed
in
a
fairly
timely
fashion,
we're
usually
pretty
overloaded
and
sometimes
issues
that
come
before
us
in
the
past
have
kind
of
rotted
for
a
while
until
poked
excessively
so
I
just
wanted
to
make
sure
if
people
wanted
to
create
a
user
group
that
you
know
so
are
usually
very
responsive.
So
that
was
my
only
point
of
contention
on
the
issue.
I.
C
C
C
G
C
Actually,
what
I
exactly
what
I
recommend
it
on
the
original
proposal
was
just
have
one
or
two
steering
committees,
members
explicitly
act
and
then
use
all
AZ
consensus,
I
think
if
we
send
it
to
a
steering
committee
mailing
list
and
then
throw
it
on
the
agenda
for
the
next
steering
committee.
Mail
is
just
to
say
this
is
happening.
That
seems
like
a
sufficient
yeah,
but
that
sounds
good
to
me.
Okay,.
D
But
do
you
feel
like
the
steering
committee
has
been
responsive
when,
like
there's
a
call
for
hey
here's,
a
PR?
We
need
you
to
like
apply
your
lgt
MS
or
vote
on
the
PR
they've
generally
been
responsive,
so
I'm
not
sure
how
concerned
I
am
about
using
the
number
of
people.
But
if
everybody
else
feels
like
it's,
it's
kind
of
hard
to
get
like
two-thirds.
D
A
The
two
solves
the
problem
and
I'm
fine
with
it
I
think
that
was
my
only
point
of
contention.
So
unless
other
people
have
other
issues,
we
can
probably
move
along
I
think
there
was
a
minor
comments
about
like
what
the
github
directory
meant.
I.
Think
multiple
people
were
confused
by
that,
but
we
can
probably
take
that
particular
one
offline,
yeah.
G
C
To
clarify
try
to
try
to
explicitly
avoid
that
by
putting
in
anti
goals
what
essentially
says
they
don't
create
any
roles
or
make
urbanised
project
decisions
or
producer
own
any
project,
deliverables
or
assets.
If
you
want
to,
if
there's
any
other
stronger
word
you
want
to
put
in
there
around,
maybe
owning
topics,
they
don't
own
topics,
they
just
have
them
available
for
discussion.
G
A
D
G
Wanted
to
give
a
heads
up
to
people
here
because
there
is
some
traffic
going
on
in
the
six
scheduling,
as
well
as
the
gaps
I
think.
So.
Basically,
the
the
rubble
was
that
six
scheduling
owns
cube
batch.
It's
in
sixth,
in
Cuban,
artists,
six
goetaborg,
but
there
are
people
working
on
cube
batch
who
wants
to
expand
the
scope
of
the
project
and
the
proposal
was
to
you
know
they
came
up
with
the
name.
First,
maybe
it's
better
for
me
to
invite
Quinton
here.
Quinton
are
you
there?
Yes,
I
am
yeah.
I
But
but
you
get
the
picture
that
Big
Data
machine
learning
applications
when
you
run
them
on
kubernetes,
they
run
into
a
whole
range
of
problems,
and
it
kind
of
doesn't
matter
what
you
know,
whether
using
spark
or
tensorflow
or
whatever
you.
You
tend
to
run
into
the
same
set
of
problems,
and
this
was
an
attempt
to
solve
a
range
of
those
problems
so
that
broader
scoped
effort
has
come
under
the
name.
J
Quit
misses
I
got
a
question.
One
of
the
issues
I
saw
in
the
volcano
project.
Documentation
was,
it
talked
about
alternative
container
runtimes
like
singularity
I
I'm,
not
sure,
if
that's
actually
in
or
out
of
scope
and
then
some
of
the
issues
you
talked
about
around
things
like
accelerators
and
pod
lifecycle,
I
I,
don't
know
if
they're
creating
another
pod
execution
agent
or
not,
but
that
that's
the
type
of
thing
that
also
I
think
was
not
clear
in
the
description.
Oh
that's.
I
I
Yet
certainly
there's
there's
a
recognition
that
is
so
and
I
can
certainly
get
them
to
come
and
tell
you
more
detail
exactly
what
the
thinking
is
there
and
to
what
extent
signal
it
wants
to
get
involved
to
be
clear,
maybe
maybe
also
just
to
take
one
step
back
so
some
of
the
stuff
that
gets
done
in
this
in
this
project.
This
volcano
project
could
conceivably
be
incorporated
into
kubernetes
over
time.
You
can
imagine
you
know
an
improved
batch
scheduler
and
that's
some
of
the
work
has
been
happening
with
with
sig's
scheduling
and
improved.
I
You
know
different
container
run
time,
etc.
May
well
be.
You
know,
consumed
into
the
into
the
core
of
the
product
or
at
least
into
the
purview
of
the
big
SIG's.
The
thinking
was
that,
rather
than
do
that
in
the
first
phase
focus
on
getting
this
working
in
a
sort
of
separate
project,
a
bunch
of
plugins
and
alternatives,
alternative
cubelets,
for
example-
and
then
once
the
moving
out
and
keep
little,
you
know
offered
up
to
the
SIG's
fall
for
something
if
they
so
wish.
J
It
sounds
like
someone's
making
tea
in
a
kitchen,
the
the
that
makes
sense
but
and
I
guess.
What
I'm
wondering
is
how
we
map
this
back
to
other
projects
that
have
come
up
and
then
it
the
scope
of
volcano
is
as
big
as
it's
implied
like.
Are
there
other
homes
like
just
as
a
CNCs
project
that
it
would
make
more
sense
as.
I
Yes,
definitely
as
that
that
has
been
floated
given
that
volcano
sorry,
given
that
cube
batch
is
already
a
sig
sponsored
project
with
a
home
and
everything
we
figured.
That
was
a
good
place
to
start,
but
you
know
it's
sort
of
minimally
disruptive
and
to
be
clear,
this
cube
patch
is
used,
for
example,
by
cube
flow
and
quite
a
few
other
upstream
consumers.
So
we
didn't
want
to
kind
of
rock
the
boat
too
heavily
here,
but
yes,
it
could.
I
Certainly,
you
know
once
it
gets
a
little
bit
more
momentum
that
this
expanded
scope
could
certainly
be
you
know.
Kind
of
kicked
kicked
up
to
the
CN
CF
and
out
of
the
kubernetes
context.
It
is
kubernetes
specific
at
the
moment,
so
it
is.
It
is
very
squarely
aimed
at
running
these
jobs
on
kubernetes
and
so
I.
Don't
know
to
what
extent
we
like
kicking
up
stuff
to
the
C
en
CF,
which
is
you
know,
entirely
focused
on
kubernetes,
but
other
than
that
caveat.
What
you
say
makes
perfect
sense.
K
K
I
K
It's
it's
honestly.
Such
a
repo
is
a
larger
project.
In
my
opinion,
it's
not
just
a
simple
small
project
anymore.
If
it
has
multiple,
six
and
I
feel
like
volcano
falls
into
that
category,
and
if
it's
a
larger
project
with
which
spans
multiple
SIG's
and
has
a
lot
of
in
a
way
like
parallel
logic,
to
existing
kubernetes
logic,
we
should
consider
it
as
a
separate
project.
That's
my
take.
H
So
I
mean
the
other
way
we
can
model.
This
would
be
as
a
working
group
with
the
charter
around
the
working
group
to
essentially
motivate
and
sort
of
describe
the
seven
features
across
SIG's
having
an
overarching
cap
that
talks
about
sort
of
what
this
thing
looks
like
makes
sense.
Also,
for
me,
one
of
the
things
that
bothers
me
about
this
is
that
it
has
like
a
non
descriptive
name
which
is
10
something
that
we've
tended
to
sort
of
shy
away
from
for
subcomponents
of
kubernetes.
I
G
I
D
Idea,
though,
is
the
working
group
would
be
at
the
same
set
of
people
but
figuring
out,
which
sake
should
own,
which
pieces
of
code,
since
it
seems
like
this
effort,
is
working
on
code
that
spans
multiple
SIG's.
The
working
group
would
be
in
charge
of
figuring
out
which
six
should
be
owning
these
pieces
and
if
you've
got
interested.
Taking
that
approach,
then
figuring
out
how
to
extract
out
seems
like
the
next
approach.
B
A
Iii
have
the
history
here
with
Klaus,
so
I
know
what
he's
thinking,
but
it's
it's
broader
in
scope,
I
understand.
Why
he's
doing
it
this
way
but
III?
Don't
it
does
make
sense?
It
is
a
logical
choice
for
the
current
type
of
workloads
that
he's
trying
to
address,
but
at
the
same
time,
like
I,
do
agree
with
everything
else.
That's
been
said,
I
do
think
it's
so
broad
in
scope
that
it
doesn't
fall
underneath
the
purview
of
a
sig
sponsored
repository
and
it's
likely
that's
not
a
good
home
for
it
and
I.
I
You
know
kind
of
problem
number
one
and,
as
I
mentioned,
the
the
decision,
whether
to
upstream
this
into
the
SIG's
all
of
the
stuff
into
the
SIG's
or
into
the
core
of
kubernetes
or
into
the
CN
CF
seems
like,
and
you
know
next
next
step
decision
to
take
and
I
mean
the
CN
CF
seems
totally
reasonable.
The
only
caveat
I
have
there
is
that
it's
only
kubernetes
and
only
ever
will
be
community,
so
does
it
makes
things
that
are.
D
I
H
Have
all
the
history
there,
but
suffice
to
say
it
was
that
we
were
actually
exerting
sort
of
more
sort
of
consistency
across
the
projects
that
actually
conflicted
with
some
of
what
helmets
doing,
and
so
that
was
one
of
the
things
that
actually
I
see
Brian,
that's
one
of
the
things
that
actually
you
know
I
think
Deutz
them
to
actually
want
to
want
to
move
to
the
to
the
CN
CF,
but
I
think
it's
the
same
sort
of
thing,
we're
trying
to
say:
hey.
What's
the
consistency?
H
C
E
Last
thing,
I
want
to
say,
is
to
Quinn's
first
point
about
hey:
we
have
this
repo
now
I
feel
like
that's
specifically,
why
we
asked
SIG's
to
own
code,
so,
like
Zig
scheduling,
needs
to
decide
if
they're
comfortable
with
the
current
state
of
a
repo
or
if
changes
are
necessary.
It's
not
a
steering
committee
decision.
K
E
G
K
I
A
C
C
So
just
take
a
look.
If
there
are
things
that
we
want
from
it
that
are
not
in
it,
we
should
provide
them
that
this
means
you
have
that
feedback.
If
it's
not
useful,
we
can
decide
whether
we
care
or
not,
but
they've,
been
sending
these
reports
every
quarter
for
like
a
year
and
a
half
at
least
so
anyway,
the
information
is
there.
We
can
also
decide
to
share
it
more
broadly.
Within
the
project.
It's
a
world
readable
link,
I,
don't
know
who
else
would
care?
C
We
don't
have
like
a
cig
marketing
exactly
since
you
have
does
that,
but
yeah.
This
slide
is
kind
of
interesting,
just
because
it's
these
cases
and
concerns,
so
some
of
the
SIG's
might
be
interested
in
that
the
key
messages
slide,
but
anyway,
just
just
take
a
look
and
we
can
have
a
follow-up
discussion
on
the
mailing
list.
If
people
have
any
thoughts.
D
Yes,
sorry,
so
this
was
a
follow
up
from
last
time
we
started
talking
about
state
cloud
provider
and
how
they
wanted
the
concept
of
people
that
were
coming
across
all
of
their
sub
projects,
but
that
they
also
wanted
like
individual
repositories
to
have.
You
know
technical,
leads
or
expertise,
and
so
this
reminded
me
we
don't
actually
have
a
very
tight
machine,
readable
definition
of
sub
project
owners.
There
are
a
number
of
ways
listed
on
how
to
do
that.
D
I
feel
like
ultimately,
wherever
one
of
these,
wherever
it's
defined,
it
needs
to
be
reconciled
to
the
other
location
for
user
friendliness.
So,
in
the
next
comment
below
I
have
a
link
taking
a
look
at
what,
if
we
just
assume
that
sub
project
donors
were
the
set
of
approvers
who
are
common
across
all
of
the
owners
files
that
are
listed
for
all
the
sub
projects
and
I've
identified
yeah.
So
all
of
the
warnings
they're
talked
about
any
sub
project
that
doesn't
have
common
approvers
amongst
their
owners
files.
D
I
could
keep
going
in
that
direction
and
find
like
where
there's
commonality
and
suggest
we
could
do
the
thing
where
we
define
sub
project
owner
centrally
in
60ml
and
then
propagate
it
out
the
same
way
that
we
do
for
sake
leads
user.
Your
leads
working
group
leads
and
stuff
I
just
wanted
to
take
a
straw
poll
to
see
if
anybody
here
cares
or
how
they
feel
about
it.
I
like.
C
The
gaps
was
just
going
through
this
process
of
rationalizing
the
owners
files
for
the
workloads
api's,
which
are
spread
over
at
least
several
sub
directories
within
kubernetes
community.
So
they've
had
a
strong
need
to
have
a
central
location
where
they
have
those
lists
of
at
least
approvers
and
reviewers
and
ideally
owners.
So
they
put
it
in
with
the
aliases
and
the
top-level
owners
files,
a
top-level
approver
to
do
that
refactoring
and
to
make
subsequent
changes.
But
that
seems
like
a
good
approach.
D
Storage,
as
my
other
canonical
example,
where
they've
spread
across
multiple
repos
and
multiple
courts,
both
inside
agent
repos,
as
well
as
all
the
individual,
CSI
repos
and
some
of
the
packages
inside
of
the
kubernetes
repo,
so
I
like
I,
still
eventually
want
to
live
in
a
world
where
most
of
this
is
defined
by
github
team.
Most
of
this
lands
in
github
teams
that
can
then
be
referenced
everywhere,
but
it's
about
like
getting
to
that
source
of
truth
and
who
authoritative
lis
should
be
in
those
github
teams
so
like.
If
there
are
no
objections.
D
But
this
was
the
AI
I
had
to
kind
of
follow
up
on
some
project
owners
meeting
the
needs
of
state
cloud
provider,
so
yeah,
ultimately,
I
want,
like
kubernetes
org,
to
have
the
files
that
arrived
all
of
the
github
teams,
so
that
we
use
a
PR
based
process
to
update
who
belongs
in
which
team
and
that
can
be
charted
out
to
different
SIG's.
So
sig
release
today
can
like
has
the
final
say
on
who
ends
up
in
stake,
released,
related
teams.
Sig
note
has
the
final
say
and
who
ends
up
in
sick
note
related
teams.
D
D
D
Could
add
github
teams,
but
I
think,
like
my
view,
this
more
as
a
social
construct,
so
the
owners
file
in
the
ideal
world
would
have
approvers
and
then
it
could
have
like
sub
projects,
owners
and
sub
project
approvers
so
that
they
both
have
approve
rights.
Maybe
for
those
sub
projects
that
are
in
fact
hierarchical.
The
top-level
owners
file
would
only
have
sub
projects
owners
yeah.
D
D
Sub
project
donors
are
most
often
the
people
who
are
in
charge
of
collaborating
and
coordinating
the
work
of
the
sub-project,
making
sure
that
everybody
is
working
on
the
same
thing,
they're
humans
that
you
need
to
know
as
a
point
of
contact
they're
the
people
who
are
most
likely
to
run
the
sub
project
meetings,
they're
the
people
that
you're
most
likely
to
ping
when
you
go
in
the
sub
projects,
slack
Channel
right
now.
What
I'm,
gonna,
try
and
do
is
take
a
look
at
all
the
common
improvers
in
the.
A
This
affects
so
many
people
I
think
it
makes
perfect
sense
that
kept
be
written
down,
at
least
to
talk
about
the
intricacies
and
who's
be
affected
and
etc.
Just
so
other
people
have
the
opportunity
to
comment
because
it
does
affect
so
many
people,
I,
don't
think
it's
controversial.
This
is
not
a
controversial
thing,
but
I
think
it
sounds
kept
worthy
if
we're
going
to
integrate
multiple
people,
multiple
processes
and
multiple
systems.
Ok,.
D
H
A
A
To
that,
or
are
there
other
things
going
once
twice
three
times
all
right?
New
issues
on
the
stereo
repo
I
figured
we
triage
those
new
in
bone
issues
just
so
that
we
give
him
a
home,
and
we
know
that
people
are
being
addressed.
There
were
two
issues
that
were
created
recently:
one
was
by
Tim
pepper,
called
leadership.
Trainings
there
was
actually
three:
there
was
the
quorum
one.
Probably
this
one's
not
controversial
and
we
are
married
already
added
it's
a
milestone.
A
B
A
But
what
about
things
like
C&I?
What
about
things
like
CRI
and
CSI,
like
in
just
the
basic
interface
projects,
for
example?
We
don't
we
don't
actually
have
rules
for
things
like
that
or
if
you
go
to
things
like
head-ons,
is
a
much
more
concrete
example.
We
want.
We
had
this
conversation
currently
about
like
what
it,
what
does
it
mean
to
be
an
add-on
and
does
that
fall
underneath
the?
If
we,
if
they're
done,
is
CR
DS
like
what
space
does
it
live
in
right,
I.
A
I'm
talking
about
the
policies
that
we
have
around
these
policies
and
governments
rules,
we
have
around
these.
So,
for
example,
a
very
concrete
example
is
the
namespace
in
which
you
create
a
CR
D,
because
right
now
everything
even
things
that
are
outside
of
the
purview
of
the
core
have
like
KH,
10
IO
right
inside
the
namespace
of
the
EOD,
that's
being
created,
and
it
probably
shouldn't
be.
We
should
probably
have
some
type
of
hierarchical
mechanism
for
this.
We
don't
really
have
that
defined.
A
So
as
we
have
these
like
layers,
where
the
core
depends
upon
it,
but
it's
outside
the
core,
then
we
might
might
have
a
stratification
for
there.
That's
that's
one
example.
Then
there's
the
there
was
basic
questions
about
governance.
With
regards
to
voting
right
like
right,
the
question
about
volcano
was
who
gets
to
decide
when
a
sub
project
is
created
we've?
A
Actually,
we
kind
of
do
it
slightly
differently
and
I
think
the
governance
model
itself
needs
a
little
bit
of
refinement
of
voting
versus
chair
sponsorship,
because
if
in
this
case,
Bobby
came
back
to
us,
but
in
the
current
model,
I
believe
he
could
have
done
things
arbitrarily
and
I.
Think
a
voting
mechanism
to
have
a
conversation
is
much
more
fortuitous.
But
this
is
an
example
of
three
issues
that
required
clarification
and
I.
Think
it's
pretty
important
and
it's
been
coming
up
repeatedly.
So
I'll
stop
there
and
see
if
flips
up
comments
to.
D
The
voting
issues,
specifically
our
governance
template
actually
says
that
voting
with
lazy
consensus
is
what
you
try.
First
with
fallback
to
leads
or
to
fall
back
to
chairs
and
technical
leads
in
practice,
I
think
everybody
has
just
gone
directly
to
chairs
I.
Don't
think
I
have
seen
anybody.
With
the
exception
of
contributor
experience,
go
on
a
lazy
consensus
vote
for
sub
project
creation.
D
D
A
Yeah
so
I
think
if
somebody
wants
to
take
ownership,
this
and
possibly
PR,
and
we
can
discuss
the
options
and
changes.
There's
a
couple
of
other
issues
that
Bobby
brought
up
with
with
regards
to
language
around
sub
projects,
making
it
more
explicit
about
the
guarantees
of
what
sub
projects
provide,
just
because
it
has
communities
somewhere
in
its
name.
That
doesn't
mean
it's
quote.
Unquote,
you
know
the
same
thing
as
as
communities.
K
Having
a
conversation
with
Brian
as
well
about
this,
that
sometimes
the
the
fact
that
a
part
of
a
project
is
sponsored
by
kubernetes
brings
this
notion
of
trustworthiness
with
it
and
we,
as
six
leads,
cannot
really
have
full
control
over
every
single
line
of
code
that
goes
into
these
projects.
So
there
is
no
guarantees
of
quality
and
also
when
a
worse
is
the
case
that
I
don't
know
a
few
years
down.
The
road
people
may
change
some
of
these
project
owners
may
change,
and
then
God
knows
what
goes
into
these
projects.
C
H
C
D
But
again,
I
feel
like
when
I
asked
about
question
at
the
community
meeting
last
week
about
so
who's
in
charge
of
defining
what
goes
into
the
kubernetes
release
as
we
try
to
live
in
a
world
where
it's
more
than
just
code
in
the
main
repo
Joe.
You've
obviously
said
that,
and
this
was
saying,
architectures
responsibility
and
so
again
I
feel
like
this
is
a
state
architecture
question.
If
everybody
here,
that's
what.
D
H
K
I
agree
with
Tim
I
think
we
should.
We
should
have
like
clear
policies
and
maybe
some
guidelines
as
well
for
for
users,
don't
just
think
about
us
in
the
community.
Our
smaller
community
think
that
there
are
like,
under
thousands
of
people,
go
to
Q,
Khan
and
I'm.
Pretty
sure
there
is
a
another
10x
number
of
users
who
who
use
kubernetes
and
maybe
someday
try
some
of
these
sub
projects,
and
we
need
to
have
some
concrete
information
for
those
folks
who
want
to
try
anything
and
me.
K
If
we
have
higher
bar
for
core
versus
non
core,
maybe
we
should
explicitly
advertise
those?
Maybe
we
should
put
it
I,
don't
know
a
bar
on
there
and
github
for
these
projects
to
say
that
these
are
their
six
sponsor
or
kubernetes
is
sponsored,
but
do
not
necessarily
have
the
same
standard
as
the
core
or.
H
Think
that's
an
interesting
idea,
I
think.
As
we
potentially
break
up
kubernetes
kubernetes,
we
have
another
signal
to
actually
say
hey.
This
is
something
that
is
part
of
the
core
and
like
we
could
define
that
like
we
have,
you
know,
can
come
up
with
the
name
core
sub
projects
versus
ancillary
sub
projects,
and
we
defined
core
is
ones
that
actually
the
code
ends
up
in
our
release,
because
there's
a
higher
level
of
responsibility
around
those
things,
I
see
Aaron's
very
excited
about
this
idea.
Yeah.
D
I
am
Not
sure
the
value
of
increased
stratification
here,
I
think
like
it's
worthwhile
to
be
explicit
about
what
sig
sponsorship
or
ownership
of
a
sub-project
implies,
but
I'm
not
sure
I'm
interested
in
now
that
SIG's
get
to
differentiate
between
their
core
and
their
non
core
projects.
I
feel
like
the
bar
that
Ryan
articulated
click.
Does
this
project
end
up
going
into
a
kubernetes
release
or
not
should
dictate
what
that
project
is
held
to
I?
Don't
feel
like
that.
So.
H
D
A
A
Perhaps
we
can
break
down
the
items
and
take
a
couple
of
people
to
get
assigned
to
this,
and
maybe
a
couple
people
can
then
go
to
arch
and
talk
about
the
other
aspects
of
it.
Does
that
seem
like
a
fair
wait
for
us
to
prevent
like
shedding,
because
this
really
does
overlap,
there's
there's
pieces
that
can
be
broken
apart
into
separate
parts?
That's.
G
C
A
I'm
not
gonna,
say
to
the
mouse
to
the
time,
because
we're
checking
near
the
end
so
just
a
quick
overview
of
the
current
milestone.
We
have
10
items.
There's
several
of
them
are
currently
active.
I
do
know
that
I
kind
of
wanted
to
walk
through
the
ones
that
haven't
been
discussed
already
where
he
talked
about
the
user
group
formation.
That's
just
needs
final
approval,
yeah
and
Brendan
send
out
an
email
and
I
wanted
to
make
sure
that
he
had
a
chance
to
talk
about
it
too,
as
well.
Funding
and
budget
for
Brandon
yeah.
B
I
mean
just
the
people
want
to
review
it.
I
tried
to
just
take
a
swing
at
what
funding,
how
to
request
funding
from
the
scene.
Yes
might
look
like.
B
A
B
G
A
A
N
Hello,
sorry,
my
zoom
was
freezing
up
yeah
we're
meeting
with
Michelle
to
talk
about
this
in
about
an
hour.
Okay,.
A
A
A
Thought
I
thought
there
was
an
original
list
when
we
first
had
the
conversation
about
this.
There
was
supposed
to
be
a
list
of
items
of
things
that
were
not
owned
by
the
project,
where
Docs
was
a
good
example
of
one
of
them,
and
we
talked
at
length
about
docks,
and
then
we
found
that
they're
apparently
sig
ducts
will
own
that
in
the
long
haul,
but
was
not
listed.
Here
was
the
actual
concrete
list
that
somebody
was
has
been
curating
over
time.
I.
C
Yeah
and
the
original
motivation
was
when
we
were
forming
all
the
SIG's
and
rationalizing
which
sig
on
what
and
defining
the
scope
and
each
sig
charter.
There
were
some
things
that,
for
a
long
time,
had
were
known
to
be
falling
through
the
cracks
like
the
things
in
the
list.
In
the
original
issue,
like
the
build
system
literally
just
came
up
this
morning
and
Tim
hosted
a
to
the
roll
board
to
ask
for
someone
to
own
the
build
system,
because
there
are
some
things
that
need
to
be
addressed.
There.