►
Description
Don’t miss out! Join us at our upcoming hybrid event: KubeCon + CloudNativeCon North America 2022 from October 24-28 in Detroit (and online!). Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
SIG Architecture Intro and Update - Davanum Srinivas, VMware & John Belamaric, Google
SIG Architecture maintains and evolves the design principles of Kubernetes, and provides a consistent body of expertise necessary to ensure architectural consistency over time. The SIG takes care of evolution of conformance definitions, API definitions/conventions, deprecation policy, design principles, and other cross-cutting concerns. In this talk, we will provide an introduction to SIG architecture, including its role and the various subprojects that support its activities. Additionally, we will provide a community update on the status of those efforts.
A
B
B
A
Okay,
so
let
me
go
over
there,
so
it's
a
little
bit
easier
than
you.
You
can
like
switch
so
the
goals
of
the
kubernetes
project.
Is
anybody
not
using
kubernetes
right
now
right?
So
all
of
you
are
using
kubernetes
and
you
kind
of
like
agree
with
the
statements
that
we've
made
there.
Those
were
the
goals
that
we
written
down
in
our
documents
saying
these
are
the
things
that
we
would
like
to
see.
A
This
kind
of
helps
us
going
forward
too.
It's
not
just
the
state
of
the
art
thing
that
we're
talking
about
right
now,
but
we're
also
when
we
design
new
features
when
we
think
about
things
that
we
need
to
do
and
how
to
do
it.
These
are
the
goals
that
literally
helps
us
figure
out.
Like
okay,
for
example,
number
three
right
like
is
there's.
If,
when
we're
designing
something
hey,
this
is
just
too
much
for
users.
It's
too
complicated
we
need
to
simplify.
A
A
A
This
is
what
we
believe
in,
and
anybody
disagree
with
any
of
these
things,
probably
not
right.
So
this
is
kept
us
very
good.
In
fact,
let
me
take
one
thing
and
poke
on
it.
Right
like,
for
example,
automation
over
process.
So
if
you
go
look
at
how
our
testing
infrastructure
is
set
up
right,
you
know
it's
running
on
really
good
with
a
few
bumps
here
and
there,
but
it's
mostly
things
are
happening
on
its
own.
A
We
write
bots
and
bots
talk
to
each
other
bought
stocks
to
people,
so
that
is
one
example
of
how
we
are
doing
number
three
okay,
next
one,
so
the
kubernetes
is
part
of
cncf.
So
overall
structure
is
cnc.
Well,
if
you
want
to
start
right
at
the
top
for
technicality,
there
is
linux
foundation
and
there
is
cncf
and
within
cncf
you
have
the
cncf,
toc
and
cncftoc
has
a
bunch
of
tags.
Technical
advisory
groups
and
tag
runtime
is
probably
what
we
come
under
and
under
poc
is
all
the
projects.
A
Kubernetes
is
one
of
the
projects
and
in
fact
the
cncf
foundation
was
started
with
kubernetes
as
the
first
project.
So
within
kubernetes
we
have
a
whole
bunch
of
special
interest
groups.
Some
of
them
go
deep.
Some
of
them
go
horizontal
I'll.
Take
some
examples
here
like
take
sig
windows,
they
focus
on
how
to
run
windows
based
workloads
on
kubernetes,
better
and
another
example.
If
you
take
sig
release,
you
can
see
that
that
sig
owns
the
release
process
and
it
coordinates
amongst
all
the
sigs.
A
It
fixes
out
the
calendar
date
when
we
need
to
make
a
ship,
and
then
we
work
backwards
to
figure
out
like
when
there's
a
feature,
freeze,
code,
freeze
and
things
like
that,
so
that
we
can
actually
have
a
release
together
right
and
we
end
up
defining
policies.
In
the
sake,
saying,
hey
we're
to
do
three
lessons
a
year.
We
are
calendar-based,
for
example
right.
So
those
are
the
kind
of
things
that
we
do
in
a
specific
sig.
A
A
A
So
then
the
steering
essentially
will
approve
the
charter,
and
you
begin
your
work
that
gives
you
the
validity
in
the
community
to
go
around
asking
for
resources
and
talking
to
people,
and
there
is
a
technical
lead
and
there
is
chairs,
and
then
you
start
doing
your
work
and
you
figure
out
how
you
want
to
do
your
work
and
we
also
have
like,
if
you
take
sig
note,
for
example,
right
you
talk
about
how
how
the
cubelet
works
storage
is.
Similarly,
what
are
the?
How
does
csi
fit
into
the
picture,
for
example
right?
A
So
so?
Essentially,
committees,
sig
groups,
working
groups
and
user
groups,
we're
trying
to
get
rid
of
the
user
groups
and
we're
trying
to
push
that
out
into
the
cncf
layer.
So
to
say
so,
and
this
is
constantly
evolving,
we
added
new
things.
We
took
some
old
things
out
that
were
not
really
relevant
or
there
was
no
work
being
done.
For
example,
there
was
a
service
catalog,
six
service,
catalog
and
they're,
not
doing
anything.
We
you
know
bump
them
out.
There
are
other
things
which
span
multiple
six.
A
B
Yeah
I
mean,
I
think
one
of
the
main
points
with
this
is
that
distribution
is
is
better
than
centralization,
and
so
each
of
these
groups
will
own
a
part
of
the
code,
the
project
level
things
tend
to
set
policies
and
processes
across
the
project,
so
architecture
fits
within
that
area.
We
don't
actually
own
much
if
any.
We
have
maybe
have
a
little
bit
of
tooling
code,
but
no
real
code
and
or
functional
code,
and
so
you
know
that
that's
that's
kind
of
where
we
fit
in
this.
B
Our
scope
falls
into,
like
I
said
kind
of
this
cross
cross
project
area,
where
we
we're
sort
of
the
the
the
monks
who
keep
the
design
principles
kind
of
in
in
line,
and
we
have
groups
and
processes
that
will
help
other
cigs
as
they're
coming
to
design
a
given
feature.
Make
sure
that
they're
in
line
with
those
design
principles
and
make
sure
that
we're.
B
So,
like
I
said,
the
processes
different
cost
credit,
cross-cutting
processes
around
conformance
api
review,
and
then
each
of
those
processes
we
can
go
to
the
next
slide
is
sort
of
oh
well.
I
guess
that's
that
comes
later.
Okay,
we
can
still
go
on
the
next
side.
So
so
we'll
talk
about
each
of
these
later
in
a
bit,
other
kind
of
issues
tend
to
come
up
for
us.
B
So
whenever
there's
a
sort
of
question
between
cigs
about
how
something
should
be
done,
what
makes
the
most
sense
with
in
the
context
of
kubernetes
as
a
whole,
they
typically
will
bring
that
that
sort
of
thing
to
us
we're
not
really
an
escalation
path.
But
a
lot
of
the
people
that
participate
in
the
sig
tend
to
be
people
that
have
been
with
kubernetes
for
a
very
long
time
and
have
very
deep
and
broad
knowledge.
B
B
B
So,
like
other
sigs
sig
architecture
is
arranged
into
sub-projects,
so
sub-projects
then
have
owners.
Those
are
the
people
kind
of
responsible
for
that
area.
So
we
talked
a
little
bit
earlier.
We
saw
a
list
of
the
different
processes.
Each
of
those
processes
is
effectively
run
by
one
of
these
sub-projects.
B
A
Yeah
sure
so
how
many
of
you
used
crds,
for
example,
right
so
crds
have
to
go
through
any.
You
know,
crds
and
other
things,
like
all.
Resources
have
to
go
through
an
api
review
right
so,
and
the
api
review
essentially
says:
okay,
if
you're,
if
you're,
adding
your
feel
or
removing
a
field
or
you're
converting
from
the
classic
example
we
have
is
like.
A
The
api
servers
and
the
cubelets
we
have
to
figure
out
if
older
cube,
ctls
can
work
with
the
newer
api
servers
and
so
on
and
so
forth.
So
through
through
time,
we
have
accumulated
a
bunch
of
thinking
around
how
we
can
make
it
easier
because
say
somebody
from
six
storage
comes
with
an
idea,
and
we
say:
oh
we've
done
something
similar
before,
but
here
were
the
pros
and
the
cons
and
the
problems.
So
maybe
you
should
think
about
doing
it.
The
other
way
where
we
had
lesser
problems
for
end
users,
for
example
right.
A
So
that
is
what
the
api
review
is
and
we
have
a
project
board
and
we
actually
written
down
the
changes
and
the
conventions,
and
things
like
that.
So
when
any
of
the
six
come
to
us
for
api
review,
we
point
to
them
to
these
two
documentations
so
that
they
can
go,
read
what
it
says
and
then
come
back
to
us
and
say
hey.
We
looked
at
these
things,
some
of
those
make
signs,
but
we
still
want
this
unique
thing
that
we
want
to
do
here.
A
B
Of
things
about
this,
so
api
review
is,
is
sort
of
one
of
the
most
critical
aspects
in
the
development
process
and
and
in
in
the
entry
apis.
The
built-in
apis.
Everything
must
go
through
code
through
api
review,
and
you
know
in
a
sort
of
if
you're
looking
to
participate
in
the
project,
and
you
really
want
to
get
deep
into
lots
of
different
areas
or
even
if
you're,
in
a
want
to
participate
in,
say,
cignode
working
towards
being
an
api
reviewer
is
a
is
a
great
way
to
to
get
involved.
B
We
really
need
more
people
to
do
that
because
it
becomes,
it
can
become
a
bottleneck.
We
have
many
reviewers
for
api,
but
there's
only
a
handful
of
people
that
can
do
the
approvals,
so
it
requires
a
sort
of
a
lot
of
knowledge
and
you
need
to
do
a
lot
of
api
reviews
under
the
guidance
of
those
few
current
api
approvers
before
you
know,
you're
sort
of
like
okay,
you're
good
to
go.
Yeah.
A
A
A
This
is
going
to
be
awesome,
everybody's
going
to
love
it
and
we
vendor
the
code
into
the
tree
and
it
pulls
in
things
from
github
here
and
there
and
guess
what,
after
six
months,
those
people
are
gone
right
because
they're
off
doing
other
things
and
it
there
is
a
set
of
people
who
have
to
maintain
the
dependencies
update
to
relevant
versions
and
make
sure
that
you
know
things
are
not
broken,
and
there
is
this
constant
thing
about
hey.
There
is
a
cv
that
was
in
this
dependency
and
you're.
A
Using
this
dependency,
my
scanner
is
screaming
at
me.
Can
you
go
click?
Please
fix
it,
for
example,
right,
so
there's
plenty
of
code,
maintenance,
things
that
we
need
to
do.
Another
example
is
a
hey.
We
need
to
switch
go
versions.
We
need
to
go
to
118
and
in
118
can
we
use
all
the
new
fancy
things
that
is
coming
in
180.?
Somebody
has
to
say:
hey:
don't
do
it
right
now,
let
us
ship
124.
A
When
we
go
to
125
you
know,
then
we
can
start
adding
generics
a
little
bit
right
and
then
we'll
figure
out
how
it
works
and
then
we'll
expand
the
usage
of
generic
somewhere
else.
So
maybe
we
should
start
with
libraries
first,
because
then
those
are
easier
smaller
to
tackle,
and
you
know
we'll
figure
out
how
we
do
the
testing.
Maybe
there's
some
additional
problems
that
we'll
end
up
seeing
with
generics.
A
One
simple
example
is
hey:
we
need
to
patch
something
in
master
and
we
need
to
backport
to
124
and
124
doesn't
do
generics
right.
So
those
kinds
of
issues
people
come
to
us
and
we
work
through
those
situations
with
them,
and
there
is
a
constant
effort
to
make
sure
that
the
dependencies
are
up
to
date.
They
work
and
the
people
who
are
ending
up
importing
kubernetes
code
into
their
repositories.
A
A
B
A
B
Sure
I
can
do
it
either
way,
yeah,
so
the
other
one
of
the
other,
the
other
sub-projects
within
sig
architecture
and
came
out
of
well
6pm
closed
down,
and
so
we
adopted
the
enhancements
process
so
the
enhancements
process
for
those
of
you
how
many
of
you
have
contributed
to
kubernetes
a
few
of
you
right.
So
if
you
want
to
bring
a
new
feature
to
kubernetes,
you
know
you,
you
don't
just
start
writing
it.
B
We
want
to
have
some
agreement
amongst
the
community
that
the
feature
is,
you
know
appropriate
for
kubernetes
that
the
feature
is
designed
properly
in
alignment
with
the
other
features.
So
people
know
how
to
use
it
without
having
to
you
know,
read
too
much
documentation
and,
and
that
it's
it's
you
know
among
other
things,
and
so
we
have
this
process
called
kubernetes
enhancement
or
cap
process.
This
is
probably
the
thing
that
contributors
interact
with
the
most
that
comes
out
of
sync
architecture
and
they
hate
us
for
the
most,
because
it
is
a
little
painful
right.
B
It's
but
it's
like
writing
a
design
document.
You
got
to
write
a
design
document
and
there's
a
bunch
of
pieces
of
information.
You
have
to
kind
of
fill
in
and
you
have
to
walk
that
through
a
bunch
of
approvals
and
gates,
so
we
own
that
process,
there's
a
sub
project
of
trying
to
make
that
better.
So
if
you're,
one
of
those
few
people
that
raised
your
hand
and
you
contribute-
and
you
don't
like
how
the
kept
process
works,
come
talk
to
us
at
that
sub
project
come
help
us
make
it
better.
B
B
To
either
of
those
lights,
so
yes
good
point
another
sub-project
conformance.
So
if
you,
if
you
look
at
different
kubernetes
distributions
like
gke
or
canzu
or
some
of
these
other
ones
right,
everyone
will
have
a
certified
kubernetes
badge
and
if
they
don't,
they
can't
call
it
kubernetes.
So
that's
a
program
run
by
the
cncf
that
allows
vendors
to
submit
their
their
test
results
and
then
cncf
gives
them
the
badge
or
not.
B
However,
it's
this
group
that
decides
what
those
tests
are,
which
tests
actually
define
kubernetes,
which
functions
are
part
of
kubernetes
and
which
are
optional
functions
within
kubernetes
and
so
sort
of
where
where's
the
name
name.
When
do
you
get
the
rights
to
use
that
name
which
test
you
have
to
pass?
So
we've
been
working
on
this
for
years
and
we
had
a
whole
bunch
of
technical
debt.
There's
a
team
from
a
company
in
new
zealand
called
ii.
That's
really
done
a
tremendous
amount
of
work
for
the
cncf
to
kind
of.
A
Pay
down
that
debt-
and
this
is
not
just
to
bug
the
vendors
to
pass
this
test
to
it-
it
is
to
make
sure
that
you
all
can
depend
on
the
the
out
output.
The
project
manage
cloud
providers.
You
get
a
consistent
experience
across
all
the
products
that
you
use.
That
say
that
they
support
kubernetes,
and
that
is
the
reason
we
do
it.
So
it's
not
for
us.
It's
for
you.
B
Absolutely
yes,
all
right
production
readiness
review.
So
this
is
one
of
those
things
that
people
don't
like
well,
contributors,
don't
necessarily
love,
but
it's
important
so
two
years
ago,
maybe
you
know
as
the
project
matured
and
there's
there's.
You
know
thousands
and
thousands
of
people
depending
on
it
to
be
stable.
B
We
we
introduced
a
process
that
a
lot
of
you
know
big
tech
companies
use
internally,
which
is
for
production,
readiness
reviews.
So
essentially
it's
contributors
when
they
write
those
caps.
We
added
a
big
questionnaire
in
there
that,
as
they
move
from
alpha
to
beta
to
ga,
they
have
to
sort
of
document
how
you
turn
the
feature
on
and
off
the
how
what
the
metrics
are
for
the
feature.
B
What
are
the
known
failure
modes
and
how
do
you
detect
them
basically
make
it
observable,
make
it
supportable
and
ensure
that
the
people
who
take
this
next
version
of
kubernetes?
That
has
this
feature,
don't
have
to
roll
back.
I
mean
that's
the
main
goal
right.
We
don't
want
people
to
have
to
roll
back
their
community.
A
B
Right
exactly
how
do
I
know
the
features
working
yeah
like,
and
how
do
I
know
if
people
are
using
it
in
my
cluster?
If
I'm
a
cluster
administrator?
How
do
I
know
my
application
developers
that
are
using
my
cluster
are
using
this
feature
and
you
see
the
big
qr
code
so
every
year
we
do
a
survey
since
we
started
this
like
our
third
survey,
we
do
a
survey
to
see
if
it's
effective
right,
because
this
is
a
burden
on
our
on
our
engineers
and
in
the
community.
B
B
A
Yeah,
so
if,
if
you
go
look
at
the
cncf
landscape,
I
know
it
is
a
huge
and
big
and
how
how
did
we
get
to
that
spot
right?
That
is
because
we
were
thinking
about
these
things.
We
were
saying:
okay,
we
need
to
distribute
responsibilities,
so
there
is
csi,
cri,
cnn,
there's,
like
you
name
it.
We
have
an
extension
point.
We
have
web
hooks.
We
have
mutating
weapons
validating
web
hooks.
We
have
all
kinds
of
things
where
people
can
integrate.
It
was
not
the
way
at
the
beginning
like
if
you
go.
A
Look
at
you
know,
five
years
ago,
kubernetes
versions
and
check
those
things
out.
You
won't
see
it
that
way
right
like
because
everything
was
in
a
mono
ripple.
Everything
any
vendor
wanted
to
get
anything
and
everything
was
going
right
into
the
same
pocket,
but
over
a
period
of
time
we
we
did
all
these
things
so
that
people
can
do
things
outside
of
us
without
asking
our
permission
without
needing
to
put
things
in
our
repository,
for
example,
right
so
and
again,
so
it's
exploded.
A
The
ecosystem,
like
there
are
literally
hundreds
of
projects
out
there
that
extend
kubernetes
in
one
way
or
another,
and
that's
a
conscious
decision.
There
are
some
bad
outcomes
to
it.
For
example,
the
people
who
used
to
work
on
the
core
now
go
do
something
else
right
like
so.
We
need
to
figure
out
like
how
to
attract
them
back
too,
and
that
is
happening
too,
because
there
is
a
plenty
of
times
where
what
we
have
done
is
we've
done
an
extension,
for
example,
scheduling
right.
A
So
scheduler
is
extremely
you
know
configurable,
so
people
went
experimented
outside
and
now
they're
coming
back
and
say
hey.
We
did
this
experiments
in
like
five
projects,
we're
trying
to
do
different
things.
Now.
We
think
that
we're
at
a
point
where
there
are
some
things
we
need
to
add
to
kubernetes
code,
then
we
can
go
around
changing
everybody
else
and
change
the
usage
of
kubernetes.
A
Again
the
examples
I
was
also
already
mentioning
that
you
know
one
example
is
a
funny
example.
Crd
was
an
iterative
thing.
It
wasn't
crd
before
it
was
called
a
tpr
third
party
resource.
That
was
one
more
experiment
that
we
ran.
Where
we
figured
out.
Okay,
we
defined
some
resources
and
we
were
trying
to
figure
out
how
people
use
it
and
then
we
said
incorporating
all
those
feedback.
Then
we
designed
the
crd,
then
all
of
you
are
using
crds.
A
B
B
The
reason
we're
not
going
to
do
it
is
because
the
instead
we
focus
on
building
extension
points
and
by
building
extension
points
we
don't
need
to
change.
We
don't
need
to
go
to
a
v2
which,
of
course,
if
you're
familiar
with
semantic,
versioning
or
v2
means
we
break
backward
compatibility.
We
don't
want
to
do
that,
so
we
can
continue
we're
going
to
continue
on
that.
There's
a
real
effort
around
things
like
crds,
and
this
would
be
an
api
machinery
saigons
that
but
to
make
them
as
fully
functional
as
the
built-in
apis
we're
working
towards.
A
A
A
Like
I
said
we
don't
buy,
so
speak
up,
offer
your
thoughts,
help
wherever
you
can
and
typically
what
we
say
is
come
to
the
closest
to
what
you're
already
doing
so,
for
example,
if
you
are
interested
in
new
features
for
your
products,
then
come
to
the
enhancement
process.
If
you
are
a
maintainer
who
loves
maintaining
libraries
and
things
like
that,
you
know
come
help
in
code
organization,
for
example
right.
So
there
is
a
lot
of
work
to
do
too
few
hands
and
we
would
like
your
help.
Thank
you.
E
Thank
you
for
your
talk.
I
have
a
question
about
ga,
so
so,
as
I
understood
you
folks
actually
like
in
charge
of
letting
the
future
happen
in
the
first
place,
but
then
there's
a
life
cycle
and
then
the
feature
reaches
ga
yep.
I've
heard
an
opinion
recently
that
if
it
features
like
if
it
reaches
ga
it's
there
forever
and
since
then
it
will
not
ever
move
from.
A
A
B
So
deprecation
policies
are
sort
of
yes,
but
we
we
do
really
want
to
make
you
know
in
an
ideal
world
once
a
once,
an
api,
it's
been
specifically
apis
once
they
hit
a
ga
v1
like
you,
don't
want
them
to
go
away
because
people
built
things
on
top
of
them
and
when
you
take
something
away
now
that
person
that
that
whole
ecosystem
build
on
top
of
that
is
either
locked
out
or
they
are
forced
into
a
migration
process.
So
we
do
take
very,
very.
A
A
E
A
A
A
I'll
give
you
the
exact
example
again
with
the
with
the
psps.
We,
the
people
in
the
sig,
said:
hey
sig
auth,
they
said
hey.
This
is
not
working,
let's
just
get
rid
of
it.
Let
people
use
oppa
q
or
no
and
other
ecosystem
projects
to
do
exactly
the
same
thing,
and
people
can
already
do
that.
So
when
all
those
things
are
there,
why
do
we
need
to
do
it?
A
A
A
So
I
I
do
want
to
say
one
thing
there,
which
is
people
in
the
room,
make
the
decision
right.
Those
are
guidelines
for
the
people
in
the
room,
because
the
same
people
are
not
going
to
be
in
the
room
all
the
time
right.
So
those
are
guidelines
for
the
people
in
the
room
to
say:
hey,
please
think
about
these
things.
When
you
are
making
a
decision
right,
yes
and
it
might,
the
order
of
the
priority
of
things
might
depend
on
the
people
in
the
room,
but
it's
a
general
guideline.
C
A
A
B
Own
time
right,
yes,
so
every
every
api
group
will
have
its
ver.
Your
group
version
kind
of
you
know.
So
your
group
version
you
get
a
v2.
We
have
some
v2s.
We
have
auto
scaling
as
v2.
We
have
a
few
v2s,
but
what
we're
talking
about
is
kubernetes
v2,
which
would
mean
like
fundamentally
changing
the
everyday.
D
B
A
A
Underlying
but
there
is
a
plan,
or
at
least
thought
process
in
in
mind,
for
some
people
saying
what
is
the
core
set
of
things
in
the
kubernetes
core
api
that
are
not
in
ga
that
we
need
to
get
to
ga
before
we
can
say
hey.
Maybe
we
can
do
a
lts
version
now
right
so,
and
that
is
an
even
longer
discussion.
A
B
People
have,
but
you
know,
there's
a
part
of
kubernetes
that
is
sort
of
container
orchestration,
but
there's
the
piece
of
kubernetes,
that
is,
the
api
machinery
which
has
been
is
being
used
for
many
many
other
things
than
container
orchestration,
and
so
you
know,
if
you,
you
know,
you
can
kind
of
parcel
out
potentially
that
that
gem
into
a
more
a
smaller
core
of
kubernetes
you
know
and
and
then
the
the
other
functionality
is
not
necessarily
all
necessary,
like
name
spaces
are
necessary.
Users
are
necessary.
You
know,
yeah,
there's
a
bunch
of
things.
A
I'll
give
you
one
more
example
like
q.
Proxy
is
something
that
people
are
aware
of
right,
but
there
are
vendors
that
don't
ship
q
proxy
because
they
do
it
differently
yeah,
so
they
don't
need
q,
proxy
psyllium,
for
example.
Right
so,
and
there
is
projects
like
virtual
cubelet,
they
say
hey
this
cubelet
thing
if
we
replace
it
with
virtual
cube,
let
me
we'll
do
another
set
of
use
cases
and
scenarios
right.
There
is
a
version
of
cube
cubelet
that
is
written
in
rust,
that
supports
wasm.
A
A
D
B
Of
us
right,
there's
a
whole
team
that
we're
just
the
chairs
right,
yeah,
there's
all
these
sub
projects
have
other
team
members,
people
working
on
it
so
but-
and
it
varies
during
the
time
of
year-
so
I
I
am
one
of
the
people
that
does
production
readiness,
reviews
and
there's
only
two
or
three
other
people
that
do
that
for
the
whole
project.
So
that
means
in
the
two
three
weeks
before
enhancements.
Freeze,
I'm
spending
a
lot
of
time.
B
A
Yeah,
it
varies
depending
on
the
calendar
time
same
for
me,
like
code
organization.
We
try
to
do
whatever
we
can
early
in
the
cycle
like
before.
We
won
no
alpha
1
or
something
like
that.
We
have
milestones
so
we
try
to
put
as
many
of
the
changes
so
that
it
bakes
in
the
ci
systems.
So
over
a
period
of
time,
we'll
watch
and
say
hey.
A
You
know
something
is
wrong
right
like
so,
you
start
making
changes
early
and
the
more
invasive
the
change
the
earlier
you
do
it.
For
example,
we
are
changing
k
log
right,
so
we
try
to
do
it
right
early
in
the
cycle.
So
later
in
the
cycle,
people
are
like
okay,
it's
smoothened
out
over
time
and
nothing
is
bothering
the
ci
systems
and
users
will
be
able
to
use
it.
Fine,
okay,.