►
From YouTube: Steering Committee 20181107
Description
Notes: http://bit.ly/k8s-steering-wd
Chat transcript (times may be off):
00:18:52 briangrant: https://github.com/kubernetes/steering/issues/31
00:27:54 Aaron of SIG Beard: https://docs.google.com/document/d/1qazwMIHGeF3iUh5xMJIJ6PDr-S3bNkT8tNLRkSiOkOU/edit# - agenda
00:45:55 Sarah Novotny: Apologies all. I need to drop. As penance, feel free to assign me things.
00:59:20 Timothy St. Clair: pinging on gluster issue.
00:59:40 Dims: Tim, see https://github.com/heketi/heketi/issues/1279
A
A
A
A
A
A
A
A
A
D
F
G
A
A
E
D
Yeah,
and
so
in
terms
of
upcoming
meetings,
they're
gonna
be
interleaved
with
the
to
keep
cons.
Is
there
anything
specific?
We
want
to
do
in
preparation
for
those
events
or-
and
we
have
the
contributor
summit
at
Seattle.
I
took
a
look
at
the
agenda.
Yesterday,
ish
looked
pretty
reasonable
with
parallel
current
contributor
and
new
contributor
tracks.
A
E
E
A
A
E
E
I'd
like
to
run
us
through
our
a
eyes
from
last
time
in
our
project
board
and
then
the
time
remaining.
We
could
talk
about
like
what
we
want
to
have
prepped
for
that
that
December
5th
meeting
and
maybe
start
thinking
about
in
person
itself
sound
good
to
everybody.
Okay,
cool
I
have
like
a
billion
windows
here.
So
give
me
a
second
before
I
find
a
phone.
E
Please
go
for
it
so
posting
us
through
they
as
a
top,
but
just
since
I'm
on
the
first
two
I.
Don't
have
any
next
steps:
Risa
projects,
it's
I,
need
to
go
and
talk
to
Steven,
Augustus
or
somebody
and
talk
to
sake,
contributing
experience
about
how
to
best
like
denote
sub
project
owners
with
friendly
human
consumable
contact
info.
E
We
are
all
agreed
that
some
projects
definitely
have
to
have
owners
files,
because
projects
represent
the
ownership
of
resources,
be
that
code
are
documents
that
describe
process,
but
people
don't
like
digging
through
owner's
files
to
figure
out
who
they
need
to
contact,
I,
think
anybody
who's
been
through
Sega
Architecture
and
had
a
discussion
of
their
some
projects
recently.
Can
sympathize
with
that.
So
I
will
attempt
to
work
on
that
they're,
probably
not
in
the
next
week
by
December
5th.
They
should
have
something
there
same
thing
with
moving
sync
role:
stuff
into
the
other
governance
doc.
E
There
were
two
Doc's
and
Kay
community
called
cig
governance,
and
one
of
them
seemed
to
be
more
about
the
logistics
of.
How
do
you
create
a
cig
as
a
contributor
experienced
person
like
what
are
all
the
mailing
lists
and
channels
and
people
you
have
to
have
the
other
one
was
more
like
roles
and
responsibilities.
E
C
All
may
take
over
yeah
all
right
cool
since
I
actually
have
the
next
two.
Both
sig
asier
and
sig
windows
now
have
charters
merged,
so
yeah.
A
Some
feedback
I
think
that's
been
addressed.
You
know
by
end
a
week,
I'll
try
and
do
another
turn
review
on
that
and
I
think.
If
it's
addressed
I'll
just
merge,
it
I
think
there
is
a
there's,
a
sort
of
point
of
order.
Around
sort
of
I
thought
it
was
fair
just
to
give
everybody
sort
of
a
last
call
on
the
email
list
on
this
and
I
think
that
probably
brought
air
in
what
is
the
process
that
we
want
to
do
in
terms
of
getting
these
things
merged
I
was.
E
Yeah
that
wasn't
in
response
to
that
I
really
appreciate
the
last
call
and
actually
Brendon
the
windows
Charter
merged
without
anybody
from
steering
committee
at
really
having
reviewed
it,
except
for
yourself.
Oh
that's,
right,
I
feel,
like
somebody
totally
forgot
to
like
follow
up
on
that.
I
commented
on
the
PR
art,
but
I
feel
like
whoever
signed
up
to
review.
That
charter
needs
to
actually
go
and
make
sure
it's
okay,
yeah
I
mean
it's
literally.
E
C
A
E
A
G
E
D
I
mean
it
could
be
that
I
they're
just
starting
to
get
involved
in
the
community
as
well,
so
they
may
not
be
super
familiar
with
what
happens,
we're
and
they
have
multiple
hats.
You
know
they're,
presumably
going
to
contribute
to
cluster
lifecycle,
also
so
yeah.
It
may
not
be
clear
to
them.
So
we
made
me
just
suggest
something:
I.
A
E
B
J
A
E
E
B
E
Lady
I
think
I
just
said
something
about
if
we
could
wind
it
down
in
the
event
of
inactivity,
I
don't
know
about
things
in
general,
you're
you're,
also
reminding
me
that
the
broader
question
of
merging
sake
cloud,
specific
SIG's
into
a
seed
cloud
provider,
was
a
fun
and
active
discussion.
During
the
most
recent
state
cloud
provider,
meeting
and
I
accidently
think
I
had
you
and
someone
else
we're
supposed
to
follow
up
on
that
I.
J
B
G
B
Of
integration
reasons
right,
there
is
code,
there
are
people
working.
There
are
owners,
files
and
stuff
like
that,
but
then
I
think
the
what
we
had
talked
about
at
the
beginning
was
when
we
set
up
the
cloud
provider,
we
said
that
we
we
can
fold
things
back
in,
for
example,
we
are
not
having
regular
meetings
in
the
signal
from
stack,
so
that
was
one
indicator
to
say
that
okay,
there
is
work
happening
both
in
the
cluster
provider
as
well
as
the
club.
It's
just
that
you're
not
having
any
regular
meetings
so.
G
E
That's
where
there
was
just
so
much
discussion
around
what
is
consolidation
mean
in
the
context
of
sig
cloud
provider?
Do
we
wants
a
cloud
provider
to
be
this
fat
sig
that
has
every
single
sub
project,
as
is
anything
to
do
with
a
cloud,
or
is
it
just
the
cloud
provider
repos
and
should
individual
cloud
sig
still
have
some
kind
of
ownership
of
all
of
their
sub
projects?
Sig
AWS
would
be
a
great
example,
since
it
has
things
like
the
application
load.
G
Like
I
think
some
projects,
or
even
some
groups,
can
have
multiple
repos
associated
with
it
like
bidi
M
does,
and
the
club
and
API
machinery
does
so,
if
you're
a
sub
project-
and
you
have
things
that
fall
underneath
an
umbrella
or
some
project,
it
seems
totally
reasonable
to
have
multiple
repos
associated
with
it.
So
AWS
sub
project
of
cloud
provider
sig
could
easily
have.
Although
some
projects
associate
with
in
cluster
lifecycle
has
been
an
example
of
a
sig
that
has
doesn't
have
any
problem
with
some
projecting
out
different.
A
Number
one
like
again:
there's
always
you
know
the
appeal
to
the
steering
committee
for
this
stuff.
You
know
number
two,
there's
nothing
to
prevent
that
state
from
writing
a
charter
that
says
well.
We
have
certain
special
type
of
sub
project
which
are
routes
on
projects
and
they
can
create
sub
sub
projects.
You
know
to
sort
of
empower
those
things
to
happen
right,
so
you
know
they.
You
know
there
might
be
a
special
sort
of
governance
model
that
makes
sense
for
the
for
the
cloud
providers
say
yeah.
D
B
One
more
wrinkle
here,
for
example,
is
the
cluster
provider
for
a
api
api
provider
for
OpenStack
is
under
the
cluster
lifecycle
sake.
So
that's
one
more,
you
know
wrinkle
here
so
yeah
I
I
would
definitely
go
for
a
workgroup,
sorry,
not
about
a
sub-project
in
cloud
provider
for
OpenStack
and
then
consolidated
the
repositories
there.
I
think
that
would
be
a
good
model.
Alright,.
E
I,
don't
think
we
need
to
rathole
on
it
here,
but
I
did
at
least
want
to
have
the
conversation
of
if
we're
cool
with
cloud
provider.
If,
as
part
of
this,
consolidation
needs
to
have
something
above
and
beyond
the
standard
template-
and
this
is
one
case
where
that
makes
sense,
Timms
and
possibly
myself
can
iterate
on
that.
B
G
D
H
So
it's
just
it's
a
different
model,
and
it's
there's
also
the
point
that
many
corporate
lawyers,
because
there's
no
there's
no
case
law
on
DCO,
are
very
leery
of
considering
DCO,
and
this
is
across
a
variety
of
companies.
So
there
is
work
being
done
by
the
new
platform
specialist
at
the
linux
foundation
or
platform
vp
or
whatever
the
heck
is
name
is
or
his
title
is
to
improve
the
CLA
and
CC
la
experience.
So
he
was,
he
said
he
should
have
a
demo
of
it
shortly
and
I
should
be
talking
to
him
tomorrow.
G
A
E
A
E
B
B
E
C
F
C
E
E
In
WG
governance
that
every
stakeholder
sig
needs
to
have
a
chair,
LG
TM,
and
the
majority
of
the
steering
committee
needs
to
that.
This
is
what
caused
me
to
bring
the
8
infra
working
group
proposal
to
the
steering
committee
two
weeks
ago
is
I
needed
to
get
a
majority
of
you
to
say
yes
and
I.
Think
when
we
left
it
was.
C
D
Used
to
be
very
unclear,
who
is
the
decider
right,
so
there
would
just
be
round
and
round
discussions
and,
depending
on
the
people
who
are
pursuing
it,
whether
they
gave
up
or
just
pushed
it
through
silently
like
was
basically
you
know,
pretty
arbitrary,
so
I
think
having
some
kind
of
process
as
we
learn
what's
important
and
what's
not
important
and
it's
good
for
now.
If
we
decide
well,
it's
not
worth
it
and
it's
going
the
way
we
want,
then
we
can
say
we're
it's
not
necessary
anymore
and
I.
Think
that's!
Okay.
D
H
D
I
think
right
now,
there's
still
enough
confusion
about
what
should
be
a
working
group
versus
what
should
be
a
sig
versus
whatever
that
it's
helpful
just
they
know
just
at
least
make
a
look
and
say
yeah.
This
makes
sense
this
working
group
or
no.
This
actually
should
just
be
a
sub
project
or
something
else
then.
G
E
G
C
D
C
D
D
E
Wanted
to
see
there
there
had
been
some
discussion
about
whether
or
not
we
wanted
working
groups
to
have
to
touch
SIG's
or
have
sig
chairs.
As
a
formal
point
of
contact,
it
seems
like
we
want
that
considering
we
say
that
the
affected
six
chairs
Mostel
GTMO
working
groups
charter,
so
there
was
a
desire
to
add
fields
for
a
working
group
to
say
like
what's
sakes,
they
are
related
to
or
touch
in
six
animals.
E
E
E
D
C
All
right
are
we
already
done
so?
The
issue
stays
open
is
the
consensus
that
I'm
hearing
correct
yeah.
She
stays
open
and
I'm
updating
the
description
to
target
and
stays
in
progress,
not
blocked.
Yeah,
okay,
Aaron
codify
steering
committee
leaves
answer
SIG's
into
SIG's
IMO
assume,
that's
still
ongoing
charters,
Mehta
issue
still
ongoing
we're
getting
closer
I
guess
I
know:
do
we
have
a
list
of
the
charters
that
haven't
merged
I?
Guess
we
can
look,
commit
yeah.
D
It's
in
it's
in
the
middle
I,
just
I,
just
added
a
link
to
the
sig
apps
charter,
which
I'm
gonna
look
at
I
poked,
the
sig,
the
other
SIG's,
that
my
name
is
attached
to
GCP
and
hni
machinery
and
docks
need
to
remember
whether
they
responded
none
of
them
ever
lee
started
yet
GCP
might
get
folded
into
cloud
providers.
So
that's
what
they're
currently
thinking
about.
C
D
C
C
E
D
B
There
was
one
thing:
I,
don't
remember
where
I
saw
quintel's
comment
was
about.
When
do
you
escalate
from
the
sub
projects?
To
you
know
the
the
the
sig
itself?
When
do
you
bring
stuff,
for
example,
if
we
have
trouble
in
the
gates
conformance
working
group,
then
what
is
the
escalation
process
for
bringing
it
back
to
you?
No
sig
architecture.
That
was
one
question,
I,
don't
think
we've
covered
in
the
Charter
yeah
I
mean
that's.
A
A
G
We
should
just
go
ahead
with
it.
Well,
that's
exactly
what
we
do
in
in
cluster
lifecycle.
Just
make
sure
that,
like
the
leads
of
the
product,
there's
enough
lead
to
the
project
that
there
isn't
a
block,
a
block,
vote
right.
So
that
way,
it's
spread
it
out
across
enough,
so
that
the
leads
of
the
of
the
sig
I'm,
sorry
have.
The
ability
to
sort
of
you
know
have
have
some
back
and
forth
to
help.
You
know,
keep
each
other
honest,
otherwise,.
D
We're
we're
bottleneck
right
now
is
just
ramping
up
more
people
who
are
willing
and
have
time
it
can
make
time
to
do
the
work.
So
that's
what
we're
trying
to
do
right
now,
like
just
on
the
conformance
effort,
for
example,
trying
to
get
people
to
join
the
conformance
working
group
mailing
lists.
You
know
it's
very,
very
low
traffic
or
once
a
month
meeting,
you
know
and
just
start
working
on
the
stuff
there.
So
that's
that's
where
our
effort
is
currently
at
it's
sig
is
just
behind
many
other
SIG's
in
terms
of
functioning.
A
The
I
mean
this
discussion
is
making
me
think,
like
we
have
this.
We
have
this
general
idea
around
modified
lazy
consensus
for
decision-making.
Do
we
need
another
sort
of
principle
around?
You
know
optimistic
unstated
process
like
don't
create
process
unless
we
actually
have
a
concrete
need
for
it
assume
that
people
are
gonna,
be
rational
and
created
on-demand
I'm,
just
I'm
gonna,
throw
that
on
the
pile.
Let's
not
talk
about
it
now,
but
I
think
yeah.
D
E
E
A
E
A
Think
it's
part
of
our
Q&A
would
be
really
good
to
review
with
everybody.
The
difference
between
working
groups,
committees
and
SIG's
concerns,
because
I
mean
we
can
write
stuff
until
we're
blue
in
the
face
people,
don't
read
it
and
so
I
think
just
starting
to
see
it.
A
lot
of
people
is
sort
of
how
we're
modeling
this
stuff
might
be.
This
way.
C
E
C
D
C
It
says
it
looks
like
DIMMs
has
some
comments
about
slack
channels,
that's
it
and
then
so
deems
it
looks
like
he.
Maybe
he
took
another
shot
at
it
that
that
George
took
another
shot
at
it
after
you
comment,
so
can
you
check
okay
I'll?
Do
that
he
didn't
ping.
The
conversation
so
I'm,
not
sure,
but
I
see
another
push.
That's
there.
He.
C
D
By
the
way
we
have
sunset
some
cigs
and
working
groups
before
one
of
the
issues
that
did
come
up
is
people
who
wanted
to
go.
Look
at
what
happened
in
that
sig
had
trouble
doing
so.
If
materials
were
shared
just
with
the
sig,
you
know,
and
the
workgroup
was
shut
down
so
is
no
longer
possible
to
join
the
group.
So
we
may
want
to
just
make
some
kind
of
comment
about
how
to
properly
archived
a
stager
working
group,
the
mailing
list
and
documents,
and
whatever
other
artifacts
that
aren't
in
github
god.
C
C
E
I
had
down
there
is
that
there's
some
minor
differences,
there's
a
matter
of
vetting
whether
all
the
docs
are
in
the
right
places
and
agreeing
on
what
those
right
places
are.
We
got
pushback
from
somebody
in
one
of
the
repos
that
said,
stop
cluttering
up
my
root
directory
with
these
Doc's.
They
shouldn't
be
here:
I
want
them
someplace,
so
they
so
people
can
see
more
of
the
readme
right.
It's
pushing
the
readme
below
the
fold
and
that
has
kind
of
deadlocked
us.
Do
we
care
if
the
docs
are
not
in
the
root
place?
E
Do
you
want
to
go
pay
the
cost
of
updating
the
automation
to
check
a
couple
different
places
instead
of
just
route,
Ryan
is
needed
if
he
is
talking
about
this
repo.
C
C
C
E
C
E
D
E
I
think
it
was.
This
is
the
typical.
Does
the
steering
committee
have
a
policy
decision
here
if
every
repo
is
supposed
to
look
like
the
kubernetes
template
project,
that
repo
has
all
of
these
wonderful
files
living
in
its
root,
not
inside
of
a
directory
called
github
or
whatever?
But
if
you
scroll
further
up
in
this
issue,
monopole
is
saying
that
there
is
precedent
within
github
for
these
files
to
live
somewhere
other
than
root,
and
could
we
please
be
okay
with
that.
E
D
C
A
C
Right,
moving
on
versus
CLA
discussion,
I
think
we've
closed
this
and
we'd
not
closed
this.
Can
we
just
close
this?
They.
B
D
C
A
C
C
C
E
I
B
D
B
One
thing
that
is
bothered
me
was
the
Hecate
e-license
HEK
ETI
and
I'm,
trying
to
push
those
people
to
realize
since
some
of
the
files
they
have.
They
do
not
have
the
she
license
anymore
for
some
files
by
mistake,
they
were
realized.
They
were
trying
to
do
Apache,
plus
LGPL,
and
when
they
were
doing
that
mechanical
change,
they
left
some
files
with
just
LGPL,
which
we
end
up
pulling.
So
is
that
kind
of
thing
that
would
it
make
us
stop
our
release
so.
A
A
A
A
A
G
A
A
B
A
B
Been
poking
them,
Nikita
has
been
poking
them
and
somebody
else
from
Google
has
been
poking
them
too,
but
then
okay,
thank
you.
The
other
related
news
is
Stephan.
Augustus
is
any
going
to
enable
the
FOS
si
things
sometime
soon,
I,
don't
know
exactly
when
I'll
find
out
and
let
you
guys,
let
you
all
know
so-
is
this
gonna
be.
D
And
the
problem
we've
had
in
the
past
is
that
we,
you
know
firefight
these
license
issues
and
then
they
crop
up
again
and
yeah
in
general.
We
need
an
owner
for
this
to
continue
oversight.
I,
don't
know
if
we
want
to
post
you're
the
owner,
Tim's,
good,
okay,
and
so
the
LF
is
also
or
seen.
Cf
is
offering
to
do
a
security
audit,
so
we
need
someone
an
owner
to
engage
with
them.
I
think
that's!
D
B
A
C
C
D
C
Okay,
well,
maybe
we
just
put
maybe
just
on
people
gonna
suggest
people
on
steering
private
if
they
have
people
they
want
to
suggest,
and
then,
if
there's
more
than
one
or
if
somebody
objects,
we
can
not
nominate
them
sure,
like
lazy
consensus
effectively
and
if
there's
more
than
two
then
we'll
have
a
vote
but
hired
more
than
two.
What.
A
C
A
It's
weird
because
I
think
you
know
the
folks
that
show
leadership
inside
of
a
kubernetes
project
who
are
doing
good
work.
You
know
number
one
is
if
we
want
them
to
keep
using
their
time
to
do
that,
and
then
the
second
thing
being
is
that
it's,
the
TOC
is
gonna,
be
a
little
bit
of
a
different
type
of
work
than
yeah.
C
D
And
so
right
now
on
the
composition
of
the
TOC,
there
are
effectively
two
people
with
an
end-user
background,
Camille
and
Sam.
Only
one
really
with
a
project
background-
and
that's
me
Jonathan,
you
can
argue
but
I
mean
he
hasn't
been
that
involved
and
then
some
you
know
other
people
from
companies
in
the
cloud
native
space.
So
I
don't
know
who
the
new
candidates
are.