►
From YouTube: SIG Architecture 20180830
Description
A
All
right,
good
morning
afternoon
or
evening,
wherever
you
are
in
the
world
today,
is
Thursday
August
30th
to
2018.
I
am
your
co-lead
of
this
sake,
which
is
take
architecture
if
make
sure
you're
the
right
place
and
the
agenda
should
you
want
to
follow
after
the
fact
is
at
Bentley
slash
sake,
architecture.
A
We
have
three
tracking
boards
that
we
follow.
If
you
go
to
those
meeting
minutes,
you
will
see
a
link
to
those
boards
there
under
the
community,
SIG's
org
and
it's
called
architecture
tracking.
So
today,
I
went
through
the
boards
and
it
didn't
look
like
there
is
anything
new
or
changed
that
we
need
to
review.
B
Had
a
question
about
how
we,
what
how
we
are
supposed
to
get
cards
moving
between
the
columns
in
those
boards,
so
I
know
of
at
least
three
things
that
are
in
progress
that
aren't
reflected
on
those.
Are
we
supposed
to
be
picking
you
or
commenting
in
the
tracking
issues,
or
how
does
that
work?
Mechanically?.
B
C
B
B
A
Yeah
I'm
not
sure
either
that
that's
something
that
I
would
have
aspired
to
or
dreamed
of
for
this
process,
so
we
can
have
more
automation
on
these
tracking
boards
because
right
now
it's
yours
truly
doing
this
and
it's
it's
kind
of
a
pain.
Definitely
if
anybody,
in
the
sake
is
interested
in
stepping
up
into
helping
figure
that
out
I
would
love
to
I
would
love
to
do
that
so.
A
D
Had
a
general
question
with
regards
to
process
for
conformance
acceptance,
yeah
we
currently,
we
currently
have
specified
and
I.
Don't
know
how
that
came
to
being
that
final
approvers
for
any
conformance
changes
would
be
Clayton
or
Bryan
versus
the
we
originally.
When
we
expected
I
was
supposed
to
be
sick
architecture.
F
A
E
E
Good,
okay
yeah,
so
what
happened
was
first
of
all,
there
is
no
such
thing
as
cigar
picture
as
like
a
well-defined
group
or
process.
So
that
was
something
that
we
were
trying
to
work
out
as
we
were
hashing
out
sub
projects
for
for
the
cig,
whereas
the
conformance
of
definition
and
approval
was
one
of
sub
projects,
not
the
entire
cig.
We
started
with
a
subset
of
D
API
approvers,
who
were
actually
involved
in.
E
Deciding
what
things
should
be
compatible
across
all
Trinity's
clusters
that
requires
understanding
of
our
architectural
requirements,
API
requirements,
expectations
of
communities
in
different
environments,
and
things
like
that.
So
we
just
started
with
a
super
small
subset,
so
we
could
lean
towards
consistency,
maximizing
consistency
as
we
developed
the
criteria
for
what
is
conformant
and
what
is
not
conformant.
So
the
main
thing
that
is
blocking
adding
people
to
that
set
is
bringing
more
people
up
to
speed
on
the
criterion
expectations,
exactly
Aaron
posted
to
the
chat
there.
E
So
that
is
underway
right
now
and
you
know
definitely
we
want
to
grow
the
set
of
people
in
terms
of
bandwidth,
July
and
August
for
just
brutal
for
me,
but
I'm,
hoping
I
have
reason
to
believe.
I
would
say
this
not
just
hope.
Id
reasons
believe
that
September
will
be
better
and
the
iterating
on
the
process
is
the
top
priority
for
the
conformance
test
reviews.
E
You
know
not
just
pounding
out
the
reviews
using
the
reviews
that
are
coming
through
as
an
opportunity
to
refine
those
criteria
and
I
think
we
made
some
useful
progress
on
that
and
artists
and
I,
definitely
by
the
end
of
September.
I
would
like
to
see
those
criteria
much
more
complete,
so
that
is
how
it
started
and
how
we
got
to
where
we
are.
D
E
So
we
should
get
you
and
dims
and
Aaron,
at
least
as
a
starting
point
together
and
start
having
some
regular
discussions
to
make
sure
we're
all
on
the
same
page
about
the
criteria
and
I
think
the
biggest
dish
issue
is
if
there
are
any
questions
about
whether
something
you
should
be
conformant
or
not
well
and
Clayton,
if
we
can
track
him
down
any
his
time,
but
if
there
any
questions
on
you
know,
should
this
be
conformant
or
not?
We
raised
that
to
the
group
and
we
come
to
an
answer
and
we
write
it
down.
E
I
think
I
think
that's
the
number
one
process
that
we
need
to
need
to
develop.
I,
don't
maybe
a
mailing
list
of
the
approvers
or
you
know,
student
via
approvers,
or
something
like
that
and
we
can
start
hashing
this
out,
like
I,
would
love
it
if
you
and
James
and
Aaron
and
others
to
do
first
cup
reviews
and
say
you
know,
I
think
this
looks
good.
There
are
no
questions.
You
know
the
criteria
covered
everything
in
this
test
and
then
we
can
go
from
there.
That's
sound
reasonable
yep.
E
F
Personally,
I've
been
trying
to
treat
it
as
I,
don't
assign
it
to
you
and
Clayton
until
I
think
it
is
ready
for
you
to
rubber
stamp
it
and
it
you
send
it
back
for
some
reason
that
helps
me
understand
what
the
further
criteria
are,
but
I
agree.
I
think
like
maybe
just
the
mailing
list
threat
on
sega
architecture
is
all
we
really
need
for
asynchronous
collaboration
was
enough:
that's
not
spread
across
a
bunch
of
PRS
yeah.
F
I
I
know
I'm
super
behind
on
both
filling
that
board
back
up
with
some
things
and
also
getting
a
Google
Doc
of
the
conformance
definition
out
for
us
to
iterate
on
because
I'm,
assuming
that,
ideally
would
be
a
place
to
land
as
many
of
those
criteria
as
possible
in
a
very
thorough
list
so
been
occupied
with
other
stuff.
This
week,
I
think
I
can
get
to
that.
You'll
see
it
out
there
by
next
week.
A
Cool,
it
would
probably
make
sense
at
some
point
once
the
sub
projects
have
more
formal
or
or
at
least
more
standardized
members
that
we
add
them
to
the
admin
group
for
this-
the
tracking
board,
so
that
they
can
move
cards
across
and
manage
their
other
projects
right.
We
can
probably
do
that
already
for
the
position
very
low
risk,
in
that
it's
more
just
confusion,
which
we
have
plenty
of
that
already
so
yeah.
E
A
So
actually
I
than
there
is.
If
anybody
on
this
meeting
is
well,
that's
a
project
and
tracking
those
things,
caps,
conforms
reviews,
etc.
Just
talk
to
Brian.
He
allowed
you
to
the
admin
groups
for
the
tracking
board,
so
you
can
also
add,
and
categories
and
stuff
I
think
for
sure,
Jordan
and
Aaron
Tim
are
people
who
should
have
that
ability.
So
both
hymns.
E
Yeah
so,
while
we're
on
the
topic
of
API
reviews
in
caps,
I
added
a
lineup
I
hope
will
be
quick
to
the
agenda,
so
I
started
looking
through
EPS
and
I
felt
they
were
roughly
two
shapes
like
incremental
features,
which
are
fine,
ish
and
bigger
figure,
changes
which
not
even
like
super
major
changes,
but
just
sort
of
scope,
creepy
kind
of
changes
and
that's
where
I
felt
like
I
didn't
have
a
good
enough
understanding
of
where
the
sig
was
headed.
To
review
that
individually.
E
So
I
was
asked
for
sort
of
bigger
picture
information
on
a
couple
of
them,
but
in
general
I
think
it
would
help
to
have
that
bigger
picture
vision
and
roadmap
from
the
SIG's
to
put
those
things
in
context
in
advance
of
receiving
a
cap
for
a
specific
detail.
I
know
the
SIG's
are
already
presenting
regularly
to
the
community
meeting.
E
The
prerequisite
for
getting
their
stuff
reviewed,
like
we
used
that
kind
of
carrot,
/
stick
for
sig
charters
and
repos
saying
you
know
you
have
to
enumerate
all
your
sub
projects
before
you
can
get
repos,
so
we
could
say
well
you
need
to
have
a
road
map,
so
we
understand
where
you're
going
before
you
get
any
API
or
kept
reviews.
What
people
think
about
that
I.
D
Think
I'm
it's
rough
to
enforce
because,
like
the
road
maps
change
wildly
wildly
from
Sigma
sig
and
it
changes
over
time
to
because
it's
a
volunteer
army
right
so
like
people
show
up
and
some
people
throw
down
and
help,
do
the
work
and
good
things
get
done
faster
and
sometimes
people
disappear
and
reduce
pop
who's.
Gonna
be
done
in
a
cycle,
doesn't
get
done
for
a
year.
I,
don't.
E
Care
as
much
about
whether
specific
thing
gets
done
in
the
next
release,
as
this
is
the
stuff
people
believe,
is
important
in
the
direction
they're
headed
and
you
know
if
they,
if
they
know
where
what
people
are
working
on,
that
helps,
put
things
in
context
that
that
changes
that
doesn't
bother
me
as
much,
but
it's
more
about.
Well,
it
is
more
we're
gonna
be
done
in
this
direction
or
it's
gonna
be
left.
E
This
is
just
like
a
point
wise
thing,
or
is
it
gonna
shift
direction
into
another
direction,
especially
when
we
get
caps
from
different
people
that
are
in
different
directions
over
time
like
and
one
release,
one
person
fits
one
cap
and
doesn't
work,
and
then
the
next
one
there's
something
in
the
different
direction:
I'm
starting
to
see
a
lot
of
evidence
of
that
as
the
project
has
become
more
more
fragmented
and
people
are
just
focusing
on
their
individual
little
things.
I
understand
it's
a
volunteer
army,
but.
E
A
A
Would
be
I
think
we
should
have
that
anyway,
I
have
and
I
know.
Other
people,
especially
in
say
p.m.
have
hand
rung
about
this
before
that.
If
we
don't
know
where
we're
going
at
least
a
couple
iterations
ahead,
where
we're
kind
of
just
floating
aimlessly
and
that's
not
a
good
thing-
that's
not
I
could
use
your
story,
so
I
think
that
I'm
having
some
direction
at
least
on
some
of
these
had
little
things.
Even
if
it's
a
single
slide
is
super
useful.
E
B
Think
presenting
it
in
the
community
meeting
is
a
good
idea.
I
think
if
you
are
looking
at
a
particular
cat
for
a
particular
design
and
I
figure
out,
there's
this
a
line
with
where
the
stick
is
going
where
the
project
is
going
having
to
then
the
hunt
through
community
meetings
to
find
content
is
not
great,
so
asking
for
it
to
be
reflected
in
some
way
in
the
SIG's
folder
under
community
or
tied
to
sub
projects,
or
something
where
like.
Oh,
this
is
sick,
often
taking
famish.
B
You
want
to
go
look
at
those
two
SIG's
and
like
make
sure
this
isn't
diametrically
opposed
to
their
vision
and
roadmap.
Will
those
things
get
out
of
date?
Probably
should
there
be
like
a
here?
Are
the
five
things
the
cig
is
working
on,
but
kept
reasonably
up
to
date?
Probably
should
be
so.
If
we
noticed
out
of
date,
we'll
ask
for
it
to
be
updated,
but
having
an
asynchronous
way
to
find
that
and
a
consistent
place
for
each
cig
seems
not
unreasonable,
easy
I,
like.
D
Also
Doug
be
apart.
Responsibility
of
both
the
sig
leads,
as
well
as
architecture
to
rationalize
some
of
the
caps
that
have
occurred
over
time.
If
there
are
inconsistencies
to
have
a
I
mean
the
purpose
of
a
cap,
isn't
it
to
be
a
living
document,
not
just
a
document
you
publish
once
and
then
gets
implemented.
It's
meant
to
be
a
document
that
it
revolves
over
time
or
evolves
over
time.
So
that
way
it's
living
and
breathing,
and
it
should
either
be
deprecated
in
favor
of
the
new
implementation
or
the
new
design
or
whatever.
E
E
A
It
doesn't
have
to
be
very
heavyweight,
it's
just
a
weighted
untangle
dependencies
and
have
some
idea
what
the
roadmap
looks
like,
etc.
That
may
be
something
that
we
can
facilitate
and
I
believe
that
CPM
is
highly
interested
in
facilitating
that
work,
so
there
could
be
some
good
cross
collaboration
as
far
as
not
having
to
have
us
beaten
once
we're
executing
on
this.
A
This
pull
from
the
sync
so
I'm
more
than
happy
to
be
the
bridge
between
those
two
works
and
I
know
that
Steven
Augustus
is
interested
in
this
as
well,
so
I
might
I'm
going
to
ask
if
he's
interested
in
volunteering
for
that
works,
I
think
he
would
be
a
good
candidate
for
that.
So
this
is
one
of
those
things
where
I
think
we
should
make
use
of
our
governance
model
to
help
us
accomplish
something
that
two
different
six
have
as
liar.
A
H
I
can
explain
a
remark,
that's
a
guy,
so
we
were
working
on
me
and
I've
got
at
work
recently,
it's
gonna
come
up
that.
Maybe
we
should
be
doing
this
out
of
treating
and
prepares
that.
Maybe
we
should
bring
this
up
to
this
group
here
to
kind
of
talk
that
over
before
we
get
forward,
so
just
want
to
have
discussion
here
on
whether
that
makes
sense
for
something
that
we're
building
like
this
to
be
on
a
tree
and
also
considering
you
know
we
did
the
cap
with
the
idea
of
this
being
in
tree.
I
H
H
J
I
E
B
I
think
that
the
API
server,
depending
on
something
that
is
not
built
into
the
API
server,
is
not
a
great
idea.
So
it
makes
sense
to
me
to
have
it
be
direct
part
of
it
was
part
of
the
question
here
was
the
overall
desire
to
define
all
api's
as
series
versus
like?
Are
there
ones
that
the
API
server
depends
on
versus
other
ones?
The
cubelet
depends
on
and
kind
of,
maybe
rationalizing
where
we
draw
the
line,
because
I
think
there
has
been
conflicting
advice
given
in.
B
E
I
E
D
B
Was
taking
a
the
configuration
API
that
is
currently
set
in
as
a
file
to
the
API
server
to
say,
enable
these
audit
events
filtered
this
way
and
it
is
making
it
controllable
via
a
REST
API,
so
that
same
file
based
API?
You
can
have
multiple
instances
of
it
directing
audit
events
to
multiple
syncs,
so
there's
largely
a
lift
and
shift
of
the
current
file
configuration
into
a
rest
resource
with
some
jumping
through
hoops
to
deal
with
API
machinery.
Auto
B
is
doing
that
so.
H
E
If
there
is
a
component
configuration
format,
I
think
it
is
desirable
for
the
pipes
to
remain
the
same,
and
that
seems
simpler
and
modular.
Our
deprecation
policy
right
even
for
administrative,
lead,
configured
things
like
flags
or
component
config.
There
is
a
deprecation
policy,
otherwise
it
breaks
install
and
things
like
that.
You.
B
I
Yeah
wonder
what
we're
talking
about
here
is
that
that
I
did
a
first
pass
on
the
API
and
and
I
hadn't
seen
the
flat
file
before
it
asked
for
a
bunch
of
changes,
because
it's
very
similar
to
the
to
the
webhook
configuration
API,
which
I
found
confusing
so
I'm,
not
sure
how
legitimate
it
is
to
work
on
reconciling
that
versus
how
how
we
want
to
optimize.
For
you
know,
use
of
development
and
well.
E
I
B
The
goals
of
the
audit
filtering
and
the
goals
of
the
admission
webhook
registration
are
a
little
bit
different,
so
one
is
wanting
to
allow
omitting
noisy
things
so
known.
Users,
for
example,
like
known,
are
really
active.
We
want
to
be
able
to
audit
them
at
a
lower
velocity
level,
or
so
that
there's
like
more
individual
addressability,
that's
desired
for
the
audit
registration
piece,
as
opposed
to
web
book
admission
like.
I
A
I
did
the
could
any
of
the
implementation.
Details
basically
interfere
like
so.
Let's
say
them
to
you.
Do
you
turn
the
AFAP
on
adjust
was
making
sure
there
was
neat
bad
neighbor
affect
them,
maybe
not
how
it's
designed,
but
I
didn't
believe
if
it
makes
API
server
crash
lip
it
would
that's
that's
what
I
was
kind
of
getting
it
if.
A
C
D
So
it's
a
little
it's
it's,
not
necessarily
frustrating
for
me
as
much
I,
think
it's
it's
more
frustrating
for
Patrick
and
for
other
folks
who
are
trying
to
help
it
along
the
way
to
try
and
make
sure
that
you
know
if
we
are
going
to
state
that
we
are
going
to
do
something
and
the
sig
leads
buy
into
that,
and
they
offered
to
review
it
within
that
timeframe.
To
get
it
pushed
out
at
the
end
of
the
cycle
can
be
disheartening
for
a
lot
of
contributors.
E
J
I
was
gonna
graduate
good
to
know.
I
was
gonna,
add,
like
I
think
the
problem
is
is
like
on
the
on
the
architecture.
Api
lead
thing
is
that
were
the
people
who
have
to
say
no
to
a
lot
of
people,
and
so
after
a
while
saying
no
to
people,
because
it's
the
right
thing
to
do
for
the
project
as
a
whole,
it
is
sometimes
you
lose
kind
of
like
it's
a
it's.
J
A
delicate
balance
between
you
know,
making
sure
that
you
say
no
in
the
nicest
possible
way,
but
still
saying
no,
because
everything
can
wait,
except
does
the
next
release
of
the
software
actually
work
or
not,
and
it's
kind
of
this
I
feel
like
this
is
the
tension
here
is
we're
trying
to
enact
like?
Let's,
we
don't
have
to
ship
everything
on
the
hard
boundaries,
because
the
only
thing
that's
important
is
connect
someone
upgrade
from
kubernetes
111
to
112
as
safely
as
possible.
J
We
don't
take
down
their
clusters,
and
so
the
balance
of
bias
is
every
bit
of
risk
is
still
at
risk.
But
then
the
counter
pressure
is
there
are
legitimate
features
that
make
people's
lives
easier.
It's
just
harder
when
they're
an
alpha
to
justify
that
extra
step,
because
an
alpha
the
feature
is
always
less
important
than
stability,
and
that's
the
tension.
I
feel
like
we're
in
in
this.
E
Case
yeah
and
that's
that
bar
is
just
getting
higher
and
higher
I.
Think
the
real
answer
to
this
is
gonna,
be
something
like
future
branches
or
something
like
that,
so
that
we
can
actually
keep
kubernetes
kubernetes
master
and
a
more
releasable
state
consider
changing
the
release
cadence
at
some
point,
so
I
agree.
G
G
In
this
particular
case,
the
API
or
the
proposed
API
changes
were
in
the
cap.
The
cap
was
reviewed,
its
status
was
changed,
implementable
and
again
it's
kind
of
like
a
11th
hour.
Let's
call
back
so
what
I
would
ask
is
that
in
the
future
we
don't
get
to
implementable
and
then
decide
that
we
need
to
change
things.
I
mean
it
it's
it's
not
avoidable,
100%
of
the
time,
but
I
think,
given
that
the
cap
went
through
multiple
rounds
of
reviews
from
different
SIG's.
Ideally
those
things
would
get
shaken
out
during
that
review
time.
E
Want
to
make
one
quick
comment
on
that,
which
is
one
of
the
number
one
things
I
wanted
from
the
cut
processed
is
to
make
sure
that
we
had
a
clear
process
for
assigning
approvers
to
the
cap
to
address
this
exact
issue,
because
when
it's
not
clear
who
the
approver
is,
then
this
kind
of
11th
hour
objection
thing
can
always
happen.
But
if
people
agree
on
who
gets
to
approve
upfront
and
I,
decide,
I
feel
that
could
address
this
yeah.
C
B
And
approve
it
again,
I
had
not
yet
so
the
part
of
it
was
timing.
So
the
cap
came
in
like
right
around
feature
freeze
when
it
kind
of
got
this
expanded
scope
and
while
I
don't
disagree
with
the
goal
of
making
the
policy
be
dynamic,
I
had
not
gotten
to
through
I
hadn't
gotten
through
it
yet,
and
so
it
wasn't
a
I
disapprove
of
this,
but
it
also
was
in
the
backlog
behind
other
things
that
had
been
in
the
backlog
longer
go.
Did
you.
E
E
H
E
J
Think
we
can,
you
can
clarify
or
future
caps
that
if
you're
proposing
API
changes
you
should
get
make
their
you
at
least
do
a
course
level
review
at
the
kept
stage.
It
doesn't
need
not
an
approver
just
reviewers,
yes
right
and
so
I'm
saying
we
should
get
one
of
the
approvers
to
say.
Fundamentally,
this
is
not
going
the
wrong
way
reviewers,
but.
J
G
J
Two
parts
here
my
bias,
would
be
I
think
it
would
be
good
like
so
in
this
case,
like
I,
think
the
API
reviewers
were
saying
they
were
and
approvers
were
saying
they
were
good
with
the
first
part,
but
the
dynamic
policy
was
the
the
late-breaking
part.
I
do
think.
There's
a
part
between
you
approve
the
cap
implementable.
You
should
absolutely
be
able
to
go,
but
you
can't
merge
until
the
API
is
finally
signed
off
on,
because
an
implementation
isn't
a
dock.
J
Isn't
the
implementation
I
do
think
that
there's
no
point
to
going
are
into
implementable
unless
there's
a
chance
that
it's
gonna
get
implemented.
So
I
would
agree
that
we
should
try
as
much
as
possible
to
front-load
cap
plus
approval
of
the
whole
of
the
high
ideal.
But
if
there's
changes
is
that
an
during
the
implementation,
are
we
going
to
keep
the
back
to
the
cap
or.
B
That's
that's
one
of
the
things
we've
wrestled
was
like
it's,
it's
really
common
to
see
a
design
and
it
lays
out
the
types
and
you're
the
data
flow
and
everything,
and
then
you
get
to
implementing
it,
and
you
realize
oh,
like
there's
one
other
fields.
We
need
to
actually
make
this
work
and,
like
you,
want
to
kind
of
be
able
to
say
that
the
idea
was
approved.
B
J
I
do
not
expect
the
final
implementation
of
a
PR,
and
the
thing
that
was
in
the
cap
are
going
to
be
the
same
in
almost
any
cases,
but
I
do
expect
that
they
are
the
same
basic
shape
and
if
I,
if
you
know
I'm
happy
to
look
at
caps
and
in
fact,
I've
been
flagging.
Lots
of
caps
for
this
purpose
to
just
say,
like
I,
think
API
here
is
generally
okay,
get
through
the
implementation.
B
Yeah
so
I
think
there
was
three
things
going
on
here.
One
was
the
kind
of
confusion
about
like
the
last
minute.
Should
this
be,
should
this
even
be
a
native
type
cursor
to
be
a
CEO
like
that
was
that
was
unfortunate
and
I
think
confusion
and
like
a
good
intention
of
saying,
hey,
there's
new
information
that
I've
heard
just
in
the
past
few
weeks
like,
let's
make
sure
we're
not
going
the
wrong
direction.
B
H
B
E
That
all
depends
on
how
much
work
you're
willing
to
redo
right,
like
sometimes
it's
helpful
to
prototype
things
to
work
out.
The
details
like
do
I
have
the
right
set
of
fields
and
things
like
that.
So,
if
you're
not
too
attached
to
it,
that's
reasonable.
If
you're
gonna
write
20,000
lines
of
code,
probably
you
shouldn't
go
all
that
far
before
making
sure
that
it's
in
the
right
direction,
all
right
sort
of
depends
on
the
scope
and
whether
you
have
reasonable
ways
to
scaffold
it
or
prototype
it,
or
some
in.
B
Some
ways
the
scope
for
this
was
intended
to
be
taken,
API
type,
that
we
already
spent
a
lot
of
time,
thinking
about
and
just
make
it
addressable
the
other
REST
API
and
I
I.
Don't
think
that
expectation
matched
some
of
the
people
who
were
looking
at
the
API,
their
work,
Daniel
I,
think
looked
at
it
and
thought.
Oh
here's
an
area
fee
I
can
look
at
which
is
true.
B
He
hadn't
looked
at
the
file
audit
API,
but
others
of
us
had
and
so
like
these
kind
of
mixed
messages
or
are
pretty
tough,
so
figuring
out
a
way
to
coordinate,
and
so
that
we
know
comes
because
what
is
this
and
I'm?
Looking
at
this
going?
Oh
yeah,
this
is
what
we
spent
I'm
looking
at
last
release.
Yeah
I
can
get
that
better.
Those.
E
A
A
Where
you
know,
planning
is
caps
and
building
is
really
the
API
review
and
getting
it
the
bolts
and
details
and
then
run
is
the
sort
of
the
release
team
making
decisions
about
what's
in
and
out
kind
of
in
the
last
minute,
so
I
think
that,
whatever
whatever
you
do
here,
we
need
to
have
some
process
that
takes
into
account
the
different
phases
of
each
of
those
because
caps
have
their
own
life
cycle.
The
reviews
have
their
own
life
cycle
and
then
the
release
has
its
own
life
cycles.
A
E
So
few
things
procedurally
time
check
we're
running
out
of
time.
We
have
about
ten
minutes
left
and
there
are
some
questions
in
the
chats
or
comments
in
the
chat
and
I
want
to
make
sure
we
pull
action
items
out
of
this
to
follow
up
on
like
document
guidance
about
C
or
D
versus
not
would
be
one
clarify,
kept
versus
API
review
and
how
those
things
glue
together
would
be
another
in
the
chat,
Tim
st.
Clair,
so
this
flow
chart
would
be
helpful.
E
E
I
E
C
J
Gut
reaction
is
that
that
sounds
silly,
which
is
we
want
to
do
as
much
as
we
can
up
front,
but
there's
always
like
dotting
the
is
and
crossing
the
t's
at
the
end.
We're
like
are
we
really
sure
that
this
is
the
right
time
to
do
it
and
let's
de-escalate
and
set
expectations
appropriately?
So
that's
not
surprising,
and
occasionally
you
know
we
want
to
grow
the
boundaries
so
that
releases
go
out
stable
and
more
things
are
done
at
a
core
that
is,
as
our
jingle
of
kubernetes
project.
E
C
B
E
I
second,
that
I
said
I
said
again:
I'd
suggest
the
mailing
list,
because
I
can
go
pull
that
specifically
separately
from
the
rest
of
my
inbox
a
reasonable
way.
So
let
me
just
see
other
chats
tangential
question.
Does
an
alpha
feature
need
any
to
be
test?
All
features
need
each
meet
us,
or
at
least
some
kind
of
test
adequate
tests.
Let
me
just
put
it
that
way.
Again.
I
mean
the
bar
is
going
up.
E
One
thing:
I've
been
doing
well,
I
haven't
been
visible
as
much
in
the
community
but
I'm,
seeing
we're
seeing
more
and
more
reliability.
Issues
from
kubernetes
saw
bugs
backward
compatibility,
breaks,
instability.
Things
like
that
so
I'm
sort
of
surveying
the
set
of
issues
and
trying
to
figure
out
how
to
drive
improvements
in
those
areas.
So
the
bar
needs
to
go
up
on
on
testing.
We
have
a
meted
problem
with
testing
that
we
don't
have
good
signal.
We
have
lots
of
tests
that
fail
all
the
time
that
nobody
pays
attention
to
they're.
E
Just
too
many
tests
and
the
matrix
is
too
complex
and
nobody
looks
at
it
or
if
they
do
look
at
it,
they
don't
know
what
to
think
about
it.
So
you
know:
we've
had
this
issue
in
the
past.
Daniel
worked
on
an
effort
to
get
that
under
control
two
years
ago.
It
has
been,
you
know,
constant
struggle
with
flakes
and
whatnot,
but
I
mean.
I
E
E
Just
my
observation
in
the
past
is:
unless
they,
if
they
run
in
the
TR
builder,
they
run
hundreds
to
thousands
of
times
more
frequently
than
any
other
test,
not
exhibits,
problems
that
are
otherwise
surfaced
anyway,
we're
almost
out
of
time.
So
did
you
get
the
answer
you
needed
dims
on
that
ok
flow
charts,
features
so
late
and
answered
it
in
the
chat?
Okay,
so
we
got
action
items
take
a
look
at
them
in
the
notes,
and
one
thing
I
would
like
to
start
doing
is
talk
about
what
we
want
to
talk
about
next
time.
J
E
Okay,
so
anyway,
I
am
gonna,
just
requests
people
to
think
about
it
in
advance.
We
are
do
you
have
the
tracking
boards?
We
are
gonna,
try
to
use
that
I
am
trying
to
put
more
energy
and
time
into
conformance,
especially
that's
higher
on
my
priority
list
and
reliability
as
well,
I'm.
Looking
at
that,
and
then
the
processes,
as
opposed
to
moving
toward
individually
issues
like
individual
new
features.
Sorry,
but
that
is
not
a
high
priority
for
me
at
this
point
we
have
lots
and
lots
of
features
that
are
poorly
tested
and
poorly
documented.
E
D
K
Let's
talk
about
that
next
week,
yeah
one
last
thing
for
me.
So
on
that
email
trend
we
talked
about,
we
were
talking
about
the
Alpha
Gates.
You
know:
how
do
we
is
there
false
for
the
Alpha,
Gate
and
stuff
like
that,
so
I
posted
an
exact
concrete
example.
I
would
like
to
hear
next
week
from
you
guys.
You
know
what
exactly
we
need
to
do
there,
because
you
know
people
were
talking
and
it
was
hard
to
figure
out
what
exactly
I
have
to
go
fix.
If
at
all,
okay.