►
Description
Kubernetes Public Steering Committee Monthly Meeting for 20201012
A
Okay,
good
morning,
good
afternoon,
good
evening,
everyone,
my
name,
is
chris
up
blecker,
and
this
is
the
october
12th
edition
of
the
kubernetes
public
steering
committee
meeting.
A
We
have
a
pretty
package
angel
today,
but
before
we
get
into
it,
I'd
like
to
remind
everybody
that
this
meeting
in
our
community
is
subject
to
the
kubernetes
and
cncf
code
conduct.
So
please
be
excellent
to
each
other.
A
Excuse
me,
so
changes
in
governance
are
always
a
a
critical
time
in
in
any
community
of
any
size
and
in
ours
in
particular,
they're
they're.
You
know
very
critical
that
when
we
we
choose
the
folks
that
are
going
to
be
making
critical
decisions
that
we
have
like
a
a
solid
process
behind
it.
A
A
A
I'd
also
like
to
extend
the
congratulations
and
thank
you
to
everybody
that
participate
in
this
election.
You
know
whether
or
not
you
were
a
successful
candidate
or
not.
We
had
an
incredible
slate
of
candidates.
People
from
all
corners
of
our
community
and
the
elections
process
is
made
better.
By
having
such
a
like,
wide-ranging
slate
of
candidates
can
participate
in
the
election.
A
We
had
roughly
the
same
amount
of
voter
turnout
as
we
had
last
year.
Percentage-Wise
we'll
also
be
you
know.
In
the
coming
days
and
weeks,
the
elections
officers
will
be
putting
up
like
a
bunch
of
the
raw
voting
data
and
that
kind
of
stuff
for
transparency
reasons.
A
So
with
that.
A
With
that,
we
will
keep
rolling
through
the
agenda,
so
the
I'm
going
to
rearrange
the
agenda
a
little
bit
so
knocking
on
that.
That's
that
that
previous
issue,
nikita
you
had
you
mentioned
about
the
retro
for
the
election,
I'd
like
to
tackle
that
next.
B
Yeah
I
was
going
to
talk
about,
so
we
need
to
create
an
election.
We
need
to
have
a
meeting
for
the
election
retro.
I
know
we
had
a
lot
of
things.
We
wanted
to
talk
about
their
things
that
we
discussed
in
the
previous
structure
that
we
probably
also
wanted
to
incorporate
in
the
next
election
us
I
would.
B
I
wanted
the
retro
to
be
scheduled
in
the
next
couple
of
weeks,
if
possible
and
get
the
changes
in
after
the
retro
instead
of
waiting
for
the
next
election,
and
I
can
like
take
the
task
of
creating
the
doodle
and
figuring
out
the
scheduling
and
stuff,
but
I'd
like
to
get
that
going
if
that
works
for
everyone.
A
Great
and
I'd
like
to
make
sure
that
we
extend
that
invite
to
the
retro
to
like
everyone
involved
in
the
election,
so
not
just
the
elections
officers,
but
also,
if
you
are
a
member
of
the
steering
committee,
a
previous
member
of
the
steering
committee,
a
candidate
for
election.
A
A
As
you
know,
any
anything
that
we
can
learn
to
make
this
process
better
would
be
beneficial.
It
can
only
enhance
our
enhance
our
community,
especially
again
in
these
like
sensitive
important,
critical
governance,
changes.
A
C
So
the
next
thing
we've
got
on
the
agenda:
sorry,
jim
yeah.
I
would
like
to
thank
all
the
candidates.
There
was
a
lot
of
energy
this
time,
so
I
was
really
glad
to
see
all
the
positive
vibes
towards
the
community
towards
the
election.
C
A
Okay,
so
next
thing
on
our
agenda
is
the
working
group
reliability
charter?
There
is
a
linked
pr
in
the
agenda.
White
tech.
Are
you.
E
B
A
What
what
you
view
or
the
goals
of
working
group,
reliability
and
then
we
can
get
into
if
any
of
the
steering
committee
folks
have
questions.
E
True,
so
so,
basically,
the
goal
or
the
mission
for
the
group
itself
should
be
ensuring
that
our
users
can
run
kubernetes
in
production.
E
A
Sorry
we
lost
you
there
for
for
a
moment.
Sorry,
would
you
would
you
mind,
starting
back
over,
we
lost
you.
E
E
Oh
sorry,
so
what
we
are
planning
to
have
in
scope
for
the
group
is
basically
first
defining.
What's
what
reliability
really
means
for
kubernetes
and
how
we
should
be
measuring
it?
What
we
or
how
I
would
envision,
that
is
that
it
will.
We
will
define
a
set
of
slos.
That
kind
of,
if
satisfied,
will
will
mean
that,
like
the
kubernetes
is
reliable,
but
it's
like
the
exact
details
are
to
be
done.
E
E
If
the
reliability
bar
isn't
really
met
for
a
given
release
and
then
like
also
providing
or
getting
a
survey
of
survey
of
like
end
users
to
to
understand
what
kind
of
outages
and
issues
related
to
reliability
they
are
facing,
and
based
on
that
and
based
on,
like
our
own
knowledge,
what
what
our
potential,
like
outages
or
gaps,
creating
and
prioritizing
list
of
like
necessary
reliability,
investments
that
should
happen
and
finally
like
based
on
that
list,
like
working
with
relevant,
seeks
for
delivering
both
the
infrastructure
that
are
needed
to
address
those
things
like,
for
example,
some
testing
infrastructure
like
upgrade
tests
or
like
chaos,
tests,
or
something
like
that,
as
well
as
like
working
in
individual
with
individual.
E
The
individual.
Six,
on,
like
specific
improvements,
mostly
like
what
I
envision
is
that
we
won't
be
like
what
is
out
of
scope,
is
like
designing
or
executing
like
of
individuals
that
are
clearly
falling
into
like
individual
six
charter,
like
I
can
imagine
that,
like
the
best
example,
is
probably
priority
and
fairness
like,
which
is
clearly
a
reliability
improvement,
and
it's
happening
now,
but
it
clearly
also
falls
into
like
sig
api
machinery
charter.
E
So
what
like
this
group
will
be
focusing
more
is
the
potential
improvements
that
are
like
cross
seek
cross-cutting,
multiple
six,
and
I
think
hopefully
this
part
is
it's
not
super
controversial?
Well,
okay!
So
maybe,
let's,
let's
move.
E
Let's
move
into
deliverables
now
because,
like
it's
pretty
connected,
so
I
think
I
mentioned
most
most
of
that
in
like
when,
when
talking
about
skull,
but
to
make
it
explicit
so
so
the
the
expected
deliverables
are
like
first
document
defining
what
reliability
means
then,
like
the
list
of
known
outages
and
and
failure,
most
list
of
specific
investments,
that
should
happen
in
this
area
and,
finally,
the
set
of
processes
that
we
would
like
to
introduce
to
avoid
like
degradation
of
reliability
over
time-
and
I
think
that
is
hopefully
not
super
controversial.
E
One
more
thing
that
is
potentially
more
controversial
is
that
we
would
like
to
to
get
the
power
to
block
some
feature
oriented
contributions
from
individual
six,
if
requested,
reliability.
Related
improvements
won't
be
addressed
by
those
six
like
the
exact.
E
What
what
exactly
it
means
is
like
to
be
done
like
I,
I
don't
want
to
propose
anything
specific
at
this
point
like
we
will
we
we
definitely
would
like
to
get
like
once
we
have
a
more
concrete
proposal,
that's
what
the
criteria
for
that
will
be.
We
will
definitely
get
back
to
sick
architecture
and
sig
release
and
whatever
other
six,
you
believe
should
be
involved
in
like
approving
that
decision.
E
A
Okay,
thanks
for
that
white
tech,
so
I'll
first
start
off
by
addressing
to
steering
or
does
anyone
have
any
questions
in
particular
for
voy
tech,
dibs.
C
So
one
thought
that
came
to
mind
while
I
was
reading
it
this
morning
was
we
need
to
somehow
involve
the
cncf
end
user
community
and
try
to
reach
out
to
the
oh,
the
people
outside
this
call.
C
Otherwise
the
usual
culprits
will
show
up
for
the
meetings
and
we
need
to
expand
our
outreach
to
make
sure
that
we
talk
to
people
outside
who
are
not
developers
who
are
more
yes,
operators,
more
product
people
who
who
run
this
in
their
own
companies.
So
we
I
would
like
some
verbiage
in
the
charter
for
it.
That
would
help,
I
think,
because
then
we
are
like
okay,
it
is
in
the
charter,
so
we
better
try
to
do
it.
C
I
I
don't
know
what
form
it
should
take,
but
we
can
try
out
a
few
things.
I
think
so.
That
was
one
thing.
The
other
one
was
the
working
group
itself.
You
know
the
the
only
previous
special
superpower
that
we
have
is
with
the
scalability
sig.
Where
us
this.
The
sig
is
interested
to
revert
back
stuff
right,
especially
in
the
european
time
zone.
When
the
west
coast
is
asleep,
we
should
be
able
to
turn
things
back.
C
So
that
is
the
only
superpower
we
have
so
far
as
a
president.
Here
we
are
we
need
to.
When
we
are
talking
about
it,
we
need
to
figure
out.
What
does
this
mean
in
terms
of
like?
Are
we
stopping
things
from
going
from
one
you
know
alpha
to
beta?
Are
we
talking
about
like
being
able
to
leave
the
features
switched
off?
C
So
what
are
the
possible
places
where
we
could
use
this
super
special
powers
that
you're
asking
for
that
would
be
one
the
other
one
would
be
the
working
group.
Does
it
recommend
to
sig
architecture
and
sig
release
and
basically
who's
going
to
what
is
the
communications
and
who's
going
to
actually
stop
things
from
happening
like
is
there
enhancements
that
needs
to
be
kicked
out
from
a
milestone
which
is
sig
release?
If
it
is,
you
know
similar
to
that,
like
which
subproject
of
cigar
needs
to
be
involved
that
kind
of
stuff?
C
So
we
need
to
think
that
through
that
a
little
bit
more,
but
I
don't
think
we
need
to
do
it
at
the
charter
right
now.
The
charter
right
now
as
it
is
is,
is
perfectly
fine,
but
I
think
we
need
to
hash
it
out
a
little
bit
in
the
initial
calls
when
we
get
this
going.
E
Yeah
sorry,
I
absolutely
agree
with
that.
I
mean
like
the
final
proposal
that
we
need
before
we
will
be
able
to
block
anything,
definitely
needs
to
address
things
like
under
what
conditions
we
can
do,
what
what
exactly
we
can
do,
whether
it's
it's
kicking,
an
enhancement
from
the
release
or
whether
it's
blocking
individual,
pr's
or
potentially
other
other
ideas.
E
I
think
that
this
all
needs
to
be
fleshed
out,
and
I
I
like
I
have
something
in
my
mind
but
like
it
needs
to
be
discussed
like
in
much
wider
groups
before
we
will
be
able
to.
E
I,
I
didn't
want
to
block
the
creating
the
charter
based
on
that,
because
I
think
it's
I
don't
want
to
block
creating
like
starting
the
the
group
from
doing
something
useful
in
the
meantime.
But
yes,
I
guess
it
will
take
at
least
a
couple
weeks
to
figure
out
something
more
specific
and
something
that
can
actually
be
approved
by
by
others.
A
G
Yeah
a
couple
questions
if
it's
okay,
boy,
tech,
so
one
thanks
for
putting
together
such
a
concrete
proposal
to
dim's
comment
around
special
powers,
like
I
kind
of
view
this
document
as
basically
implying
a
future,
maybe
governance
update
to
sig
arch
itself
right
like
so
I
just
to
make
sure
I
understand.
G
Do
you
anticipate
the
work
group
dissolving
before
it
exercises
these
powers
and
then
just
a
sub-project
of
cig
arch
is
going
to
be
the
one
that's
actually
exercising
the
power
and
if
so,
maybe
tim's
or
john
or
myself
could
look
at
and
see
if
the
sig
arts
charter
needs
to
be
updated.
So
that
was
my
first
thought
on
that
and
then
the
second
question
was:
how
frequently
are
you
guys
is
everyone
intending
to
meet
in
in
the
working
group?
I
I
didn't.
E
I
think
I
think
it's
not
yet
anyway,
so
to
to
your
first
question:
we
we
we
are
also
considering
where
we
were
like
briefly
discussing
it
like
we
were
considering
making
like
production,
readiness,
subproject
of
cigarch,
to
be
to
be
the
the
one
who
will
be
exercising
the
power,
but
we
will
definitely
keep
you
in
the
loop
before
like
before.
We
actually
open
it
for
like
wider
approvement
approval.
I
think
there
are
multiple
options
still
on
the
table.
E
I
don't
want
to
like
make
a
decision
here,
because
it's
it
will
be
just
my
opinion.
So,
but
yes
like
definitely
we
want
like
full
sick
architecture
buying,
like,
I
guess,
all
of
three
at
least
all
three
of
you,
so
so
we,
you
will
definitely
be
in
the
loop
there
regarding
cadence
and
frequency
I
like
for
now
we
are.
We
will
be
starting
that,
like
there's.
No,
like
the
first
meeting
still
didn't
happen
like
we
are.
E
We
were
trying
to
do
it
but
like
we
are
still
waiting
for
all
results
and
stuff
like
that,
for
what
time
will
work
better,
but
what
we
are
initially
at
least
planning
is
like
every
every
one
hour,
bi-weekly
so
by
weekly
meetings
taking
one
hour
so
pretty
much
the
same
as
cigars,
for
example,
is
happening
now
we
will
like,
after
a
month
or
something
we
will
see
if
it's
enough
or
we
need
more
or
maybe
we
need
less,
which
I
doubt
at
least
initially.
But
yes,
we
will
be
adjusting
it
potentially
later.
B
To
just
add
on
to
what
tim
synderick
said
in
the
chat,
would
it
make
sense
to
split
the
special
power
thing
into
like
that?
The
working
group
will
have
us
might
have
a
special
power
to
block
features
in
the
future,
and
one
of
the
deliverables
would
be
to
figure
out
the
process
for
how
that
would
be
done.
E
A
A
Is
that
or
they're
actually
going
to
be
like
working
with
sub-project
owners
to
say,
like
hey?
No,
don't
merge
this
particular
thing
to
this
directory
and
kk
or
or
something
like
that.
A
Like
there's
some
there's,
I
think
there's
also
some
mechanical
details
around
blocking
merges,
because
I
don't
think
that
we've
necessarily
had
that
explicitly
as
a
lever
before
I
know
we've
in
previous,
we
have
like
it's
been
leveraged
to
block
releases
that,
like
hey,
this
thing
needs
to
be
done
before
we
will
actually
cut
a
release,
but
blocking
it
pre-contribution,
pre-merge
or
having
you
know
or
having
the
power
to
revert.
A
Is
it
similar
to
like
scalabilities
powers,
they're,
like
yeah
I'd,
be
interested
in
some
of
the
more
mechanical
details
as
well?
In
addition
to
the
criteria,
that's
all
that's
already
called
out.
E
Sure
so
we
well.
We
were
talking
a
little
bit
with
like
six
testing
folks
about
that
so,
but
I
think
it
was
back
then,
when
we
were
thinking
only
at
the
level
of
like
individual
prs
and
not
like
caps
or
features
themselves.
So
what
we
were
discussing
back,
then
it
was
actually
written
in
the
original
google
doc
before
I
opened
this
charter.
So
what
we
are
thinking
about
it
is
basically
extending
or
pretty
much
using
like
doing
that
at
the.
E
Sorry,
I
missed
the
word
so
basically
at
the
emerge,
bot
more
or
less
level,
basically
by
saying
that
only
prs
like
specifying
a
sigs
that
are
currently
blocked
in
some
way,
probably
in
some,
some
like
somewhere
in
some
config
of
pro
and
blocking
all
the
pr's
that
are
that
that
are
annotated
with
that
seek
and
like
kind.
That
is
not
like
test
test
fix
or
failing
test
or
flake
or
regression
like
basically
blocking
features
and
feature
or
oriented
pr's.
E
E
This
is
probably
this
proposal
is
like
and
it
seems
that
like
we
were
talking
with
like
and
with
sick
testing
folks,
and
it
doesn't
seem
to
be
much
work,
but
that
proposal
back
then
was
purely
oriented
on
like
blocking
prs,
and
we
may
also
consider
just
blocking
blocking,
for
example,
feature
graduation
and
not
the
cult
itself.
So
I
think
I
wouldn't.
I
wouldn't
take
what
I
said
as
something
that
we
we
actually
really
propose.
E
I
think
we
may
we
might
change
the
decision
to
to
be
kept
based
or
or
something
a
little
bit
different.
So
this
is
also
why
I
didn't
put
the
mechanics
anywhere
yet
because
I
realized
that,
like
blocking
prs,
may
not
be
the
final
decision.
A
Yeah
that
that
that
makes
sense,
I
think
we
should
probably
call
that
out
then,
like
that
you
know
just
adding
on
something
to
the
special
power
section
saying
like
these
things,
in
particular
like
the
mechanics
of
how
we
do.
This
has
not
been
decided
yet
just
so
that
it's
clear
that,
like
this
is
still
like
an
open
discussion,
because
I
could
see
that
particular
discussion
not
only
involving
cigar,
which
has
been
called
out,
but
also
testing
and
release
as
well.
H
Hey
so
so,
josh
had
a
question
in
the
chat
that
I
wanted
to
since
the
sig
release
chairs
are
here.
I
wanted
to
give
a
chance
to
address,
if
possible,.
C
Can
you
speak
it
out,
stephen,
so
for
the
recording
people
can't
see
the
chat
right?
No.
I
Okay,
yeah!
No,
I
just
wanted
one
of
the
recent
or
the
current
release
lead
to
speak
on
because.
H
Yeah,
so
I
would,
I
would
say,
from
from
the
perspective
of
like
large
sweeping
changes,
whether
it
be
like
some
of
the
issue
triage
stuff
that
recently
came
out.
We
tried
to
do
that
earlier
in
the
cycle,
or
we
try
to
coordinate
ideas
like
that
earlier
in
the
cycle
and
then
not
action
on
them
unless,
unless
they're
easy
to
do
and
not
crazily
wide
sweeping
this
is
this.
This
would
be
a
huge
change
and
I
wouldn't
expect
it
to
to
happen
until
at
least
1
21..
H
With
regards
to
blocking
merges,
we've
discussed
this
for
years
right.
We've,
we've
discussed
being
able
to
block
releases
on
things
like
this
for
years
and-
and
I
think
the
gates
that
we
currently
have
in
place
are
gates
that
are
human
gates
right.
I
would
be
really
curious,
and
I
know
that
they-
I
know
that
the
the
details
were
explicitly
left
out
of
the
proposal
I
think
partially,
because
we
don't
know
what
they
would
be
right
now,
we've
done.
H
We've
we've
had
this
discussion
so
many
times
throughout
the
community,
and
I
don't
think
we've
come
to
an
answer.
I
think
that
the
closest
thing
that
we
have
to
do
in
terms
of
blocking
merges
are
pre-submits
right,
like
that's,
that's,
that's
our
gate
right
now,
anything
that
anything
that
comes
into
kubernetes
kubernetes
as
a
result
of
a
as
a
result
of
an
enhancement,
a
cap
completion.
H
There
are
multiple
people
working
on
that
at
any
one
time
and
there's
no
guarantee
that
all
of
those
people
are
on
the
same
page
and
are
going
to
do
the
right
things.
So
we
have
to
have
the
machines
block
and
it
has
to
happen
at
pre-submit.
E
Yeah
go
forward
one
quick,
clarifying
question
to
stephen,
so
I
agree
with
what
you
said
basically,
but
do
you
have
any
specific
concerns
with
like
how
the
charters
currently
how
it
currently
looks
like,
or
is
it
like
more
comment
for
how
we
should
be
executing
on
that
later.
H
Oh
for
sure,
no
I
I
approve
the
charter
too.
I
I
believe
in
it
I
believe
in
it,
and
I
and
I
think
it
was
clever
to
explicitly
leave
out
details
for
the
implementation
that
was
going
to
block
formation
of
the
group.
We
testing
architecture,
this
group
and
release
all
have
to
get
together
and
figure
out
how
to
do
this,
because
it's
it's
not
easy.
We
haven't
solved
it
yet
so
sure.
C
Okay,
so
the
first
thing
that
I
wanted
to
say
was:
how
do
we
know
something
is
going
to
be
reliable
or
not
it's
like
only
after
we
check
it
check
it
in
merge
it,
and
then
we
figure
out.
Oh,
this
is
not
working
right
like,
and
then
we
realized,
oh,
my
god.
We
need
to
either
revert
or
switch
it
off
or
do
something
like
so
that
mechanism
itself.
I
think
you
know
I'll
be
interested
in
figuring
out
for
sure,
but
the
second
one
is
in
the
charter.
C
I
think
what
we
can
do
is
we
can
explicitly
say
that
how
and
where
we
apply
the
special
powers
is
still
under
discussion
and
will
be
they'll,
we'll
add
another
document
when
it
is
done
and
leave,
leave
it
like
that
right.
So
that
way
the
charter
can
go
ahead
and
then,
when
the
process
document
gets
returned,
then
we
can
get
explicit
sign
off
from
all
the
sigs
and
then
move
on
that
will
help
unblock
both.
E
Yeah,
from
my
perspective,
absolutely
regarding
your
first
comment.
I
think
it
doesn't
necessarily
mean
like
that.
We
will
be
blocking
a
particular
feature
because
we
believe
if
it's
it's,
it
may
be
unreliable,
but
it
may
also
mean
that,
like
other
features
that
are
already
there,
that
are
owned
by
biasic
aren't
reliable
enough
and
we
we.
E
I
agree
that
like
preventing,
like
checking
whether
like
a
new
feature,
will
be
reliable.
Enough
is
a
little
bit
more
more
harder,
but
I
think
we
can
do
that
with
like
proper
processes
too.
Things
like
each
feature
have
an
slo,
but,
like
I
don't
want
to
go
to
get
into
like
details.
C
E
Yeah,
I
I
think
we
we
need
a
reliable
like
reasonable
criteria.
I
don't
think
we
we
we
will
be.
We
should
be
able
to
say
something
from
like
two
years
ago
or
four
years
ago,
in
case
of
like
cron
jobs
is
not
reliable.
You
can't
merge
anything
now.
I
think
we
need
it
needs
to
be
something
like
if
your
very
very
old
feature
isn't
reliable.
E
C
So
we
would
help
by
quantifying
what
is
the
threshold
that
is
going
to
be
acceptable
for
the
work
that
the
city
is
going
to
do.
Okay,.
A
Okay,
so
I'm
going
to
put
a
time
box
on
this-
maybe
like
eight
more
minutes
of
discussion
today,
because
there
is
one
other
item
that
I'd
like
to
make
sure
we
have
time,
for
it,
looks
like
aaron
and
then
derek.
F
Hey
you
get
to
talk
not
as
a
steering
member
for
the
first
time,
so
I
just
I
agree
with
most
of
this
charter,
except
for
the
special
powers
thing.
I
I
guess
I
bristle
at
the
fact
that
this
has
been
raised
a
number
of
times
before
the
desire
to
block
things.
We've
never
done
it.
I
feel
like
this
is
a
more
specific
case
of
we
want
to
force
the
project
to
pay
down
tech
debt,
and
we
need
to
find
a
way
to
incentivize
people
to
do
that.
F
I'm
not
sure
if
this
is
the
appropriate
way-
and
I
also
question
like
why
is
it
that
reliability
is
the
thing
that
gets
to
block
stuff
like?
Why
isn't
it
security
issues
right
like?
Why,
wouldn't
we
say
we're
not
going
to
contribute
anything
else
until
we've
cleaned
up
the
results
of
the
security
audit
or
test
flakiness
or
whatever
right?
F
So
I-
and
I
don't
want
to
like-
have
that
block
the
idea
that
we
as
a
project
want
to
start
focusing
on
reliability,
and
there
are
a
lot
of
things
that
we
can
add
to
the
project
to
do
this,
but
I
feel
like
the
conversation
around,
how
do
we
focus
as
a
project
shouldn't
be
about
a
superpower,
so
I
kind
of
am
more
interested
in
how
we
can
help
sig
release
kind
of
ship
focused
releases
or
we
can
focus
our
contributions
there
yeah.
I
guess
that's
all.
I
had
to
say.
A
Thanks
aaron
derek.
G
Actually
aaron,
I
really
like
how
you
captured
that,
and
so
I
think,
a
lot
of
the
charter.
I
like
around
documenting
what
it
means
to
be
reliable
and
measuring
our
present
reliability.
I
think
you'll
have
to
reflect
a
little
bit
on
what
aaron
noted
for
jumping
right
to
the
the
carrot
and
stick
is
the
right
outcome
or
not,
but
I
guess
we
can
iterate
on
that.
The
question
I
just
want
to
ask
clarify
on
is:
what's
the
intended
scope
of
the
working
group?
G
Is
it
covering
that
which
is
covered
in
cube
conformance,
or
are
you
intending
to
measure
reliability
across
every
sub-project
in
the
sigs
that
may
or
may
not
be
within
what
we
might
think
of,
as
as
conformance
I?
I
read
this
as
you're,
focusing
on
reliability
of
that
which
is
exposed
in
a
cube,
conformance
suite,
but
I
want
to
make
sure
that
that
was
an
accurate
understanding.
E
G
Potentially
like,
if
you
do
intend
to
have
a
stick
right,
oftentimes,
it's
because
pockets
of
interest
within
cigs
that
can
get
motivated
by
particular
subprojects
that
might
be
outside
of
the
scope
of
what
you
were
trying
to
measure
and
to
some
degree
you're
trying
to
shift
attention
away
from
that.
And
so,
when
we
talked
about
like
great
merge
right
powers,
it's
not
meaningful.
If
you
can
still
merge
in
other
sub
projects
within
your
sig
and
you're,
just
kind
of
blocking
merging
in
the
kk
repo
or
something
like
that.
So
details
work
out
but
yeah.
G
If
you
can
just
add
some
language
that
says
where
you'd
focus.
I
think
that's
a
great
first
start.
E
Yeah,
I
think
jordan
just
mentioned
me
offline,
that
there
are
better
features
that
actually
destabilize,
kubernetes
and
beta
features
are
enabled
by
default.
So
maybe
we
don't
want
to
make
it
like
only
conformance
yeah.
We
probably
need
to
discuss
that
a
little
bit
more.
G
Yeah,
I'm
thinking
even
like
things
like
I
don't
know,
six
scheduling
has
a
scheduler
component
right.
Are
you
intending
to
measure
the
reliability
that
I
I
doubt
it
right?
I
don't.
I
don't
think
performance
is
a
first
priority
and
so
just
kind
of
like
clarifying
them
your
order.
But
then,
if
the
outcome
was
that
a
great
superpower
is
going
to
be
developed
to
prevent
sig
scheduling
from
checking
into
the
scheduler
but
still
merge
into
the
d
scheduler,
I
doubted
that
as
well,
but
either
way
just
focusing
on.
A
So
one
question
that
I'd
like
to
throw
out
there
directed
towards
steering
members.
We've
had
a
lot
of
discussion.
That's
focused
on
the
you
know
the
special
powers
to
block
merges
outside
of
that
section,
which
obviously
needs
some
some
refinement.
A
Is
there
any
other
questions
or
comments
or
concerns
about
other
parts
of
the
charter?
In
particular,
I'm
looking
at
scoping
and
stakeholders
and.
A
Sign:
okay
got
about
two
minutes
left.
If
there's
any
other
questions
or
comments
that
anyone.
A
A
Okay,
great,
thank
you
so
much
wojtek
for
attending
appreciate
that
we
can
take
those
refinements
back
to
the
pr
and
if
everything
looks
good
at
that
point,
then
we
can
call
about
to
to
look.
C
At
merging
dim
christophe,
do
you
want
to
summarize
what
you
would
like
wytek
to
do
to
the
rock.
A
Yeah,
so
my
under
my
understanding
is
there's
going
to
be
particular
revisement
around
the
special
power
section.
Looking
towards
noting
that,
like
mechanics,
have
not
been
decided
that
specific
mechanics
will
probably
need
to
be
worked
out
with
testing
and
release
we're
also,
it
looks
like
there's
still
an
open
discussion
point
around
conformance
and
what
what
the
scope
is
of
like
what
types
of
reliability
will
actually
block
merging
if
it's
only
conformance
if
it's
something
outside
of
conformance,
but
I
think
those
are
like
the
key.
A
Okay,
great,
thank
you
so
much
for
watching.
So
we
have
one
last
issue
that
we're
going
to
discuss
today
looks
like
term
limits
for
steering
committee
members
nikita.
B
Yeah,
so
just
for
record
paris
worked
on
it,
a
lot
more
which
she
had
to
drop
off,
so
I'm
just
gonna
walk
through
the
pr.
So
the
pr
just
have
the
link
in
the
chat
documents
term
limits
for
the
steering
committee.
We
have
discussed
this
pr
in
one
of
the
previous
steering
committee
meetings
and
we
came
to
the
conclusion
that
what's
written
as
is
looks
good,
but
we
also
wanted
to
add
a
few
additional
things
so
right
now
steering
commit
so
like.
As
per
the
pr
steering
committee.
B
Members
would
cancel
only
two
consecutive
two-year
terms,
so
in
total
they
could
serve
two
consecutive
terms
for
four
years
and
a
lifetime
of
four
terms.
So,
like
a
lifetime
of
eight
years
on
the
steering
committee,
we
will
not
be
considering
the
bootstrap
committees
and
the
initial
election
that
took
place
which
nominated
folks,
which
electric
forces
for
one
year
I
think
and
terms
that
result
in
equal
to
a
less
than
one
year.
So
this
could
be
due
to
changes
in
company
or,
like
someone
decides
to
step
down
or
for
whatever
reason.
B
A
Think
so
we
had
had
a
number
of
discussions
about
this
in
the
the
last
term
of
steering
committee,
and
we
had
decided
that
this
is.
This
is
probably
a
a
good
fair
bar
to
set,
but
that
we
should
probably
wait
until
post
election
before
putting
it
in.
A
I
think
that
again,
as
we've,
just
like
we've
just
brought
in
three
new
string
committee
members,
I
think
we
should
probably
not
vote
on
this
today,
but
I
think
we
should
probably
add
this
to
our
our
next
meeting
agenda
to
actually
review
and
potentially
vote
on
once
the
new
members
have
had
a
chance
to
to
kind
of
review
it.
I
think
that
the
my
opinion,
which
I've
stated
before
but
I'll
just
say
it
again
to
kind
of
get
any
conversation
rolling
on
this.
A
The
the
bar
that
we've
set
is
is
kind
of
a
mix
of
like
not
wanting
to
like
basically
wanting
to
give
an
opportunity
for
people
to
fairly
serve
terms,
but
also
allow
the
project
to
set
itself
up,
for
you
know
healthy
succession
and
being
able
to
kind
of
pass
the
baton
around
to
different
different
folks.
A
So
we
have
different
voices
and
different
representation
kind
of
like
at
that
highest
level
of
you
know,
office
for
for
the
kubernetes
project,
just
to
ensure
that
we
don't
get
stagnant
and
people
don't
burn
out.
A
You
know
if
you
know
okay,
this
is
this
is
the
limit
of
what
I
can
do
and
I
need
to
you
know,
set
set
something
up
that
in
such
a
way
that
you
know
the
decisions
that
we
make
as
a
steering
committee
can
have
traction
not
only
with
the
folks
in
the
seats
who
made
the
decisions,
but
that
those
decisions
can
kind
of
like
hold
over
time
and
that
the
project
can
change
directions
if
it
needs
to
at
some
point
in
the
future.
A
F
Yeah,
I
don't
know
if
you
want
to
do
this
after
having
served
two
consecutive
terms,
I
think
you
really
need
the
time
off
for
what
it's
worth
this
this
was.
This
was
part
of
what
factored
into
my
decision
to
move
on,
because
I
just
believe,
like
service
rotation
is
extremely
healthy
for
the
community.
It's
really
healthy
for
the
individual.
G
A
A
Okay,
if
there's
no
other
comments
that
brings
us
to
the
end
of
our
scheduled
agenda.
I
would
like
to
call
out
once
again
thank
you
to
all
the
steering
committee
candidates.
Congratulations
to
the
three
folks
that
were
elected
and
an
extra
special
thank
you
to
aaron
and
lucky.
A
Thank
you
so
much
for
your
your.
You
know
your
service
on
this
project.
It's
it's
been
amazing,
working
with
everyone,
and
you
know,
especially
like
I,
I
like
to
call
it
lockheed
who,
who
stepped
in
mid-term
to
to
to
fill
a
fill
a
gap
in
our
governance.