►
From YouTube: 20210519 SIG Arch Prod Readiness
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
Hello,
everyone
and
welcome
to
today's
edition
of
the
production,
readiness
review,
meeting
sub
project
of
sig
architecture.
It
is
currently
wednesday
may
19th
2021
and
I
think
we're
going
to
start
today
with
a
retrospective
for
how
prr
went
for
the
122
cycle
for
enhancements.
Freeze
david.
Do
you
want
to
kick
us
off.
B
Sure
I
went
ahead
and
stopped
in
good
bad
improvements
and
things
that
were
suggested,
so
I
thought
this
time
going
through
it
after
it
had
been
required
once
before
meant
that
things
graduating
from
beta
to
ga
went
much
easier.
B
The
the
comments
already
there
you
had
the
metrics
and
you
just
had
to
diff
the
like.
Did
you
actually
create
the
metrics
that
eduard
and
did
the
feature
appear
to
work
with
the
scaling
profile
that
it
claimed
it
was
going
to
have?
B
But
the
trip
from
alpha
to
beta
is
like
a
sheer
cliff.
Someone
has
to
climb
the
we
want
alpha
to
be
easy
in
the
sense
of
like
you,
don't
always
know
what
the
characteristics
are
going
to
be.
You
don't
know
precisely
what
you
can
measure,
and
you
know
the
threshold
is
lower
right,
you're,
just
you're
just
starting
with
it,
and
so
we
don't
want
to
make
it
hard.
I
I
think
that
could
be
an
area
where
we
might
be
able
to
make
it
easier
on
people
trying
to
move
forward.
B
C
B
B
People,
because
of
the
beta
guarantees
or
the
beta
desired
guarantees
right.
You
shouldn't
break
an
api.
For
instance,
if
you
miss
a
scaling
consideration
in
beta,
it's
difficult
to
fix.
A
Does
that
change
if
people
are
going
to
beta
with
like,
for
example,
a
feature
flag
as
off
by
default,
for
whatever
reasons
like
there
are
a
few
cases
where
that's
true,
for
example,
if
you've
got
like
version,
sku
concerns
between
cubelet
and
the
api
server.
C
Yeah,
I
think
I
think
that's
the
only
case
where
we
can
think
of
like
moving
some
questions
like
from
beta
to
ga.
I
think
if
we,
if
you
have
like,
but
I
I
I
was
looking
into-
and
I
was
thinking
about
that
too
and
I
think
all
of
the
questions
are
needed
as
soon
as
you
enable
the
feature
by
default.
B
A
Yeah
for
what
it's
worth,
this
is
maybe
a
good
thing.
I
have
found
at
least
because
some
people
had
asked
me,
you
know,
is
the
prr
process,
a
bunch
of
extra
paperwork
or
is
it
helping?
A
And
this
was
my
first
review
as
a
prr
approver
and
for
the
most
part
I
found
that
the
questionnaires
were
actually
really
helpful
that
in
a
lot
of
cases
when
I
was
doing
the
review,
it
wasn't
just
a
no-op
like
I
ended
up
asking
people
questions
and
it
either
helped
them
with
their
designs
or
helped
them
think
of
things
that
they
hadn't
thought
about
when
they
had
initially
gone
to
like
operationalize
their
feature.
And
so
while
I
agree
that,
I
think
the
the
beta
paperwork
is
probably
the
biggest
jump.
A
I
think
alpha
and
ga
right
now
are
pretty
reasonable
in
terms
of
the
requested
stuff.
But
at
least
I
did
do
some
beta
reviews
as
well,
and
I
think
that
it's
it's
not
unreasonable
of
us
to
ask,
and
it
does
seem
to
be
helping.
So
I
don't
know
that
we
can
measure
that
necessarily
yet
I
think
that's
we're
still
waiting
on
data
from
john's
survey,
but
definitely
I
thought
it
was
good
and
I
think
I've
gotten
good
feedback
from
the
folks
that
I
was
reviewing
as
well.
So.
C
C
So
I
think
we
are
catching
real
errors,
and
I've
also
heard
a
bunch
of
like
positive
feedback
from
from
both
people
that
are
that
are
filling
in
the
pr,
but
but
also
from
sig
leads
that,
like
they
are
sometimes
missing,
some
things
and
like
the
additional
pr
review
actually
makes
sense,
even
in
their
opinion,
as
a
second,
like
second
round
of.
A
Review
yeah,
one
of
the
things
that
I've
definitely
found
in
the
like
metrics
and
slo
side
is
a
lot
of
people
going
through
this
process
have
not
thought
about
that
stuff
at
all.
Like
they're,
you
know
developers,
they
don't
really
have
a
concept
of
what
it
would
be
like
to.
You
know
operationalize
this
or
run
it
in
production
and
so
there's
an
opportunity
to
have
a
conversation
like
well.
A
A
So
it
gives
them
an
opportunity
to
be
able
to
think
about
that
and
to
make
sure
that
there's
some
defined
experience
for
the
people
who
are
going
to
be
running
this
feature
on
clusters,
like
I
had
some
really
interesting
conversations
with,
for
example,
stuff
that
like
had
bypassed
the
process
for
alpha
and
beta,
because
it
was
too
old
and
was
going
straight
to
ga
and
I
was
like
well.
How
do
I
know
if
this
is
working
and
they're
like
well?
I
hadn't
really
thought
about
that.
A
D
Just
as
an
observer,
it
seems
like
it's
there's
been
a
lot
of
really
good
substantive
conversations
that
probably
wouldn't
have
happened,
but
the
other
added
bonus
is
that
you're
almost
like
these,
like
sort
of
neutral
third
parties,
as
opposed
to
like
people
who
are
really
like.
I
just
want
this
cap
in,
and
so
I
think,
like
the
quality
of
conversation
and
the
things
that
people
have
picked
up
on,
has
just
been
like
a
huge
sort
of
value.
D
Add
in
the
kept
process
of
like
having
you
know
these,
like
knowledgeable
reviewers
that
aren't
like
you're
personally
invested
in
like
kubernetes,
but
you're
not
personally
invested
in
the
cap,
and
I
don't
know
I've
seen.
People
get
a
lot
of
value
out
of
that,
and
I
just
wanted
to
say
thanks
for
all
of
your
work.
B
Thank
you,
that's
good
feedback.
I
had
a
question
that
I
struggled
with
on
a
couple
reviews,
particularly
for
signoid,
with
how
strict
we
want
to
be
with
how
features
exposed.
Whether
you
know
if
or
not
it's
working
right
like
there
are
features
for
for
cubelets
in
particular,
cubelets
and
storage
are
the
two
that
seem
to
have
this
trouble
where
you
get
back
a.
How
do
I
know
that
it's
working
and
the
answer
is,
it
is
exposed
in
this
run.
B
This
like
xfs
quota
space
command
on
a
node
and
you'll,
know
whether
it's
working
or
not-
and
I
struggled
with
that
because
you
know
sitting
as
someone
who,
like
most
of
our
my
interaction,
is
at
the
level
of
tell
a
customer
to
go
off
and
collect
something,
and
I
look
at
that
data
afterward.
My
customers,
don't
like
the
idea
of
ssh
to
every
single
one
of
your
nodes
around
this.
C
B
There
is
there
there
is
that
part
as
well.
You
end
up
in
in
a
spot,
though,
where-
and
this
came
up
when
I
was
when
I
was
asking
derek
about
how
some
I
don't
know,
the
answer
I
got
back
is
like
it's
exposed
in
some
c
group
status
thing
and
I
was
like
derek.
What
is
this?
Can
I
see
this
and
what
he
tells
me
is
that
there
is.
B
There
are
often
processes,
that'll,
sort
of
fleece,
that
information
and
then
expose
it
back
up
and
he
referenced
c
advisor
as
a
project
that
would
do
that.
Where,
like
yes,
is
located
down
here,
c
advisor
will
summarize
it
for
you
and
then
you
can
gather
it
from
c
advisor,
and
so
I
asked
is
it
reasonable
to
have
the
person
authoring?
The
feature
tell
me
where
to
find
it
and
see
advisor,
and
he
wasn't
as
confident
in
that
right
because,
apparently
I
guess
c
advisor
isn't
optional.
I
think,
and
I
don't
actually
know.
A
It's
it's
not
quite
optional
right
now,
it's
it
would
be
very,
very
hard
to
split
it
out.
I
think
at
some
point
we
want
to
get
rid
of
c
advisor,
but
right
now
it's
intriguing.
So,
okay.
B
Well,
he
described
it
as
you
could
have
other
fleecing
agents
right
yeah,
and
I
don't
know
that
I
want
to
reach
resolution
on
it
on
this
call,
but
it
is
something
I
think
we
should
think
about
how
prescriptive
you
just
want
to
say,
like
you
got
to
give
me
at
least
one
example
that
doesn't
require
me
to
ssh
to
a
node
that
would
sort
of
be
you
know
not
a
huge
bar,
but
hopefully
whoever's
developing.
It
would
be
able
to
know
of
at
least
one
example.
A
C
Yeah
I
have
an
example
from,
for
example,
or
like
problem
with
the
same
category
where,
like
there
is
an
extension
of
a
feature,
but
the
original
feature
is
completely
unmonitorable
and
unobservable,
and
not
all
like
the
example
that
I
had
was
like
from
network
policies
like
there's
no
metrics
for
network
policies,
no
even
network
policy.
Api
object
doesn't
even
have
status
status
field
or
like
struct
inside.
So
there
was
nothing.
So
the
question
is
like:
how
much
can
we
push?
C
Actually
in
that
situation,
if
someone
was
just
adding
a
small
extension
to
like
network
policies
or
some
some
sub
feature,
if
they
feed
the
like
the
the
the
the
bigger
feature
itself,
doesn't
have
anything
so
because
that
effectively
means
that
they
need
to
do
in
many
cases,
it
would
mean
that
they
would
have
to
like
add
observability.
B
That,
or
not.
A
A
My
bad
thing
is
that
I
think
that,
like
more
than
half
of
the
things
that
I
ended
up
reviewing
for
prr,
I
didn't
even
get
assigned
until
the
last
two
days
and
that
made
for
a
very
unpleasant
wednesday
and
thursday
for
me
and
everything
that
had
been
assigned
to
me
sooner
than
that
I
got
to
in
a
timely
manner.
So
it
was
very
frustrating
for
me
to
like
be
sitting
around
waiting
and
just
nothing
was
assigned
and
like
a
lot
of
things,
weren't
ready
or
I
hadn't
filled
out
the
questionnaire.
A
So
I
ended
up
kind
of
like
hitting
a
bit
of
a
wall
in
terms
of
just
the
amount
of
workload
that
got
dumped
sort
of
last
minute.
So
like
is
it
possible
for
us
to
say
well,
the
enhancement
freeze
is
like
blah
date,
but
you
have
to
have
the
pr,
like
questionnaire,
filled
out
like
five
business
days
before
that,
or
something
like
that.
D
I
mean
I'm
not
saying
anything
like
officially,
but
I
don't
see
why
not
like
the
docs
have
a
deadline
for
a
placeholder
pr
and
that's
just
creating
a
pull
request
that
they
make.
People
do,
and
it
seems
like
the
one
thing
that
I
was
going
to
say.
As
I
was
listening
to.
You
was
just
because
everybody
is
really
late.
C
D
Them,
and
so,
if
that's
not
happening,
you
don't
have
to
get
through
them
all,
but
also
if
it
would
facilitate
it
more
by
having
a
deadline
for
the
prrs
to
facilitate
a
in-depth,
solid
review.
I
don't
see
what
the
problem
would
be
because,
like
it
can't
be
like
everybody
puts
it
all
in
the
last
day,
and
then
all
the
pr
reviewers
have
to
scramble
to
get
it
in
and
then
suddenly
the
whether
or
not
it
kept
gets
in
is
like
somehow
on
your
shoulders,
like
that's,
not
sort
of
the
proper
placement
of
responsibility.
A
The
the
chairs
and
the
people
who
are
working
on
them
are
willing
to
put
in
all
this
time
so
like,
if
it's
possible
to
say
the
prr
deadline,
and
you
have
to
have
like
some
pr
in
some
form
open
with
prr,
whether
or
not
that's
like
the
whole
cap
update
or
just
the
prr
a
week
before
the
deadline.
A
If
people
are
okay
with
that,
I
think
it
would
be
really
helpful
because
I
don't
want
to
have
to
like
I
mean
I
must
have
done
like
a
dozen
plus
reviews
just
on
wednesday
and
like
they're,
not
easy.
Reviews
like
you
have
to
go
and
read
through
the
entire
cap
and
think
of
how
all
the
ways
that
the
future
could
potentially
break.
So
I
would
much
prefer
to
space
that
out,
if
I
possibly
could
have.
D
When
I
saw
it
happen
because
I
was
like
well
like
for
the
caps,
often
we
see
people
putting
them
up
at
the
very
last
minute
and
I'm
like
that's
cool
that
you
put
it
up
the
last
minute
but
like
there
also
has
to
be
padding
onto
whatever
your
last
minute
is
because
people
have
to
review
it
as
a
general
matter,
and
you
might
have
to
change
it
and
update
it,
and
I
think
that
it's
very
reasonable.
If
you
think
that
this
is
going
to
facilitate
the
review
work
to
have
the
prrs
in
then.
B
So
I
got
a
question
about
that:
there
there
were
a
lot
of
them.
Was
it
worse
than
last
time
or
better
than
last
time.
I
I
don't
know,
maybe
about
the
same,
but
did
did
we
find
them
they
get
assigned
the
last
couple
days
because
we
didn't
find
them
earlier
or
because
they
weren't
available
earlier
right.
So
I
know
in
some
cases
like
you
know,
there
were
caps
that
were
open
like
two
days
before
a
deadline,
and
they
said
hey.
B
A
Were
it
was
a
combination
in
my
case,
a
lot
of
them
had
been
like
open,
I
think
a
while
before
or
had
like,
had
been
opted
in,
but
there
either
was
not
a
pr
update
opened
or
they
had
opened
the
thing,
but
they
hadn't
filled
out
prr,
and
so
when
I
finally
got
tagged
into
review
like
two
days
before
the
deadline
was
like.
Well,
you
need
to
fill
out
the
questionnaire.
C
Had
one
round
like
I
mean
I
did
one
round,
but
no
one
looked
into
like
my
comments
for
a
week
or
something
and
then
suddenly
they
wake
up
like
a
couple
hours
before
deadline
and
and
they
yeah
they
try
and
in
all
cases
it
was
actually
wasn't
even
applying
the
comments,
but
were
trying
to
convince
me
that,
like
all
the
things
are
not
needed,
and-
and
actually
I
had
an
example
here
where
they
were
explicitly
asking-
also
see
leads
that
maybe
they
can
confirm
that
it's
really
not
needed,
and
maybe
we
can
ignore
that,
and
actually
that
was
that
was
one
of
the
things
that
went
pretty
well.
C
Was
that,
like
siege
leads,
I
had
two
such
cases
from
two
different
secrets
where,
like
they
said?
No
no
no
like
if,
if
he
is
asking
for
that,
like
I
support
that,
like
those
are
useful
in
both
cases,
it
was
about
metrics
actually
or
like
observability,
so
so
that
went
really
well
actually
that
we
have
support
from
the
sikhs
themselves.
D
You
could
always
tell
the
author,
like,
I
think,
you're,
going
to
have
to
submit
an
exception
for
this,
so
that
I
can
fully
review
this
with
enough
time.
I
mean
that
would
also
be
a
fair
request
because,
like
you
have
to
do
your
role
properly
and
if
you
haven't
really
had
the
opportunity,
because
these
are
late-breaking
things-
it's
also
within
the
realm
of
reasonableness,
to
say
that
it
kind
of
sucks,
because
that
puts
the
burden
on
you
personally,
to
have
to
say
it
and
block,
which
is
why
potentially
a
soft
deadline
would
be
better.
D
But
I'm
just
throwing
that
out
there,
like
just
as
a
statement,
because
I've
seen
this
happen
in
various
forms
of
like
late-breaking
things,
and
then
other
people
have
to
hustle.
So
the
exception
thing
is
always
open
for
that
author
and
then
they
can
explain
in
the
exception
why
they
didn't
have.
You
know
their
stuff
up
and
the
pro
done
and
ask
their
stake
for
more
time
and
give
you
more
time
to
properly
reveal
it,
because
we
don't
want
your
reviews
to
be
like
rushed
or
incomplete,
because
then
that
undermines.
A
D
A
B
I
think
we
actually,
if
we
want
to
do
that,
I
think
we
should
show
up
to
one
of
their
meetings
and
and
lay
it
out
and
explain
what
the
challenges
were
and
before
we
go
there.
We
should
try
to
gather
the
information
about
how
many
came
in
late,
I'm
supportive
of
the
idea,
but
I
want
to
make
it
an
easy
question.
A
A
Well,
I
think
we
might
also
want
to
consider
the
stuff
that
got
removed
from
milestone
that
we
also
had
been
asked
to
do
prr
on
and
like
missed
it
completely,
because
there's
a
lot
of
those
where
it
it
was
like.
Please
do
prr
and
I
look
at
it
like
this
is
not
filled
out,
so
I
can't
and
then
they're
like
okay
yeah,
there's
no
way
we're
going
to
get
this
in.
So
I
have
I.
B
Actually,
I
actually
keep
a
little
diary
just
of
all
the
ones
that
I
do,
and
the
exchanges
back
and
forth
and
the
dates
that
happened
just
so
that
there
is
a.
B
Should
an
explanation
be
of
of
why
something
didn't
make
it
be
necessary?
I
have
it,
but
I
only
have
mine.
Do
you
guys
have
a
similar
list?
We
could
find
those.
A
I
think
it's
fair
to
ask
all
of
us
to
maybe
go
and
like
for
the
things
that
we
reviewed
come
up
with
the
list
and
say
like
when
the
prr
questionnaire
was
actually
completed
like
in
terms
of
like,
maybe
when
we
were
assigned
when
it
was
completed,
because
I
think
I
should
be
able
to
find
that
pretty
easily
from
everything
that
I
was
assigned
to
and
approved.
Okay.
B
B
A
Some
of
them
are
also
stuck
in
perma-beta,
so
actually
that
raises
a
question:
how
are
we
finding
like
people
migrating
some
of
these
older
things
to
like
the
newer
templates?
Has
that
been
a
source
of
friction.
B
It's
only
come
up
with,
I
don't
know,
maybe
a
half
dozen
features.
I've
been
a
little
bit
more
generous
in
cases
where
someone's
like
I
created
this
cap,
but
like
this
is
so
old.
It
came
from
the
community
repo
and
you
know,
has
no
formatting
and
doesn't
have
the
same
sections,
but
it's
been
on
and
heavily
used
for
the
past
three
years.
What
should
I
do?
B
I've
been
generous
to
the
point
of
tell
me
what
metrics
looked
as
I
know,
that's
working
a
best
effort
of
how
to
turn
it
off
will
will
be
good
enough.
But
basically
you
know
for
stuff
like
that.
That
migrated
I
have
not
been
as
I've
tried
to
be
accommodating.
A
And
maybe
another
question
around
tooling:
how
did
people
find
like
the
spreadsheet
versus
cuddle
versus
other
things,
because
I
was
basically
only
using
the
spreadsheet
cuddle
was
missing
a
bunch
of
things
for
me.
B
I
didn't
realize
that
I
was
using
cap
control
for
half
of
it.
I
guess
I
switched
over
about
tuesday.
C
A
A
Oh,
yes,
sorry,
I
think
I
said
I
don't
know
what
you
got,
but
I
said
there
were
like
at
least
25
things
that
were
not
assigned
by
the
time
I
went
and
looked
at
the
spreadsheet
and
I
had
been
filling
it
out
based
on
what
had
been
assigned
to
me
according
to
cap
cuddle,
but
also
like
people
poking
me
on
irc.
Sorry,
I'm
slack
not
irc
yeah.
C
A
That
sounds
good.
I'm
also
going
to
add
a
note
here
that
everyone
was
using
an
old
binary
that
john
had
lying
around
because,
like
head,
was
broken.
D
A
Just
have
that
immediately
usable!
Well,
that's
what
happened
for
me,
and
so
that
was
we
asked
them
it
was.
It
ended
up
being
a
little
bit
late
that
we
asked
them
to
add
it,
and
then
they
added
it
over
the
weekend.
So
we
only
really
had
it
in
the
like
the
last
days
of
the
cycle,
but
it
was
super
helpful.
Well.
D
Just
have
you
set
up
in
a
spreadsheet
and
like
if
you
don't
use
it,
you
don't
use
it
because
you're
using
the
tool,
but
if
the
tool
isn't
working
you're
already
loaded
into
the
spreadsheet,
so
that
you
can
have
like
a
more
seamless
kind
of
experience,
and
we
can
just
make
sure
that
you
have
permissions
for
that.
I
think.
A
So
this
was
awesome
and
there
were
a
bunch
of
different
reasons
for
that,
but
some
of
the
things
off
the
top
of
my
head
was
that
it
made
it
really
fast
for
me
to
be
able
to
filter
by
anything
that
got
removed
from
the
milestone,
anything
that
did
not
have
prr
approved,
because
I
could
set
like
the
prr
approved
or
not
approved,
and
I
could
filter
by
that.
None
of
those
things
I
can
currently
do
in
cap
cuddle.
A
A
How
do
we
feel
about
like
the
structure
and
process?
I
know,
for
example,
for
myself
this
being
my
sort
of
first
kick
at
the.
Can
there
were
a
bunch
of
things
that
I
ended
up,
reviewing
that
it
turned
out
were
out
of
tree,
and
so
they
were
kind
of
they
weren't
necessarily
a
noaa,
but
prr
was
optional,
and
so
that
was
a
cool
learning
experience
where
I
got
to
sort
of
both
guide
them
and
was
guided
myself
over
the
course
of
their
review.
A
I
think
we
now
have
that
sort
of
clarified,
but
that
might
be
sort
of
oral
history
as
opposed
to
written
policy.
I
don't
know
if
that's
written
down
anywhere
if
we
want
to
capture
that.
B
I
think
it's
worth
thinking
about
what
that
precise
guidance
would
be.
There
are
probably
some
distinctions
based
on
exactly
what
out
of
tree
is
getting
updated.
For
instance,
if
someone
goes
and
says
hey,
I
want
to
change
structured
merged.
If
right,
I'm
going
to
say,
yeah
prr
is
not
optional
on
that
you
have
to
do
it
because
we
include
that
in
our
core
product
and
if
I'm
going
to
ship
it,
I
need
to
have
confidence
that
I
can
figure
out
whether
that's
working
or
not.
A
Would
so,
I
would
argue,
in
that
case
it's
not
out
of
tree,
because
it's
going
to
get
vendored
in
tree
immediately
and
presumably
we're
sticking
with
the
kubernetes
release
cycle.
The
sorts
of
things
I'm
thinking
of
that
are
like
sort
of
n
a
out
of
tree
are
like
sig
instrumentation
has
some
binary
like,
for
example,
cube
state
metrics,
that's
not
part
of
the
main
repo
and
is
versioned
totally
separately
and
like
does
not
follow
the
kubernetes
release
cycle.
In
those
cases
I'm
just
kind
of
like
it
doesn't
really
apply.
A
There
are
other
things
that
I
think
are
also
a
little
bit
like
the
the
lines
are
blurrier
so
cube.
Adm
was
another
example
where
I
in
reviewing
it,
like
the
only
changes
were
in
cuba.
None
of
them
were
in
any
of
the
kubernetes
components,
and
so,
even
though
I
think
cube
adm
is
still
developed
in
the
kubernetes
kubernetes
repo,
it's
kind
of
considered
an
out
of
tree
component,
so
I
don't
know.
C
B
It
is
out
of
tree,
it
is
clearly
a
sig
project.
B
Some
would
I
say
most:
no,
some
have
actually
written
caps
about
themselves.
B
Trying
to
think
of
whether
I
saw
one
this
release
this
time
there
was
a
whole
csi
driver
provider
which
actually,
I
guess
technically,
the
whole
thing
is
out
of
tree.
It's
for
windows
right,
but
I
think
the
prr
review
for
that
was
was
helpful
because,
even
though
it's
not
a
tree,
it's
it's
going
to.
B
D
Yeah
because
that's
a
that's
a
state
arch
question,
and
I
think
that
the
other
thing
is
that
entry
out
of
tree
is
also
what
the
release
team
will
track
or
not
so
like.
If
you
think
that
there
are
things
that
are
out
of
tree
that
should
be
trapped,
then
I
think
that
that
needs
to
be
a
that's
like
a
totally
fair
thing
to
say,
but
that
should
be
like
a
broader
discussion,
so
that
then
the
release
team
can
properly
track
things,
because
that's
that's
also
like
that.
D
Well,
we're
not
going
to
spend
all
of
our
time
tracking
out
of
tree
enhancements
and
like
there.
There
is
a
push
to
kind
of
move,
those
into
eventually
some
some
other
form.
But
if
they're,
if
you're
seeing
value
and
reviewing
some
of
these,
then
I
think
that
that's
like
a
good
discussion
to
bring
up
in
cigar
potentially
enhancements.
D
I'm
not,
I
guess,
enhancements,
but
it
feels
like
a
bigger
question
in
a
way
than
just
like
an
enhancement,
and
then
I
would
just
say
that,
as
just
one
f,
one
small
follow-up
for
some
of
the
pr
process,
if
like.
If
you
have
specific
things
that
you
think
the
release
team
might
be
able
to
assist
you
with
like,
if
you
like,
when
they
make
a
pass
through
all
of
the
enhancements,
if
there's
a
column
that
you
would
want
them
to
add
to
the
spreadsheet.
It's
like.
D
Oh
there's,
not
a
pr
here
or
some
sort
of
like
pretty
reasonable
tracking
that
that
team
can
do
since
they
make
passes
through
all
of
the
caps
as
well
like
in
the
very
beginning.
I
would
add
that
to
the
belief,
team,
retro,
doc
and
then
people
will
discuss
it
and
then
just
say,
like
yeah,
we'll
do
that
in
the
next
go
round
so
like
because
there's
only
three
or
four
of
you
and
there's
a
lot
more
there's.
Also
these,
like
enhancement,
shadows
and
things
that
are
going
to
be
these
pr's
as
well.
D
So
if
there's
any
support
that
you
need
from
that
team,
I
would
just
think
about
that
and
add
that
to
the
retro
doc.
A
A
D
Add
a
placeholder
into
the
retro
dock
and
then
I'll
just
like
link
it
into
this
thing
and,
like
you
guys,
can
add
whatever
you
want
to
add
to
it,
just
to
be
discussed
on
a
release
team
and
later.
A
I
think
they're
great
I
mean
hopefully
john-
will
get
by
with
reading
the
notes
and
not
having
to
watch
us,
but
in
any
case
the
recording
will
be
there.
We
did
not
go
over
this
things
suggested
section.
Do
we
want
to
briefly
spend
some
time
discussing
that
there
was
a
suggestion
from
stephen.
B
Yeah,
it's
the
only
one.
I
know
of
steven
asked
whether
we
wanted
to
mark
some
caps
is
not
requiring
prr
with
some
sort
of
marker
file
in
the
prr
folder,
so
that
we
would
have
to
say
yeah.
It
doesn't
really
require
it.
I
think
the
decision
of
that
slack
thread.
B
I
believe
you
were
there-
was
that
it's
not
that
common,
and
so
you
know,
if
you
deal
with
two
of
them
per
person
per
lease,
it's
easy
to
just
say:
yeah,
you're
right,
you
don't
need
it
and
I'll
mark
it
for
you.
I
think
that's
good
enough
for
my
purposes.
For
now.
A
Yeah
I'd
be
a
minus
one
to
adding
more
metadata,
I'm
having
a
hard
enough
time
getting
people
to
fill
out
the
required
stuff,
and
I
am
very
happy
to
just
approve
it's
a
no
up,
because
somebody
has
to
go
and
like
look
at
it
to
tell
it's
a
no-op
to
begin
with,
and
my
worry
would
be
that
you
know
if
we
add
that
as
a
lever,
a
bunch
of
people
are
going
to
start
putting
prr
is
not
required
what
it
is
and
then
there
won't
actually
be
a
review.
Well.
A
B
A
Okay,
I
don't
think
do
do
you
have
anything
else.