►
From YouTube: 20200915 SIG Arch Enhancements
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
Hi,
so
I'm
laurie
apple
and
I
guess
I'll
be
hosting
most
of
this
enhancement
sub
project
meeting
today.
As
always,
please
be
excellent
to
each
other
and
follow
our
code
of
conduct,
so
we're
here
today
to
try
to
find
out
what
we
can
do
to
move
forward
with
one
of
our
most
important
long-term
efforts,
which
was
kept
617,
which
was
basically
how
to
implement
a
cups
process
and
enhance
it.
So
for
this
meeting
I
have
spun
out
this
document,
which
acts
as
a
roadmap
of
sorts
it's
aimed
at
covering
one.
A
A
And
then
what
are
our
questions
that
we
haven't
answered?
Yet
there's
a
lot
of
questions
in
this
document
about
status
of
things,
so
my
plan
for
the
session-
and
we
also
have
ricardo
katz's
issue
here.
So
I
don't
want
to
steamroll
over
ricardo
here,
but
if
this
might
actually
cover
the
what
we're
going
to
do
might
actually
cover
this
item
in
some
way.
A
B
Hi,
my
my
item
is
just
like,
as
I
proposed
that
in
this
live
channel,
and
I
think
that
bob
asked
me
or
john
asked
me
to
bring
this
to
the
meeting
okay,
so
this
is
like.
I
think
this
is.
This
is
actually
fast
and
probably
it's
going
to
complement
the
cat.
It's
just.
How
can
we
keep
the
track
off
of
abandoned
future
games
or
how
can
we
keep
keep
the
track
and
deprecate
them
or
make
them
ga,
and
what's
the
problem,
the
process
that
we
want
to
follow.
A
Okay,
I
want
to
try
to
make
that
do
happen,
for
you
and
everyone
else
keep
in
mind
ricardo
with
like
10
minutes
on
this
topic.
So
if
we
can
make
that
happen
plus
one,
so
let's
just
run
through
quickly
what
we're
going
to
do
here.
So
my
plan
is
to
just
review
the
goals
of
the
stock
which
I've
already
started
and
then
how
it's
set
up,
also
most
maybe
done
so.
That
brings
us
to
the
next
step,
which
is
actually
running
through
the
headers
in
the
dock.
A
So
just
looking
at,
like
the
high
level
things
that
we've
called
out
in
the
past
that
we
would
like
to
do
just
so,
we
can
get
a
sense
of
the
narrative
and
the
different
needs
that
we've
pointed
out.
So
to
compile
this
document,
I've
actually
gone
through
github
issues,
agendas,
side,
documents,
past
notes,
like
everything
that
I
could
find
a
related
enhancements
process.
A
I
tried
to
distill
into
the
essence
of
what
the
action
items
were
and
put
them
here
in
a
narrative
that
we
can
follow
and
then,
as
we
go
through
the
items
at
the
header
level,
we
bookmark
with
us
asterisk.
What
is
a
goal
that
we
would
like
to
achieve
during
120.,
so
these
are
like
roots
and
then
the
items
with
the
most
asterisk
will
return
to
in
the
next
step
for
further
clarification.
A
So
we
just
want
to
run
through
this
stuff
real
fast,
knowing
that
we're
going
to
get
to
it
again
in
more
detail
after
we've
done
that
exercise
as
we
go
through
the
doc.
We'll
see
that
there
are
questions
in
yellow,
highlight,
there's,
also,
questions
in
aqua,
which
I've
marked
with
a
aqua
cue,
and
those
are
questions
that
we're
likely
to
not
be
able
to
ex
to
answer
today.
A
But
I
think,
with
the
highlighted
questions
in
yellow,
we
can
because
they're
just
mainly
like
what
is
the
status
of
this
and
then
hopefully
we
have
enough
time
to
discuss
the
items.
We've
asked
us
the
most
to
the
point
where
we
can
actually
think
about
who
might
own
and
drive
them.
What
else
is
needed,
etc,
I'm
from
a
process
and
execution
level,
and
then
what
do
we
do
with
the
rest?
A
And
there
was
a
question
here
about
whether
stale,
caps
and
unresponsive
caps
might
be
related
to
the
above
yeah.
Absolutely
bring
those
bring
your
points
into
that
into
this
discussion
about
that.
A
Okay,
so
here's
our
doc-
and
I
just
put
the
timeline
at
the
top-
to
give
us
a
sense
of
like
what
we've
already
defined
for
like
anything
that
we
do
anything
we
we
want
to
do
we
decide
to
do
for
120..
A
D
Yeah,
like
with
the
folder
and
the
the
cap.yaml
and
the.
F
Two,
do
you
mean
I
mean,
I
think
all
cups
that
are
being
delivered
in
1.20
should
be
in
the
new
format.
I
don't
know
something
about.
I
guess
previously
about
converting
them
all
as
a
as
a
potential
like
I
know,
tim
hawkins
did
try
to
do
that
at
one
point.
He
looked
at
it
and
it
was
going
to
be
a
huge
pain
because.
B
F
So
I
don't
know
how
important
it
is.
What
we've
generally
been
doing
is
the
the
tooling
kind
of
can
interpret
both
types,
although
it's
not
always
successful,
there's
certainly.
D
A
So,
okay,
cool
yeah,
so
please
make
sure
that
we
don't
lose
your
question
just
bookmark
that,
because
I
think
we're
going
to
get
to
it.
A
Everything
is
literally
here,
I
think,
all
right.
So
there
are
two
action
items
just
highlighted
here.
Just
I
didn't
know
where
they
went
so
I
just
put
them
here
that,
but
these
were
established
goals
for
120,
and
I
just
I
don't
know
what
they
are
in
relation
to.
So,
if
you
know,
then
you
can
feel
free
to
move
it
to
the
appropriate
item.
A
A
So
there's
the
upstream
kubernetes
developer,
who
wants
to
complete
a
feature
or
pitch
something
that
replaces
a
proposed
feature
with
something
better:
an
end
user
who
wants
to
consume
a
feature
and
know
what
kept
in
progress
or
what
the
status
of
them
is,
and
this
is
also
like
for
paris,
like
think
of
paris
and
acting
in
her
capacities
like
how
would
we
inform
her
accurately
about
kept
in
the
status
and
then
the
communications
team
is
another
potential
end
user
for
how
to
share
information
with
the
cncf
on
the
blog,
other
and
other
venues,
social
media.
A
Some
of
you,
the
reviewer,
who
once
needs
to
block
a
current
cap
for
some
reason
and
say
chairs,
are
leads
aiming
to
road
map,
their
sig
cycles.
You
know
what
features
do
they
want
to
push
in
a
cycle
and
then
also
align
with
others
and
be
responsive?
You
know,
ideally
to
other
other
people
and
other
cigs
and
other
bodies
in
the
ecosystem.
A
F
I
think
the
reviewer,
I
think
it's
not
just
who
needs
to
block
a
current
campus
reviewer,
who
needs
to
identify
so
so,
like
I'm
thinking
of
identified
caps
that
need
attention.
F
Okay
and
that
could
be
because
they're
assigned
like
as
a
pr
roofer
for
example
or
or
an
approver
or
it
could
be
because
it's
you
know
associated
with
their
sig
or
whatever.
So.
A
Okay,
yeah,
that's
great
context,
so
I
guess.
A
Yeah
all
right,
so
we've
got
that
fleshed
out
a
bit
all.
C
A
F
Before
we
jump
into
the
processing
steps,
can
we
have
a
a
thought
here
or
any
opinions
in
120
of
these
persona
personae?
F
Which
ones
do
we
see
as
the
ones
we
mo
or
or
rather
regardless
of
release?
Which
of
these
do
we
see
as
the
ones
we
want
to
address
more
urgently?
Does
anybody
have
any
thoughts
around
that
I
mean,
I
think.
D
I
I'm
I'm,
I'm
just
the
I'm.
The
enhancement
lead
for
120,
so
I've
gone
through
and
I've
basically
cleaned
up
the
tracking
sheet
and
pinged
all
of
the
all
the
caps
and
everything
they
get
like
a
sense
of
what's
going
on,
and
I
think
the
reviewers
is
kind
of
one
of
the
most
important
user
personas,
because
they're
the
people
who
are
the
most
overwhelmed.
They
don't
always
have
the
context
and
they're
kind
of
the
most
essential.
So
I
think
that
anything
that
can
help
the
reviewers
immediately
is
probably
going
to
help
everybody
else.
A
E
F
D
F
Right,
we
definitely
want
to
validate
yeah,
okay,
the
specific
whether
it's
meeting
requirements.
D
D
A
All
right
so
we're
20
minutes
in.
I
think
we
need
to
go
faster
to
be
able
to
cover.
A
A
A
really
good
pull
out,
it
really
is
defining
a
person.
That's
it's
good,
all
right.
So
the
first
step,
I'm
going
to
just
run
through
these
real
fast.
The
first
step
in
this
process
is
determining
if
a
cap
is
needed
or
not
so
the
following
items
just
address:
where
can
I
go
for
information
about
caps
in
the
process
determining
whether
a
cap
is
needed
or
not,
and
then
ensuring
the
process
is
as
clear
and
streamlined
as
possible
so
that
I
can
like
actually
do
this.
A
So
some
of
the
high
ticket
or
high
level
items
kristen
did
you
want
to
say
something?
A
Maybe
yeah?
Maybe
you
coughed
or
something?
Okay,
all
right.
So
at
the
higher
level,
these
are
like
github
issues,
we've
previously
covered
or
just
questioned,
so
we're
like
big
ticket
questions,
updating
enhancements
repo
documentation
to
provide
guidance.
A
So
there's
a
link
here
I
was
just
wondering
what's
unresolved,
so
if
someone
can
click
through
that
and
and
what
what's
what's
left,
what's
keeping
it
open
and
then
refining
existing
documentation?
A
So
here's
a
couple
of
things
speaking
to
the
need
for
maintaining
leverage
to
ensure
that
we
don't
end
up
with.
Like
perma-betas
during
the
process,
you
know,
there's
there
were
some
documentation
related
efforts
that
would
help
clear
up
some
of
the
process
questions
here.
A
A
A
No,
the
idea
here
is
to
go
to
the
high
level
and
then
we
go
through
details,
but
some
of
these
are
like
medium
levels,
so
I
just
want
to
like,
I
think,
with
this
one,
because
this
one's
kind
of
tightly
packed.
Actually
I
wanted
to
go
through
these
sub
items
too,
and
then
here's
the
formalizing
one
enhancement,
one
cup
for
alpha
beta
ga-
is
that
resolved
or
not.
This
was
also
in
617.
A
A
A
A
A
much
larger
issue
is
revisiting
criteria
and
the
process
for
alpha
beta
ga.
There
are
general
process
improvements
and
clarification
needs.
You'll
see.
Some
of
these
notes
define
a
clear,
workflow
or
guidance
for
graduation
criteria,
settling
questions
about
kept
ownership
like
who's
the
assignee,
these
sorts
of
things.
A
This
is
a
like.
Another
theme.
Just
within
beta
is
using
the
caps
beta
milestone,
and
I
don't
know
why
this
is
a
different
size,
but
it's
just
basically
it's
the
information
on
using
this
clear
or
consistent
or
documented.
A
A
How
could
we
limit
the
lifespan
of
cats
that
are
unresponsive
or
abandoned
these
sorts
of
things
step
3a?
This
is
about
the
tooling.
A
A
A
A
E
Yeah,
oh,
I
think
the
metadata
split
from
kept
text
is
done,
at
least
with
the
change,
the
the
format
of
go
like
breaking
it.
Out
from
the
read
me.
A
Oh
okay,
that's
like
the
cap
down.
A
E
A
Okay-
so
I
so
I've
put
this
here
is
that
is
that
accurate.
D
F
A
So
yeah
that
comes
a
little
bit
further.
It
should
be
really
soon
okay,
so
these
two
we
think
are
resolved
then
so
we
have
the
automating
generation
of
cups
and
then
there's
the
automation
of
the
graduating
tracking
validating
capture
approval
phases.
A
So
this
is
where
it
got
a
little
tricky,
because
we've
had
the
question
all
along.
What
does
kep
cuddle
actually
do?
Do
we
need
more
tools,
so
I'm
trying
to
trying
to
present
the
info
with
that
question
in
mind,
but
first
there's
just
one
other
side
issue
to
this
process,
which
is
defining
the
triage
and
tracking
process
for
these
kind,
dash,
feature
issues
and
prs
and
kk.
F
What
is
the
so
automatic
automate?
Graduated
tracking
validating
capture
approval
phases?
So
so
I
think
we
need
to
rework
like
how
we
how
we
use
the
feature
tracking
issues
versus
the
cap
metadata
and
then
there's
discussion
of
the
sort
of
ticketing
system
for
for
enhancements
and
inclusion
in
a
like.
We
need
that
right
up
or
that
discussion
or
somebody
needs
to
think
through
or
propose
what
that
actual
workflow
is-
and
I
guess
this
this
is
part
of
that.
But
it's
not
maybe
the
whole
thing.
A
Yeah,
that's
why
we
need
to
figure
out
what
the
entrance
door
to
that
question
is.
So
you
have
a
lot
of
options
here
so,
like
you
know,
just
moving
through
the
rest
of
the
list
deciding
what
kept
cuddle
should
cover
and
not
cover.
This
was
high
priority,
so
I've
put
some
notes
about
how
it's
been
framed.
A
Current
features.
This
is
actually
a
question
because
I'm
not
100
clear
still
and
how
how
this
thing
works
and
what
it
does.
So
you
we
can
cl.
You
can
clarify
that
all
and
then
the
next
item
here
is
defining
and
implementing
automated
receipts
process
to
help
enhancements
team
divest
from
cat
hurting.
A
E
I
think
I
think
much
of
the
automate
graduating
tracking
and
validation
also
goes
hand
in
hand
with
the
automating
of
receipts,
because
those
two
workflows
are
sort
of
tied
together,
at
least
from
the
the
previous
talks
of
how
the
sort
of
entire
thing
would
work.
A
A
Yeah
and
then
here's
the
cap,
no,
it's
confusing
here's
the
capyama
improvements,
so
I
found
two
issues
related
to
this
and
there
might
be
others
that
we
need,
but
I
think
the
question
here
is:
are
they?
Are
they
in
the
right
place?
So
do
they
go
with
anything
else?
We've
already
covered.
C
F
Probably
they're
about
the
validation
of
caps
but
they're
about
the
the
tool,
not
the
process,
which
everything
I'm
trying
to
find
where
the
things
are
in
the
dock.
A
Yeah,
like
they're
still
in
that
validating
header,
so
they
are
under
that
umbrella.
But
it's
really
like
what
helps
you:
okay,
okay!
So
then,
after
that,
there's
basically
just
one
more
step
which
is
making
the
website
and
I'm
not
meaning
technically
right,
maybe
all
the
technology.
Maybe
all
the
tools
just
make
this
website
as
a
side
effort,
but
you
know
that
final
publicizing,
what
kept
their
lives,
what
they
need,
how
which
ones
need
help
social
media
guidelines.
F
So
one
of
the
questions
that
I
see
there's
two
things
I
see
kind
of
popping
up
a
couple
times
in
here.
One
is:
how
do
we
get
the
attention
of
reviewers?
You
know
when
a
cap
needs
urgency,
like
that's
it's
kind
of
expressed
in
different
ways.
F
This
last
one
of
these
questions
that
was
just
in
one
of
them
was
like
and
kirsten
brought
up
code
being
merged
like
how
do
we
prevent
disconnect
between
the
truth
on
the
ground,
like
what
codes
merged
for
a
feature
and
whether
the
feature
is
in
or
out
of
the
release
and
yeah?
You
know,
and
that
gives
back
kind
of
to
like
well
maybe
to
the
future
gate
piece
like
like
if
people
just
merge
code
and
they
don't
update
the
cap,
the
code's
still
still
in
the
release
right.
D
Well,
I
also
see,
I
also
do
see
people
like
kind
of
getting
pr's
in
and
then
they
open
a
cap
and
then
they're
like
oh,
like
and
then
people
kind
of
disagree
with
the
cap,
but
they
already
kind
of
merged.
Other
pr's
that,
I
guess
people
didn't
know,
was
a
part
of
something
else
that
they
planned.
So
I
think
some
kind
of
I
don't
know
so
this
is.
E
F
A
A
A
F
And
I
don't,
I
don't
think
personally
my
step.
One
determine
the
cap
is
needed
that
right
now,
christian's
saying
that
that's
still
somewhat
of
a
problem
in
the
sense
that
like
people,
merge,
stuff
and
then
create
the
cap,
which
is
a
problem,
but
that
addressing
that
is
probably
more
about
continuing
education
for
the
the
reviewers
yeah.
The
change.
F
And
making
sure
people
realize
this
is
really
important
to
do
in
order
for
the
rest
of
the
product
to
have
visibility
into
what
their
city
is
doing.
I
I
think,
if
there
are
questions
there
around
refining
the
criteria,
it
is
somewhat
of
a
judgment.
Call
right
of
oh,
that's,
just
a
minor
tweak
versus
that's
something
that
we
need
to
have
consensus
on.
F
D
E
F
Sig
there
are
things
that
come
out
of
the
weird
horizontal
segments
like
arch
and
scalability.
In
my
opinion,
like
I
don't
and
this
you
know
a
process
like
that's,
not
most
people
right.
Most
people
want
to
build
some
feature,
so
it's
built
around
the
80
case
and
I'm
not
sure
that
we
need
to
resolve.
F
I'm
not
sure
that
resolving
this
will
help
very
many
people.
That's.
D
That's
wrong
yeah
for
those
like
a
lot
of
times
like
even
just
as
the
enhancements
team
you
just
like
do
like
a
track
out
of
tree
or
whatever,
because
it's
not
going
to
necessarily
follow
the
same
process
as
like
a
normal
like
sig,
node
feature
or
something
so.
E
A
Oh
right,
that
would
be
another
group
that
would
have
this
need,
for
whatever
reason
my
browser
doesn't
it's
weird.
D
Like
just
going
going
through
all
of
the
caps
this
weekend,
like
there
were
only
maybe
like
three
caps
that
would
be
like
is
this.
I
mean
if
you're
talking
from
a
cosmic
sense
like,
should
this
be
a
cap
versus
some
sort
of
policy,
something
like
there's
not
very
many
of
them.
F
F
The
process
and
the
tooling
don't
or
the
tooling
rather
doesn't
support
that
super.
Well,
we
tried
to
make
that
better
with
the
617,
where
we
created
these
not
resolved
denotations,
you
can
see
it
there,
but
I'm
not
sure
how
well
that
works,
because
we
don't
have.
We
would
need
to
support
like
that's,
that's
actually
good.
I
would
need
something
to
say.
F
F
What
one
question
I
have
is
do
peop,
maybe
bob
you
would
know
this,
and
I
I
don't
know
if
we
have
any
way
to
measure
this
but
like
what
is
generally
people's
workflow.
Are
they
github
notifications?
Are
they
the
pr
dashboard.
F
E
It's
unfortunately,
all
of
the
above,
like
everyone,
has
their
own
different
workflow,
generally
dependent
on
honestly
how
much
stuff
they're
subscribed
to
one
of
the
big
things.
So
the
you
know
keps
did
have
something
where,
like
there
was
a
status
like
it's
like
not
accepted,
or
you
know
that,
like
you
know,
we
are
actively
agreeing
not
to
do
this,
but
those.
F
E
Yeah,
because
going
back
to
the
thing
of
saying
no
just
generally,
people
don't
want
to
do
that
sort
of
thing.
Ideally
before
you
know,
a
cap
is
necessarily
drafted.
It's
discussed
with
the
you
know,
owning
sig
and
in
many
cases
that
does
occur,
but
there
are
there
are
places
where
they
aren't
and
that's
where,
where
things
can
start
to
get
a
little
a
little
hairy.
F
E
Actually,
I
have
an
idea
for
that:
one:
okay
and
in
either
you
know
keps.yaml
or
the
template
or
whatever
essentially
make
it
a
requirement
to
have
like
a
link
to
you
know,
either
the
meeting
notes
or
some
other
document
where
the
original
you
know
what
prompted
it.
E
F
D
B
D
Like
you
know
like
before,
people
start
saying
like
yes
to
it,
like
try
the
flat
channel,
try
the
mailing
list,
try
the
you
know
sig
meeting
and
I
think
a
lot
of
people
just
they
think
if
they
open
a
cap,
they
just
they
float
in
and
they
open
the
cap
and
then
they're
like
okay,
like
is
john
gonna,
read
this
now
and
approve
it
and
I
think
making
that
mandatory
like
whether
it's
a
sponsor
or
whether
it's
like
proof
that
you
socialize
the
idea
at
least,
is
going
to
cut
down
on
a
lot
of
the
confusion
of
like
what
do.
F
So
if
you
want
to
give
time
to
richard
ricardo,
but
just
we've
also
talked
in
the
past,
about
having
what
requiring
caps
to
have
a
sponsor
or
a
shepherd
yeah,
that's
well
known
in
the
sig
I
mean
we've
talked
about
leads,
but
I
think
that's
putting
too
much
on
leads
personally,
but
it
has
to
be
somebody
that
is
well
known
and
involved
involved
has
credibility.
Maybe
you
need
to
be
an
approver.
F
Maybe
that
would
be
a
way
to
measure
that,
as
opposed
to
a
lead
that
would
kind
of
probably
be
the
second.
D
It
might
be
another
release,
so
you
have
to
be
kind
of
committed
to
socializing
your
idea
and
getting
feedback
on
it,
and
you
know
doing
all
of
the
work
I
think
is
gonna
actually
cut
down
on
a
lot
of
the
problems,
because
people
are
gonna
know
better
what
they're
getting
into
like
immediately
instead
of
just
like,
I
have
my
pr's
up.
I
have
this
cap.
Can
somebody
approve
it
so
I
can
merge
it
which
isn't
really
gonna
happen
better.
A
E
A
F
I
would
just
leave
it
here.
It's
fine,
I
mean
yeah,
we'll
need
to
take.
There's
going
to
be
because
of
the
way
that
the
structure
right
there's
going
to
be.
We
want
to
do
process
so
we're
going
to
go
through
and
and
identify
process
points,
and
then
we're
going
to
have
to
like
rework
them
to
fit
how
they
fit
to
the
tooling,
because
which
is,
I
think,
the
right
way
to
do
it,
but
it's
we
don't
need
to
do
it
right
now.
E
F
B
A
D
A
A
D
A
A
D
Add
it
you'd
add
it
to
a
template
and
then
you
would
make
it
a
triage
step
for
the
enhancement
team,
and
I
would
say
you
know
before
you
can
proceed
on
any
cap.
You
just
have
to
make
sure
that
this
is
filled
out.
If
this
is
sold
out,
then
it's
a
no-go.
D
E
So
yeah
like
sorry
how
about
go
for
it.
F
F
So
we
just
need
to
sign.
E
This
is
great,
and
but
now
we
do
have
we
are
at
the
last
10
minutes,
so
we
should
switch
over.
A
A
E
Yeah
I'd
say
let
let's
move
that
one
to
slack
at
least
for
now.
Just
so
we
can
cover
the
next
topic.
Yep.
C
Great
so
here.
B
We
are
so
what
happened
here.
I
was
going
to
send
you
the
the
issues
first,
but
I
think
this
is
pretty.
B
I
can
explain
by
this
those
issues,
so
tim
hawking
started
to
open
a
lot
of
issues
in
our
sig
network
meeting
to
move
or
deprecate
or
make
them
ga
a
lot
of
feature
gates.
That
seems
to
be
abundant,
so
we
had
like
the
ipvs,
that
is,
it's
ga,
since
110
or
111,.
B
And
other
ones,
so
this
is
like
the
the
ipvs.
It
didn't
got
any
logics
inside
the
code
that
needed
to
be
removed.
Only
the
cube
features
stirs,
and
then
we
asked
it
for
jordan.
For
for
jordan,
egypt.
C
B
What's
the
the
deprecation
lifecycle
of
this,
and
he
told
us,
okay,
you,
you
cannot
like
move
this
one
from
amin.
I
mean
it's
also
in
the
in
the
meeting,
because
even
if
this
one
it
was
marked
to
bga,
I
think,
was
on
the
one
118.
B
So
this
those
are
the
this
is
the
case.
This
one
is
another
case,
but
this
what
happens
in
this
one
is
that
this
feature
game
was
marked
to
be
to
move
it
to
ga
in
one
119,
and
I
think
it
wasn't
and
then
to
remove
it
in
one
one.
C
B
One
so
the
question
here
is:
how
can
how
can
we
keep
the
thread
of
those
feature
gates
that
need
to
be
moved
and
they
need
to
be
blocked,
so
we
can
keep
the
the
code
clean.
So
I
I've
tried
to
like
assign
a
milestone
in
sorry.
I
think
this
one
so,
okay,
if
we
are
going
to
remove
this
on
one
122,
I
can,
I
won't
just
assign
a
milestone
and
then
the
the
c
release
or
the
c
architecture.
Someone
can
keep
the
track
into
this
one
and
oh
you
forgot
to
move
this
to
ga.
B
V130,
you
know,
and
in
v130
you
you
need
to
move
that
tube
to
better
to
better
or
to
remove
that
from
the
comb,
and
when
you
move
that
to
better
you,
you
can
close
that
that
previous
issue
and
then
open
a
new
one
to
move
that
to
ga.
So
you
cannot
lose
that
you
don't
lose
the
track
or
future
gates,
and
you
and
those
those
kind
of
stuff
doesn't
happen.
I'm
still
waiting
for
jordan
and
two
team
to
decide.
I
I
don't
know
if
it's
only
them
or
if.
B
E
That's
actually
maybe
make
feature
gates
a
require,
not
necessary
required
field,
because
some
things
won't
have
them
make
them
a
field
in
like
the
kep
metadata.
So
that
way
you
have
specifically
listing
it.
Yeah.
F
F
We
kept
at
yama
already
asks
for
the
feature,
gate
or
gates
associated
with.
We
have
one
endpoint
slices
that
has
two
different
feature
gates
for
for
featuring
the
future
gain
associated
with
it.
So
as
we
move
a
cap
from
through
the
process,
which
is
also
in
the
kept.yaml
right,
we've
got
alpha
what
releases
it
goes
to
alpha
where
at
least
it
goes
to
beta.
What
releasing
goes
to
ga
we.
F
We
may
need
to
have
some
way
to
ask
postga
right
to
say,
flag
this
and
say
this
one,
ga
last
release
or
two
releases
or
whatever
our
policy
is
the
future
gate
is
still
there.
I
don't
know,
that's
a
great
question
like
how
much
of
this
we
can
automate,
because
people
forget
stuff
or
you
create
an
issue,
and
then
people
walk
away,
and
you
know
if
they're
one
of
200
issues
for
the
sake
and
they
don't
notice
it
so
like.
We
need
a
way
to.
D
D
D
You
could
mark
it
as
implemented,
but
leave
it
in
the
milestone
so
that
the
only
things
that
remain
in
the
github
issue
milestones
are
these
feature
gates
that
need
to
be
removed
or
tracked
or
whatever,
and
then
somehow
automate
that
and
say,
like
hey
sig,
whatever
you
have
like
you.
Have
these
things
open
like
that
would
be
like
probably
the
easiest
way,
because
there
is
that
step
for
the
enhancements
of
going
through
and
closing
the
milestone.
D
D
That
would
be
one
way
to
track
it
without
adding
like
a
ton
of
process
and
then
automate
the
pings
off
of
that
and,
like
just
add
a
flag
that
says
like
like
so
the
kepler
would
say,
implemented,
maybe
something
with
a
feature
gate
and
then
maybe
a
issue
tag
with
futuregate
or
something
and
then
constantly
ping,
whoever
about
those
things
that
are
open
there,
I'm
just
making
this
up,
though.
So
I
have
no
idea
if
this
is
a
good
idea
or
not.
F
I'm
not
sure
I
don't
know
about
leaving
stuff
in
the
milestone.
I
don't
know
who
else
is
using
that
and-
and
you
may
know
so-
that
may
well
be
the
right,
the
third
a
viable
way
to
do
it.
It's
not
what
I
would
think
of
as
miles
like
the
thing
is
that
the
feature
gate
removal
doesn't
happen
in
the
same
milestone
the
future
right
future.
The
feature
gate
removal
happens
in
a
future
milestone.
So
the
question
is
how.
D
D
Workout,
why
not
make
a?
Why
not
when
you
have
to
mark
your
capacity
always
the
thing
is
you
always
have
to
go
back
and
mark
your
cap
as
implemented,
and
then
it
has
to
be
removed
from
a
milestone.
So
there's
that
action
that
has
to
happen
and
if
there's
something
that
that
makes
like
a
feature
milestone,
generated
or
something
that
that
is
trackable
like,
I
think,
that's
the
that's
the
spot.
D
Right
so
we
have
a
matter
of
writing
up
some
some
process
and
then
making
sure
that
the
people
who
own
the
feature
and
then
also
the
enhancements
like
lead
or
whoever
was
just
gonna,
go
through
and
like
double
check
things
that
are
implemented
like
because
that's
two
sets
of
people
that
would
look
at
it
and
then
make
sure
that
this
other
thing
is
generated.
As
they're
closing
out
the
milestone.
F
Yeah,
I
think
that's
probably
the
best.
That's
the
thing
we
can
do
right
now.
I
will
bring
up
one
thing:
quick,
you
know,
we're
out
of
time
is
that
we.
B
C
F
Api
is
deprecated
on
the
on
your
api
on
your
control,
queries
and
we're
also
in
another
release
or
so
gonna
start
automatically
stop
serving
apis
after
they
age
out,
and
they
haven't
gone
from
beta
to
ga.
It's
a
little
pressure
to
stop,
leaving
things
in
beta,
so
we
might
want
to.
B
Is
this
was
a
question
that
I've
made
to
jordan
if
we
warn
a
user
when
he's
using
a
ga
feature-
and
he
showed
me
in
the
call
that
yes,
we
already
do
this
so
here
it
is.
C
B
So
if
the
future
is
ja,
then
we
are
going
to
issue
a
warning
that
you
are
setting
a
ga
feature
and.
F
So
can
we
okay?
We
should
also
see
if,
like
I
suppose,
the
issue
is,
if
you
don't
remove
the
feature
gate
and
somebody
uses
it,
then
your
your
start.
Your
execution
of
the
process
fails
right,
so
I
I
don't
know
if
that's
really
a
failure,
condition
or
as
or
as
another
warning,
but
anyway
it
should
be
rather
but
we're
out
of
time.
So
maybe
we
can
bring
that
up.
D
F
Yeah,
I
agree
yeah
yeah,
if
you
can,
that
would
be
awesome.
If
you
can
do
that
ricardo
before
we
go,
could
you
link
this
ticket
in
the
agenda
so
that
it's
easy
for
us
to
find.
C
F
C
B
F
Okay,
so
I
think
that
we're
pretty
much
we're
out
for
past
time
and
I
think
that
two
things
come
do
not
let
ricardo
one
is
kirsten's
team
for
the
release.
Team
is
gonna,
create
future
issues
for
when
future
gates
are
supposed
to
be
removed,
to
send
in
the
future
milestones
and
then
we'll
try
to
follow
up
more
on
the
tickets
around
whether
there's
other
things
we
can
do.