►
From YouTube: Kubernetes SIG Cluster Lifecycle 20180102
Description
Meeting Notes: https://docs.google.com/document/d/1deJYPIF4LmhGjDVaqrswErIrV7mtwJgovtLnPCDxP7U/edit#heading=h.28g6lc7lhcgu
Highlights:
- Should we save content that was previously on the wiki?
- Adding more folks to GitHub teams for cluster lifecycle
- Should we support hyperkube?
- Plan to use certification as a means to cull the number of turn-up guides in the official Kubernetes documentation
- Please review the kubeadm GA document
- Next week we will do 1.10 planning
- Please review the contributing to the sig document
- Discussion about `kubeadm --join --master`
A
Hello
and
welcome
to
the
first
edition
of
the
cig
cluster
lifecycle
meeting
for
2018
today
is
January.
2Nd
I
was
hoping
to
start
off
the
year
going
through
our
mission
statement,
which
Jessica
and
Barbara
was
kind
enough
to
write
a
draft
of
last
year
and
I.
Think
that
will
help
us
focus
as
I
think
Lukas
has
later
in
the
agenda
that
we
should
also
talk
about
like
what
are
what's
a
roadmap
for
2018,
and
where
are
we
headed
if
we
kind
of
have
an
agreement
on
what
our
overall
goals
are
as
a
sig?
A
I
think
this
part
of
this
mission
statement-
Lukas
I,
also
presented
at
cube
con.
Hopefully
it's
not
too
controversial.
I
think
some
of
the
details
might
be
controversial,
but
hopefully
the
overall
points
aren't.
It
starts
out
saying
sequester
lifecycle
examines
how
we
should
change
communities
to
make
it
easier
to
operate.
That's
sort
of
the
one-line
blurb
of
what
we
think
we're
doing,
which
I
think
Justin
put
you
know,
put
pretty
well
into
text.
A
He
also
wrote
that
a
compared
to
C
cluster
ops,
which
is
focused
on
how
to
operate
today's
version
of
kubernetes,
and
if
you,
if
you
look
at
what
Rob
is
trying
to
do
with
sequester
ops,
it's
really
trying
to
gather
operators
and
talk
about
best
practices
of
what
they
are
doing.
Let's
just
and
said
with
what
we
have
today,
whereas
the
cluster
lifecycle
is
looking
at,
how
do
we
make
it
better?
In
particular,
how
do
we
write
code?
How
do
we
change
the
core?
How
do
we
write
tools
to
make
it
easier
to
operate.
A
Yes,
no
you're
sort
of
all
in
there.
Alright.
If
people
generally
tend
to
agree
on
that
and
again,
please
feel
free
to
go
back
and
add
comments
or
suggestions.
The
doc
after
the
fact,
but
Justin
sort
of
wrote
that
down
into
four
primary
areas,
I
think
this
is
where
we're
gonna
maybe
start
to
have
a
little
bit
more
discussion.
A
The
first
one
is
controlled
playing
configuration
management.
So
how
do
we
configure
different
parts
of
the
humanities
control
plan
so
how
do
highly
pass
flags
to
API
server,
the
controller
manager
etc,
and
in
particular
we
do
that
with
flags
today,
but
we
prefer
not
to
be
using
flags
in
the
future
and
so,
as
a
sig,
we
have
been
driving
the
component
configuration
efforts,
thoughts,
suggestions
on
that
section.
A
Okay,
I'm
going
to
keep
moving
since
we
have
lots
of
other
agenda
topics.
Next
is
add
on
management,
and
this
is
basically,
we
have
the
core,
which
is
pretty
generally
agreed
on
upon
what
that
is
pretty
much
all
to
raise
installations
installed.
Api
server,
the
controller
manager,
the
scheduler,
but
there
are
other
things
that
aren't
part
of
that
control
plane
that
people
want
to
install.
A
So
you
know
on
GCE
we
wrote
this
terrible
shell
script
to
manage
what
we
called
add-ons,
which
is
still
alive,
cops,
has
channels
other
systems
have
sort
of
done
their
own
thing
and
cube
admin.
You
know
just
you
pedal
applied
a
chef's
cube
proxy
and
you
can
apply
your
network
CNI
implementation
as
well,
and
those
are
sort
of
additional
parts
of
your
cluster
that
are
sort
of
needed
that
Ford
sort
of
the
cluster
itself
to
function
as
opposed
for
applications
to
function
a
while
back.
A
We
had
a
discussion
when,
when
Brian
was
on
the
call
about
how
atom
management
was
part
of
seed
cluster
lifecycle,
so
I
don't
think
it's
going
to
be
too
contentious
that
we
own
data
management,
I
think
what's
maybe
more
contentious
that
came
out
of
the
meeting
before
Q
Khan
was
a
actually
what
add-ons
are
and
what
it
means
to
manage
them.
So.
A
A
A
So
next
is
sed
management,
so
this
is
how
do
I
run
at-te
and
I
think
this
is
maybe
maybe
a
little
bit
more
contentious,
because
there's
a
lot
of
overlap
between
the
sig
API
machinery
and
us
in
this
case
we're
interested
in
sed
because
it's
part
of
standing
up
a
cluster.
It's
part
of
the
life
cycle
of
upgrading
a
cluster.
How
do
when
you
upgrade
up
at
CD?
How
do
you?
How
do
you
deal
with
the
storage
versions?
A
But,
on
the
other
hand,
at
CD
in
some
ways
is
an
implementation
detail
of
the
API
server
as
its
data
store
and
the
entire
system
is
built
around
talking
to
the
API
server
and
not
talking
to
at
CD,
and
no
one
should
actually
care
whether
we
run
at
CD
or
maybe
we
replace
it
with.
You
know,
zookeeper
or
something
else
in
the
future.
Everything
should
continue
working
because
it's
really
just
a
datastore
for
the
API
server.
C
D
Going
to
say,
the
fcd
is
an
implementation
detail
so
for
a
user
case,
I
think
they
shouldn't
care,
but
an
operator
of
case
absolutely
must
for
the
reason
you
said
backing
that
I
see
is
not
only
the
hardest,
but
it's
the
most
important
part
of
managing
and
kubernetes
cluster
I.
Think
unless
you
use
something
like
the
operator
to
reduce
debt
by
management,
cost
I.
A
D
Enough
I
just
think
it
in
these
aren't
even
has
to
be
management
problems.
First
aid,
but
battering
at
CD
is
not
sufficient
to
restore
a
kubernetes
cluster
right.
There
they're
a
bunch
of
application,
specific
deployment
details
that
you
have
to
understand
I
mean
in
the
case
of
entity
failure
you
do
lose
some
data.
The
question
is
understand.
What
I
need
is
whether
you
care
I.
E
I
think
this
buddy's
from
my
point
of
view,
is
that
we
I
think
we
have
a
clear
idea
of
how
it
might
be
that
we
do
that
right
in
an
ideal
world,
great
I
think
we
have
a
clear
idea
of
how
to
manage
the
control
plane
through
kubernetes
with
the
component
comfort
I
think
we
have
less
of
an
idea
about
how
to
do
at
CD,
Management
or
how
we
should
run
a
CD.
Even
if
we
had
component
config
working
today
right.
We
have
that
C
the
operator,
but
it
maybe
isn't
the
right
way.
E
A
So
Timmy's
sort
of
alluded
to
the
last
thing
here
so
that
the
first
one
we
mentioned
was
configuration
of
the
control
plane
and
the
last
one
is
actually
managing
the
control
plane
software,
which
is
actually
you
know
what
what
do
we
run
on
a
machine?
So
if
you
bring
up
a
new
machine
that
should
be
a
master
control,
plane
node,
what
actually
runs
there,
and
so
one
question
is:
should
should
sed
run
there
right?
That's
it's
one
way
to
computer
command
either.
You
can
also
point
to
external
entity.
A
That's
run
on
a
separate
set
of
machines,
and
maybe
that's
another
place
where
we
a.
We
can't
be
too
opinionated,
because
everybody's
gonna
have
especially
people
who
are
running
their
own
clusters
are
gonna,
have
a
way
that
they
want
to
run
it
and
where
maybe
that
CV
is
sort
of
treated
as
more
of
a
special
snowflake
than
the
rest
of
kubernetes
control.
Planes
I
think
that
might
be
sort
of
why
Justin
called
it
out
is
because
it's
it's
sort
of
a
different
snowflake
and
it
has
to
be
treated
a
little
bit
differently.
B
Okay,
I
think
most
of
the
topic
areas
under
purview
for
his
goals
are
pretty
non-contentious.
I.
Think
the
one
comment
that
was
in
the
chat
channel
was
possibly
having
non
goals
listed
underneath
add-on
management
such
that
we
don't.
You
know,
we
know
we're
bounded
in
scope
there,
just
DOS,
explicit.
A
Give
suggestions
what
those
non
goals
should
be
I
mean
I.
Think
Adam
management's
tricky
because,
as
I
said,
like
there's
not
really
consensus
on
on
what
that
even
means.
At
this
point,
and
so
it's
not
clear
to
me,
we
we
know
what
it
what
it
doesn't
mean
either
and
maybe
it's
easier
to
say
what
it
doesn't
mean,
because
there's
some
things
that
are
clearly
out
of
scope
but
I'm,
not
sure.
Since
we
don't
know,
what's
in
scope,
exactly
how
to
bounce
that,
and
maybe
just
make
that
clear.
A
E
But
we
didn't
II,
don't
want
to
be
to
build
something
for
for
deploying
like
end-user
applications
with
complicated
templating
right.
It
might
be
that
what
we
build
happens
to
serve
the
purpose
for
basic
applications,
but
it's
not
our
goal
to
build
something
for
the
generic
to,
like
you
know,
replaces
mean
of
CI
CD
system.
A
Okay,
so,
given
that
this
has
been
pretty
unconscious,
I
would
propose
that
we
turn
this
into
a
pull
request
to
put
somewhere
that's
a
little
bit
more
visible
than
the
Google
Doc,
where
we
can
point
people
at
it
and
that
can
be
found
via
search.
I
think
this
Google
Doc
is
pretty
hidden,
and
unless
someone
is
attending
this
meeting
or
reading
our
meeting
notes,
they're,
never
gonna
stumble
across
a
tourist
and
parsec
does,
and
then
we
should
link
it
from
the
community
directory
that
describes
our
things.
A
F
For
now
so
we
can
get
our
own
repo
if
we
want
to
over
time,
but
one
of
the
things
that,
as
part
of
couture
backs
that
I
think
we're
gonna
end
up
doing
is
turning
the
community
repo
into
a
site
that
is
a
pier
site
to
Kate's,
do
something
like
community
decades,
dot,
IO
and
so
they'll
be
sort
of
pretty
rendering
and
easier
ways
to
find
it
and
all
that
stuff.
If
you
keep
in
the
community
repo
and
that.
C
A
Yeah
I
feel
like
it
would
be
useful
for
us
to
actually
have
a
road
map
on
an
endo.
You
sent
out
like
a
doc
for
2018
road
map,
and
that
should
probably
be
in
context
of
where
we're
going
in
general
and
again
I
think
you're.
Putting
that
in
the
community.
Repo
is
sort
of
the
right
place
to
put
it
like
under
RSA
directory
in
the
community,
rebuild.
C
Yes,
at
least
this
right
now
and
the
Cygnus
lifecycle
flash
my
dreaded
from
Viki
roll
back
rub
map
just
like
the
road
map
cluster
deployment
and
it's
basically
the
same
place.
We'd
put
our
like
mission
statements
as
well,
and
if
we
want
and
think
my
2018
roadmap
somewhat
describes,
the
current
stay,
the
Raval.
C
A
C
Yeah
we
should
expand
our
github
team
right
now.
We
don't
have
many
people
there.
I
just
wrote
down
a
couple
of
names.
If
you
feel
that
you
want
to
be
in
this,
these
github
teams,
which
basically
means
if
we
at
kubernetes,
slash
c-class
lifecycle
and
one
team
which
can
be
bugs
feature
quest
via
reviews.
Whatever
you
should
go,
sort
of
I
think
I
had
a
URL
there,
no
I,
don't
anyway,
you
can.
C
B
I
think
we're
gonna
have
to
be
mindful
to
that
some
of
these.
Eventually,
if
you
want
to
get
on
the
orders
files,
that
means
certain
obligations
to
write
like
this,
isn't
basically
a
notification
mechanism
so
be
aware
of
what
you're
getting
yourself
into
you
will
be
spammed
heavily,
so
you
will
don
to
set
up
the
filters
and
whatnot
I
have
like
a
ray
of
filters,
along
with
only
setting
myself
up
to
certain
groups
are
the
notification
ones
and
I
will
fully
get
myself
off
of
the
other
groups
right.
A
C
That
is
basically
I,
think
I
know
this,
so
I
mean
for
me.
It's
a
peer
Alexandra
and
Jamie
at
least
would
be
nice
to
get
there.
You
know
you're,
probably
as
well
from
what
I
understand
is
gonna
help
out
this
quarter,
and
maybe
the
next
ones
as
well.
We
serve
a
Ryan.
If
you
want
I
mean
I,
find
this
useful,
but,
as
Tim
said,
if
you
aren't
too
many
teams,
it's
definitely
a
well
game
to
play.
A
I
mean
I
can
also
force.
Add
people
to
the
groups
to
like
other
people,
you
think
should
be
in
the
group.
You
just
add
them
and
if
other
people
want
to
join,
there's,
there's
a
opt-in
process.
So
if
they're
people
in
the
owners
files
I
think
we
should
just
go
ahead
and
add
them
to
all
the
groups
and
tell
them
we're
sorry
about
the
extra
email
and
then
they
can,
they
can
take
themselves
out
of
the
groups.
C
A
F
Think
is
it
something
that
we
want
to
sign
up
to
support
I,
think
it's
part
of
your
question,
or
should
we
kill
it
I
think
if
we
killed
it
it
would
definitely
make
things
harder
for
folks,
I
figure.
We
have
to
go
one
way
or
the
other
I'm,
not
sure
who
else
would
sign
up
to
own
the
thing.
C
C
C
Okay,
well,
we
have.
We
have
two
different
things,
so
one
thing
is
that
we
run
all
server
processes
inside
of
the
same
process.
At
the
same
time,
I
don't
think
we
want
to
do
that.
That
is
what
mini
cube
is
doing
now
until
this
release
or
something
where
they
switch
to
cubed
M
so,
and
they
basically
want
to
kill
that.
But
on
the
hypercube
side
we
have
a
lot
more
to
discuss
so.
B
We
we
actually,
you
did
a
while
ago,
the
comparison
of
wanting
to
use
hypercube
for
cube
ATM,
and
we
actually
backed
away
from
it
because
of
the
two
major
reasons
that
I
recall
feel
free
to
amend
other
bits,
but
the
other
first
one
was
the
in
it
bottling
does
you
know,
there's
so
many
units
that,
if
you
trace,
if
you
ask
trace
it,
it's
kind
of
crazy.
The
second
one
was
the
the
binary
bloat
in
that
it
was
like
hundreds
of
megabytes
smaller.
When
we
did,
we
separate
binaries
versus
the
funk,
really
that's
confusing.
B
F
So
one
issue
is
that
we
we
started,
throwing
everything
into
hypercube,
including
the
cubelet
and
cube
Caudill,
so
like
it
really
took
on
a
whole
bunch
of
stuff
I.
Think
if
we,
if
we
remove
the
cubelet,
if
we
remove
cube
cuddle,
because
one
of
the
other
things
is
that
when
we
have
the
cubelet
in
there
and
then
we
build
a
docker
image
around
it,
that
docker
image
has
to
bring
in
all
the
dependencies
that
the
cubelet
needs
to
run
when
it's
dog
rised,
which
is
a
lot
right.
F
Whereas
if
we
just
do
the
the
sort
of
the
making
control
plane,
components,
I
think
it
gets
a
lot
smaller.
It's
quicker
to
build
and
it's
easier
to
distribute
when
you're
talking
about
distributing
stuff.
So
so
maybe
the
right
thing
to
do
is
to
is
to
pare
it
down
a
little
bit.
I
I
do
know
that
if
we
decided
to
kill
hypercube
I'm
sure
that
there
would
be
people
who
would
be
upset
because
we
were
in
their
flow
I
know
that
there
are
folks
using
it.
C
Yeah
I
mean
that
anything
is
real,
I
mean
all
the
all
the
gold
EPS
that
kubernetes
has.
Some
of
them
have
a
lot
of
nasty
stuff
that,
when
you
add
all
the
Oh
every
single
package
in
kubernetes
into
the
same
binary,
we
have
even
hit
some
like
going
limits
in
other
versions,
not
recent
ones,
yeah,
the
the
main
benefit,
as
he
said,
is
like
local
development
or
whatever
that
we
can
have
the
same
image
that
we
could
distribute
to
all
places.
B
C
C
C
B
We
we
mark
this
as
a
Help
Wanted
and
leave
the
flag
to
leave
it
open
for
the
time
being,
because
I
don't
think
it's
gonna
be
prioritized
in
the
near
term.
Unless
we
have
a
use
case.
That
makes
a
lot
of
sense,
but
we
can
always
just
mark
the
flag
to
leave
the
issue
open
and
leave
it
as
Help
Wanted,
so
people
who
are
new
to
the
space
who
wanted
to
start
to
spin
up
into
it.
B
C
C
C
Basically
this
as
I
as
I
wrote
in
my
2018
goals
or
roadmap,
as
proposed
once
I'd
like
us
to
require
that
the
the
getting
started
guides
in
the
docs
should
be
marked
come
for,
like
should
have
posted
the
conformance
results
to
CN
CF
/k,
its
performance
I.
Think
that's
Stane
requirement
that
you
can
prove
that
this
is
confirming
this
is
upgradable,
and
maybe
some
sort
of
force
requirement
as
well,
and
by
doing
that,
we
can
actively
reduce
the
number
of
getting
started
guys.
C
C
A
A
C
This
company
has
web
sites
repo,
like
you
bait
em,
like
cops,
maybe
cube
spray
projects
like
that,
but
if
you're
a
vendor
that
as
a
product,
you
may
get
referenced,
if
you
are
confident,
but
not
like
all
your
ducks
into
that
place.
But
if
we
have
this
requirement,
it
would
be
easy
to
remove
a
lot
of
different
I
mean
I've
tried
to
do
this.
C
B
Yeah
the
negative
test,
I
think
that's
a
good
idea,
if
it's
not
conformance
and
they
haven't
updated
and
put
the
effort
in
I,
think
that
we
should
start
trimming.
We've
got
a
lot
of
cruft.
We
got
a
to
maintain
it
over
time.
Actually
leads
people
down
the
wrong
path
right.
It
does
about
it.
So
I
think
that
it
makes
perfect
sense
that,
in
my
mind,
to
have
it
as
a
base
level
requirement
for
removal.
As
Robert
said
earlier,
as.
E
Cups
passes
the
tests
and
I
found
out
the
rules,
and
there
are,
if
you're,
a
vendor,
you
have
to
do
if
you
like,
join
the
CNC
F,
but
if
you're
open-source
community
based
there
is
a
there,
is
a
path
to
getting
on
there.
So
it's
not
a
barrier
for
for
shouldn't,
be
a
barrier
for
anyone.
I
think,
okay,.
A
Other
than
like
it
sounds
like
tongue
isn't
on
the
list
today,
so
we
might
want
to
hold
off
like
you
know,
two
weeks
and
give
cops
and
coops
for
a
sort
of
a
heads
up
saying
this
is
the
plan
we're
gonna
rip,
all
the
stuff
out
that
doesn't
have
a
certification
label?
Let's
you
know,
since
those
projects
should
already
be
passing
all
of
the
tests,
it's
more
of
a
process
of
getting
the
documentation
in
place
so
that
we
don't
sort
of
letter
for
nose
to
spite
our
face
as
we're
trying
to
clean
stuff
up
here.
A
E
C
I
was
thinking
like,
let's,
let's
do
the
announcement
now,
like
we
could
say,
like
you
can
study,
say
with
just
the
conformance
thing
we
could
add
like
you
should
have
ducts
to
upgrade
as
well
or
whatever,
and
but
but
just
start
with
the
conformance
thing
you
should
be
on
that
list
and
if
you're
you
are
not,
you
will
be
removed
right
after
1:10
it's
released
and
then
you
won't
get
into
111.
Doc's
I
think
that's
a
fair
timeframe,
because
it
gives
the
maintain
as
three
months
notice.
C
A
C
A
C
B
Again,
like
I
mentioned
earlier,
my
plan
for
this
cycle
is
not
to
actively
take
on
hurtful
tasks
but
to
facilitate
other
tasks
that
people
are
executing
on
so
I'm
going
to
help
manage
sort
that
list
over
this
cycle
this.
So
we
can
keep
on
truckin
and
also
would
welcome
any
help
for
folks
that
want
to
help
be
facilitating
or
help
facilitate
this
group,
because
it
is
a
non-trivial
of
my
work
just
to
pry
off
the
backlog
is
kind
of
bananas.
B
C
We
really
made
and
I
mean
it's
a
lot
of
just
just
four
cubed
M,
give
us
four
this
repository,
it's
a
lot
of
reviews
that
are
made
every
cycle.
So
it's
a
lot
of
work
and
I
really
appreciate
that
you're
committing
to
help
out
with
that
cool,
TRS
bootstrapping.
Do
we
think
we
could
just
slap
the
GA
label
on
this.
F
H
F
F
C
Yep
and
I've
written
up
as
we
discussed,
cubed
MTG
a
doc
and
that
twenty
seven
twenty
eighteen
roadmap
well
basically
just
extracted.
What
I
had
is
when
eighteen
roadmap
into
a
separate
duck
as
requested,
so
it's
easier
to
share
with
others.
It's
a
draft,
both
our
drafts.
So
please
do
go
ahead
and
edit
them
I'm,
not
gonna,
have
time
to
actively
add
a
lot
of
stuff
there
or
refactor
or
whatever.
So
this
is
in
the
hands
of
the
sig.
C
A
Love
to
see
us
go
all-in
on
caps,
but
I
don't
see
it
being
realistic.
It's
been
a
month
or
so,
since
we've
made
our
first
one
and
we've
kind
of
you,
one
more
I
think
we
should
sketch
out
a
foot
doctor
because
it'll
be
quicker
and
easier
to
review
and
then
maybe
try
to
turn
those
into
caps
and
use
the
caps
going
forward
from
there.
I
mean
we're
already
partway
through
the
one
time
release
cycle
frightened,
so
I
think
we
should
just
do
that
next
week.
A
C
B
C
Code
free
the
release
cycle
begins
today.
It
says
here
it
ends
on
release
day,
which
should
be
Wednesday
March.
Twenty
first
feature
freeze
is
January
the
2nd
of
January,
which
is
in
three
weeks.
We
should
have
a
clear
sense
of
caps.
We
want
to
have
the
seat
well,
the
features
that
are
there
and
create
the
features
issues
for
those
escapes
or
whatever
we
call
them
tracking
items
code
freeze,
which
is
the
one
of
the
most
important
dates,
is
February
26th
and
Doc's
review.
B
That
we
had
bantered
about
it,
but
no
one
had
actually
maybe
I
should
take
this
to
the
community
meeting
and
I
know.
Robert
you
had
mentioned
it
earlier
to
was
whether
or
not
four
releases
per
year
made
still
made
sense
to
go
at
this
cadence
versus
something
like
three.
Has
there
been
any
communication
any
of
that
at
all,
because
sometimes
our
dead
cycles,
like
the
last
release,
was
totally
compressed
which,
having
the
four
per
year,
that.
B
Think
I
should
I'll
try
poking
the
Hornet
nest
on
the
community
meeting,
because
the
the
last
develop
cycle
was
kind
of
I.
Don't
know,
moreover,
the
overhead
to
productive,
useful
code
ratio
was
really
high,
so
the
I
think
three
per
year
makes
a
lot
of
sense
to
me,
but
I
want
it's
a
community
saying
not
again,
you
know
my
team's
opinion.
Roberts
opinion
racing.
C
Yeah
on
on
this
note,
Tim
had
a
very
interesting
talk.
I'm
Tim,
Hawking
I
mean
I,
had
a
very
interesting
talk
at
UConn
on
Colonel's
vs
distres
I
could
link
it
here
as
well,
which
basically
says
that
we
should
release
faster
and
slower.
At
the
same
time,
by
separating
the
code
like
the
kernel
like
the
Linux
kernel
from
the
Ubuntu
like
release
schedule,
they
should
not
be
the
same
and
right
now
they
are
kind
of
the
same
imaginable.
Releasing
every
three
months,
I
mean
or
every
12
weeks.
A
Again,
like
they
was
saying,
that's
one
person's
opinion,
a
different
team
in
this
case
and
there's
not
necessarily
community
consensus
or
anyone
through
changing
processes.
In
response
to
that
talk
at
this
point
we're
still
kind
of
cranking
the
wheel,
as
we
did
last
year,
without
looking
back
and
making
sure
that's
the
right
way
to
be
Noble.
C
Absolutely
yeah
I
mean
that's
yeah,
definitely
just
one
opinion
or
like
idea,
and
for
what
it's
worth
I,
don't
think
he
had
many
that
many
action
items
or
tasks
it's
executed
on
in
a
sock,
so
so
we'd
still
like
as
a
community
I,
have
to
figure
out
some
way,
and
it
might
be
that
we
just
considered
a
is
for
good
banana
stew
or
whatever
and
whatever
that's
gonna.
Look
like
I,
don't
know.
B
I,
don't
I
have
opinions
on
this
conversation
which,
but
I
think
we
should
probably
table
it
for
I.
Don't
know
whether
or
not
sick
architecture
makes
this
well
I,
don't
know
whose
where's
the
landing
location
I'll
start.
The
I'll
start
the
conversation
in
community
and
see
if
it
has
a
landing
home
for
somewhere.
C
C
A
We've
got
10
more
minutes,
let's
move
to
the
next
one.
This
looks
like
sort
of
a
furthering
of
the
conversation
that
Tim
was
mentioning
earlier
about
Tim
taking
over
is
the
sort
of
overhead
manager.
If
you
will
dealing
with
issue
panic,
log
and
I
know
if
there's
anything
in
particular
from
these
links
that
we
want
to
call
out
to
the
larger
group
or
if
we
just
want
to
let
Tim
Tim
triage
and
pull
things
up
that
he
thinks
are
important
today,
supplies
here,
yeah.
C
I
basically
wrote
this
before
I
like
started
thinking
about
it.
I
should
write
it
down
an
issue,
and
now
I've
got
a
issue
with
some
starting
pr's
to
to
look
at,
and
the
contributors
I
mentioned
have
already
created
done.
They
have
already
done
their
job
and
created
the
terrific
PR
and
everything
so
should
be
fine.
A
C
Yeah
I
mean
this
is
basically
I
started
from
the
document
I
had
in
the
Kuban
repo,
but
disgusts.
It
makes
more
sense
to
have
a
more
general
contributing
to
the
sig
verses.
This
is
what
cube
ATMs
release
cycle
looks
like
that's
a
small
but
important
difference
there,
and
this
should
be
more
general
and,
alongside
all
the
other,
stick
related
documents,
not
something
that
sits
living
in
a
queue
very
repo
and
nobody
ever
notices
so
yeah,
Justin
or
Chris.
C
A
A
G
I
played
a
little
bit
about
the
idea
of
implementing
the
cubed
me
in
join
and
masters
and
I
first
prototype
that
works
quite
well,
and
the
videos
like
sand
and
in
the
document
there
is
the
current
limitation
of
the
of
the
prototype
last
time
to
a
couple
fifty
I
did.
We
can
then
consider,
if
make
this
part
of
the.
C
So
from
what
I
saw
at
a
really
brief
just
look
reset
it.
It
seems
like,
like
the
the
current
version
that
you
have.
There
is
more
syntactic
sugar
on
top
of
I.
Instead
of
instead
of
running
cube,
every
minute,
you'd
run
this
joint
it
master,
but
it
would
do
essentially
the
same,
and
you
still
have
to
invoke
the
manual
steps
like
creating
the
load.
Balancer
copying
over
files,
whatever
so
I
I
think.
C
Definitely
the
the
PR
or
whatever
you
have
the
folk.
The
branch,
the
the
place
way
develop
should
have
an
open
PR
and
have
some
some
place
where
we
could
check
the
out
different
ideas.
Prototype
test
try
to
find
some
some
common
ways
to
simplify
and
to
help
out,
but
I'm,
not
sure
whether
it
actually
will
get
merged
before
110.
If
we
prioritize
stabilization
and
go
to
GA
cuz,
it
seems
like
most
of
the
things
you
can
do
with
cube
any
minute
today
or
am
I
wrong.
G
G
But
there
is
a
some
differences
that
doing
this
prototype
I
discovered
some
weakness
in
the
current
API,
come
definition
for
qubit
mean
or
some
weakness
in
the
current
process
of
doing
could
mean
me
in
it.
In
the
second
master,
you
can
create
some
problem
for
for
the
next
updates
and
so
on,
and
so
on.
So
yeah
Cashion
for
me
is
interesting.
Then,
if
implement
or
not
in
this
cycle
is
a
is
another
busy
yeah.
C
C
A
That
was
also
the
last
thing
on
the
agenda,
which
is
convenient,
so
we'll
see
everybody
next
week,
I
will
put
together
the
110
flying
dock
and
we
can
go
over
that
at
the
be
in
the
meeting.
Hopefully
we
won't
take
the
entire
meeting
and,
please
add
any
other
gender
you
I
didn't,
do
have
and
I'll
try
to
get
Walter
to
show
actually
and.