►
From YouTube: Kubernetes SIG Architecture Community Meeting 10-12-2017
Description
A
All
right
all
right,
welcome
to
cig
architecture,
community
meeting
for
Thursday
October,
12th
2017
I-
am
your
host
co-lead
of
this
cig,
chasing
your
doom
arms,
and
if
you
want
to
follow
along
after
the
fact,
we
have
the
agenda
available
for
your
perusal
at
bit.
Dolly's
sake,
architecture
and
I
encourage
you
to
sign
into
the
document
now,
if
you're
attending,
which
I'm
doing
myself
and
let
people
know
that
you
are
attending,
we
don't
have
much
of
an
agenda
today.
A
A
Essentially
this
is
the
implementation
arm
of
the
cap.
It
reinforces
the
governance
model
down
around
SIG's
being
the
keepers
of
their
own
features,
documentation
backlog,
but
it
does
provide
critical
oversight
for
product
management
architecture,
another
program
level,
six
and
essentially
there's
a
planning
event
that
is
attended
by
a
support
role
that
we're
going
to
create
for
each
sake.
It's
called
a
product
owner
anybody
familiar
with
agile,
probably
knows
about
product
owners
and
that
it's
a
way
to
sort
of
provide
team
level
access
to
the
customer
voice.
A
So
product
owners
are
a
sort
of
a
direct
delegate
from
the
product
management
and,
in
our
case,
they'll,
probably
say
architecture
as
well
and
help
sort
of
ensure
enlightenment
over
time,
with,
what's
being
done,
it
that
the
sort
of
team,
slash
weekly
monthly
level
and
the
long
term
arc
of
communities.
So
then,
so,
like
I
said,
it
creates
support
roles
instead
of
asking
SIG's
to
attend
product
manager
meetings,
because
that
is
a
has
been
a
notorious
waste
of
time
for
people
and
it
hasn't
actually
been
very
effective.
A
So
that
is
short
circuits
that
essentially
feature
freeze
is
not
a
thing
anymore.
It
really
happens
after
we
have
a
planning
event
that
occurs
during
the
code
freeze,
so
during
code
freeze
of
1/8
we
would
have
a
planning
session
for
1/9
and
that
would
probably
be
product
owners
and
sake
delegates
to
talk
about
what
they're
going
to
commit
to
what
overlaps
interdependencies.
A
But,
for
example,
if
somebody
comes
in
midway
through
the
cycle
and
didn't
do
planning
and
wants
to
just
put
something
in
as
far
as
a
cap
that
maybe
is
the
wings
and
not
implemented,
they
would
go
through
some
sort
of
exception
process
on
that
to
make
sure
that
that's
not
inhibiting
some
other
teams
work
or
whatever
it
is
so
essentially
a
feature
freeze
is,
is
sort
of
becomes
a
non-issue
because,
if
you're
not
if
you're,
not
planning
to
work
and
you're
not
implementing
work,
what
are
you
doing
that?
It's
not
a
good.
A
That's
not
a
good
pattern
for
us
to
follow
as
a
community
and
then
basically,
the
the
further
I.
Take
that
one
step
out
is
that
the
concept
of
features
and
features
repo
and
all
that
is
completely
deprecated.
We
don't.
We
don't
really
have
features
it's
it's
not
like
that
anymore.
We're
not
filling
in
giant
gaping
holes
in
terms
of
Qunu,
curb
in
a
nice
functionality,
we're
really
fine-tuning
and
honing
the
ecosystem
and
working
with
a
beautiful
set
of
primitives
that
we
have
in
place
that
that
provide
a
tremendous
amount
of
value.
A
So
our
role
and
architecture
is
to
continue
adding
value
from
an
architectural
perspective
and
make
sure
that,
when
we're
doing
planning
for
releases,
if
we're
going
to
deprecate
something
or
move
a
repo
that
that's
part
of
the
planning
process,
so
we
are,
we
have
become
first-class
citizens
in
what
has
traditionally
been
a
sort
of
feature
oriented
world
and
that
some
things
will
give
us
a
lot
of
leverage.
So
essentially
caps
describe
the
value
and
this
process
delivers
it.
So
that
is
the
that.
Is
it
in
a
nutshell.
Any
questions.
B
So
one
of
the
things
that
I'm
struggling
with
is
this
idea
of
product
ownership
in
an
open
source.
World
I,
don't
view
personally
kubernetes
as
a
product,
it's
a
project
it
doesn't
have
like,
and
so
there
are
places
and-
and
so
this
this
the
whole
idea
of
product
ownership
and
it
it
seems
like
it's
much
more
suited
to
a
top-down,
hierarchical
type
of
type
of
structure.
B
A
Totally
agree
in
that
that
actually
was
I
as
I
was
going
through.
This
process
I
had
a
little
bit
of
heartburn
around
the
the
product
owner
label,
because
really
what
it
is
is
is
basically
somebody
I
mean
it's:
it's
come
combining
like
the
scrum
master
rule,
so
somebody
helps
untangle
blocks
and
it's
somebody
who
is
sort
of
a
delegates
product,
the
product
management,
competency
and
it's
somebody
who's
basically
got
their
eye
partly
on
architecture.
So
it's
it,
but
in
the
end
I
mean
if
we're.
A
If
we
want
to
build
a
product
and
and
I
think
kubernetes
is
a
product.
Kubernetes
has
a
user
base
and
has
a
life
cycle
and
as
deprecations
and
as
policies,
it
has
a
governance
model
now
I
mean
essentially
we
want
to.
We
want
to
be
able
to
encapsulate
customer
voices
low-level
as
possible,
so
we're
not
building
like
the
Winchester
mansion
we
need
to.
We
need
to
be
focused
on
how
we
direct
our
efforts
and
companies.
A
You
know
like
ours,
I
mean
you
know
have
BIOS
is
well-funded,
but
you
guys
have
to
be
careful
about
how
you
invest
your
money
and
time
into
kubernetes.
I
mean
that's
a
really
big
deal
and
if
you're
busy
doing
something
that
you
do
a
bunch
of
PRS
for
and
it
wasn't
in
it
gets
dropped.
That's
that's
a
significant
impact
to
your
company
and
everybody
else's.
C
On
that's,
like
kind
of
echo,
Joe
yeah
OpenStack
had
product
manager,
Linux
does
not
have
product
managers.
Are
we
trying
to
be
more
like
OpenStack
in
how
we
approach
the
features
that
go
in
to
the
project,
or
are
we
trying
to
be
like
Linux,
where
there
is
a
general
given
give
a
tug
given
tug
or
given
push
and
pull
among
a
variety
of
interests?
C
A
I
think
that's
a
really
valid
concern.
So
let
me
let
me
address
it
as
I've
seen
it
first
of
all,
I
would
say
that
the
product
management
sake
and
the
activities
that
the
product
management,
sig
does
and
the
whole
features
repo,
and
all
that
stuff
is
the
worst
kind
of
incarnation
of
what
you
just
said.
A
I
feel
like
the
world
we're
living
in
right
now,
where
the
cigs
have
to
do
all
this
work
around
product
management
and
keep
things
updated
in
in
the
issue
and
then
there's
a
spreadsheet
and
all
that
I
understand
the
spirit
of
that
and
I
understand
why
you
know
people
have
wanted
to
do
that,
but
that
has
that
has
now
become
a
liability.
It
is
not
actually
helping
us,
it
is
andreas.
A
So
what
what
I
did
in
in
my
conception
around
this
was
to
not
throw
out
the
baby
with
the
bathwater
to
acknowledge
that
with
especially
with
pretty
much
everybody
matters
being
in
on
board
with
the
CNC
F.
This
has
a
tremendous
amount
of
I.
Don't
know
how
to
say
this
than
just
I
guess:
I'll
say
organizational
bias,
that
for
for
companies
to
want
to
invest
in
this
and
continue
investing
in
it
and
supporting
it
that
there
has
to
be
some
tiny
semblance
of
something
that
they
understand
and
the
ER
and
the
organizational
model
around
it.
A
So
what
I'm?
What
I
tried
to
do
is
think
of
ways
that
we
can
empower
six
through
support
roles
and
not
try
and
make
sakes
be
accountable
to
anybody.
So
basically,
this
is
distributing
the
product,
the
product
management
directly
to
the
SIG's
and
saying
we're
not
just
going
to
throw
you
to
the
wolves
and
say
now
you
have
to
manage
your
own
backlog.
You
have
to
untangle
your
own
dependencies
across
SIG's.
You
have
to
figure
out
how
to
get
cross.
Sig
visibility
yourself.
It's
not
anything!
That's
like
we're!
A
Gonna
we're
going
to
backstop
your
effort
by
trying
to
provide
a
role
to
you.
It
as
a
support
will
help.
Mit
is
not
there's
no
authority
in
it.
There's
no
control
in
it.
It's
simp
just
a
way
for
people
to
get
together
and
talk
about.
What
are
we
gonna
do
in
the
next
release?
How
do
we
ensure
that
there's
not
dependencies
cross
SIG's
that
are
gonna
p.m.
string
us
half
way
through
the
release,
so
we're
investing
a
bunch
of
money
and
wasted
coding,
time
and
product
time?
It's.
A
B
B
The
first
one
is
boundaries
we
needed
to
find
what
kubernetes
is
in,
isn't
and
give
clear
boundaries
in
a
way
to
actually
let
people
know
early
on
when
something
is
out
of
scope
for
kubernetes
and
then
there's
I
work
out
attractors
here
but
like
there
are
certain
things
and
priorities
that
we
want
to
actually
encourage
people
to
actually
invest
it.
We
can't
force
anybody
to
do
anything,
but
what
we
can
do
is
we
can
say:
hey
if
you're
gonna
be
working
on
this
you're
gonna
have
an
easier
time.
B
You're
gonna
get
more
priority
in
terms
of
people.
Reviewing
your
stuff
you're
gonna,
get
more
attention
right
and,
and
it's
it's
not
a
it's
more
of
a
carrot
than
a
than
a
stick
type
of
model,
and
then
the
third
one
is
communication,
and
that's
really
what
the
caps
are
about.
You
know
who's
doing
what
when
and
where
and
it's
gonna
be
messy
and
it's
going
to
be
slow,
but
that's
I
think
the
nature
of
open-source
versus
something
that
is
much
more
top-down.
B
Now
you
also,
you
talked
about
hefty
investment
in
in
in
kubernetes
and
I
and
I
want
to
I
want
to
draw
attention
to
like
when
we've
been
making
investments
in
the
kubernetes
ecosystem.
I.
Think,
like
a
lot
of
folks,
we've
been
as
much
as
possible
looking
to
make
investments
outside
of
the
kubernetes
/
kubernetes
right.
We
want
to
do
highly-leveraged
thing.
There's
we
know
it's
going
to
take
a
lot
longer.
B
I
think
the
best
thing
we
can
do
is
enable
people
to
actually
experiment
outside
of
outside
of
the
the
official
repo
here
one
example
here
is
in
and
I'm
torn
on.
This
also
is
that,
like
we've,
been
we've
been
talking
about
this
application
definition
stuff
through
six
CLI
and
there's
going
to
be
a
working
group
that
we're
son
Gayle
about
Brian
has
some
very,
very
specific
thoughts
of
their
and
and
he's
starting
to
prototype
and
sort
of
evangelize
those
thoughts
and
that's
great.
B
B
Think
we've
seen
that
similar
things
happen
with,
with
with
other
projects
that
have
started
more
on
the
periphery
and
have
become
more
and
more
of
a
part
of
the
ecosystem
over
time
and
in
my
mind,
that's
a
healthier
model
than
the
sort
of
like
top-down
hierarchical.
This
is
the
way
we're
gonna
solve
it
for
everybody.
We
really
have
to
embrace
the
bizarre
here
in
terms
of
you
know
letting
a
lot
of
projects.
B
Experiment
find
the
stuff
that
that
the
community
supports
and
then
and
then
adapting
what
works
instead
of
actually
trying
to
to
plan
this
stuff
out
from
the
from
the
get-go
and
so
again,
I
I'd
view
it
again
more
like
the
Linux
kernel
versus
versus
a
product,
and
then
finally,
you
mention
it.
Cn
CF
I
think
the
biggest
thing
like
there.
B
There
is
a
danger
from
all
of
the
attention
that
kubernetes
and
the
CN
CF
is
getting
in
terms
of
tons
and
tons
of
people
running
it,
for
resources
want
to
make
themselves
for
wanting
to
to
and
I
see
this
in
terms
of,
like
you
know,
people's
performance
reviews
actually
hinging
on
the
fact
that
they
need
to
be
a
cig
lead
or
you
know,
people
are
like.
If
I
can't
get
this
project
into
into
kubernetes
incubator,
then
you
know
then
I'm
gonna
miss
my
goals
for
the
quarter
right.
We
see
that
stuff
is
unhealthy.
B
I
think
the
best
thing
we
can
do
is
to
essentially
you
know
as
much
as
possible,
lock
down
what
kubernetes
is
and
try
and
say
no
to
that
stuff.
Now
this
is
I,
think
probably
a
larger
discussion
for
the
for
the
steering
committee,
but
but
with
respect
to
this
process
here
I
you
know
I.
My
gut
here
is
that
we
just
want
to
be
a
little
bit
more
sort
of
embrace
the
messiness
to
some
degree,
and
we
just
like
concentrate
on
communication
trial
showed
up
for
a
while
sorry,
I
was.
D
Just
gonna
say:
I
agree
with
you
a
lot
on
this,
because
you
know
I'll
just
go
back
to
an
example.
We
know
deployment
manager
used
to
be
part
of
kubernetes
and
helm
came
as
part
of
the
ecosystem
and
just
naturally
something
that
was
developed
out.
An
ecosystem
ended
up
becoming
the
model
that
ended
up
winning
and
that's
just
where
people
gravitated
we.
D
You
know,
there's
put
it
on
an
awesome
list,
I'm
sorry
that
doesn't
really
cut
it.
You
know
that
that's
the
advice
that
was
given
to
me
just
getting
on
an
awesome
list,
and
it's
gonna
be
that
then
people
know
it's
part
of
the
ecosystem.
It's
great!
That's
not
true.
We
need
a
way
to
kind
of
highlight,
what's
going
on
the
community
and
and
the
ecosystem
and
to
elevate
that
and
to
show
it
off,
and
we
don't
have
that
capacity
now,
which
kind
of
forces
everyone
as
they
get
it
in
in
a
kubernetes
org.
D
Then
it's
official
and-
and
you
do
that
through
incubation,
and
so
we
kind
of
need
to
round
out
some
of
this.
That
lets
the
messiness
happen,
and
then
we
can
see
what
rises
to
the
top
in
that
and
and
I
do
think.
It's
really
important
that
we
figure
out
what
is
kubernetes,
because
you
know
I've
talked
to
a
few
different
people
on
the
steering
committee
and
they've.
D
Given
me
different
opinions
on
what
kubernetes
is,
which
means
it's
really
hard
to
communicate
that
one
of
the
diagrams
that
I
created
said
you
know,
here's
core
and
then
here's
kubernetes
ecosystem,
verse,
other
and
I've
got
a
lot
of
pushback
on
this.
But
but
what
really
is
that
we
could
put
into
a
picture
that
we
can
convey
to
people
and
that
that
isn't
decided
now
I
realize
that's
more
for
the
steering
committee.
But
it's
it's
hard
to
build
a
process
to
embrace
the
messiness.
If
we
can't
even
decide
on
what
is
kubernetes.
E
We've
drifted
a
bit
from
the
earlier
point:
I
think
that
is
a
great
point.
Matt
and
I
was
just
talking
to
an
opus
at
contributor
at
mechana
rowdy
on
Tuesday
about
this.
That
OpenStack
really
did
a
great
job
about
a
lot
of
people
to
experiment,
but
that
rough
stack
came
far
too
late
to
allow
users
to
actually
know
what
OpenStack
was
and
have
workloads
be
portable
between
different
distributions
of
OpenStack
I
think
we
were
really
trying
to
nail
down
what
product
management
means,
and
you
know,
Jace
comes
from.
E
You
know
an
agile
background,
as
do
I,
and
so
this
means
you
know
what
service
are
you
providing
both
teams
and
the
users
of
what
your
team
produces
when
you
want
to
call
out
a
product
or
I?
Guess
I
would
call
this
a
program
I
think
it's
fine,
but
just
figuring
out
what?
But
what
we're
looking
for
in
terms
of
responsibilities,
I
think
maybe
in
important
before
we
talk
about,
we
forget
to
go
far
in
the
weeds
there,
yeah.
A
I
think
that's
think
you
killed.
That's
that's
yeah.
My
everything
it
was
said
after
I
mean
Matt's
comments
and
Joe's
comments
as
well,
then
those
are
not
in
any
way
mutually
exclusive
to
what
this
proposal
is,
in
fact,
they're
very
complementary.
The
thing
that,
if
the
thing
that
we
the
thing
that
if
we
commit
to
something
that
we
want
to
get
done,
the
worst
thing
we
can
do
is
just
hope
that
it's
going
to
get
done
and
have
no
know
any
kind
of
boundaries
about
tracking
it
or
understanding
it
or
whatnot.
A
A
So
there's
there's
things
that
have
to
happen
in
an
orderly
way
and
then
there's
things
that
I
want
to
see
all
sorts
of
scribbling
and
like
crazy
things
happening,
and
those
are
that
that's
the
ecosystem
outside
of
core,
and
so
the
what
we're
talking
about
is
trying
to
let
let's
make
the
things
that
we
need
to
count
on
count
honorable
and
let's
make
the
things
that
are
wild
and
fun
and
crazy
and
and
not
necessarily
so
accountable.
Those
should
continue
the
way
they
are
and
and
building
those
strong
competitors
on
the
the
periphery
anymore.
A
You
know
I
think
case
on
it
and
something
we
are
both
great
examples
of
that
I
mean
those
are
exactly
those
are
going
to
become
inseparable
from
from
ecosystem
just
like
alum.
So,
but
but
let
me
let
me
let
me
say
in
really
blunt
terms
here
that
we
are
at
a
huge
risk
point
right
now
with
the
way
product
management
is
happening
right
this
second,
so
it's
great
to
define
what
is
community?
Isn't
everybody
sing
Kumbaya
about
it,
but
while
that's
happening,
we
are
alienating
our
six.
A
We
are
creating
a
process
that
is
hard
for
contributors
to
follow
and,
frankly,
we're
wasting
a
lot
of
valuable
time
from
people
filling
out
things
that
aren't
delivering
any
value
that
are
making
this
product
and
project
and
everything
else
program
harder
to
deal
with
from
a
contributor
standpoint.
So
what
I'm
trying
to
say
is:
let's
stop
the
bleeding
we're
gonna
do
the
kept
process,
let's,
let's
take
the
kept
process
and
have
some
sort
of
way
of
translating
those
critical
pieces
of
value
that
we
define
into
actionable
things.
A
Let's
make
sure
that
we're
being
wise
about
how
we
do
that
and
not
doing
a
bunch
of
dependencies
and
and
just
ignoring
that,
there's
things
that
have
dependencies
on
other
things
when
we're
doing
planning
and
let's
try
and
commit
to
a
couple
things,
and
if
we
don't,
then
that's
great,
but
this
let's
give
it
a
shot.
Okay,
that
seems
reasonable
to
me.
So
a
couple
questions.
C
Just
so
sure
things
that
are
like
there's
many
things
we
have
to
nag
people
about
no
matter
what
so
yes
right
themselves
and
release
notes,
aren't
gonna
be
consistent
without
people
encouraging
and
enforcing
then
I.
Don't
think
the
answer
is
that
one
person
writes
all
the
release
notes
so
like
like
there's
the
cap
at
one
end.
C
A
Doable
not
if
this
is
done
right,
because
caps
translate
to
issues.
Issues
have
have
metadata
in
fields
like
a
template,
just
like
any
other
for
the
work
that
needs
to
get
done.
It
has
to
be
work
that
can
be
actually
actionable
and
then
to
set
that
up
as
a
template
that
can
be
scraped
should
be
trivial
and
I've
already
talked
to
everyone
about
this.
Even
okay,.
C
Maybe
maybe
maybe
I'm
just
overly
cynical
about
the
the
there's
kind
of
because
it
kept
like
there
are
hundreds
of
issues
that
go
into
every
kakou
brands.
Release
that
mostly
deserve
release,
notes
that
cross
that
line
that
aren't
caps,
and
so
that's
what
I
would
just
I'm
just
trying
to
tease
the
part
where
you
see
that
that
difference
in
we
have
to
document
every
API
change
and
that's
not
a
like
an
API
change
that
goes
out
that
bring
someone
that
we
drop.
A
E
E
You
know
as
new
enhancement
or
functionality
is
being
proposed,
and
so
I
think
I
would
like
to
see
a
process
where
you
that
the
kept
themselves
formed
a
lot
of
that
sourcing
material
for
the
draft
release,
notes
for
the
draft
blog
post
and
so
they're
working
with
the
occupation
team
to
make
that
actually
possible
rather
than
having
to
chase
I
mean
yes,
there's
always
gonna,
be
think.
That's
perhaps,
but
definitely
getting
most
or
much
of
the
documentation
done.
First
I
think
is
one
of
the
goals,
caps
least
from
me.
Yes,
okay,.
C
Yeah
I
mean
I,
see
it
as
a
60
60
65
percent
solution,
but
not
a
hundred
percent
solution,
so
I,
just
I
was
curious
as
to
how
you
guys
felt
that
that
overlap
was
because
I
lots
of
issues
that
would
never
get
a
cap
that
deserve
release
notes
and
vice
versa,
as
well
as
caps
that
the
release
notes
are
much
more
specialized
than
we're.
You
know
we're
adding
storage,
metros,
great
high
level,
the
actual
practical
usually
doesn't
emerge
until
the
very
end.
You
know
it's
not
a
it's,
not
a
waterfall
process.
C
A
C
Sig
p.m.
right,
it's
somebody
who
owns
like
who
owns
six
storage
and
like
the
act
of
assigning
and
owner
like
I,
have
some
I
may
not
concerns,
but
that
definitely
seems
like
a
area
where
we're
talking
about
things
that
we
were
concerned
about
for
sig
leads
right,
sig
leads,
being
arbiters
and
ultimate
deciders.
Does
a
product
owner
have
to
be
a
decider?
In
that
same
thing,
a.
A
Product
owner
is
only
given
as
much
power
to
make
decisions
or
what
not
as
the
sig
gives
them
I
mean
this.
This
is
the
thing
is
that
product
management,
this
this
is
a
blanket
statement.
There
may
be
examples
where
this
is
not
true.
In
my
opinion,
as
a
general
product
management
should
never
be
able
to
tell
us
they
to
do
anything.
A
Architecture
probably
can
because
there
there
are
things
the
guidelines
and
whatnot
the
that
should
be
done,
but
I
mean
sinks.
Sinks
should
be
the
masters
of
their
own
destiny,
so
a
product
owner
again
is
really
about
enabling
the
sig
to
do
the
work
they
need
to
do
so.
The
the
product
owner
should
be
in
communication
with
other
sakes.
A
C
I
mean
agile
I
mean
for
the
most
part.
Agile
is.
It
is
not
an
organic
process
that
emerges
from
open-source
projects.
It
is
a
process
that
these
my
somewhat
biased
you.
You
know
it's
used
effectively
in
companies.
I,
don't
I,
haven't
seen
a
lot
of
open-source
communities
that
work
in
the
agile
product
owner
sense,
because
the
product
owners
are
typically
the
people
who
are
very
motivated
to
set
the
direction
for
the
project
which
are
typically
like
I'm.
C
A
A
Think
that
it's
all
about
how
you
implement
it,
because
I've
seen
it
I've
seen
it
in
huge
projects
where,
essentially,
when
you
get
into
some
of
these,
these
companies
that
are
so
massive
that
they're,
they
all
sensibly
become
like
open
source
projects
where
there's
there's
teams
that
work
together
that
have
never
even
talked
to
each
other
like
there.
There
are
plenty
of
ways
in
which
that
can
be
can
be
used
as
an
information
point
in
the
process.
So
I
don't
want
to
just
again.
A
You
assume
that
it's
not
going
to
work
because
it
hasn't
like
there.
There
are
things
about
this
that
can
allow
it
to
work
extremely
well,
but,
let's,
let's
not
I,
didn't
want
to
be
dogmatic
about
anything.
What
I
want
to
say
is
we
have
a
need.
This
is
a
need
that
we
need
to
fix
here's
a
way
to
do
it.
That
is,
that
is,
nobody
else
seems
to
be
proposing
anything
about
how
to
get
us
out
as
current
bind.
So
I
feel
like
that.
B
B
As
it
wasn't
worth,
yeah
so
definitely
I
mean
like
it's
a
discussion
that
we
need
to
be
having
I,
don't
think
anybody
here
is
like
let's
stick
with
the
status
quo.
Okay,
I
think
I
think
it's
clear
that
that
we
need
to
find
ways
to
improve
this.
We
need
to
find
ways
to
make
the
process
less
frustrating,
more
transparent
and
more
effective,
so
I
think
I,
think
those
goals
are
all
aligned
and
so
yeah
I
mean.
A
I
appreciate
that,
thanks
and
if
I'm
frustrated,
it's
cuz
I,
sometimes
you
know
when
you
have
ideas
in
your
head
and
it's
so
hard,
sometimes
to
fully
articulate.
This
is
like.
Oh,
my
head's
gonna
explode,
but
I
I
might
ask
for
a
little
bit
of
trust
on
this
to
you
know,
have
my
own
my
own
experiment
with
this
a
little
bit
or
to
ask
for
help
to
try
and
find
a
way
to
experiment
with
this
I.
B
I
mean,
let
me
tell
you
sort
of
my
impressions
here,
and
this
isn't
fair
and
so
I'm,
just
like
I'm
gonna
profess,
preface
it
with
that.
The
sick
p.m.
meetings
have
been
at
a
time
where
I
can't
attend
them,
and
so
from
somebody
at
from
the
outside.
Who
can't
go
to
those
meetings?
What
it
feels
like
is
it's
a
bunch
of
folks
who've
been
assigned
by
big
companies
who
are
sitting
around
telling
the
rest
of
the
project.
What
to
do?
B
B
Conflict
I
may
have
a
skewed
impression
of
that,
but
I
think
you
know
in
terms
of
naming
in
terms
of
crafting
and
communicating
this
process,
making
sure
that
it
viewed
it
comes
across
as
a
way
of
like
how
do
we
actually
help
the
project
and
help
the
six
be
successful
versus
tell
them
what
to
do,
and
and
and
maybe
it's
as
simple
as
something
like
me,
me,
I,
don't
know.
Yeah.
A
No,
that's
the
you're
100%,
like
exactly
what
you
said
and,
and
the
thing
is
I
mean
I
want
to
be
careful
too,
because
the
people
who
are
in
sick
p.m.
the
people
who've
spent
a
lot
of
time
working
on
that
have
done
a
very
valuable
service,
and
this
is
the
thing
that
we're
I
feel
like
we're
at
this
tipping
point.
As
a
is
a
project
where
and
I
felt
it
at
the
sig
leadership
thing,
especially
like
there's
this
pivot
point,
that
has
to
happen,
it
happens
with
every
startup.
A
It
happens
with
every
growth
company,
where,
basically,
you
have
to
have
there's
some
line
you
cross,
where
you're
thinking
more
about
maintaining
than
you
are
building
like,
and
so
when
you're
in
more
of
a
maintenance
mode,
you're
thinking
about
sustainability.
How
do
you
create
things
that
are
enduring
and
lasting?
And
you
think
about
the
lifecycle
of
features
and
how
to
serve
your
community?
And
you
have
the
success
out
there.
I
feel
like
kubernetes
is
really
at
that
point.
So
a
lot
of
these
things
are
just
standard
growing
pains
about
you
know.
A
A
really
great
product
team
did
fantastic
things
for
one
three
and
one
four
one
five
and
then
maybe
a
little
less
in
one
six,
even
less
than
one
seven
and
one
eight,
it
actually
was
like
now
causing
strife
and
struggle.
So
it's
like,
let's,
let's
learn
from
that:
let's,
let's
mature
the
process
and
figure
out
how
to
move
forward
and
and
I
I
welcome
comments
on
this
document.
I
welcome
anybody
to
meet
with
me
privately
and
talk
about
it.
Let's,
let's
craft
it
hone
it,
but
I
do
believe
the
kernel.
B
A
No
and
I've
already
done
this
pitch
to
sig
p.m.
and
they
were
actually
very
receptive.
Then
nobody,
nobody
is
thinking
that
the
way
we're
doing
it
right
now
is
great,
so
we're
just
doing
the
best
we
can
hey
Quinton
did
you
have?
Did
you
have
anything
that
you
wanted
to
add
to
the
agenda?
Cuz
I
know
you
you're
kind
of
gonna
take
a
look
at
it.
Asynchronously
was
there
anything
that
you
wanted
to
run
by.
F
F
A
F
A
B
I'd
like
to
try
and
move
the
ball
forward
a
little
bit
on
the
kept
process.
I
think
oh
I
made
some
changes
that
Brian
checked
in
there
I.
Don't
you
know
I
want
to
make
sure
that
you
know.
None
of
that
stuff
is
final,
yet
I
want
to
I
want
to
make
sure
that
we
do
Cosette
and
folks
see
what's
going
on
there,
especially
Caleb
and
I,
don't
know
if
Caleb,
if
you've
had
time
to
to
dig
in
this
a
little
bit.
B
How
do
we
assign
you
know
what
we
call
them
like
editors
or
shepherds,
essentially
sort
of
people
to
actually
help
these
things
move
forward?
And
how
do
we
do
that,
through
the
eyes
of
sort
of
we're
going
to
have
limited
capacity
for
this
stuff
right?
It's
not
going
to
be
an
unlimited
type
of
thing
and
so
I
think
there's
a
prioritization
going
on
there,
and
so
that's
got
to
be
part
of
the
process.
Also
yeah.
E
C
B
And
then
the
last
thing
is
that,
like
do
we
want
to
open
up
this
idea
of,
like
you
know,
whole
project
caps
versus
per
cig
caps
as
a
one
way
to
sort
of.
Maybe
you
know
unlock
more
bandwidth
here,
because
when
something
is
is,
is
you
know
relatively
confined
to
a
cig?
They
may
want
to
use
this
process
for
their
own.
B
F
I
got
I
had
something
which
I
added
to
the
review
at
the
time
and
I'm
not
actually
sure
what
happened
to
it.
I
think
it
was
kind
of
semi
ignored,
because
it
was
one
of
those
disruptive
comments
and
I.
Didn't
I
didn't
want
to
hold
up
the
works
and
like
prevent
the
merge
happening
or
whatever,
but
the
one
concern
that
I
had
was
that
we
seemed
to
be
with
that
proposal,
trying
to
do
two
quite
distinct
things,
the
one
of
which
is
to
kind
of
ensure
technical
integrity
of
the
product.
F
Here's
the
you
know
very
specifically,
maintaining
technical
integrity
of
the
product
is
is
a
goal,
and
these
are
the
specific
steps
to
achieve
that
goal,
and
then
communicating
what's
happening
so
that
people
can
know
that
release
one-point-seven
has
got
feature
X,
Y,
&
Z
in
it
seem
like
a
completely
different
goal.
You
know,
there's
some
degree
of
overlap
there
and
I
didn't
think
that
that
came
across
particularly
well
in
that
document
it
might
have
changed
significantly
since
I
read
it,
but
I,
don't
think
so.
Well,.
B
What
is
the
case
law
for
what
it
you
know
what
the
architecture
is
for
kubernetes,
which
is
what
this
stuff
will
become
over
time
and
then
and
then
you
know
what
is
happening
on
a
day
to
day
basis,
you
know,
or
when
these
days
it
seemed
like
two
zero
problems,
but
they
are
related.
So
yeah,
hey,
look.
F
You
know
they
just
seem
if
you
try
and
solve
both
of
them
together
and
you
don't
recognize
that
they're
semi
separate
but
related,
it
just
becomes
like
a
much
or
they
pick
a
problem
to
solve
I.
Think,
whereas
if
you
solve
them
somewhat
more,
do
you
solve
the
first
one
which
I
think
I
think
you
can
somewhat
solve
the
first
one
without
considering
the
second
one
too
much,
and
then
you
can,
you
know,
use
the
output
of
the
first
one
to
solve
the
second
one
kind
of
thing.
So.
E
We
have
for
project
management
for
the
project
and
I
think
that's
a
very
dangerous
place
for
the
project
to
drift
into
from
a
sustainability
standpoint
like
if
we
can't
communicate
and
all
easily
have
like
have
the
sort
same
source
of
information
for
when
we're
communicating
about.
What's
going
on
in
the
project.
The
against
the
the
fragmentation
in
and
marketing
and
communication
concerns
be
quite
a
bit
at
least
looking
at
how
that
has
gone
in
other
large
platform
projects.
It's
not
a
place.
I
want
to
be
in
when.
F
F
E
E
E
But
I
don't
disagree
that
there's
the
two
different
challenges
but
like
if
you
are
making
a
technical
decision,
I
guess
the
the
motivation
is
often
lost
or
hard
to
find
about
why
you
decided
a
technical
decision
was
required
in
the
first
place
and
getting
that
information
stored
someplace.
So
you
can
look
at
it
later
and
communicate
about
why
it
was
important.
I
think
it
is
crucial
for
a
project
that
is
supposed
to
enable
others
to
write
software
against
the
API
is
run
software
against
using
these
these
api's.
E
So,
at
least
in
terms
of
the
developer
and
operator
personas
that
we're
trying
to
support
here
I
think
we
need
to
do
a
much
better
job
about
explaining
why
the
technical
changes
were
making
at
the
cigar,
kotecha
level
or
even
more
narrowly.
An
individual
sig
are
important.
All
of
this
stuff,
you
know
happens
in
these
hallway
conversations
at
large
corporations
and
I
just
want
to
pull
this
stuff
into
the
into
the
light,
because
we
are
an
open
source
project.
E
B
I
think
you
know
we're
in
probably
90%
agreement
here,
I
think
getting
getting
the
important
decisions
documented.
You
know
in
a
way
that
is
accessible
and
easy
to
communicate.
I
think
is
the
overarching
goal
here.
I
think
that
the
disconnect
here
is:
how
does
this
actually
relate
to
decisions
versus
work
done
and
and
the
the
decisions
may
take
multiple
releases
to
actually
sort
of
come
to
fulfillment
right,
like
think
about
the
work
around,
you
know,
refactoring
the
the
go
packages
out
of
the
mono
repo
right.
That's
that's
an
ongoing
thing.
B
That's
gonna
take
a
long
time.
I
wish
we
had
a
cap
on
that
right
because
that's
he
feels
like
that's
the
type
of
thing
that
would
benefit
from
wide
communication
and
some
discussion
and
some
understanding
of
the
Y
about
that,
because
I,
my
suggestion
is
that
the
API
machinery
folks
are
getting
tired
of
explaining
this,
but
what's
happening
on
a
release
by
releases
basis
is
different.
Now
I
could
see
that,
like
oftentimes
like
at
the
beginning
of
the
release,
you
know
having
a
summary
saying
like
we've
made.
B
This
progress
on
these
caps
would
be
a
part
of
the
release
and
then
people
could
actually
go
and
read
those
things
to
see
that
the
bigger
arc
of
where
things
are
happening
so
so
my
mind.
These
things
are
definitely
related
and
there's
tools
and
it's
going
to
enhance
the
that.
But
it.
But
in
my
mind
that
the
cap
stuff
is
a
longer
arm.
Well,.
A
A
Yeah
I
think
in
that
you
know
that
makes
good
use
of
the
milestone
right
because
essentially,
if
you
think
of
the
kept
spread
over
three
releases,
you're
gonna
have
the
first
series
of
issues
tied
to
work,
flow
requests
that
are
merged
for
four
milestone,
one
at
eight
and
then
the
next
batch
for
one
tonight
and
then
we'll
not
ten
and
in
over
time
you
get
to
see.
Well,
we
did
we
did.
You
know
seven
issues
over
the
course
of
this
cap.
A
Two
of
those
were
in
one
day,
two
of
those
room
one
night,
and
then
one
was
in
its
the
next
or
whatever,
and
then
those
you
know
fanned
out
to
fifty
PRS
for
the
one
release
and
ten
for
the
next
year.
So
it's
going
to
help
you
see
over
time
how
these
things
get
implemented,
and
it
will
be
it's
a
it's
a
method
of
managing
the
work
that
is
enduring
and
makes
sense
and
is
completely
trackable
the
aversion
control
which
is
really
important.
A
B
I
mean
I
could
imagine
that,
like
some
releases,
it'll
be
I'll,
release
notes
as
fully
memo.
You
know
kept
one
two,
three
right
and
it'll
be
done
in
one
release
and
you
link
back
to
that
cab
and
cap
and
and
there
you
go
I.
Imagine
in
other
cases
it'll
be
like
you
know.
You
know
we
did
XYZ
towards
implementing
kept
one
two
three
one
of
the
nice
things
about
having
the
cap
process,
at
least
when
it
comes
to
collecting
release
notes.
There
is
like
you
know,
you
can
poke.
B
Somebody
says,
look,
there's
a
bunch
of
things
that
were
done
towards
this
cap.
Can
you
summarize
all
those
issues,
one
release,
no
no
diet
of,
instead
of
actually
trying
to
synthesize
and
there's
a
name
that
is,
you
know,
and
some
folks
that
are
on
on
the
hook
for
for
essentially
owning
the
release.
Note
for
that
particular
account.
Yeah.
A
In
this
to
kill
this
important
point
about
how
we
communicate
about
this,
that
when
it's
just
like
you,
know,
Stephen
Hawking
right,
he
writes
about
these
really
mind-blowing
things,
but
he
does
it
in
a
way
that
you
can
understand
it.
And
if
you
want
to
dig
into
you
know
how
this
affects.
You
know
things
in
a
mathematical
level
you
can.
But
if
somebody
is
trying
to
explain
these
at
a
very
coarse
level
to
somebody
you
know
from
tech,
Target
or
whatever
you
can
just
talk
about
the
cap
and
say
we.
B
C
A
F
C
E
Totally
agree
with
that
Quentin
we
need
to
do
a
much
better
job
briefing
the
press
about
the
structure
of
the
project
and
who
they
need
to
be
talking
to
to
understand,
what's
what's
going
on,
but
we
don't
have
that
today.
I
tried
with
this
for
this
version
of
the
release,
notes
to
have
SIG's,
introduce
themselves
to
the
wider
community
and
try
to
build
that
understanding,
but
like
we're.
So
far
from
from
that
now,
the
the
press
is
just
funneled
towards
the
release
team,
which
Genomes
a
huge
amount
of
unscoped
work.
I've.
A
A
A
It
is
a
very
demanding
large
program
level,
effort
to
get
the
release
out
currently
and
that
that
that
person
should
be
able
to
speak
to
the
press
and
that
I
think
that
that's
a
fair,
fair
thing
to
ask
what
what
I
don't
want
to
see
is
what
almost
happened.
This
time,
where
marketing
was
going
and
talking
about
release
level
themes
that
we
had
already
in
the
process
of
the
release
said.
Let's
declare
bankruptcy
on
this,
because
there
are
no
release
level
themes,
and
so
they,
you
know
they
sort
of
were
inventing.
A
You
know,
manufacturing
things
about
to
release
them,
aren't
even
true
so,
and
not
only
not
true,
but
they
were
things
that
were
countered
at
what
SIG's
were
trying
to
get
across
in
their
own
work.
So
it
was
like
provably
false
yes,
so
what
I
don't
want
to
see
is
that
I'd
rather
see
somebody
who
has
a
little
bit
more
of
a
deco
view
speak
to
it,
then
somebody
who's
so
disconnected
from
the
nuts
and
bolts
of
it
that
they're
actually
manufacturing
things
that
didn't
happen.
A
D
D
A
A
D
Question
of
cuz
yak
is
the
thrown
to
the
Wolves.
How
many
cig
leads
are
going
to
be
comfortable,
getting
in
front
of
press
or
other
people
to
talk
about
the
technicality
now
I
know
say:
gaps
were
probably
different.
Michelle
Adnan
and
I
are
probably
all
pretty
comfortable
doing
that,
but
can
all
the
SIG's
say
that.
E
Not
necessarily
but
I,
don't
think
it's
a
role
that
needs
to
be
just
the
sig
lead.
I
think
anyone
in
a
cig
should
be
empowered
to
be
able
to
speak
about
work
that
was
done
by
the
sig
and
we
need
to
have
the
structure
that
allows
anyone
to
do
that.
I
mean
any
any
off
is
a
spot.
We
can't
tolerate
really
single
point
of
failure
for
people.
E
And
I
think
certainly
that
we
need
someone
to
help
find
these
people
and
connect
them
with
with
the
press
and
get
them
their
media
training,
but
yeah
I
think
that
most
SIG's
at
least
think
we
should
have
should
be
able
to
find
someone,
within
the
sake
to
talk
about
work
that
they
have
delivered.
I,
guess
kind
of.
If
you
can't
talk
about
it,
why
did
you
do?
It
is
something
that
was
a
question
that
comes
to
my
mind,.
A
There
was
quick,
quick
announcement,
just
real
quick
if
one
dot
8.1
is
out
I
mean,
has
a
fix
in
the
the
conformance
test
around
ICMP,
so
some
of
the
cloud
providers
as
your
it's
a
blocks
ICMP.
So
it
wasn't
it
wasn't.
This
is
really
the
best
test
for
conformance
for
us,
but
so
that's
been
removed
as
a
blocking
test
for
conformance
and
there's
less
other
good
fixes
in.
There
also
need
to
fill
more
release
team
roles
as
you,
as
we
saw,
there's
a
link
in
the
announcements
to
that
anything
else.
Before
we.
B
Close
I'm
gonna
be
trying
to
find
some
time
to
continue
to
sort
of
you
know,
submit
some
changes
around
the
cap
process.
I
welcome
anybody
else
who
wants
to
to
review
and
commits
on
that,
and
you
know
Caleb.
That
means
especially
you
because
I
know
we're
not
totally
lined
up
yet,
but
I
want
to
continue
down
that
path.
Yep
I.
E
Definitely
definitely
do
I
think
yes
personally,
to
comment
that
Derek
made
early
in
the
process.
Maybe
it's
time
to
start
trying
to
do
likes
kind
of
can't
see
the
Scarecrow's,
but
back
testing
the
process
on
things
we
have
already
delivery
contingent,
GA
and
things
that
are
on
their
way
into
GA
and
try
and
rough
out.
You
know
smooth
some
of
these
rough
edges
through
that
process.
I.
B
Think
you
know
one
way
to
solve
launched,
it
might
be
to
be
like
you
know:
hey
the
kept
process
is
advisory,
but
if
you
want
to
get
a
lot
of
eyes
on
something,
if
you
want
to
actually
sort
of
grease
the
skids
hopes
can
opt
into
that
and
without
trying
to
sort
of
force
it
down
everybody's
throat
just
to
try
and
prime
that.
But
we
can
talk
about
that
later
out
of
time.
There.