►
From YouTube: Kubernetes Community Meeting 20160526
Description
We have PUBLIC and RECORDED weekly video meetings every Thursday at 10am US Pacific Time.
https://docs.google.com/document/d/1VQDIAB0OqiSjIHI8AWMvSdceWhnz56jNpZrLs6o7NJY
Helm demo, why does Deis contribute, 1.3 release watch, core API inclusion criteria proposal, merge queue optimizations.
A
Good
day
today
is
Thursday
in
May
26.
This
is
the
Cooper
Nettie's
community
meet
up,
it
is
recorded
and
we
do
this
every
week.
Today's
agenda
is
actually
pretty
cool,
it's
very
exciting
and
we
are
going
to
have
Matt
butcher
talking
about
helm
this
morning
and
then
after
that
demonstration
we
will
also
have
Gabe
monroy
from
Deus
talk
about
why
they
want
to
contribute
to
Cooper
Nettie's.
A
It
is
API
with
workflow,
potentially
as
any
specific
example
on
that,
then
we
have
an
update
on
some
urge
q
optimizations
with
daniel
Smith,
who
I
have
not
actually
heard
a
check
in
from,
but
that's
I
will
get
that
in
a
moment
and
then,
as
a
last
reminder
now
and
at
the
end
of
the
meeting,
next
week's
meeting
is
going
to
be
at
five
p.m.
pacific
time
trying
an
asia
friendly
time
or
a
sum
of
asia
friendly
time.
A
In
order
to
see
if
we
can
get
some
more
overlap
from
that
community,
it'll
be
the
second
time
we
try
it
and
see
how
it
goes.
We
had
a
low
attendance
last
one,
but
tell
all
your
friends
who
might
be
will
find
that
more
convenient
time
to
join
us
all
right,
so
Matt
I
think
I
heard
you.
So
let's
go
ahead
and
get
started
with
the
helm
demo.
If
you,
if
you're
ready.
B
I'm
here
I'm
here,
ok
yeah,
the
the
infamous
mute
problem
yeah.
So
my
name
is
Matt
butcher,
I'm
an
architect
at
dais
I'm
on
the
team
of
core
contributors
that
works
on
keroon,
Eddie's
helm
and
we
are
currently
in
the
middle
of
building
the
helm.
V2
release
really
really
excited
about.
What's
going
on
so
helm,
if
you
haven't
heard
of
it
is
a
tool
for
deploying
and
managing
career.
Nettie's
charts
and
a
chart
is
basically
like
a
bundle
of
sort
of
prefabbed
resources,
communities,
resource
files
and
manifests
with
template,
support,
and
things
like
that.
B
With
this
new
release,
you
know,
we've
had
you
know
gotten
together
with
bitnami,
with
Google
with
several
other
orgs
and
tried
to
build
something
that
was
a
little
more
powerful
and
a
little
more
attuned
to
teamwork
right,
so
helm
classic
was
entirely
client-oriented
like
homebrew,
but
what
we
found
was
say
you
and
I
are
both
deploying
something
right,
so
we're
working
together
on
it.
I
do
a
helm,
install
of
something
and
then
I
take
off
for
the
weekend
and
take
my
laptop
with
me
right.
B
The
helm
classic
story
was
well
now
you're
kind
of
in
trouble,
because
I
was
the
you
know
the
source
on
that
one.
So
we
built
a
server
and
in
cluster
component
this
time
around
so
I
install
something
I
take
off
for
the
weekend.
You
can
log
into
communities
and
see
what
I
deployed
and
how
I
deployed
it
grab
my
config
tweak
it
push
it
back
in
and
then,
when
I
come
back,
I
can
see
the
changes
you
made
in
teams
can
collaborate
more
effectively.
B
We
also
like
the
idea
of
having
an
in
cluster
part,
because
that
means
that,
as
we
continue
developing
helm,
we
can
add
more
and
more
features.
It'll
make
managing
earth
of
things
more
automatic
right
automate
a
lot
of
these
things
because
the
cluster
can
be
the
helm
in
cluster
peace
can
be
watching
the
state
of
the
cluster
and
reacting
accordingly.
So
we're
really
excited
about
this
new
direction.
It's
taking
us
a
little
longer
than
we
had
hoped
to
get
it
really
off
the
ground,
but
now
it
is.
B
As
of
yesterday,
we
got
a
developer
preview
release
out
tag
alpha
1
and
we're
really
excited
about
the
way
it's
going
from
here
on
out.
We
expect
the
velocity
will
pick
up
and
so
we'll
be
cutting
an
alpha
2
very
shortly.
Right
now
you
still
have
to
build
from
source.
So
if
you
wanted
to
go
kick
the
tires
on
helm,
v2
you
head
over
to
github
/q
burnetii,
/,
helm,
download
the
repo
and
run
you
know,
make
bootstrap
build
and
it'll
try
and
bootstrap
your
local
environment
and
then
build
all
the
binaries
you
need.
B
So
what
I'm
going
to
do
today
is
take
kind
of
a
quick
walk
through
some
of
the
core
features
of
the
new
helm,
I'm
running
not
only
off
of
master
but
off
of
fixed
branch,
because
I
was
fixing
something
this
morning
and
I
didn't
have
time
to
switch
everything
back
and
get
it
config.
So
I'm
living
on
the
edge
we'll
see
how
it
goes
on
a
fixed
bridge
on
an
alpha
release
is
share.
My
screen
here.
B
B
Okay,
like
I,
said
we're
on
alpha
I'm
running
on
the
edge,
so
we're
running
off
of
Adam
riess
is
one
of
our
core
contributors
I'm
running
off
of
his
image,
because
it's
hopefully
more
stable
than
my
last
image.
But
here
we
go
so
it
has
now
configured
my
helm,
home
I
point
mine
to
a
separate
place
by
default.
It
should
go
in
users,
dollar
user,
slash,
dot,
helm,
I
think,
is
where
it
goes.
By
default.
I've
got
mine
overridden,
so
you
can
see
it's
going
into
my
home
underscore
home
directory.
B
That's
like
my
local
cache,
where
stuff
goes
just
to
keep
it
cached,
where
my
local
config
files
go
stuff
like
that.
Now
the
server
side
component
of
helm
is
called
tiller.
Tiller
is
the
connection
point
between
the
helm
of
a
boat
and
the
rudder
in
the
back.
I
guess:
that's
where
the
rudder
is
I'm,
not
really
an
April
guy,
but
this
o
tiller
is
the
thing
that
helps
us
steer
this
ship
tillers
running
server
side.
So
if
I
do
a
que
get
pods
the
default
namespace
is
is
helm
inspiring
as
it
is
there.
B
So
there
we
go.
I
can
see
that
I'm
running
a
tiller
pod
somewhere
in
there.
That's
the
server
side
component.
Okay,
so
it
looks
like
we're
up
and
running
so
we're
going
to
continue
living
dangerously
by
installing
something
so
I've
got
a
local
Alpine
chart
here.
Helm
can
install
out
of
two
different
places
we'll
get
to
the
second
one,
the
repository
oriented
stuff
a
little
bit
later
in
this
demo,
but
for
developers
it's
really
useful
to
be
able
to
say,
hey,
I'm
working
in
this
directory.
B
C
B
So
when
I
install
it,
it
takes
my
chart,
it
pushes
it
up
to
tiller
tiller,
runs
a
release
and
generates
a
name
for
me.
I
can
override
the
name
and
give
it
my
own
if
I
want
to
but
I,
let
it
generate
one
for
me.
So
it
releases
like
an
instance
of
the
chart.
It's
a
running
instance
of
the
chart,
so
it
generated
an
Alpine
one
and
and
it
named
it
singing
angelfish.
B
So
if
I
go,
you
know
actually,
let
me
just
list
it
so
I'll
list
and
see
what
I've
got
running
in
there.
I've
got
singing
angelfish
running
in
there.
I've
got
a
little
extra
debugging
info
there,
so
you
can
ignore
that
top
part,
but
you
can
see
there
the
name
singing
angel
angel
fish,
it's
running
the
Alpine
zero
dot,
one
chart.
It
was
created
just
a
few
moments
ago.
So
now,
if
I
run
a
cooper
Nettie's
command,
I
should
see
that
resource
running
in
there
right.
B
So,
let's
just
look
at
all
of
them
there,
so
I
can
still
see
my
tiller
RC
pod
running
there.
I
can
also
see
my
new
singing
angelfish
alpine
pod
in
there
and
running.
So
the
idea
here
is
that
tiller
is
going
to
handle
that
taking
the
manifest
taking
the
user-supplied
values,
merging
the
template
and
the
values
and
then
uploading
the
manifest
into
Cooper
Nettie's
and
then
Cooper
Nettie's
takes
care
of
all
the
rest
of
this
stuff.
So
this
means
you
can
use
any
of
the
regular
Cooper
Nettie's
tight
types
depending
on
how
you
compile
it.
B
You've
got
all
kinds
of
additional
extensions
enabled
for
you,
but
basically
we're
using
the
Cooper
Nettie's
library
to
do
all
of
this.
So
all
the
Cooper
daddy's
types
are
supported
out
of
the
box,
so
we
got
this
pod
we've
got
it
created.
We've
got
an
object.
It's
a
release.
Object
in
tiller.
The
release.
B
Object
is
basically
just
tracking
the
stuff
that
we
deployed
out
into
Cooper,
Nettie's
and
tracking
is
sort
of
a
loose
term
right,
we're
trying
to
use
as
much
of
Cooper
Nettie's
as
possible
and
not
try
and
duplicate
State
tracking
or
anything
like
that.
Alright,
so
we've
released
something
in
there
I
can
you
know
check
on
okay?
So
remember
that
scenario
I
talked
about
at
the
beginning,
I
take
off
for
the
weekend.
It's
your
responsibility
now
to
go,
find
out
how
I
configured
singing
angel
fish
right.
B
Was
it
yet
and
it'll
dump
the
manifest
back
out
or
I
can
drop
the
manifest
now
in
here,
and
basically
just
try
and
dump
as
much
of
the
info
as
it
has
and
it'll
tell
me
what
the
chart
was
when
it
was
released
if
I
passed
any
configs
which
I
hadn't
up
to
the
server
and
what
the
generated
manifest
looks
like.
So
this
is
the
way
you
can
sort
of
share
data
very
conveniently,
and
you
can
fetch
this
stuff
back
down
and
and
take
care
of
it.
B
You
know
get
get
work
done
the
way
you
need
to
get
it
done.
Okay,
so
let's
just
delete
that
one
out
of
there
too.
Now,
if
I
go
back
and
run
a
helm
list,
I
see
that
that's
still
there
well.
Why
is
that
still
there?
Because
when
we
delete
stuff
and
will
probably
add
some
filters
on
this,
so
that
you
don't
have
a
bazillion
deleted
things,
but
we
want
to
track
inside
of
tiller
when
something
is
deleted.
B
We
don't
want
to
just
simply
have
it
go
away
because
I
might
delete
it,
you
might
say
hey
we
were
using
that,
and
so
you
might
want
to
roll
it
back
and
say
alright.
What
was
the
10
is
singing
angelfish,
let's
roll
that
back
to
the
last
release.
The
rollback
stuff
is
not
done,
but
that's
what
we're
working
on
this
is
a
kind
of
stuff
we're
planning
on
for
the
future.
B
But
the
idea
is
we
want
to
track
some
very
minimal
state
inside
of
tillers,
so
that
when
something
gets
deleted
we
can
see
that
it
was
deleted,
because
if
we
go
look
at
the
pods,
we're
not
going
to
see
in
there
the
deleted
pots
right
so
we'll
probably
add
some
flags
and
a
little
bit
of
sugar
around
it.
So
it's
easier
for
you
to
say:
I
want
to
see
deleted
or
I
don't
want
to
see
deleted
it,
but
that's
sort
of
the
basic
idea
all
right.
So
in.
B
B
So
if
you
take
a
look
at
the
URL
that
I'm
about
to
add
you'll
see
that
that's
just
the
google
GCS
storage,
it's
turned
on
in
website
mode,
so
we
can
grab
charts
and
now
we
can
basically
go
and
search
and
see
what
let's
try
helms
search
and
that's
searching
for
charts
with
e
in
the
chart
name,
and
you
can
see.
I've
got
some
from
the
coop
charts
repo
that
I
just
added
the
local
charts.
B
Basically,
the
ones
I'm
working
on
locally
and
then
the
other
thing
we
wanted
to
streamline
was
making
it
easy
to
create
new
charts.
So
you
know,
if
I
type
in
helm,
create
my
chart
now.
I've
got
my
chart
stubbed
out
when
I'm
ready
to
release
it.
I
can
basically
do
home
package.
My
chart
and
it'll
build
me
a
little
tarball
of
the
there
you
go
so
basically,
what
we're
doing
now
is.
B
We've
got
three
big
parts:
here's
where
to
the
summary
right,
we've
got
the
command
line,
helm
utility,
which
communicates
with
the
server
/
grp,
see.
We've
got
the
server
side
component,
which
is
tiller,
whose
job
is
basically
to
take
packages,
deploy
them
into
communities
and
manage
them,
and
then
we've
got
this
third
concept,
which
is
really
the
repository
where
you
can
take
charts.
Put
those
charts
up
there
either
make
them
public
for
other
people
or
run
one
inside
of
your
org,
so
that
you
can
build
or
wide
charts
or
just
use
them
for
personal
development.
B
A
B
So
so
I
can
give
you
several
places
to
reach
us
really
easily.
We've
got
the
helm
slack
channel
in
the
cooper
Nettie's
server
we're
all
very
active
in
there.
We
try
and
post
our
daily
stand.
Stand
there
on
thursdays.
In
fact,
right
before
this
meeting,
we
actually
do
a
zoom
based
stand
up
that
anybody
is
invited
to
you
can
come
in
and
find
out.
What's
going
on,
the
link
to
that
is
I,
think
on
our
github
page
and
also
in
the
karoo
Nettie's
slack
channel.
The
issue
queue
is
relatively
active.
B
That's
a
great
place
to
jump
in.
You
know
show
up
to
any
of
those
places,
we're
also
very
active
in
sig
apps,
because
sig
apps
is
kind
of
the
place
where
a
lot
of
us
were
interested
in
deploying
and
running
things
in
Coober.
Nettie's
hang
out,
so
that's
another
great
place
to
contact
us
I'm,
probably
forgetting
something
else,
but
I
think
that's
good.
So
our.
A
Options-
and
you
can
always
add
them
to
the
notes
document
as
well,
if
you
think
of
other
places,
all
right
thanks
much
I'm
gonna
jump
right
on
and
not
take
questions
this
time,
because
we're
running
a
little
tiny
bit
behind
so
Gabe.
You
were
going
to
tell
us
why
dais
has
say
spent
so
much
time
and
effort
working
on
home
and
with
the
Q
burnaby's
project.
Oh
sure,.
D
Yeah
thanks
for
sure
a
little
bit
about
this,
so
the
day
seems
actually
been
helping.
Customers
with
container
textin,
it's
about
August
of
2013
and
you
know,
is
given
we
started
pretty
early.
We
started
to
hit
the
limits
of
some
of
the
early
container
schedulers.
You
know
quite
early
on
and
experienced
some
some
real
pain
from
customers
and
really
derive
the
need
for
something
more
robust
and
that
actually
led
to
a
pretty
thorough
evaluation
of
docker
swarm
maze
us
and
Cooper
Nettie's
I'll,
be
it.
D
You
know
quite
a
few
months
back,
we
actually
took
it,
took
our
time
and
integrated
each
different
orchestrator
into
sort
of
our
past
project
as
a
technology
preview.
So
we
could
actually
get
real
feedback
from
from
our
community
and
not
just
like
make
it
our
opinions,
but
actually
get
opinions
of
other
folks,
and
we
also,
as
we
started
to
learn
some
of
those
code
bases
ended
up.
D
You
know
sending
patches
upstream
to
to
fix
things
in
each
of
those
projects
that
we
needed
to
fit
our
needs,
and
you
know
when
the
does
from
that
evaluation
process
settled.
It
was
really
Cooper
Nettie's
that
was
left
standing,
so
there's
sort
of
a
technical
aspect
to
that
and
kind
of
a
non-technical
from
a
technical
standpoint.
There
are
really
three
things
that
sit
out
with
Cooper
Nettie's.
The
first
was
the
architectural
foundation.
We
take
a
look
at
the
API
design
and
cure
benetti's.
D
It's
just
incredibly
well
done
things
like
kinds,
inversions,
and
the
way
that
the
crud
semantics
are
implemented.
It's
all
really
extensible.
You
can
kind
of
see
that,
and
you
know
the
way
the
API
extensions
are
managed
and
then
under
the
hood
you
know
kerber
Nettie's
is
powered
by
these.
You
know,
control
loops,
that
are,
you
know,
pushing
desired
state.
You
know
and
defined
by
the
clarity
of
api's.
These
seem
obvious
to
folks
that
are
using
career
Nettie's
today,
but
you
don't
find
this
stuff
in
a
lot
of
the
other
projects
that
we
were
looking
at.
D
The
second
aspect
was
the
thing
that
the
ability
to
push
loosely
coupled
infrastructure,
kuber
Nettie's,
uses
these
concepts
of
labels
and
label
selectors,
which
is
like
sort
of
a
query
language
that
allow
it
to
model
really
complex
systems.
That
map
really
well
to
the
type
of
environments
that
our
customers
are
running.
You
know
that
they
consist
of
many
different
types
of
objects,
and
you
know
many
different
versions.
Things
like
canary
deployments,
I'm
all
kind
of
living,
and
you
know
in
the
same
cluster
at
the
same
time.
D
So
this
ability
to
promote
loose
coupling
was
important
and,
lastly,
on
the
technical
side
was
well
defined.
Scope
like
all
great
software.
The
kubernetes
project
really
seems
to
value
what
it
won't
do
as
highly
as
what
it
does
do,
and
you
know
you
see
that
in
terms
of
you
know
the
you
know
being
guarded
around,
you
know
what
kind
of
primitives
do
end
up
getting
introduced
and
where
it's
appropriate
to
use
composition
rather
than
kind
of
building
everything
into
the
court.
D
But
just
as
important
as
those
three
technical
aspects
is,
is
what
I
consider
the
long-term
prospect
for
the
project
and
I
definitely
think
that
the
Google
roots
obviously
helped
a
lot
in
terms
of
laying
a
strong
technical
foundation,
but
I
think
a
bigger
issue
is:
is
the
strength
of
the
community?
You
know
the
to
me
that
says
a
lot
more
about
the
future
of
any
open
source
project
and
if
you
look
around,
you
might
have
noticed.
D
Goober
Nettie's
has
a
really
extremely
diverse
group
of
users
and
contributors,
and
and
also
vendors,
like
ourselves,
lots
of
opinions
floating
around
lots
of
interest
in
starting
up
new
cigs
and
attending
existing
cigs
and
just
generally
helping
push
the
project
forward,
and
you
know,
there's
always
of
course
room
for
improvement
in
terms
of
yoga
community
management
and
that
sort
of
thing.
But
I
will
say
that
the
level
of
energy
diversity
embodied
by
the
communities
community
is
unique
in
the
space.
That's
something
that
we
know
firsthand
so
yeah.
A
Thanks
for
your
summary
gate,
that's
fantastic
to
hear
the
the
what
contributed
to
the
choice
and
what
you
guys
want
to
get
out
of
it
as
well.
I
got
a
reminder
that
we
are,
of
course,
in
the
run
up
to
1.3,
so
Before
we
jump
into
our
clone.
Api's
asked
for
a
super
quick
update
on
where
we
are
against
1.3,
so
Brian
grants
is
going
to
give
us
an
update
there.
E
E
We
did
have
our
future
complete
date
on
monday,
and
he
you
know
not
everything
got
in
and
we're
all
bombed
by
that,
but,
like
I
said,
we
are
trying
to
stick
to
the
release
date
this
time
so
at
the
we've
shifted
gears
and
people
are
focused
primarily
now
on
fixing
bugs.
So
we
are
now
automatically
opening
github
issues
for
test
failures.
You
can
find
those
test
failures
by
the
searching
for
the
kind
flake
label
in
get
up
on
the
repo
any
on
a
side.
E
Issue
is
fair
game
or,
if
you
just
want
to
help
us
d
duplicate,
open
issues.
That
would
also
be
super
useful.
You
know,
but
all
the
test
results
should
be
accessible
publicly.
Occasionally
we
have
problems
with
that.
If
you
do
encounter
a
problem,
definitely
let
us
know,
but
you
should
be
able
to
go,
get
the
logs
from
the
running
tests
and
debug
and
issue
and
set
a
PR
de
for
fix.
E
E
E
A
We
can
have
a
discussion
there,
but
Brendan
appears
to
be
live
broadcasting
from
outside
and
we
are
going
to
move
on
to
a
conversation
about
workflow
and
inclusion
of
inclusion
standards
for
core
api's,
Brennan
and
Eric
tuned
and
Dario
I
believe
are
talking
about
these
and
if
you,
if
you
guys,
can
keep
this
to
25
minutes
plus
or
minus
five.
That
would
be
awesome
because
we've
still
got
more
and
more
excitement
in
today's
meeting.
Yeah.
F
A
F
Guess
I
put
on
the
community
I
guess
if
there's
lots
of
questions
so
I
don't
know
is
Eric
here
as
well:
stereo,
oh
yeah,
okay!
So
as
Genesis
sure
this
discussion
came
up
a
while
ago
in
the
context
of
workflow
and
Gabe
and
Gabe
and
I've
kind
of
alluded
to
this,
actually
in
his
little
feel
about
the
choices
of
guru,
Nettie's
and
I.
Think
that
you
know
we
start
to
talk
about
it
on
and
off
for
a
while
about
the
limits
and
we've
made
some
decisions
along
the
way.
F
I
mean
we've
sort
of
explicitly
said
that
config
is
outside
with
the
limits
and
on
the
other
side,
we've
sort
of
explicitly
said.
The
Machine
management
is
outside
the
limits.
Right,
like
we've
made
decisions
about
not
representing
mo
represent
nodes
but
were
probably
never
going
to
represent
machines
in
the
API
and
deal
with
sort
of
machine
health
management
and
maintenance.
I
thought
it
was
important
to
have
a
conversation
and
get
some
things
that
are
a
little
bit
more.
Both
the
conversation
in
the
community
and
also
just
get
some
things
written
down.
F
So
it's
better
guidelines
about
how
and
win,
and
we
decide
to
include
api's
into
the
into
the
core
right,
I'm,
partially,
because
I
think
we're
on
the
path
towards
the
ability
to
have
extensible,
API
zavod
from
the
outside
and
and
also
because
I
think
that
you
know
we
were
just
finishing
up
a
lot
of
the
stuff
that
we
think
is
his
core,
and
so
we
need
to
start
slowing
down
the
rate
at
which
we
introduce
new
ideas
in
it.
If
you
guys,
specifically
around
workflow,
we
made
we
merge
this
proposal.
F
That
said
that
we
were
going
to
add
workflow
and
I
think
you
know,
after
some
discussion
with
Dario
and
Eric
and
other
people,
we've
made
a
decision
to
actually
do
this
on
the
outside
and
do
this
via
a
third
party
because
and
I'll
sort
of
it,
Ali
I
will
use
that
as
context
for
sort
of
the
general
gotten
lines
that
I
think
we're
moving
towards.
And
so
let
me
pull
up
my
little
notes.
F
You
know
I
I,
think
that
I
guess
Carta.
This
is
the
motivation
that
we're
never
intending
like
I,
never
intended
communities
to
be
the
end-all,
be-all
system.
Right
I
mean
you
can
see
this
with
open
chef
living
on
top
right.
Openshift
provides
things
like
image,
build
and
source
to
source,
to
deployment
that
we're
just
never
going
to
do
right.
It's
not
part
of
our
scope,
that's
not
part
of
our
Charter
and
then
also
I.
F
So,
concretely,
you
know
I
think
that
we
are
what
we're
moving
towards
and
I'm
going
to
put
this
into
a
PR,
but
this
is
sort
of
the
gentle
to
be
the
initial
stage
of
the
discussion.
We're
moving
towards
effectively
raising
the
bar
for
API
inclusion
into
court
and
the
basic
criteria
that
I
think
we're
trying
to
come
up
with
is
that
we
and
I
sort
of
used
the
workflow
and
scheduled
job,
or
we
have
sort
of
used
the
workload
scheduled
job
as
a
nice
example
of
this
distinction.
F
We
want
to
have
a
single,
generally
accepted
solution,
and
so
we
think
that
you
know
cron
is
a
single,
generally
accepted
solution.
There
really
isn't
a
lot
of
effort
by
people
to
rebuild
different
versions
of
chron.
There's
no
like
language
wars
around
on
spec
time,
format
like
it's
just
it's
there's
not
a
lot
of
componer.
It's
it's
a
well-understood,
spec
and
that's
sort
of
criteria.
One
is
that
there's
a
single
generally
accepted
solution.
F
The
second
criteria
is
that
the
object
is
expected
to
be
generally
useful,
I
put
in
fifty
percent
of
the
community
as
kind
of
a
placeholder.
You
know
we
got
to
maybe
argue
about
what
we
actually
want
the
number
to
be,
but
you
know
I
think
we
want.
We
only
want
things
in
the
because
adding
things
to
core
requires
documentation
requires
conceptual
overload
for
people.
F
We
only
want
to
add
things
to
the
core
that
we
think
are
generally
useful
to
a
lot
of
people
and
finally,
I
think
that
this
sir,
maybe
the
squishies
criteria
that
it's
there
is
general
acceptance
that
the
object
is
that
the
curb
entities
there
so
I,
don't
exactly
know
what
general
acceptance
means.
I
think
we
all
kind
of
have
a
feeling
for
I
mean
and
brian
has
written
this.
What
is
Q
brunetti
stock?
That's
actually
out
there
on
the
web
already.
F
You
know,
I,
think
that
gives
a
definition
of
what
we're
trying
to
provide
here
and
I
think
over
over
I'm.
You
know
that
definition
make
it
may
change,
and
that's.
Okay,
like
things
evolve
as
new
things
become
apparent,
but
I
think
we
need
to
have
a
general
acceptance
that
you
know
that
this
is.
This
feels
right
right.
F
The
philosophy
of
what
we're
trying
to
provide
this
object
feels
right
in
that
context,
so
those
are
sort
of
the
criteria
and
then
we
want
to
lay
out
some
exceptions
because
the
first,
when
you
lay
our
criteria,
you
don't
want
to
lock
block
people
from
doing
things
and
the
two
exceptions
that
I
hope
that
we
love
that
want
to
lay
out
is
that
there
are
no
there's,
no
other
way
to
implement.
This
functionality
incur
benetti's
and
I'm
not
actually
sugar
any
examples
of
this
anymore.
F
But
you
know
at
times
there
have
been
api
objects
that
you
just
simply
couldn't
implement
outside
of
luminance
and
then
the
other
one
is
exceptional
circumstances
as
judged
by
committers,
and
this
is
really
intended
to
be
kind
of
the
escape
clause.
Where,
like
I,
don't
want
us
back
into
Horner.
There
was
a
great
deal
of
concern
from
other
people
about
effectively.
F
You
know
I
think
maybe
pet
set
might
be
a
an
example
of
this,
in
the
sense
that
I'm
not
actually
sugary
is
a
single,
generally
accepted
solution
for
pets
ahead
right
over
we're
kind
of
breaking
new
ground
there,
but
as
committers
and
esme
containers,
we
believe
that
it's
an
important
object
to
add
took
your
names,
so
that's
about
it.
I
guess
so.
Many.
A
Brands
me,
we
also
talked
about
consent.
There
was
considerable
discussion.
I
know
inside
Google
about
this.
You
sort
of
framed
this
out
as
all
the
different
things
you
wanted.
We
wanted
to
bring
that
conversation
out
here
without
dominating
the
discussion.
Did
you
guys
come
up
with
because
I
think
David
Oppenheimer
and
our
tuna
were
also
going
to
present
slightly
different
variations?
Is
that
still
the
plan,
as
I
put
you
all
on
the
spot?
I
have.
G
It
wouldn't
be
good
for
the
users
who
I
think
really
should
be
our
first,
our
first
our
first
priority,
because
if
we
don't
have
users,
we
won't
have
a
community
because
there
won't
be
anyone
to
build
stuff
for
and
so
I
think
by
by
having
I
think
these
guidelines
are
great
and
I.
Think
by
having
a
little
bit
of
flexibility
and
being
able
to
use,
used,
use
judgment
in
applying
them,
it
addresses
the
concern
I
had
about
being
overly
overly
a
you
know,
restrictive.
A
A
You
know,
ten
to
ten
Googlers
all
arguing,
so
we
we
tried
to
come
up
with
a
way
to
have
that
conversation
and
then
also
bring
the
opportunity
out
for
you,
the
rest
of
the
community
and
and
the
users.
If
we
have
users
on
here
to
talk
about
this
as
ways
that
people
are
engaging
with
with
Cooper
Nettie's
and
bringing
things
in
and
it
looks
like
Clayton
has
been
writing
notes
as
we
go.
Do
you
want
to
just
talk
through
those
Clayton.
H
Nettie's
would
be
madness
like
not
just
this
is
sparta
madness,
but
you
know
real
development
gridlock,
where
all
of
the
criteria
that
Brendan
mentioned
I
think
are
things
that
that
I've
personally,
you
know
felt
there's
a
good
rules
of
thumb,
which
is:
is
it
something
that
can
be
implemented
in
the
core?
No
other
way?
H
Is
it
something
that
everyone
agrees
on,
and
all
those
exceptions
are
also
great
examples
of
you
know,
use
cases
and
for
us,
like
I,
think
the
thing
that
we've
been
trying
to
get
to
over
the
last
year
is
actually
getting
to
the
point
where
someone
could
build
extensions
around
Cooper,
Nettie's
and
how'd.
It
work
all
of
the
hard
work.
That's
been
done
on
third-party
resources
and
API
extensions,
and
you
know
security
and
off
like
this.
H
This
whole
class
of
problems
that
are
really
hard
to
get
right
and
we're
not
quite
there
yet,
but
we're
starting
to
get
to
the
point
where
we
can
actually
see
the
light
at
the
end
of
the
tunnel
and
I
think
it
is.
You
know
we're
already
starting
to
see
people
try
and
use
this
in
ways
that
is
actually
demonstrating
that
this
is
the
right
approach.
F
Yeah
I
would
say
actually
that,
in
the
spirit
of
community
discussion,
the
thing
that
was
struck
that
that
caused
the
greatest
amount
of
discussion
and
angst
and
pain
was
effectively
what
happens
when
third-party
resources
are
really
ready,
find
any
fully
ready
and
so
I
think
that
you
know
we're
not
gonna
have
that
discussion
now
and
I.
Don't
want
to
have
that
discussion
now,
but
I
think
over
the
next
few
months,
and
you
know
the
next
six
months.
F
H
I
think
the
one
other
note
is
that
the
support
that
we
would
need
to
have
a
viable
set
of
tools
that
aren't
just
the
core
Cooper
Nettie's,
but
the
things
built
around
it
that
people
can
find
and
use
the
work
with
home.
You
know
the
workpeople
been
doing
on
the
build
system
is
submit.
Q
like
these
are
all
things
that
healthy,
viable
projects
need
to
have
healthy,
viable
ecosystems,
and
you
know
we're
gonna
have
to
keep
committing
to
improve.
You
know
yeah.
A
F
All
sorted
out,
I
think
I
was
just
a
like
a
fantastic,
and
I
mentioned
it
I
sort
of
mentioned
it
in
passing
at
the
very
end
of
community
meeting.
As
everyone
was
hanging
up,
we
just
sort
of
like
let's
circle
back
and
then
cross
the
t's
dot,
eyes
and
I.
Think
we've
done
that
I'd
are
in
the
stereo,
has
a
that's.
I
A
I
Place
every
we
need
more
time
on
this.
This
is
a
pity
because
we
planned
to
use
in
production
soon.
We
have
a
lot
of
work
flow
today
in
our
not
on
communities
minimal
data
center.
We
have
thousand
overflow
that
run
every
day
and
the
plan
was
to
not
to
bring
everything
on
openshift
because
we
are,
we
use
open
shift
in
production,
but
to
start
to
at
least
two
tests.
We
have
to
wait.
That's
the
reality!
That's
the
way.
It
is
yes,
but
they
puts
part
of
the
business.
Okay.
I
Great
though
nope
anyway,
my
plan
is
to
implement
at
least
the
proposal
would
be
remove.
It
probably
went
to
remove
from
the
from
the
documentation,
mm-hmm
and
but
anyway,
we'd
have
to
get
the
beginning.
We
are
I
mentioned
the
year
and
they
are
in
the
github
that
we
we
need
more
than
the
workflow
proposal.
We
need
the
schedule
at
work
flow,
because
this
is
what
we
have
in
production
and
the
idea
was
start
with
the
stepid--
scheduled
job.
I
E
I
A
Awesome
all
right,
I'm
going
to
bookmark
the
conversation
on
contributors.
I
think
we
need
so
people
who
are
interested
in
that.
Please
reach
out
to
me
because
they've
agreed
to
come
up
with
a
scope
of
what
the
real
problem
is
today
and
what
we
want
to
do
with
it
going
forward.
So
that's
that's
an
important
one
for
us
in
upcoming.
If
we
have
no
other
questions
on
API
Sorka
discussion
on
the
api's
for
workflow,
then
let's
go
on
to
the
next
item.
So
last
call
for
discussion,
I
api's,
oh.
A
K
Sarah,
can
you
hear
me
yes,
okay,
great,
so
I
can
talk
about
a
lot
of
stuff
here,
but
first
of
all,
I've
put
some
optimizations
in
the
cymek
you
and
it
has
been
going
a
little
faster
on
the
basic
optimizations
are:
don't
like.
You
know
how
it
retests
pr's
when
they
get
to
the
top
of
the
queue
in
some
circumstances
it
would
it
used
to
test
them
twice
like
if,
if
the
tests
ahead
broke
and
then
started
passing
again
so
now,
it
doesn't
do
that
anymore
and
additionally,
I
made
it
more
lenient.
K
So
soon
it
will
handle
will
find
old
issues
and
soon
it
will
know
the
difference
between
the
entire
suite
broke,
and
somebody
needs
to
consider
all
a
group
of
failures
together
versus
these
are
individual
tests
flakes
so
but
more
more
generally,
and
so
that's
specifically
a
few
things
that
have
happened
to
the
submit
kiya,
but,
more
generally,
as
I'm
sure,
you've
noticed.
We
have
a
problem
with
throughput
merge
throughput.
K
Even
with
that,
even
with
that
those
optimizations
in
place,
we
can
probably
get
another
doubling
and
throughput
and
by
the
way,
those
those
optimizations
I
mentioned,
they
pretty
much
doubled
throughput
over
the
last
weekend
so
and
I
think.
If
we
can
fix
individual
flakes,
we
could
probably
get
another
doubling
and
throughput,
and
that's
probably
about
the
maximum
that
is
possible
with
our
current
setup
to
get
faster
than
that.
We
need
to
consider
a
few
things.
We
need
to
consider
making
the
the
tests
that
it
runs
because
it
runs
every
issue
in
serial.
K
K
So
we
here
at
Google,
have
we've
noticed
that
this
is
a
problem
and
we've
drafted
a
few
people
to
focus
on
on
creating
this
is
this
is
like
the
fourth
time
this
project
has
had
a
major
test:
flake
emergency,
so
we've
drafted
a
few
people
were
writing
up
some
goals
and
extra
criteria.
We
want
to
produce
a
system
that
keeps
tests
fixed
because
we
have.
We
have
two
things
that
we
need
to.
K
We
need
to
get
two
things
working,
we
need
velocity,
we
need
people
to
be
able
to
get
changes
into
the
project
and
we
also
need
stability.
We
need
the
test
to
continue
to
working,
because
we
want
to
deliver
a
quality
piece
of
software,
so
I
will
be
publishing
some
goals
to
curb
entities.
Dev
will
be
soliciting
help
for
some
items.
You've
already
seen,
Eric's
soliciting
you
for
owning
a
tests
individually.
So
this
is
one
of
the
things
that
we
want
to
do
to
improve.
K
K
A
A
We
were
I
wasn't
kidding
this
morning
when
I
sent
the
email
thing.
This
is
a
great
way
to
get
on
board
it
and
you
will
get
lots
of
help
and
attention
from
people
who
are
already
contributors
or
already
meditators,
because
they
want
this
fixed.
So
you
submit
something
that
looks
like
it's
a
text
fit
a
test.
A
I
work
on
something
testing
related
a
lot
of
attention
and
and
review
work
that
happens
against
the
fees,
because
this
is
a
huge
push
and
also
work
toward
making
this
never
happened
and
I
know
we
talked
about
that
at
the
end
of
1.2,
but
they
are
here
now
and
so.
Thank
you.
Thank
you
to
Daniel
for
all
the
work
on
this
I
can.
L
L
Glenn
immediately
and
so
I'm
going
through
and
trying
to
be
expedient
about
these
manual
merges
and
such.
But
you
know
I,
don't
it's
hard
for
me
to
go
and
read
every
single
PR
in
detail
and
determine
how
safe
and
whatnot
it
is.
It's
also
tricky
to
see
which
PRS
are
like
fixing
bugs
vs,
adding
features,
versity
fixing
test
flakes,
and
so,
if
you
want
to
make
that
a
little
more
explicit
on
your
PRS,
if
you
have
candidates
that
are
testing,
flake
fixes
or
bug
fixes
call
those
athletes
mm-hmm.
K
A
Okay,
let's
see,
does
anyone
else.
We
remark,
ibly
I
thought
we
had
it
fully
fully
stuffed
agenda
and
we're
going
to
run
right
up
to
the
last
minute,
but
remarkably,
we
have
about
10
minutes.
So
is
there
any
special
interest
group
that
did
things
this
last
week?
Did
you
all
take
the
last
couple
of
days
quietly
after
getting
everything
in
for
1.3?
Anybody
want
to
give
updates
or
ask
questions.
M
Hi
I
think
this
is
really
kind
of
what
I
was
asking
for
earlier.
When
I
was
suggesting,
we
have
a1
dot,
3
release,
update
okay,
not
really
clear,
given
the
current
state
without
actually
showing
up
to
the
to
the
burndown
meetings
or
I,
actually
noticed
your
you
call
it
a
turn
down
meeting
earlier
that.
M
I
thought
that
was
actually
quite
they're
quite
the
great
way
to
probably
be
thinking
about
those
meetings
anyway.
I
think
you
know,
maybe
for
next
time,
if
we're
really
prepared
for
today,
but
I
mean
there's
a
number
of
features
on
the
on
the
list
that
it
would
be
good
to
get
what
one
of
the
things
I
management,
like
summary
of
where
we
stand
on
these
things,
including
pet
sets,
one.
G
Of
the
things
we've
talked
about
is
actually
sending
out
a
weekly
or
twice
a
week,
or
something
a
status
to
Coober
Nettie's
dev
about
the
key
1.3
features
about
their
status.
I
think
that
might
be
the
best
solution
to
this.
The
I
don't
think
that
idea
went
anywhere,
but
it
might
be
more
scalable
than
trying
to
get.
You
know
around
the
room
status
report
on
and
very
large
value
and
features
in
the
community
meeting.
I
am
happy
to
try
to
organize
that
if
other
people
don't
have
time.
A
G
Would
ya
like
I,
agree
and
I,
but
I'm
just
saying
I
think
I
think
that
that
information
is
very
important
for
the
community,
but
I
think
the
right
way
to
disseminate
it
is
through
the
mailing
list,
rather
than
a
like.
Everyone
has
to
synchronize
in
the
same
I'm
in
space
and
then
or
each
other
with
with
with
status,
I
I.
Don't.
M
M
What's
going
on
so
there
it's
very
hard
to
figure
out
for,
even
even
for
folks,
like
us,
who've
been
pretty
involved
in
the
project,
dig
through
all
of
these
things
and
figure
out
kind
of
where,
where
things
stand
at
any
given
moment,
I'd
really
want
to
see
this
done
by
way
of
updates
to
the
wiki
or
in
some
other.
Some
other,
like
documentation,
current
state
documentation
needs
to
be
updated.
Otherwise
to
figure
things
out,
people
are
going
back
through
email
archives
and
trying
to
piece
the
puzzle
back
together.
Again,
hey
it's.
G
G
G
A
A
One
of
the
things
that
I've
been
banding
about
with
people
and
I'm
going
to
start
reaching
out
more
broadly
with,
is
the
idea
that
we
have
a
product
and
product
project
management,
technical
project
management
group
out
of
the
community.
So
not
just
the
google
pm's,
not
just
the
google
tpms,
we've
gotten
Mike
supper
of
from
core
OS
and
we
have
Andy
Goldstein
from
redhead.
A
But
we're
not
doing
this
in
and
Clayton
is
a
lead
from
Red
Hat
we're
not
doing
this
in
a
cohesive
and
thoughtful
way,
but
in
one
the
1.4
timeline
bringing
together
a
group
which
is
accountable
to
one
another.
To
give
this,
give
this
back
to
the
community
as
opposed
to
only
being
accountable
to
you
know
your
own
devs
or
occasionally
being
asked
to
come
forward
to
the
community
meeting.
That
kind
of
thing
is
that
something
you
have
people
that
you
would
be
willing
to
help
us
staff
with.
A
M
Yeah
I
think
I
think
in
some
ways
what
I'm
proposing
here
is
that
we
need
something
like
a
product
manager,
ish
role,
maybe
I'll
call
it
a
feature
owner
and
the
future
owner
should
really
be
able
to
compete.
It
keep
keep
that
updated
and
is
kind
of
a
identifying
that
anyone
can
go
and
ask
and
I'm
available
to
do
some
of
that
work.
We
have
other
people
on
the
team.
C
M
A
That
is
exactly
what
I'm
trying
to
do
is
pull
together.
A
a
community
group
that
does
this
product
product
or
technical
project
management
and
then
maybe
delegate
some
pieces
to
feature
leads.
Maybe
they
are
feature
leads,
and
some
gay
or
not
teacher
leads
but
feature
owners
in
the
product.
Sense,
we'd,.
E
E
A
I
think
these
will
all
help
us
into
going
forward
if
we
can
collect
around
it
and
make
it
the
way
we
do
this
at
least
while
we
iterate
against
whatever
the
next
way
is
because
we
find
some
ways
to
improve
and
then
so.
Yes,
I
will
start
reaching
out
to
people
to
form
a
group
of
product
and
and
feature
owners
toward
1.4,
but
there's
still
the
main
point
of
1.3
yep
Sarah.
This
isn't
fair,
not
I.
I
was
paying.
A
N
C
And
I
mean
it's
like
so
I
compiles
original
spreadsheet,
google
spreadsheets
right
I
know
it's
not
the
ideal
form,
but
as
much
as
kind
of
for
now.
I'm
just
reach
into
sig
leads
if
they
can
give
the
least
updated.
So
at
least
we
can
track
what
went
into
13
and
what's
going
to
spill
over
to
14
I,
think
it's
a
good
point
and
I
also
kind
of
try
to
work
from
the
future
templates
at
Brian
mentioned
to
build
similar
spreadsheet
for
now
404.
A
All
right,
we
have
four
minutes
and
we
have
a
grand
vision
going
forward.
We
have
a
partner,
has
volunteered
to
do
some
cleanup
on
the
1.3
to
get
better
status
out
Aparna.
Are
you
going
to
give
some
summary
feature
updates
next
week
on
this
meeting?
It
is
at
five
o'clock.
This
is
where
I
get
my
notice
and
5
p.m.
next
thursday,
instead
of
regularly
at
10am,
because
we're
trying
the
see
if
we
can
engage
our
Asian
counterparts
a
bit
more
I
think.