►
From YouTube: 20210624 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
Hello,
hello:
everyone
today
is
june
24th.
This
is
the
bi-weekly.
It
is
bi-weekly
right,
yeah,
bi-weekly,
sub-project
meeting
for
enhancements.
This
is
enhanced.
The
enhancements
sub-project
is
a
sub
project
of
sig
architecture.
This
is
a
meeting
that
will
be
recorded
and
available
on
the
internet
later.
So
please
be
mindful
of
what
you
say
and
do
please
be
sure
to
adhere
to
the
kubernetes
code
of
conduct
and
in
general,
just
be
awesome
people.
So
we've
got
a
pretty
short
agenda
today
kirsten
do
you
want
to
take
it
away
with
your.
B
A
A
Sure
yeah,
let
me
you
have
access
hold
on.
B
Okay,
cool
we're
only
looking
at
what
we
should
be
looking
at
so
yeah.
Basically,
I
was
going
through
a
lot
of
the
enhancements
like
I,
I
was
trying
to
go
through
a
lot
of
like
the
enhancements
to
do
and
a
lot
of
the
sort
of
ideas
that
we
had
and
the
one
thing
that
struck
me-
and
this
came
up-
I
came
up
with
it
in
the
last
meeting-
was
that
a
lot
of
them
seem
to
depend
on
like
having
an
existing
infrastructure
for
kind
of
iterating
on
caps.
B
So
there's
a
couple
of
things
that
I've
noticed
across
time
is
that
we
make
sort
of
incremental
changes
to
the
cap,
template
which
is
okay
like
when
we
were
getting
trying
to
get
the
cap
template
to
a
point
where
it
made
sense.
But
I
feel
like
we're
now
sort
of
mature
enough
to
say:
okay,
we're
not
going
to
just
like
merge
incremental
changes
into
a
template
that
is
active
that
everybody's
using
and
it's
for
a
couple
reasons.
First,
we
have
some
tooling
that's
being
worked.
A
B
We
have
a
website,
that's
being
worked
on.
We
want
to
increase
sort
of
communication
about
the
template
and
say
like
hey
like
this
is
eventually
like.
We
want
to
version
the
template
and
say
this:
is
you
know
the
version
that
we
expect
you
to
be
on
and
have
some
policy
for
that,
and
also
we
don't
have
like
a
great
way
to
like
gif,
templates
or
or
even
even
start
versioning
them,
because
we
don't
ever
have
like
the
template.
B
We
just
have
a
document
in
the
directory,
and
so
I
thought
that
a
good
way
to
start,
because
this
seems
also
like
a
prerequisite
for
a
lot
of
other
things
like
we
want
feedback
and
we
want
to
iterate.
Well,
how
do
you
iterate
on
something?
Or
how
do
you
start
creating
these
draft
things
and
start?
You
know
thinking
about
new
ideas
if
you
can't
like
have
a
stable
way
to
say:
okay.
Well,
this
is
the
working
one.
B
This
is
this,
is
this
is
the
active
template
and
then
this
is
the
one
that
we're
working
on
so
to
me,
like
this
kind
of
seems
like
a
key
thing
to
do
as
a
basis
for
a
lot
of
the
improvements
that
we
want
to
make,
and
that's
kind
of
why
I
started
to
just
focus
on
this
idea.
A
B
Having
the
active
template
but
then
having
a
staging
directory
and
having
all
of
the
changes
that
people
want
to
go
into,
the
template
go
into
the
staging
directory.
That
is
potentially
periodically
reviewed,
and
then
you
know
batched
out
in
some
way,
whether
it's
an
official
version
or
it's
an
unofficial
version
or
whatever
just
to
bring
some
stability
to
the
existing
template.
Because
I
do
think
that
it.
I
think
that
the
increments
mental
changes
are
actually
harder
to
catch
from,
not
there's
no
version
so.
B
But
I
think
that
the
incremental
changes
are
are
hard
to
identify
and
it's
hard
to
say,
hey,
like
people
really
need
to
have
this
update
or
that
update,
and
I
also
want
to
start
thinking
about
versioning
the
caps,
but
also
like
coming
up
with
a
versioning
policy
and
other
things
so
like.
This
is
just
like
a
bare
bones
idea
that
I
just
threw
up
a
pr
just
to
like
kick
off
some
kind
of
discussion,
because
it's
gonna
probably
require
some
other
things.
B
But
all
I
did
was
since
this
is
what
I
talked
about,
and
I
know
I
talked
about
it
with
bob
as
well.
Like
was
just
creating
a
staging
directory,
which
is
basically
I
just
made
like
I'm
not
wedded
to
any
of
these
directories
or
names
or
anything.
But
basically
this
is
the
candidate
kept
template,
which
would
be
a
subdirectory,
which
would
be
where
all
of
the
changes
would
go
into,
like
all
of
the
new
changes
would
be
merged
into
or
potential
changes.
B
The
readme
just
says
like
merge
into
staging
not
directly
into
the
active
template
and
then
eventually,
like
we
formally
archive,
I
created
an
archive
as
well,
but
I
don't
know
where
that
went,
and
then
we
would
formally
like
move
the
current
template
to
the
archives
directory.
Wherever
that
went,
I
can't
find
it
anymore.
B
Here
it
is,
I'm
done
I
added
a
readme
just
to
make
sure
that
the
directory
was
there.
So
it's
basically
the
idea
of
put
your
changes
into
staging.
You
can
see
all
the
changes
together
and
see
like
hey
like
is
this:
do
we
have
enough
changes
to
actually
change
the
official
template?
Yet
maybe
not
right
like
maybe
it's
like.
We
have
a
bunch
of
trivial
changes
that
aren't
really
worth
it.
B
Maybe
we
have
a
pressing
change,
I
don't
know
and
then
formally
sort
of
move
the
active
template
into
the
archives,
because
that's
going
to
also
let
us
do
diffs.
You
know
because
the
one
thing
that
I
noticed
too
is
that
we
don't
have
a
good
way
to
say:
hey,
you
need
to
make
these
changes
like
because
you
don't
have
versioning,
but
these
are
the
new
changes
that
we
made
it's
just
like
looking
at
looking
at
the
template
with
your
eyeballs,
which
really
sucks.
B
So
I
think
that,
like
potentially
moving
to
this
this,
this
workflow
is
going
to
be
a
bit
better
for
us,
but
obviously
you
can't
just
create
dating
directories
without
doing
other
work,
because
it
brings
up
a
bunch
of
other
questions,
so
I
kind
of
have
like
a
work
in
progress
issue.
This
is
all
like
work
in
progress
and
just
like
kind
of
bring
it
up
thing.
It
would
be
like
create
this
staging
directory,
create
some
guidelines
for
that
right,
because
there
could
potentially
be
changes
that
need
to
go
in
faster.
B
It's
not
just
like
a.
I
would
love
for
this
to
be
more
clear.
This
might
be
like
I
would
be
thinking
of
tooling
right,
like
hey
like
this
is
actually
broken
this.
This
has
broken
our
tooling.
This
is
very
urgent,
so
I'd
like
to
kind
of
think
about
enumerating
those
changes
where
maybe
either
you
would
still
merge
into
staging,
but
that
might
quickly
go
into
the
template
with
some
sort
of
announcement
like
and
that's
why
I
have
number
three,
which
is
create
communication
guidelines
about
this.
B
So
the
one
thing
that
I've
I've
noticed
is
that
sometimes
the
kept
template
changes,
but
we're
not
telling
anybody
that
it's
changing
we're
not
like
highlighting
that
and
we're
also
not
like,
I
said,
create
a
deprecation
policy.
We're
not
we're
not
telling
people
hey
like
this
change
is
big
enough,
that
we
think
that
everyone
should
update
their
cap
to
have
it.
We
did
that
for
prr.
B
We
definitely
transition
that,
but
for
there
are
other
changes
that
kind
of
go
into
the
test,
and
I
do
think
that
we
need
to
come
up
with
an
idea
of
like
when
do.
People
need
to
update
to
the
new
template.
When
do
people
need
just
in
general,.
A
B
The
one
thing
that
I
would
worry
about
for
versioning
is
that
you
know
people
are
constantly
telling
people
to
update
their
app.
Like
let's
say
you
have
an
active
alpha
beta
ga.
How
many
times
should
you
really
have
to
update
the
template
of
the
cap
for
that
right?
So
I
would
say
think
that
through
and
say
like,
we
should
really
think
about
minimizing
the
urgent
changes
to
the
caps
template
where
we're
forcing
people
to
upgrade.
B
B
I
drink
a
lot
of
coffee,
something
I'm
working
on,
I'm
just
trying
to
think
through
sort
of
what
this
would
need
to
work,
but
also
trying
to
make
it
lightweight
enough
that
it
doesn't
become
like
too
bogged
down
in
everything
else,
and
then
hopefully
this
will
help
all
of
the
other
iterations
that
we
want
to
do
on
the
cast.
Hopefully,
it
will
make
sure
that
we
don't
break
anything
for
tooling,
because
that's
something
that
I
also
want
to
think
about
is
like
keeping
the
template
stable
and
having
people
working
on
tooling.
A
A
So
we
are
we're,
I
think,
we're
barking
up
the
the
same
tree
with
maybe
different
approaches.
So
this
come.
I
think
this
comes
back
to
the
to
kept
ctl
right
so
kept
ctl.
I
I
would,
I
think
I
don't
know
if
I've
said
it
on
a
recorded
call
before,
but
originally
kept.
Ctl
looked
like
it
was
written
in
five
different
ways
by
at
least
five
different
people,
and
it
was
it
was,
is
the
answer.
A
So
I
think
you
know
over
the
last
cycle
and
change,
we
have
tried
to
kind
of
like
marry
all
of
those
different
streams
and
write
each
of
the
separate
commands
in
a
similar
way.
The
where
that
is
leading
or
where
that
hopefully
leads,
is
running
running
your
kept
through
a
command
is
supposedly
supposed
to
be
your
source
of
truth
right.
A
If
the
template
tells
you,
or
rather
not
so
much
the
template,
but
the
the
metadata
itself,
if
our
command,
if
you
know
v1
of
or
v1
you
know,
0
1
0
of
kept
ctl
says
that
it
runs
that
it
accepts
the
you
know
v0
through
v2,
of
the
kept
metadata
right
and
there
are
conversion
mechanisms
between
each
of
those
points
right.
If,
if
between
you
know
for
for
kept
metadata,
v01
0
right,
n
0,
5
0.,
we
decided
that
prrs
are
are
required.
A
Maybe
that's
not
actually
0
0
1
0
to
0
5
0.
Maybe
that's
zero
one
zero
to
one.
You
know
to
to
version
one
right
because
we've
made
we've
made
a
like.
Is
it?
Is
it
a
backward,
compatible
change?
If
we,
if
we
had
them
in
both
versions
of
the
metadata,
depends
right,
but
the
tooling
should
be
able
to
support
that
right.
I
should
be
able
to
use
kept
ctl
to
say,
like
ctl,
promote
whatever
or
kept
ctl.
A
You
know
reconcile
fields
right
and
it
should
spit
out
hey
you're,
missing
scope,
you're
missing
this.
This
stage
is
blah
for
right
or
we
don't
use
that
format
anymore.
Right
it
should
give
you
a
list
of
like
here's,
how
to
fix
your
thing
or
automate
it
right
right.
A
So
so
that
is,
that
is
one
aspect
of
it.
The
the
tooling
should
prevent
you
from
doing
the
wrong
thing
right,
the
like
whether
it's,
whether
it's
the
combination
of
the
tooling,
as
well
as
the
the
pre-submits
like
our
pre-submits
today,
will
make
sure
that
one
like
kept
ctl
can
actually
be
built
into
that
they.
A
You
know
that,
like
the
the
caps
that
are
written
down
today,
have
like
appropriate
tables
of
content,
so
on
and
so
forth,
right
and
some
of
the
metadata
checking
the
the
the
templates
are
are
part
of
that
right,
but
I
think
that
I
think
that
ultimately,
it
comes
down
to
the
content.
A
The
reason
I
mentioned,
the
versions
is
because,
if
we
look
at
this,
if
we
look
at
this
like
semantically
right,
if
we
look
at
this
from
the
perspective
of
semver
and
we
talk
about
versioning,
these
templates
are
versioning
the
metadata.
In
the
same
way,
then,
when
you
know
one
we're
looking
at
multiple
release
boundaries
right,
if
I
say
that
if
I
say
that
we're
going
to
make
a
breaking
change,
we
say
that
we're
going
to
make
a
breaking
change
to
the
kept
template
between
releases,
122
and
123
right.
A
We
announce
we
announced
prior
to
that
boundary
and
we
give
people
we
give
people
the
tool
that
they
need
to
get
onto
the
right
version
of
the
template.
Right,
say
it's
say
it's
a
smaller
change
right
say
it's
a
say:
it's
a
wording.
Change,
that's
just
really
is,
is
a
quality
of
life
improvement
right.
A
Maybe
that
is
maybe
that
is
a
patch
version
of
a
template,
change
right
or
a
patch
version
of
a
metadata
change
right,
and
we
say
that
like
oh
well,
you
know
the
there's,
no
reason
that
we
need
the
v's
in
the
versioning
and
the
versions
for
the
kept
metadata.
Maybe
we're
going
to
strike
the
v's
or
we
say
that
the
v's
are
optional
or
something
like
that
right.
That
could
be
an
example
of
something
that's
that's
a
patch
update
for
for
the
metadata
or
for
what's
in
the
kept
templates
right.
Ultimately,
the
we
can.
A
I
the
reason
I
the
reason
I'm
pointing
at
the
metadata,
as
opposed
to
the
template,
I'm
not
disagreeing
with
the
fact
that
I
think
that
you
know
there
should
be
some
system
for
the
templates
as
well,
but
the
metadata
is
something
that
we
can
programmatically
validate
against
right
and
and
and
releasing
releasing
both
the
tool.
A
The
tool,
the
metadata
spec,
as
well
as
updates
to
the
template
along
the
same
versioning
boundaries,
give
us
an
opportunity
to
do
like
a
release.
Announcement
right,
like
hey,
you
know
we
changed
this
and
you
know,
scope
is
now
required.
Prrs
are
now
required
this.
You
know
the
the
template
has
been
updated
in
these
ways
to
assist
you
with
that,
and
the
tool
will
now
block
changes
unless
you
are,
if
you
do
kept
ctl
convert
to
blah
you'll
get
the
right
or
kept
ctl
fix
or
whatever
we
want
to
call
it
right.
A
You'll
get
the
right
stuff
out
the
it.
I
think
you
know
some
some
of
the
some
of
the
the
template
updates.
Make
sense
like
you
said
to
do
immediately
because
they
are
quality
of
life
improvements
right
yeah.
Maybe
it's
something
like
it
points
to
the
glossary
now
and
you
know:
we've
just
updated
a
glossary
and
it
points
to
glossary
now
or
you
know,
or
the
template
is
in
a
totally
different
location
now.
A
But
I
see
this
as
like
a
you
know
the
same
way
we
we
might
do
go
modules
and
maybe
template
you
know
templates
v1,
v2,
blah
blah,
so
that
there's
no
need
to
there's
no
need
to
necessarily
like
archive
something,
but
you
get
the
same.
You
get
both
the
same
template
as
well
as
the
same
metadata
within
that
module.
B
B
For
those
people
who
might
be
being
proactive
or
might
need
references
right
like
because
true
telling
you
one
thing
is
one
thing,
but
you
still
need
to
go
somewhere
and
be
like
okay,
I
gotta
change
something.
How
do
I
have
to
change?
Yes,
so
you
do
need
that
sort
of
very
visual
representation,
but
I
also
think
that
it's
about,
like
you
were
saying,
communication
and
being
able
to
to
say,
hey
like
this,
is
the
whatever
template
that
we're
using
these
are
the
changes
from
the
old
template.
B
This
is
what
you
should
know.
I
I
think
that,
having
that
visible
to
the
user
because
tools
regardless,
it's
like
you-
have
to
use
the
tool
to
find
out,
you
have
to
have
the
tech
written
to
find
out,
and
so,
if
you're
sickly,
that's
not
necessarily
going
to
be
as
helpful
because
you're
like
well,
I'm
not
really
like
running
this
through
a
tool.
I
just
want
to
see
the
new
changes,
or
maybe
we
want
to
communicate
the
changes
in
a
way
that
we
can
say.
Hey
like
this
is
a
diff.
A
B
Be
aware
that
you
might
need
this
new
information.
This
is
what
the
template
looks
like.
So
I
think
that
they're,
like
supportive
ideas,
but
also
like
the
kept
ctl,
isn't
like
it's,
not
ai,
right.
It's
not
making
the
decision.
People
have
to
make
the
decision,
and
so
I
think
like
having,
even
though
it's
like
super
low-fi
having
this
way
of
doing
it
is
what
helps
facilitate
people
making
the
decisions
which
then
kept
ctl
picks
up
on,
because,
like
it's
going
to
be
enhancements,
that
says
hey.
I
think
that
this
is
an
important
change
now.
B
I
think
we
have
enough
for
this
to
be
a
real
version
that
people
we
need
to
block
on,
so
that
kept
ctl
is
going
to
block
on
it,
and
I
think
that,
like
I
think
that
they're
like
one
is
like
people
tooling,
that
fuels
like
the
automated
tooling,
because
I
know
like
I
wouldn't
be
able
to
really
say-
hey
yeah,
like
I
think
that
these
are
enough
changes
without
really
looking
at
the
changes
and
being
like.
B
A
B
Pooling
is
telling
me
one
thing:
it's
like
well,
why
is
the
tooling
telling
you
that
and
it's
like?
Well,
we
actually
made
these
changes,
and
these
are
why
they're
important
and
whatever
you
can
have
like
a
little
change,
vlog
and
a
little
blurb.
So
I
think
that
those
are
really
complimentary
ideas,
but
I'm
also
just
a
little
bit
concerned
about
as
tooling
is
developing,
not
changing
the
template
willy-nilly,
like
that
I
mean
for
me.
It's
like.
B
I
don't
want
this
template
to
change
willy-nilly
anymore,
like
I
want
it
to
be
very
like
just
as
a
general
thing
considered,
because
I
think
that
we
potentially
can
really
break
a
lot
of
things
and
also
just
like
undermine
credibility
with
the
greater
community.
If
we
at
this
point
where
the
template
is
just
make
changes
all
the
time
to
it,
yeah
yeah.
A
B
A
Right
yeah.
B
A
With
with
the
template
changes,
I
you
know
to
your
point.
I
also
worry
about
moving
things
around,
because
there
are
docs
from
time
immemorial
and
different.
You
know,
and
you
know,
different
things
that
have
been
published
about
us
and
you
know
that
link
to
very
specific
places.
So,
ideally,
we
can
like
not
change
those
links
and
not
break
those
links,
but
I
I
also
worry
about
like
what
are
we
putting
into
the
template
that
what's
the
right
way
to
phrase?
Sorry,
you
know
james,
you
have
your
hand
up
so.
C
Stephen,
when
you
say
cap
metadata,
you're,
referring
to
the
data
in
the
yaml
file
right,
that's
that's
exactly
that's
what
you
mean.
Okay.
My
other
question
was:
if
we're
talking
about
the
vision
by
the
way,
I'm
a
big
plus
one,
the
versioning.
This
is
like
this
whole
thing.
Kristen
is
something
I
didn't
think
we
needed.
I
didn't
didn't
even
consider
that
we
might
want
until
you
said
we
should
do
this,
I'm
like,
of
course.
Why
aren't
we
doing
this?
We
weren't.
A
Ready
we
weren't
ready.
So
if
you
look
at,
if
you
look
at
the
repo
you'll
notice
that
there
are
two
milestones,
one
is
kept
beta
and
the
other
one's
kept.
Ga
the
goal
was
always
versioning.
B
Just
just
to
clarify,
though,
I'm
also
talking,
I'm
not
thinking,
I
mean
I'm
thinking
of
the
kept.yaml
file,
but
I'm
actually
really
thinking
about
also
the
readme
file,
because
I
know
that
that
that
that
file
can
really
be
improved,
and
sometimes
there
are
incremental
changes
that
go
in
and
that's
sort
of
the
file
that
people
interact.
C
B
A
lot
and
that's
what
people
are
reviewing
and
I'm
thinking
about
bringing
stability,
especially
to
that
that
readme.md,
that
has
like
all
of
the
meat
of
the
of
the
cabinet.
C
So
I'm
sorry,
my
quick
follow-on
question
would
be
especially
for
you
customer
this
proposal.
Why
don't
we
jump
straight
to
a
basic,
rudimentary
versioning?
Why
don't
we
just
say
what
we
have
right
now
in
the
repo
is
that
version
I
don't
know
zero
one
zero
or
whatever
version
one
doesn't
matter.
C
B
Well,
yeah
that
that
was
kind
of
like
implicit,
but
I
didn't.
A
B
I
didn't
want
to
have
to
like
sort
of
I
I'm
like.
I
don't
want
to
get
into
like
how
do
I?
What
do
we
call
the
versions
or
anything
like
that?
I
was
kind
of
like
okay,
like
first
get
the
directory
set
up
and
then
just
have
people
merging
into
staging
instead
of
into
an
active
template,
because
that
is
nails
on
a
chalkboard
for
me,
then
you
know,
let's
think
about
yeah,
because
you
can't
really
say
this
version
is
version
x
until
you
stop
changing
the
version.
A
B
B
First
like
let's
get
into
the
practice
of
not
changing
and
active
template
without
more
consideration
and
communication
and
having
a
staging
directory,
and
once
we
can
actually
like
say
we're
not
merging
directly
into
that,
then
we
can
say:
okay,
that's
actually
version
zero.
You
can
call
it
version
whatever
you
want
and
then
now
we're
at
staging.
B
C
Sorry
one
more
quick
question:
it
feels
almost
to
me,
like
with
a
kind
of
archive
directory
and
like
the
staging
directory
like
we're
effectively
re-implementing
a
git
workflow
with
like
okay.
B
Git
is
great
right
because
you
have
a
bunch
of
commits
and
you
can
see
the
history.
But
when
you
want
a
version,
you
don't
necessarily
care
about.
All
of
the
individual
commits
you
care
about
like
what
is
the
biggest
change.
What
are
all
of
the
changes
from
here
to
here
and
memorializing?
That,
and
like
I
mean
the
fact
is,
is
like
no
user
wants
to
look
at
a
git
history.
They
want
to
just
see
maybe
a
diff.
B
They
want
to
see
the
new
version
and
they
might
want
to
see
the
old
version,
and
I
think
that
it's
about
like
a
better
sort
of
ux
ui
for
that,
as
opposed
to
like
relying
on
yet
because
git
is
great
for
code,
but
it
is
freaking
terrible.
What
even
for
releases
get
kind
of
sucks
like
it
helps
kind
of
get.
B
B
It's
about
potentially
bashing
it
out
too
and
squashing.
All
of
those
commits
and
saying
these
are
the
changes
into
the
template
like
this
is.
This
is
now
like
get
commit
template
this
you
know
like
and
and
because
I
do
not
know
if
having
individual
commits
on
a
template
is
as
much
clarity
as
people
also.
C
B
Could
just
have
like
one
commit
perversion
and
then
gift
them
yeah,
because
it's
really
for
me
to
change
wrong
and
the
not
change
wrong
change
log
and
a
diff
where
you're,
just
because
there's
I've
just
noticed
that,
after
dealing
with
this
for
so
long
where
it's
like,
it's
really
hard
to
tell
people
what
they
need
to
update
and
not
in
the
yaml,
but
in
the
readme,
that's
extremely
hard
and
being
able
to
say
these
are
the
changes
you
have
to
make
them
or
you
don't
have
to
make
them
they're
optional,
whatever
whatever
it
is,
these
these
are
them
and
letting
the
person
be
able
to
just
see
that
and
be
like.
A
So
for
for,
for
me,
I
I
think
you
know,
at
least
as
like
a
custodian
of
the
process
and
tooling
and
yada
yada
yada.
What
I've
found
over
time
is
that
the
I
think
we've
laid
down
enough
of
the
process
like
before,
like
the
reason
this,
like
the
reason
that
milestone
was
like
kept
beta,
I
was
like
I
don't
even
know
what
beta
looks
like.
I
don't
even
know
what
like
I
was
like
we're.
Definitely
in
alpha
right
now.
A
We
we
shipped
this
thing
with
two
plus
years
ago
and,
like
I
know
what
that
is,
I
know
what
we
initially
started
off
with.
I
don't
know
what
beta
looks
like
everything
else
goes
into
beta.
I
think
now
that
we
have
a
the
reason
I
keep
coming
back
to
the
the
metadata
is
because
it
gives
us
an
opportunity
to
enforce
rules
if
those
rules,
ideally
those
rules
map
to
things
that
are
written
in
in
the
template
as
well,
right
and,
and
that
makes
it
that
makes
it
easier
to
tie
together.
A
B
B
I
would
say
the
version
is
held
in
the
ammo
and
so
it's
like
and
maybe
there's
a
field
in
the
readme
just
to
verify
that
the
person
didn't
just
update
the
ammo
or
something
like
I
don't
know,
but
I
think
that
the
version
means
that
you
have
to
check
both
the
yaml
and
the
readme.md,
but
the
readme.mb
is
really
the
tricky
one
where,
like
I'm,
not
I'm
not
as
concerned
about
like,
is
your
yaml
correct
or
not?
I'm,
because
that's
like
okay,
fine
tooling,
can
handle
that.
B
A
Yeah,
okay,
okay,
that
is
all
right
yeah,
because
so
we're
we're
on
the
same
page,
then,
because
yeah.
B
To
me,
those
community
to
me,
there
are
units
they
go
together
like
gamble
and
the
readme.
they're
like
they're
a
unit
they
don't,
they
match
yeah.
A
That's
a
line
in
you
know
that
we
may
add
you
as
a
comment
to
you
know
to
the
readme,
but
it's
the
reason
I
was
keep
coming
back
to
the
the
metadata
is
because,
like
that's
something
that
we
can
enforce
in
the
tool
and
we
can
block
prs
right
so
for
me,
the
enforcement,
the
enforcer
like
the
the
policy
change-
is
definitely
a
a
component
of
you
know
of
the
communication,
but
going
from
going
from
warnings
which
you
will
never
see
like
if
no
one's
looking
at
like
the
test
and
for
as
a
is
a
fun
example
where
there
are,
I
think
there
are
warnings
for
various
types
of
tests
and
whether
or
not
you
have
like
test
grade
alerts,
configured
or
they're
on
the
right
dashboards,
depending
on
what
folders,
they're
in
or
they're
going
to
the
right
clusters.
A
That's
a
good
example
of
like
we're
getting
warnings,
but
the
warnings
are
not
visible
until
a
failure
happens
right.
So
the
so.
The
reason
I
bring
it
up
is
for
like
sig
release
when
we,
when
we
build
a
new
branch,
and
we
have
to
have
to
do
the
new
branch
jobs.
A
Often
we
will
get
multiple
failures
during
during
the
branch,
job
creation,
because
they're
they're
actually
they're
like
oh
well,
where
did
these
warnings
come
from
they're,
actually
warnings
that
were
always
cropping
cropping
up
in
the
tests,
but
they
only
presented
themselves
because
there
was
also
a
failure
attached
to
them
right.
So
there
is
a
for.
For
me.
I
see
that
there
is
a
like
a
warning
mode
for
kept
ctl
or
whatever
validations,
that
we
run.
That
like
would
pop
up
in
pre-submits,
but
also
would
be
something
that
you
could
just
run
and
say
like.
A
It
needs
to
be
one
of
these
values,
and
then
you
know
the
next
phase
of
that
is
enforcement.
Where,
like
okay?
Well,
we
told
you
this
was
coming,
we
put
in
the
readme,
we
announced
it
on
the
the
release
notes.
Now
it's
a
blocking
change
right.
So
any
caps
that
do
not
have
this
thing
will
not
merge
so
yeah.
A
The
reason
I
keep
coming
back
to
the
tooling
is
because,
like
it's,
it's
so
clear
that
we
need
enforcement
at
the
stage,
given
the
amount
of
folks
that
are
working
on
this
are
not
able
to
work
on
this.
B
Even
even
for
the
release
team,
though
the
one
thing
that
strikes
me
when
I
did
the
release
chamber
when
I
look
at
caps
is
that
it's
like.
I
know
that
this
kept
is
not
the
right
version
like
I
know
it's
missing
some
changes.
I
know
that
it
has
like
some
old
fields,
but
I
don't
have
a
good
way
to
easily
tell
the
author.
A
A
B
B
I
just
think
that,
like
it's
like,
like,
I
think,
you're
talking
about
a
lot
of
like
quantitative
tools,
but
there's
always
going
to
be
a
sort
of
qualitative
aspect
to
the
tests,
because
there's
a
lot
of
text
there's
a
lot
of
feeling,
there's
a
lot
of
ideas,
and
I
think
also
improving
that
part
and
making
that
a
little
bit
more
straightforward,
because
authors
want
to.
They
want
to
have
a
correct
hat.
A
B
B
B
And
saying
like
hey,
like
the
changes,
especially
to
the
readme,
are
not
trivial
changes
to
kept
yaml,
I
mean
they're,
not
trivial,
but
they're
really
straightforward.
To
read
me:
it's
not
straightforward,
and
so
I
think
we
have
to
be
really
careful
about
how
we
batch
out
changes
to
that
reading.nb
file.
So
I
guess
that's
what
I'm
thinking
more
of
instead
of
the
cap.animal
I
mean,
is
that
really.md
and
being
able
to
articulate
those
changes
clearly
being
able
to
articulate
when
we
want
that
updated,
because
that
is
a
lot
more
work.
B
A
Yeah
yeah,
so
I
think
that
part
of
this
is
like
when
again
I
keep
saying
like
the
reason
I
keep
bringing
up
the
metadata
right
so
like
a
large
chain.
Ideally,
a
large
change
to
the
template
can
be
bound
to
a
change
in
the
metadata
right,
like
pr
enforcement
scope,
changes,
yada
yada.
Those
are
things
that
are
kind
of
easy
to
be
like.
Oh,
you
got
to
go
click
that
button
or
change
that
word
in
the
metadata
for
it
to
pass
down
right.
A
A
You
know
maybe
a
patch
change
is
you
know
a
patch
changes,
some
non-blocking
like
maybe
it's,
maybe
it's
some
language
fix
or
maybe
like
a
link,
broke
and
and
we're
fixing
that
and
it's
kind
of
one
of
those
things
like
just
put
it
in
because,
like
it
again,
it's
quality
of
life
improvement
and
it's
not
really
like
we're.
Changing
the
template
out
from
under
you,
it's
like
literally.
B
A
Link
broke,
it's
a
404
like
go,
go
fix
that
then,
then,
we've
kind
of
got
these,
like
you
know
these.
These
pat
these.
These
minor
changes
that
are
like
okay,
well
they're,
still
they're
still
compatible
with
what
you
had
right
so
and-
and
maybe
there
is
a
thing,
that's
coming.
A
That
would
be
nice
if
you
had
it
included
in
the
template,
but
the
release
t
like
the
but
the
release
team
might
not
block
on
this
kind
of
thing
right,
and
maybe
it's
something
that
maybe
it's
something
that
does
fit
in
the
scope
of
fits
in
the
scope
of
like
a
metadata
change
and
a
version.
B
A
For
the
the
cap
metadata,
and
maybe
it
doesn't
right
but
then
there's
a
there's-
the
this
is
going
to
like
completely
up
end.
Your
process
like
you
should
like
you
need
to
pay
very
close
attention
to
this,
and
you
will
may
need
to
rewrite
portions
of
this
cup
to
get
it
done
and
the
portions
are
like
so
much
different.
Like
that's.
You
know,
that's
the
major
change
to
me
and
like
so.
C
A
I
mean
even
the
I
think
we
can.
We
can
look
at
a
current
example
or,
or
a
currently
being
discussed
example
right,
adding
a
version
to
to
the
the
metadata
right
this.
This
would
be
a
change,
but
it
is
it's
a
change
that
we
can
tell
kept
ctl.
It's
like
hey,
it's
cool.
They
didn't
have
versions
before
if
they
didn't
have
versions
before
assume
it's
pre
version,
1,
0,
1,
0
or
something
right,
and
that's
something
that
we
can
let
fly,
because
we
don't
expect
you
to
like
that's
a
like.
A
A
It
feels
a
little
silly
right,
but
moving
forward
once
we
do
set
this
like
if
we
are
going
to
decide
on
a
version
and
we
make
changes
that
are
outside
of
the
scope
of
that
version,
then
being
able
to
say
okay
well
now,
we're
now
we're
doing
a
version
bump,
but
we
also
need
to
to
ensure
that
the
caps
that
came
in
with
this
version
number
or
pre,
this
version
number
at
least
have
a
minimum
version
right
so
that
that
may
be
a
tooling
change.
We're
like
oh
now,
this
stuff
like
we
set.
B
Well,
yeah,
on
on
the
issue
I
already
had
like
like
that
was
this
general
thing
was
something
that
I
was
working
on,
because
I
know
that,
like
you
just
can't
there
are.
The
directories
can't
stand
alone,
so
I
will
take
a
stab
it's
like
just
kind
of
getting
it
all
out
there
it's
like,
but
I
feel
like
it's
easy
to
talk
easier
to
talk
about
than
actually
to
do
so.
I
was
like.
Let
me
make
the
directories
first,
people
can
stare
at
it.
B
Let
me
then,
like
think
about,
because
I
already
have
like
something
in
progress
for
the
sort
of
process
but
yeah
like
major
liner
patch
or
something.
A
So
yeah
so
also
with
the
let's,
I
think,
yeah,
I
think
about
think
about
the
directory
names
a
little
bit
even
think
about
the
the
name
names
of
I.
A
There
are
parts
of
me
that,
like
want
to
move
a
bunch
of
things
around
in
in
the
in
the
repo
like
caps,
so,
okay,
we
have
production,
readiness,
reviews,
production,
readiness
reviews
are
really
bound
to
caps.
Why
are
they
in
a
separate
directory
they're
in
a
separate
directory
to
provide
you
know
to
provide
ownership
to
the
pr
review
team,
but
that
directory
should
potentially
be
within
the
kep
directory?
A
It
does
make
some
of
the
search
and
filter
stuff
for
for
the
for
the
tool
easier
if
they're
kind
of
skipped
within
the
same
directories,
that's
a
silly
thing,
but
you
start
to
think
about
like
okay.
Well,
we've
got
caps
and
then
potentially
staging
and
potentially
archives
right.
The
the
staging
archives
live
within
the
kept
directory
or
they
live
slightly
above
it.
A
I
would
almost
say
that,
like
they
live
above
it
so
that
they
don't
impact
tooling,
that's
fine
and
you
know,
and
then
you
and
then
you
think
of
like
module-y
things
right.
So
if
we
were
to
shape
this
like
a
go
repo
or
and
we're
not
doing
branches
or
something
like
that
like
we
could
do
branches,
but
maybe
we
shouldn't
do
branches.
Maybe
that's
a
crazy
idea,
if
you,
if
you
shape
it
like
okay,
I'm
bumping
from
a
you
know
a
sub.
A
You
know
a
sub
or
up
to
the
one
module
to
v2,
I'm
either
going
to
bump
the
I'm
either
going
to
bump
the
go
mod
and
say
it's
it's
v2
now
or
I'm
going
to
go
in
and
add
another
subdirectory
that
says
v2,
v2,
v3,
etc
right
and
then
all
the
content,
the
content
would
be
a
mirror
or
a
mirror-ish,
plus
whatever
new
content
right.
So
in
so
I
I
guess
I
say
that
to
say
instead
of
staging
or
instead
of
like
one,
there
will
be
a
question
of.
Do
we
need
archives?
A
Or
can
we
just
say
that,
like
these
are
the
versions
right
explicitly
say,
these
are
the
versions
right
and
and
if
it's
you
know,
if
it's
v05
or
something
like
that
cool
all
the
v05
content
gets
in
there
when
it's
time
to
merge,
we
merge
in
into
head-
or
you
know,
main
of
of
keps,
and
then
we
include
the.
I
don't
know
we.
A
We
can
decide
that
it's
just
strictly
release
content
or
we
can
decide
that,
like
oh
we're,
adding
a
changelog.md
to
the
caps,
you
know
keps
slash
changelog.md
right,
and
that
includes
like
all
the
content
for
for
v05,
but
v05
can
work
work
in
the
separate
tree
or
subdirectory
like
you're,
saying
staging
I'm
just
saying
that
like
if
we
say
that
it
is
what
it
is,
we
know
that
it's
version.next,
then
that
makes
it
a
little
easier
to
reason
about,
as
opposed
to
just
like
global
staging
and
then
the
so
then,
like
the
concept
of
archives
goes
away
functionally
right
because
yeah.
B
It's
about
having
something
that
is
clear
and
sort
of
like
the
truth,
and
so
that
people
can
clearly
refer
back
to
it
if
they
have
a
question,
clearly
diff.
If
they
have
a
question
and
know
what
was
in
the
past
and
know
what
is
in
the
present
and
know
what
is
in
the
future,
I
don't
care
about
the
names
of
it,
but
the
the
real
crux
of
the
whole
thing
is
just
like
do
not
merge
into
the
active
template
like
yeah.
A
So
I
I
think
I
think
the
criteria
for
do
not
merge
into
active
template
would
and
that's
that's
why
I
was
suggesting
doing
the
the
major
minor
patch
stuff
right
because,
like
if
it
if
a
link's
broken
like,
I
would
prefer
to
see
that
fixed
asap
in
the
the
template,
as
opposed
to
it
being
seated
in
a
staging
directory
and
then
getting
copied
in
and
adding
to
like
it's
it's
something
that
like
we
should
just
go
fix.
A
A
A
quality
of
life
improvement,
or
it's
something
that
like
went
funny
in
the
tooling
that
we
need
to
both
mention
in
the
metadata
or
fix
in
the
metadata,
as
well
as
mentioned
in
the
readme,
to
watch
out
for
kind
of
things
right
like
when,
like
knowing
where
those
boundaries
are,
I
think,
will
be
helpful
in
developing
the
process.
C
I
also
think
it's
pretty
likely
that
we're
going
to
end
up
supporting,
I
say,
supporting
but
having
multiple
different
versions
of
the
template.
Kind
of
live
like
I
wouldn't
be
surprised
if
like.
If
not
seven
was
the
latest
greatest
version,
we
might
start
a
release
and
say:
okay,
we're
gonna.
Allow
kept
in
this
release
must
be
at
least
not
five,
but
they
can
be
no
five.
No
six
or
nine
yeah.
A
So
one
potential
problem,
so
it
worries
me
in
general
to
have
too
much
content
out
there
in
terms
of
like
too
much
content.
That
looks
similar
because
I
worry
about
people
and
that's
part
of
the
reason
why
I
was
like
pull
the
staging
directory
up
or
make
it
very
clear
that
it
is
not
part
of
the
the
the
main
right,
because,
as
I
worry
about
someone
like
oh
well,
I
followed
the
template
for
this
thing
and
we're
like
well.
It
wasn't
live
yet.
A
A
A
Like
or
you
know
related
to
the
versions
is
this
something
that
goes
in
like?
Does
it
actually
go
in
a
branch?
Should
it
actually
go
in
a
branch
so,
like
you,
can
you
can
view
the
branch
and
track
changes
and
stuff
like
that,
but
it
doesn't
actually
get
merged
in
until
we
decide
that
we're
cutting
a
new
release.
A
So
I
mean
there
are
a
bunch
of
different
ways
that
we
can
slice
it,
and
I
know
that
that
wasn't
your
final
presentation,
the
what
else
worries
about
yeah,
so
we're
yeah
worries
about
having
the
content
in
multiple
places,
but
also
like
finding
the
answer
to
I.
I
don't
think
we
solve
the
question
of.
Do
I
need
like
do.
I
need
a
prr.
Is
the
release
team
tracking
this
right
and
we
started
like
slicing
it
up
into
the
different
like?
Well?
Is
it
release
impacting,
or
you
know,
is
it
is
it
this?
A
Is
it
that,
like
what
is
it
an
apple
or
an
orange,
and
we
kind
of
did
that
exercise
for
a
little
bit?
We
didn't
finish
it
and
I
think
the
what's
gonna
happen
at
the
end
of
it
or
what
we
decide
is
the
the
end
or
the
beginning
of
the
end
of
it
is
there
will
be
multiple
kept
templates.
B
Well
that
that
was
a
reason
why
I
think
that
it's
important
to
sort
this
flow
out,
because
I
don't
think
that
we
can
create
good
templates
if
we
don't
have
a
process
for
actually
managing
templates
and
changes
like
that
to
me
as
well.
So
what's
in
the
back
of
my
mind
where
I'm
like
cool
like
then
we're
going
to
have
like
a
zillion
templates
that
are
especially.
B
They're
new
they're
going
to
have
a
lot
of
changes
coming
in
right,
like
they're
not
going
to
be
stable.
So
that's
why
this
also
feels
like
a
very
important
thing
to
figure
out,
because
then,
when
we
say
okay,
we're
thinking
about
doing
this
new
template,
we
already
have
a
way
to
do
it.
We
have
a
way
to
manage
those
changes
and
we
have
a
way
to
get
that
out,
communicate
that
out
version
that
and
and
and
have
that,
going
because
you
can.
B
We
cannot
figure
that
out
at
the
same
time
and
it's
going
to
be
a
mess.
If
we
do
so,
it's
like
get
the
flow
right
on
what
we
have
right
now,
because
you
have
a
lot
of
experience
on
this
and
then
this
will
be
the
flow
that
we
use
to
be
able
to
iterate
on
these
new
templates
that
we
are
going
to
make
because.
B
Do
these
new
templates
without
having
a
way
to
do
it,
saying
hey
like
this,
is
now
because
what
I'm
thinking
is
like
okay,
we
have
staging,
or
we
have
the
new
version
that
we're
working
on
ever.
Since
everything
now
goes
into
the
access
template,
we
don't
have
a
great
way
to
communicate,
but
for
a
new
template
you
you're
going
to
want
like
hey.
This
is
this
is
what
we're
working
on
we've
iterated
a
bunch
of
times.
We
want
feedback.