►
From YouTube: 20200407 sig cluster lifecycle
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
According
this
computer,
hello
today
is
April
7th
2020.
This
is
the
standard,
sequester
lifecycle.
As
always,
we
have
a
code
of
conduct
policy
which
basically
boils
down
to
a
paycheck.
If
folks
want
to
add
their
details
to
the
attending
list,
that
would
be
super
useful,
I'll
just
start
going
in
through
group
topics
that
we
can
go
into.
A
Some
project
updates
any
other
topic
search
and
item.
So
if
you
have
things
that
you
want
to
talk
about,
feel
free
to
hit
it
to
the
agenda,
so
the
first
one
I
wanted
to
talk
about
was
we
had
feedback
from
the
cluster
API
call
and
I
decided
to
take
a
look
at
all
the
policy
settings
and
configuration
knobs
that
exist
for
for
zoom
and
I
changed
some
of
the
settings
or
the
entire
state.
Basically,
only
the
host
can
share
screen
now,
there's
a
bunch
of
other
things.
A
We
could
do
to
lock
it
down
even
tighter,
but
I'm
kind
of
leery
to
do
that
in
part,
because
we
have
all
these
extra
policies
from
critics
that
are
in
place
and
if
we
lock
it
down
tighter,
we
get
into
this
weird
state
where
we
could
be
locking
out
people
that
we
might
want
to
bring
it
to
the
fold
to
be
part
of
the
community.
So
I
don't
know
if
other
folks
have
thoughts
here.
B
A
A
But
it's
it's!
It's
basically
like
a
level
of
indirection,
so
like
you're,
gonna
minimize
your
somebody
would
have
to
be
on
the
list
to
know
what
the
password
is
and
they'd
have
to
be.
You
you're,
basically
going
to
eliminate
a
whole
swath
of
focusing
you
can
bisect
to
trigger
it.
Cause
if
you
wanted
to
so
you
can't
just
do
Rando
Rando
pass
would
be
really
rough
to
do
so.
You
could
bisect
and
figure
out
who
are
the
parties,
or
at
least
you
can
have
a
limited
subset
versus
like
a
subset
of
the
universe.
A
Without
the
host
being
there
and
stuff,
or
we
could
have,
we
can
do
a
separate
thing
to
or
could
have
a
a
secondary
person
as
host
to
monitor
the
meetings.
So
if
you
go
to
a
meeting
always
have
two
people
there,
one
person
is
the
active
moderator
and
the
other
person
is
basically
there
to
scan
the
the
guests
to
make
sure
that
they're
legit
and
to
boot
some
boot
bad
actors,
boot
mute.
A
A
D
C
A
So
that
seems
like
a
reasonable
approach
to
me
that
doesn't
isn't
too
bad,
so
we
could
just
keep
the
meetings
the
way
they
are
for
the
time
being,
if
you're
a
host
try
to
find
a
co-host
for
a
meeting.
If
it's
a
smaller
meeting,
you
know
it's
pretty
obvious.
If
it's
a
larger
meeting
this,
this
meeting
isn't
too
large
but
like
close
to
API
calls
can
have
like
30
people
on
it.
You
probably
have
a
co-host
who's
scanning.
The
list.
A
C
So
be
going
back
and
forth
between
the
seek
release
and
the
cigarette
addiction
eating
discussing
the
booth
cube
medium,
it's
sort
of
become
become
a
bureaucracy
loop.
At
this
point,
so
I
decided
to
write
the
documentary
toe
the
feedback.
I
got
and
I
sent
it
to
the
email
to
all
the
mailing
lists.
Don't
tell
the
air
is
that
when
we
move
such
an
acute
care
of
360,
oh
I,
don't
really
know
what
what
version
schema
they
are
going
to
follow.
How
are
we
going
to
release
a
component
in
terms
of
your
picking
the
source
code?
C
Building
it
same
applies
for
cube
ADM,
except
the
difference
with
key
medium
is
that
we
wanted
to
follow
the
kubernetes
release
schedule.
The
latest
feedback
from
signal
detection
is
that
we
shouldn't
be
doing
that,
and
this
used
to
be
like
a
conflict
of
interest
coffee
to
five
years
between
the
different
six,
so
I
decided
to
file
this
email
and
get
the
feedback
on
the
mailing
list.
So.
A
In
the
moving
had
a
tree
talk:
what
year
is
this?
It's
2020,
the
movie
got
a
tree.
Talk
has
existed
for
since
2016,
and
the
problem
is
that
it's
a
logistical
mess
right
like,
and
we
need
to
have
somebody
own
the
logistics
to
what
it
means
to
build
a
distribution
from
a
federated
set
of
repositories
and
no
one's
really
owning
that
so
I
was
always
of
the
mind.
A
You
know,
I
always
said
like
kuba
TM
will
be
like
a
second
or
third
follower
to
those
who
pilot
the
way
and
make
sure
that
it's
extends
due
diligence.
I've
never
been
one
to
want
to
basically
break
into
jail
here.
I,
don't
want
to
be
the
first
sub-project
to
really
do
this
because
I
think
it
we
be
owning
all
of
the
problems
that
come
along
with
it,
and
there
are
many
and
if,
if
sig
release
wants
to
own
that
space,
then
they
should
own
it
and
make
sure
that
there's
a
speck
around
it.
A
C
C
I
opened
a
bunch
of
questions,
ideally
I
agree.
The
cigarette
texture
and
sig
release
should
be
the
author
of
that
deciding
what
we
should
do
with
the
projects,
how
it
should
spin.
It
I
gave
examples
in
the
document
that
some
projects,
like
I'm,
not
gonna,
mention
which
ones,
but
they
made
some
decisions
as
soon
as
keith
was
available
as
a
version-control,
they
started
making
some
moves,
and
that
was
a
long
time
ago.
The
community
is
just
decided
and
made
Simoes
equalities.
A
Don't
see
any
benefit
unless
the
broader
group
secretly
sensing
architecture
have
a
well-defined
process
in
place.
Otherwise
it's
just
a
we
own,
all
the
pain,
right
and
I.
Don't
think
that
is
right
either,
because
in
order
to
get
the
Federated
repository
model,
Tex
you've
work,
you
need
all
the
logistics
done
there
and
the
testing
apparatus
needs
to
be
capable.
Now
the
testing
apparatus
says
since
we've
started,
having
federal
repositories
is
much
more
capable,
but
the
the
actual
release
process,
I,
would
say,
is
nowhere
near
ready
for
this.
B
My
hand
I
I,
also
do
not
think
that
we
should
make
your
baby
em,
be
the
guinea
pig
for
this
country.
Well,
you
might
expect
and
I
I.
Don't
think,
though,
that
we
in
suggestive
lifecycle,
are
gonna,
get
rid
of
the
problem,
because
I
think
we
are
going
to
be
one
of
the
first
to
encounter
the
problem,
because
there
are
things
that
are
being
developed
out
of
treat
like
cloud
provider
or
extraction.
B
Don't
it
does
seem
that
sig
release
is
not
wanting
to
own
the
distributed
release
and
it
does
seem
like
we
are
going
to
have
to
deal
with
some
aspects
of
the
distributed
release
separately
from
Cuba
D
and
where
the
cube
ADM
is
and
yeah
I
feel
like.
We
are
doing
our
fair
share
or
we'll
be
doing
our
fair
share.
C
Yeah
to
buy
the
silly
seek
release
for
the
time
being,
don't
want
to
own
this
distributed
the
release
process
because
they
are
busy
with
other
work.
They
don't
want
to
think
about
this
problem,
but
they
definitely
want.
They
definitely
have
to
start
doing
something
about
it,
because
secret
architecture
is
pushing
for
the
split
of
these
components.
So
it's
like
conflict
between
the
different
six
and
we
are
somewhere
in
between
six
here.
Why,
as
well.
A
Is
there
any
parting
words
of
this
I
mean
I,
don't
really
know
what
the
action
is
here
like
we
can
talk
about
it
sure,
and
but
unless
somebody's
gonna
really
own
the
whole
process
and
I
really
don't
think
it's
in
our
best
interests
to
like
we
can
help
facilitate
once
they
have
a
proposal
and
have
well-defined
semantics
for
how
they
want
to
incorporate
other
or
sub
projects
as
part
of
the
release
funnel
then
sure,
but
I,
don't
I,
don't
want
to
break
in
jail
here.
There's
there's
a.
C
A
C
B
Have
a
follow-up
question
which
was
about
a
detail?
You
said
you
said
that
they
didn't
want.
The
cigar
context
are
encouraged,
Kamini
I'm,
not
to
follow
the
release,
schedule
of
kubernetes
and
I.
Guess
my
I
want
to
clarify
whether
they
meant
don't
try
to
release
at
the
same
time
or
don't
try
to
ally
in
releases
two
different
versions:
minor
versions
of
Cru
Nettie's,
for
example,
so,
like
cops
in
Cuba
diem,
will
likely
for
the
foreseeable
future,
have
a
118,
119
120
version.
B
C
A
How
can
we
possibly
not
follow
the
cadence,
because
how
are
you
going
to
actually
get
signal
that
your
release
is
good
right,
like
you
comedians?
What
is
it?
Release
informing
Stoller's
of
release,
pocket
I
was
released
blocking
now,
if
performing
so
they're
still
using
slash
cluster
directory
to
gate
the
release
which
no
one
uses
so
the
primary
signal
to
block
or
release
as
release
informing
which
we
do
actually
respond
to
is
cuvee
DM
yeah.
A
A
A
D
A
D
We
release
new
a33
I
feel
like
it
was
like
a
week
ago
before
that
11
days
ago.
So
now
we're
working
towards
it,
see,
look
before
just
like
focus
and
like
a
lot,
especially
for
kcp,
and
we
running
test
test
test
like
a
lot
of
enzyme
tests,
and
this
is
like
a
good
place
like
if
folks,
one
okay
involved,
definitely
reach
out,
we'll
be
publishing,
tested
matrix
that
we're
working
on
to
the
community
soon.
D
D
A
Weird
because
normally
we'd
have
like
this
whole
PR
train
and
be
like
coop
con
and
everything
else
so
we're
trying
to
like.
We
got
to
ring
the
cowbell
far
and
wide
to
get
a
lot
of
folks
to
get
engaged
I'm.
Not
quite
certain
I
need
to
think
about
it.
But
if
folks
have
ideas
for
how
to
you
know,
get
more
interested
adoption
outside
of
the
typical
venues
that
we've
had
I'm
all
yours.
G
A
Kubernetes
has
a
main
blogging
website
for
all
the
sub
projects
and
kubernetes
proper
and
usually
every
release
cycle
there
there's
a
series
of
blogs
that
go
out
I,
you
know
talking
about
the
different
features
for
the
release.
Talking
about
all
the
details
were
on
the
release,
train
which
is
train,
seems
to
be
backed
up
for
this
cycle,
but
there
is
not,
it
hasn't
been
published
yet
so.
G
Okay,
thanks
I
appreciate
the
explanation
and
the
reason
I
was
asking
is
I
know
that
you
know
there'd
been
a
little
activity
around
some
newcomers
coming
to
cluster
API.
Recently,
one
of
the
big
ones
was,
it
looks
like
the
airship
project
is
really
getting
involved
in
cluster
API
I'm
trying
to
I
know
they're
they're,
putting
together
some
sort
of
blog
post
to
talk
about
close
to
your
API,
but
it's
kind
of
out.
A
G
A
Well,
I
think
awareness
in
the
community
is
important
and
it's
part
of
our
responsibility
as
a
sig
is
to
make
sure
that
we
as
we
create
sub
projects
and
as
they
gain
in
maturity.
We
want
to
make
sure
that,
like
we,
we
do
the
appropriate
cowbell
for
the
project,
and
typically
this
would
be
done
at
koukin.
But
given
the
certain
circumstances
like,
we
need
to
find
another
way
to
sort
of
raise
that
flag
to
bring
broader
awareness
to.
What's
going
on
in
the
community.
G
Yeah
makes
sense
to
me:
I
mean,
like
I
personally,
have
been
working
on
some
blog
posts
to
talk
about.
You
know
kind
of
the
experiences
that
I've
been
having
with
close
to
API,
but
if
there
were
a
place
where
these
contributions
can
be
made
in
a
more
I
guess
visible
way,
you
know
I'd
be
happy
to
submit
information
there
too.
It's.
G
A
Well
folks
have
thoughts,
feel
free
to
reach
out
to
the
group
I'm
all
the
years,
given
the
certain
circumstances.
I
think
that
there's
there's
adoption
from
a
lot
of
vendors.
That's
for
sure,
I
think
that
I'd
like
to
see
a
raising
bar
of
end-users,
because
what
vendors
typically
do
is
they
wrap
the
functionality
but
I
think
end-users,
giving
you
that
unfiltered
view
of
the
world
which
I
think
is
always
good
to
have,
because
it
keeps
you
honest,
yeah.
A
B
You,
yes,
thank
you
no
particular
cross-project
updates
on
cups.
I
think
we
are
the
most
cross-project
is
that,
like
we
are
continuing
to
try
to
work
towards
the
working
group
Cates
in
for
our
release
process
or
their
artifacts
for
binaries
and
containers,
and
so
I
think
that
is
actually
progressing.
I
think
some
other
projects
here
might
have
already
done
that.
So
that's
exciting,
and
that
will
be
our
next
big
thing
that
will
unblock
the
release
process
from
being
something
which
a
which
I
basically
have
to
do
to
being
something.
We
should
be
more
community
driven.
A
The
last
word
I
had
was
that
they
were
planning
for
the
multi
nodes.
Look
like
cluster
deployment
for
mini
cube.
I
still
would
like
to
get
an
understanding
if
the
roadmaps
or
mini
cube
and
kind
could
somehow
be
converged,
or
that
we
can
have
a
clean
set
of
user
stories
for
a
then
B
or
just
special
together
or
figure
out
how
to
make
one
tool
that
developers
can
go
to.
A
That
is
solves
all
their
major
user
stories,
because
a
big
reason
for
the
evolution
of
kind
was
always
because
that
keep
didn't
support
the
doctor
and
doctor.
So
he
took
a
long
time.
It
didn't
actually
support
multi
cluster
mode,
but
now,
with
these
features
coming
online,
if
there's
a
Venn
diagram
of
overlap
of
user
stories
is
getting
more
translated
and
it
becomes
more
confusing.
I
don't
know
if
anyone
else
has
class
here.
C
My
my
thinking
process
about
the
overlap
is,
we
can
potentially
say
to
mini
cube,
hey.
You
should
stop
developing
these
features,
but
I
told
you
think
this
is
the
right
thing
to
do,
because
mini
cube
had
multi
note
in
the
plans.
Probably
before
kind
existed,
so
it's
not
working
the
project
or
working
on
features
that
they
want
wanted
for
very
long
time,
also
Qaeda's
old
Fermanagh
by
another
sick.
So
we
don't
have
control
there.
Maybe
we
can,
we
can
technically
say
to
bend
hey.
C
H
A
Not
I
don't
want
it's
better
to
use
carrot
versus
stick
here
too,
to
make
it
easier
for
users
right,
I,
think
at
the
end
of
the
day,
having
like
a
person
who
can
outline
the
user
stories
and
make
sure
that
they
all
drive
together
and
there's
a
migration
plan
for
things
to
do
/
still
together,
I
think
that
would
be
in
the
community's
best
interest.
In
my
opinion,
because
I
still
to
this
day
now,
I
get
even
more
questions
about
people
asking
about.
A
What's
the
tool
I
should
use
and
I'm
like
I
want
to
give
them
one
tool,
and
the
answer
is
I.
Give
them
many
tools
and
I
say
for
this
scenario:
use
a
and
for
that
scenario,
use
B,
and
for
this
scenario
you
see
and
anyone
who's
you
come
into
the
communities
community.
That's
a
bad
taste
in
your
mouth
as
a
bad
experience,
because
you,
if
you're
a
new
developer
and
you
want
to
just
get
started,
you
want
things
to
just
work
right.
You
don't
want
to
give
them
like.
A
C
Yeah
definitely
agree
if
we,
but
if
we
see
a
future
sorry
a
project
that
emerges
right
now
we
can
say
here
you,
you
are
going
to
overlap
with
these
in
these
projects.
You
shouldn't
do
this
one,
but
if
these
existing
projects
have
their
separate
roadmaps,
unless
we
tell
them
to
stop
working
on
these
features,
we
don't
really
have
a
way
to
prevent
them
from
working
from
from
doing
this,
work,
no.
A
G
G
A
I'm
not
gonna,
believe
it
because
you
don't
have
folks
here
to
talk
about
it,
but
if
you,
if
you
think
about
this
topic,
some
more
or
if
you
hear
something
I
think
probably
raise
it
to
the
brighter
sake,
and
we
can
have
a
conversation
on
slack.
Let
me
try
to
reach
out
to
them
on
slack
I'll.
Take
it
and
actually
have
to
figure
out
like
hey.
Do
you
guys
have
a
conversion
roadmap?
Yes,
No.
I
F
About
yeah,
so
we
had
some
discussion
about
how
the
cluster
anions
project
can
interoperate
with
cluster
API
and
provides
some
of
the
requirements
that
we
need
there,
especially
when
we
start
talking
about
things
like
CNI
providers
and
information
that
they
require.
That
would
also
impact,
say,
infrastructure
provisioning
for
those
clusters
that
you
want
to
deploy
the
CNI
on
to.
A
Now
that
cluster
API
is
maturing
slowly
but
surely
and
gaining
an
adoption
and
I
think
the
the
state
space
of
add-on
management
is
as
well
as
component
configuration
are
the
two
primary
hot
topics
for
the
next
six
months
to
a
year
to
get
right.
You
know
we've
kind
of
languished
on
both
of
those
for
quite
some
time,
but
their
component
component
can
standard
is
never
pretty
it's
a
lot
of
plumbing
work.
I
think
that
it's
super
useful
for
the
community
add-ons.
I
Yeah
we
we
do
have
a
little
bit
of
tension
in
that
Lea.
They
put
a
lot
of
effort
into
a
kind
of
proof
of
concept.
Implementation
based
around
cube,
ATM
and
and
the
feeling
in
the
the
cube
ATM
meeting
is
that
it
it
can't
it
can't
be
merged
as
a
as
a
kind
of
early
proof
of
concept,
it
has
to
provide
answers
to
a
whole
bunch
of
hard
questions
before
to
move
forward
and
I.
I
I
A
I
A
I
think
I
think
we're
at
the
point
now
where
these
other
tools
are
maturing
enough,
that
and
it's
become
a
problem
for
them
like
there's,
there's
a
bunch
of
problems
that
exist
inside
of
Covidien
and
there's
a
bunch
of
problems
that
exist
instead
of
cluster
API,
doing
add-on
management
for
a
lifecycle
because
of
the
way
it
currently
has
done
that
we
would
ideally
like
to
have
one
solution
here
that
that
can
just
straight
across.
We
don't
have
to
deal
with
it
anymore,.
I
I
A
A
So
I
think,
like
you
know,
once
the
vetting
has
occurred,
if
there's
like
CI
signal
for
doing
upgrades
and
verifying
that-
and
you
know
it's
all
about
due
diligence-
that
we
can
add
it
in
I-
don't
think
that
would
be
a
big
problem.
I
think
one
of
the
we're
gonna
probably
use
source
resource
it.
At
least
you
know
just
being
honest
from
the
VMware
side,
we're
going
to
definitely
eval
add-ons
operator
in
the
next
cycle,
so
we'll
probably
have
more
resources
coming
your
way.
J
Every
time
we
check
in
with
contributors
on
on
their
work
streams
right,
like
they're,
dealing
with
the
same
things
so
I
think
even
from
a
project
management
standpoint,
our
project
management
correctly
enumerates
the
streams
of
work,
but
has
none
of
the
updates
on
what
has
been
done,
which
makes
it
a
little
a
little
difficult
to
determine
like
even
what
streams
of
work
need.
Help.
J
A
Yeah
I
think
we
have
a
broad
set
of
issues
with
inside
of
the
project
itself,
where
there
there
is
a
plethora
of
inbounds,
but
not
a
way
for
us
to
turn
that
inbound
into
meaningful
action.
That
is
tangible.
A
part
of
this
has
to
do
with
you
know
getting
enough
time
for
new
ICS
as
well
as
like.
Some
of
this
areas
are
actually
complicated,
as
all
get-out
I
wouldn't
wish.
Api
machinery
on
on
people
who
are
near
this
space.
J
Yeah
I,
definitely,
you
know,
will
hesitate
to
give
a
shout
out
to
all
of
the
new
contributors
who
joined,
who
you
know
God
on
countless
calls
intro
to
API
machinery
and
discussions
about
why
things
occurred
there.
There
are
some
people
who
took
a
bunch
of
free
time
to
learn
the
hardest
parts
of
got
Tsukuba
denny's,
and
then
they
made
changes
and
they
they
PR.
You
know
test
Suites
and
yeah,
read
about
decoders
and
all
that
kind
of
stuff.
J
It's
got
over
a
couple
of
design
problems
that
are
still
not
solved
and
then
kuba
diem.
On
like
last
week,
we
chatted
about
it.
A
little
bit.
I
has
taken
on
the
support
burden
of
those
unsolved
problems,
and
it's
resulted
in
workarounds
and
some,
in
my
opinion,
design
this
steps
in
the
way
that
cube
idiom
works
and
that
that
creates
a
thorny
or
landscape
to
to
work
with
the
config
and
their
API.
Is
that
back
then?.
J
J
With
the
component
config
implementation,
we
also
took
on
config
management
for
multiple
machines
and
completely
and
then
like.
We
took
on
API
upgrades
and
stability,
but
then
there's
no
conversion,
machinery
that
respects
users.
You
know
declarations,
and
so
it's
there
are
some
missing
pieces
and
we
added
things
to
get
around
problems,
but
we're
not
willing
to
say
like
override
a
config
file.
You
know
for
a
particular
machine,
so
we
don't
support
heterogeneous
clusters
in
some
ways.
J
We've
moved
backwards
with
our
component
config
implementation
and
the
resources
and
agreement,
and
the
support
like
for
versioning
policies
that
we
hold
ourselves
to
have
kind
of
glue
this
in
place
with
making
this
a
good
thing
for
users.
So,
even
just
all
of
that
context
like
trying
to
get
a
new
contributor
to
consume.
Some
of
that
has
been
challenging.
We
really
mean
a
concerted
effort
from
some
experienced
folks
to
for
one
or
two
cycles,
but
have
a
serious
amount
of
time
to
make
components,
standard
a
thing.
I.
A
C
Who
is
already
following
the
corporates?
Others
meetings
in
progress,
you
know,
I,
think
a
very
important
for
us
to
resolve
in
know
in
this
group
in
API,
machinery
is
instant,
specific
component
config
and
there's
a
keeping
progress
for
that.
So
originally
comedian
started
following
what
the
couplet
is
doing
in
the
couplets.
I
have
an
argument
that
the
cooperate
was
doing
some
of
the
stuff
wrong.
C
It
has
a
single
component
coffee,
where,
instead,
it
should
have
been
instant,
specific
corporate
config
and
a
component
config
that
is
shared
across
all
the
loads,
so
we
have
a
design
for
the
couplets,
the
incubator
and
started
following
this
same
pattern,
and
we
have
now
I
have
to
go
back
likely
same
customer
back
fix
this
problem
and
cube.
Atm
and
future
components
have
to
be
adapt.
This
adopted.
J
Yeah
I
think
that
general
problem
of
config
management,
what
is
shared
and
what
is
like
group
or
instance
specific,
is
one
of
the
design
issues
that
we
need
to
tackle
more
formally
and
then
yeah
usability
and
upgrades
and
migrations.
Supporting
these
api's
is
the
other
major
one
that
I
see
if
we
can
get
together
and
solve
these,
then
I
think
we
have
the
designs
in
place
to
then
go.
Do
all
of
the
very
tiring
work
of
fixing
everything.
J
J
Yeah,
just
changing
the
it's
been
said
like
from
the
beginning
that,
like
components,
standard
has
like
very
different
incentives
than
a
lot
of
the
kubernetes
project,
so
I
think
the
struggle
of
like
getting
folks
to
be
able
to
consistently
work
on
it
and
I'll,
certainly
own,
like
choosing
to
work
on
other
things
rather
than
component
standard
because
of
being
incentivized
by
different
things.
So
that's
the
the
one
thing
that
I
can.
Control
and
I
have
not
been
perfect
or
morally
ideal
in
that
regard.
A
Think
one
of
the
things
that
might
help
here-
maybe
we
should
sync
offline
I-
have
a
separate.
We
need
to
talk
about
this,
because
this
has
been
a
long-standing
issue
of
mine
where
we
had
this
technical
debt.
That's
in
the
best
interest
of
everyone
who
uses
kubernetes
and
it
is
not
a
user
level
facing
feature
immediately
so
that
way
it
gets
ill
funded
by
all
parties
in
perpetuity
until
it
develops
the
critical
mass
where
it
overtakes,
which
is
the
like.
You
need
enough
gravity
and
enough
mass
in
order.
B
Cholesteric
I
seems
like
a
we
can
do
it
in
cups
as
well.
Cluster
API
feels
like
a
very
like
cluster
if
it
has
a
better
model
for
this
thing
cup
size
cups
is
obviously
adopting
cluster
API,
so
they
will
be
more
in
the
same,
but
today,
like
there
is
a
a
nicer
model
in
cluster
API
for
what
happens
when
you
change
a
configuration,
how
it
flows
through
a
like
machine
Diploma
into
machine
set.
K
Yeah
we
went
adopting
this
thing
and
end
up
in
the
problem
that
we
have
now
is
that
we
are
stuck
basically
if,
tomorrow,
a
new
release
of
some
component
company
config
comes
out.
We
cannot
support
that
great
well
user,
and
this
is
something
released,
considering
the
number
of
each
other
lining
of
cook
at
me
and.
J
So
things
like
that,
you
know,
are
the
kinds
of
stuff
that
we
have
to
rollback
like
it's
fine,
if
that
is
built
as
an
optional
alpha
grade
feature
that
somebody
can
decide
to.
Maybe
use
I
had
like
shared
instance
configuration,
but
the
more
primitive
thing
that
we
always
needed
to
support
was
like
allowing
user
to
supply
a
crudely
config
like
whenever
they
stand
up
a
couplet
and
that's
not
supported
by
kuba
diem.
It's
supported
from
a
Flags
perspective,
so.
C
A
A
That
was
one
of
the
things
that
we
were
talking
about
when
we
originally
put
it
in
its
memory
serves
me
correctly,
that's
a
long
time
ago
now,
so
we
can
sync
offline
about
this
topic
and
see
how
we
can
try
to
make
progress
here,
because
I,
don't
think
I,
don't
think
it's
in
the
best
interest
of
the
sub-project
or
the
community
to
be
too
stagnant
on
this,
because
these
are
things
that
users
are
asking
for.
So
we
need
to
figure
out
a
migration
strategy
that
makes
sense
Mike.
G
Yeah,
no,
it's
I
mean
it's
interesting
to
us
and
I,
just
I
guess
by
way
of
context,
I'm
a
little
I'm
a
little
newer
to
some
of
these.
You
know,
issues
that
are
going
out
in
the
community
and
I
was
just
curious
if
I
guess
Li
you're
Tim
or
someone
when
you
guys
might
have
like
a
link
or
something
we're.