►
From YouTube: Kubernetes 1 9 Release Retrospective Part one 20181220
Description
A
Corners,
hey
welcome
everybody
to
the
1.9
community's
release
retrospective.
This
is
literally
our
last
call
of
the
year,
as
Swarna
has
pointed
out,
so
this
has
been
quite
an
amazing
year.
This
is
our
fourth
release.
This
year,
we've
hit
within
two
days,
I
believe
every
release
target
milestone
we've
set
for
the
year,
which
is
beyond
remarkable
I,
don't
know
that
any
other
project
with
as
massive
a
release,
students
and
being
Community
Supported,
has
done
as
good
a
job
with
that.
A
So
we
need
to
all
pat
ourselves
on
the
back
for
doing
what
is
widely
considered
impossible
by
many
standards
so
again,
greatest
community
ever
I'll
just
leave
it
right
there.
So
before
we
get
into
the
the
release
retrospective
itself,
I
wanted
to
take
a
moment
and
just
reflect
on
why
we
do
the
release
retrospective
and
sort
of
the
rules
of
engagement.
A
Really,
what
we're
trying
to
do
is
ferret
out
what
are
the
ways
in
which
we
can
make
our
release
process
better,
more
inclusive,
hopefully
more
predictable
and
easier
for
the
community
to
interact
with
and
consume.
Also,
how
do
we
increase
our
visibility
and
transparency
to
the
community
that
uses
the
the
software,
because
this
is
becoming
mission-critical
for
so
many
things
in
the
world,
and
we
have
this
incredible.
A
Covenant
of
trust
that
we
need
to
maintain
and
the
release
process
is
absolutely
right
in
the
middle
of
that,
and
so
that's
definitely
a
key
tenant
is
if
we
want
to
preserve
that.
So
as
we're
going
through
this
remember
to
be
respectful
and
solution
oriented
in
your
communication,
we
want
to
make
sure
that
everybody's
voice
is
heard
and
respected.
A
If
you
have
something,
that's
a
concern
or
something
you're
frustrated
with
during
the
process,
make
sure
that
you
focus
on
the
process,
the
tools,
the
technology,
whatever
that
was
and
less
on
the
people,
because
really
those
are
the
things
as
a
community
that
we
can
change.
How
we
are
we
operate
in
the
world
and
yeah
get
in
people.
Problems
are
usually
best
served
on
a
1:1
basis
and
within
the
constructs
of
the
Code
of
Conduct.
A
So
if
you
add
an
item
to
the
list,
please
put
your
name
by
it
so
that
you
can
speak
to
it.
If
you
have
something
that
you
don't
want
to
call
out
publicly,
just
send
me
a
message
behind
the
scenes
and
I
will
definitely
raise
it
as
a
concern
anomalously
for
you
and
if
you
at
any
point
during
this
meeting,
feel
like
there's
something
happening
that
you're,
not
okay
with.
Please
also
message
me
privately
and
I'll
take
care
of
it.
A
Okay,
great
so
in
1.8
we
had
a
list
of
things
that
we
had
talked
about.
Doing.
I
I
was
not
deeply
involved
in
the
release
this
time
as
much
as
I
wasn't
1.8,
so
I
didn't
actually
go
through
and
analyze
the
the
things
that
were
follow-ups
from
1.8,
but
I
would
ask
people
in
in
the
retro
to
just
take
a
quick
look
at
this
list
in
the
retro
doc.
And
if
you
don't
have
the
doc
I'm
gonna
head
and
paste
a
link
to
it
here
in
the
chat.
A
A
Okay,
so
if
you
scroll
down
the
document
to
what
went
well
in
1.9,
you'll
see
a
list
of
things
there
and
we're
gonna
go
ahead
and
run
through
those,
so
I
mean
fair
fight.
Aaron
is
on
the
call
I'm,
not
sure
he
could
make
it.
He
has
a
few
of
these,
so
I'll
probably
have
to
speak
for
Aaron
and
this,
but
okay
so
well.
This
is
our
chance
to
call
out
things
that
went
well,
people
that
you
want
to
recognize
as
having
done
an
excellent
job
during
the
release
process.
A
A
First,
one
I'll
claim
was
that
I
think
you
Anthony
did
an
absolutely
fantastic
job.
During
this
release
and
I
think
in
some
ways
the
queue
for
release
of
kubernetes
is
the
absolute
most
difficult.
Because,
oh
let's
see
we
got
holidays,
we
got
a
shortened
dev
schedule,
we've
got
coop
con
I
mean
it
was.
It
was
truly
a
cat
herding,
extravaganza
and
I
think
you
Anthony
did
and
just
stellar
job
on
this
release
and
and
I
appreciate
it
tremendous.
It
was
a
lot
of
work.
A
A
So
moving
down
the
list,
Aaron
Creek
and
burgers
had
I
liked
the
use
of
cig
release,
issues
that
I
could
link
to
for
specific
builds
throughout
the
release
process.
Did
this
is
a
question
for
them?
Can
community?
Did
you
know
that
there
is
a
project
board
and
cig
release?
And
if
so,
did
you
ever
look
at
it?
A
I'm?
Probably
not
anybody
did,
but
if
you
did,
maybe
let
me
know
in
the
in
the
chat
because
I'm
curious
if
the
project
board
is
useful
or
not
also,
Erin
said
that
he
liked
the
the
1
9
the
119
was
meeting
weekly
I
also
think
that
was
great.
Having
regular
meetings
was
was
helpful
to
keep
everybody
in
alignment.
A
B
The
other
thing
is
the
additional
automation
like
the
automation
around
the
PRS
that
got
chatted
was
very
helpful
and
we're
now
in
the
state,
where
the
only
thing
that
we
can't
do
via
commands
to
the
box
is
milestone
assignment.
So
it
makes
it.
It
makes
it
easier
for
everybody
to
actually
control
the
status
of
issues
without
needing
to
mock
your
own
inner
permission.
So.
A
Josh
yeah,
that
was
both
of
them.
Okay,
I
just
want
to
make
sure
you
said
what
you
needed:
Jennifer
you're
up
next.
C
Okay,
I
have
more
to
say,
I
should
say,
but
what
we
didn't
do
for
1-9
that
we
said
we
would
do
at
the
end
of
1/8,
but
for
all
that
I
thought
that,
given
especially
all
of
the
structural
constraints
around
this
release,
that
the
release
notes
really
went
pretty
darn
well,
I
think
this
having
two
writers,
one
sort
of
lead
and
what
shadowing
it's
awesome.
It
takes
so
much
of
the
individual
burden
off
and
I.
Don't
think
Nick
is
on
the
call,
so
I
just
want
to
call
out.
He
was
amazing.
C
C
It's
still
not
I
think
the
process
we
want
to
land
on,
but
I
think
that
having
the
Google
Doc
worked
pretty
well
for
people
and
again
I
want
to
call
out
thanks
to
everybody
who
worked
on
the
release,
notes
during
coop
con,
because
people
did
step
up
to
the
plate
and
do
that
and
I
was
pinging
individuals
during
a
conference.
I
knew
that
they
were
busy
and
they
were
all
super
responsive.
A
C
D
Yeah
just
like
to
mention
how
we
we
were
good
with
the
features
with
this
release
in
the
fee
interest
timeline,
comparing
to
the
previous
releases,
where
we
fed
a
set
of
extra
features
that
were
proposed
after
the
formal
features
deadline.
Was
this
release
almost
every
single
feature
that
was
proposed
and
then
implemented
in
109
was
proposed
beforehand
did
and
did
make
the
big
benefit
for
multiple
errors
of
cabinet
is
one
deadline
and
especial
for
the
marketing
area?
It's
yet
another
big
note
for
me,
so
we
were
really
good
with
marketing
activities
in
his
release.
D
There
they've
been
a
huge
media
and
marketing
coverage
before
had
especially
during
clip.
Condit
was
the
largest
industry
event
of
the
year,
and
almost
every
single
person
was
aware
of
cabinet
responded
was
happy
named
expanded
9,
even
despite
the
fact
that
many
responded
9
wasn't
really
at
that
moment.
So
I
would
mention
how
how
marketing
teams,
especially
Natasha,
did
a
great
job.
Didn't
it.
A
A
A
Okey-Dokey
I'm
moving
on
to
the
next
thing.
The
next
thing
is
what
could
have
gone
better
and
I'm
gonna
turn
the
microphone
over
to
Anthony
for
the
first
part
and
then
we'll
go
from
him
to
I.
Don't
know
if
Lucas
is
on
the
car.
Not
me,
take
a
look:
I,
don't
see
him
so
I'll
do
Lucas
is
but
go
ahead
and
fire
off
Anthony
I.
E
Right
things
that
I
added
during
the
during
the
release
process
as
we
had
to
stop
procuring,
which
was
me
one
of
the
things
that
came
up
first,
was
at
the
point
we're
asking
people
to
open
the
placeholder
text
that
was
confusing
for
some
other
day.
They
were
thinking
like
I,
don't
know
what
kind
of
hard
to
get
as
I
understand.
We
know
the
necessary.
He
could
have
a
tough
written
at
that
point
and
there
were
some
words.
It
was
like.
Oh,
why
do
I
need
to
do
this
and
I
was
trying
to
explain
like
well.
E
E
A
A
E
Left
her
any
comments
on
that
an
excellent
and
the
next
one
was
a
Dakota
breeze
was
scheduled
on
the
last
day
before
us
holiday.
Many
reviewers
approved
route
that
be
placing
increased
burden
on
the
queue.
For
me
a
good
example.
This
was
team
Aachen,
who
was
like
the
only
top-level
reviewer
who
was
not
out
of
town
on
that
day
and
I
say
for
freezing,
so
it
would
be
pretty
much.
Everything
fell
on
him
if
it
wasn't
covered
by
a
smaller
owners
file.
E
This
one
was
kind
of
a
conundrum
because
it
seemed
equally
bad
to
push
it
earlier
and
it
did
to
push
it
later.
So
it's
something
that
we'll
have
to
think
about
for
the
next
cue
for
relief,
I
J
said
we
have
a
lot
less
time
in
q4
than
all
the
other
quarters
and
we
need
to
figure
out
a
way
to
establish
the
scope
of
the
release
and
q4
in
order
to
prevent,
having
could
be
a
thin
line
so
close
to.
A
Cool
okay,
any
comments
about
that
I
mean
obviously
this
sort
of
gets
into
the
general
aspects
of
the
q4
and
actually
I'm
gonna,
but
I'm
gonna
do
something
I'm
gonna
move
up
my
item
because
we're
sort
of
already
thinking
about
this,
which
is
the
queue
for
you
for,
is
really
really
hard
to
schedule
around
and
something
I
would
love
to
see
us
dialogue
on
is:
should
we
even
be
doing
this?
Is
this?
A
E
F
E
F
I'm
I,
yes,
I,
largely
agree,
they're
having
a
release
schedule
near
or
on
Thanksgiving
or
Kuk
on
or
most
of
the
holidays
in
general
was
a
bad
idea.
I
raised
my
objections
to
this
when
we
were
scheduling
their
lease
in
the
first
place,
and
now
we
all
have
the
experience
and
data
to
show
how
well
this
works.
F
A
E
Is
he
headed
to
the
schedule
after
I
became
released,
leave
the
Pinto
was
put
up
before
I
was
relieved
and
one
of
the
things
that
I
changed
was
I,
think
I
converted
in
an
RC
into
a
beta,
because
something
about
the
timing.
It
wouldn't
they're,
actually
given
us
anything
better
than
like
I,
wouldn't
have
been
ready
for
an
RC
at
that
point
and
we
also
have
think
had
zero
betas
or
something
something
weird
like
that
in
the
original
schedule.
E
So,
basically,
it
was
just
renaming
the
RC
to
adina-in
or
two
more
everything
to
keep
the
amount
of
confidence
we
were
going
to
have
in
that
release
at
the
time
and
so
by
the
time.
I
did
that
there
was
just
no
rule
EFT
in
the
schedule
to
have
another
RCT
and
that's
that
sort
of
a
queue
for
unique
issue,
because
if
we
had
one
more
week,
we
could've
easily
gotten
our
theme.
D
I
have
one
question
I
get
at
it,
so
you
should
have.
Why
would
have
implemented
arity
of
ever
having
our
C's?
One
of
the
main
reasons
was
to
push
these
RC
is
to
the
potential
to
be
nerdy,
sweaters
and
other
people
are
companies
who
like
to
consume
it
before
I
made
sure
that
we
did
it
with
with
the
latest
beta
correctly,
for
if
I
am
wrong,
I.
E
A
We
had
a
there
was
tragically
little
attention
paid
to
those,
and
it's
not
really
out
there
long
enough
to
get
solid
feedback
anyway.
I
mean
I,
the
comedian
folks
and
one
utter
obviously
using
it.
There's
a
few
here
in
there
a
bit
we
with
the
the
release
candidate,
just
generally
speaking
as
a
Ford
like
a
really
forward-looking
thing,
as
the
project
gets
more
more
de
streeted,
the
ecosystem
becomes
less
dependent
on
kubernetes,
kubernetes
and
more
on
what
things
are
basically
consuming
it
that
those
are
going
to
be
super
important
and
we
keep
talking
about
it.
D
B
He
is
a
Compton
of
of
us
having
a
short
release
cycle
compared
to
some
projects.
There's
three
months
and
the
RC
is
honestly
not
being
out
very
long
before
we
get
the
final
release.
I
mean
the
last
couple
of
really
cycles.
There
are
seeds
have
been
out
for
a
matter
of
days
before
we
do
the
final
release,
so
you
know:
when
would
anyone
adopt
them
so.
G
So
quick
question:
do
we
have
adoption
of
any
of
the
tag
things
before
an
RC
because
I'm
looking
now
and
so
we're
starting
to
look
at
tools
running
on
top
of
kubernetes
1-9
and
we're
trying
to
find
out?
Where
can
we
get
in
an
environment
spun
up
to
start
testing
tools
on
and
it
seems
there
isn't
high
adoption
of
1-9
even
several
days
after
it's
been
out,
and
I'm
wondering?
B
That's
a
reasonable
substitution
I
think
one
problem
is:
is
that
I
guess
personally,
I
have
not
witnessed
well
I
guess
to
you
appointment,
certainly
I
guess
a
several
enters
that
I
have
seen
have
struggled
to
either
they're
far
I'm
the
will
to
consume
and
make
environments
available
for
one
nine,
either
internally
or
externally,
for
those
who
provide
hosted
solutions.
I
don't
personally
know
how
to
improve
that.
I
do
think
that
that
prevents
some
adoption,
at
least
for
tools
built
on
top
of
rigs,
that
there's
not
an
easily
consumable
a
hosted
option
for
for
getting.
D
G
Yes,
April
are
releases
itself,
oh
well,
one
eight
took
a
while
before
it
started,
getting
out
there
as
well
and
so
I'm
wondering
if
we'd
like
to
see
adoption
of
our
alphas
and
our
C's
and
maybe
get
a
release
out
there
sooner
is
there
way
we
can
make
it
easier
for
people
to
spin
up
an
environment
or
to
get
going.
Is
there
something
we
can
do
to
lower
that
barrier,
because
it
seems
hard
right
now
and
that
might
be
making
it
more
difficult,
especially
with
short
cycles.
E
In
an
egg
problem,
I
think
we
had
an
open
source
project
can't
make
that
happen
because
that's
more
on
the
providers,
but
in
order
for
the
providers
to
start
thinking
about
that,
we
as
a
project
as
an
open
source
right
I
have
to
get
pretty
good
at
reliably
producing
our
entities
with
enough
time
before
the
final
release.
That
is,
and
it
makes
sense
for
them
to
invest
in
well.
F
Parenthetical
rants
about
us
cutting
alpha
and
beta
releases
with
our
tests,
failing
so
the
results
that
we
display
show
that
our
state
or
passing
our
own
tests.
So
if
I
were
a
downstream
provider,
why
would
I
trust
that
this
release
is
any
good
anecdotally?
What
I
heard
up
on
the
cuca
on
floors
were
that
you've
apple-like
reputation
where
you
never
ever
trust
the
thought.
Oh
release,
always
just
wait
until
adopt
one,
let
all
the
suckers
who
adopt
the
dato
be
the
guinea
pigs,
and
this
is
what
we
want
the
release
candidate
to
be.
F
F
H
I
J
F
So
this
is
personal,
why
I,
try
and
give
precedence
to
when
I
hear
complaints
like
this
confrontive
come
from
Canadia,
because
they
are
an
example
of
a
downstream
consumer
of
our
binary
artifacts
that
is
still
kind
of
close
to
the
fold,
so
they're
very
communicative
for
all.
We
know
there
might
be
a
lot
of
other
people
out
there
who
have
the
same
problems
that
cube
ATM
does
but
they're
not
willing
to
come
up
and
participate
in
this
process,
and
so
I'd
like
to
you
know
better
understand.
F
I
Okay,
I
have
a
related
comment
to
make
that
kind
of
stretches
across
a
few
of
these
things
and
I.
Think
it's
the
same
issue.
Is
this
so
I'll
use
the
opportunity
to
jump
in
and
and
say
the
one
thing
here,
which
is
okay,
that
the
I
think
the
symptom
here
is
they,
as
as
a
community
where
we're
setting
up
these
bars
thresholds,
things
that
need
to
be
done,
but
then
we're
not
actually
sticking
to
them
when
it
comes
to
release
time.
I
I
I
thought
Aaron's
comments
at
the
dev
summit
were
particularly
apropos
on
this
point,
which
is
we
talked
about
stability
releases,
but
for
some
reason
we
never
quite
seem
to
get
there
I
think
just
you
know,
sticking
to
our
own
sticking
to
our
own
principles
as
we
go
through
through
the
release
here
is,
or
you
know,
it's
a
really
hard
thing
to
do,
but
it's
getting
to
be
increasingly
important
and
I'm
glad
to
hear
that
see.
There's
at
least
one
member
of
the
steering
committee
here.
A
I
J
Back
to
the
ownership
right
I
mean
we
tell
that
the
six
have
to
own
their
issues.
Try
out
their
issues,
take
care
of
their
CI
jobs
and
things
like
that
and
things
are
not
happening
there
right.
We
don't
see
that
happening,
I,
don't
know
how
to
fix
it,
but
we
don't
have
a
strong
core
ownership
by
the
six
of
the
day
that
they're
responsible
for
and
we
are
seeing
the
effects
of
that
spill
over
here.
C
At
the
cig
level,
we
haven't
really
moved
forward
very
far
in
1.9,
but
what
we
really
want
to
do
in
no
1.10
cycle
and
Jared
body
and
I
are
really
kind
of
driving
towards
this
is
start
getting
better
sigdoc
sort
of
representation
on
each
cig,
so
that
those
of
us
who
know
what
a
good
release
note
looks
like
can
help
both
identify
where
it
should
go
in
issues
or
in
the
PRS
and
help
folks
figure
out.
What
writing
it
better
would.
C
Look
like
Nick
also
got
some
good
ideas
for
tagging
stuff
so
that
we
organize
things
better.
The
same
thing
goes
for
the
docs
work,
so
it's
not
just
a
matter
of
saying,
okay,
you
know
things
need
to
be
responsible
for
release,
note
content
or
for
Docs,
but
sig
docs
will
also
help
them
get
there.
Now
we
can't
offer
a
representation
to
everybody
for
one
release.
We're
gonna
have
to
iterate
over
this,
but
we
really
want
to
try
to
do
it
and
hope
that
it
will
help
on
that
side
of
things.
C
Don't
know
I
died,
I'm
part
of
sig,
Docs
and
well
Jared
and
Zak
Courtney
said
are
really
the
leads
for
that.
But
I've
been
pretty
involved
for
a
while
now
and
I
brought
this
up
in
a
sig
Knox
meaning
of
a
few
weeks
ago
and
Jared's
you
know,
has
been
wanting
to
push
toward
this
for
awhile
I
think
with
both
of
us
driving
it
and
with
me
having
to
really
pieces
behind
me.
C
It's
no
promises
right,
there's
all
kinds
of
implementation
issues
here,
and
this
is
only
on
the
you
know-
writing
string
web
side
of
things,
but
I
think
you
see
the
points
here.
There
was
some
bleeding
around
docs
for
1.9
and
we're
pretty
good
at
sort
of
lessons
learned.
There
I'm
also
going
to
be
leaving
the
docs
effort
for
when
docked
in
moving
from
annex
notes
to
Doc's
I.
I
I
am
so
I
think,
there's
two
questions
or
I
think
you
did
a
really
nice
job
of
describing
all
of
the
things
that
folks
in
the
state
can
do
to
help
move
things
forward.
My
real
question
there.
The
reason
I
was
asking
the
sig
ownership
question
is:
does
the
doc
sig
or
does
any
sig
feel
sufficiently
empowered
to
say
whatever?
Is
this
feature
like
in
the
docs
case?
I
This
feature
the
docs
are
not
good
enough,
so
it
doesn't
get
in
to
the
release
and
I
feel
like
we
still
have
not
gotten
all
of
the
SIG's
to
the
point
where
they
were
willing
to
say
something
like
good
enough.
So
it's
not
gonna
make
it
in
the
release
and
the
release
can
go
ahead
and
whether
that's
you
know
test
case
is
or
Doc's
or
passing
tests
or
whatever
it
happens
to
be.
This
seems
to
me,
at
least,
to
be
the
kind
of
the
root
of
the
thing
that
right
that.
J
Would
be
only
when
we
have
feature
gates,
sorry,
feature
branches
for
larger,
larger
features
that
we
are
developing,
because
you
know
there
right
now.
It's
gonna
be
really
hard
to
pull
stuff
out
from
the
lis
is.
If
you
have
to
take
commits
away
and
revert
a
bunch
of
things,
then
it's
gonna,
you
know,
cause
a
whole
lot
of
chaos
towards
n,
but
towards
the
ownership
I
had
one
more
thought
is
the
other
other
foundations.
They
have
concepts
like
a
liaison.
J
It
doesn't
have
to
be
the
sig
lead
who
is
taking
part
in
all
the
release,
meetings
and
the
doc
meetings
they
can
delegate
one
person
from
the
sig,
for
you
know,
for
the
release
getting
into
the
release
team
meetings
and
one
person
into
the
docs
meeting
in
that
person
will
be
the
coordinator
for
that
effort.
So
that
is
the
concept
which
which
probably
can
drop
I,
think
I.
G
H
F
No,
that
was
all
okay,
no
I
feel
like
I,
don't
know
those
who
attend
say
p.m.
can
speak
better
to
it
than
I
can.
But
I
thought
there
was
at
one
point,
an
effort
to
have
a
P
M
representative
from
each
sig,
instead
of
a
Doc's
representative
for
me
to
sing
to
make
these
sort
of
horizontal
or
I'll
say
collaboration
efforts
easier
to
do,
I'm,
not
sure
how
well
that's
paid
off
or
what
practice
so.
A
Sorry
I've
been
I've
been
trying
to
beat
this
drum
for
a
while
that
we
actually
need
to
turn
the
model
around
and
empower
SIG's
through
facilitation.
Another
like
the
liaison
model,
because
you
know
you
think
about
what
works
well
in
dev
teens.
You
know
you
don't
ask
a
dev
team
like
hey
pick
a
scrum
master,
that's
one
of
your
developers
and
have
them
you
know:
they're
gonna
go
attend
scrum
of
scrums
and
they're
gonna
attend
project
meetings
that,
like
they're
a
developer
they're,
not
a
scrum
master.
A
That
did
just
simply
don't
make
sense.
So
I
think
the
the
docs
having
a
Doc's
person,
who
is
the
go-to
to
help
the
sig
sig,
do
the
best
work
and
having
a
p.m.
representative
that
goes
into
the
stakes
to
help
them
do
their
best
work
and
so
on
and
I
think
this
model,
I
think
is
gonna,
be
the
winning
model.
And
it's
it's
just
a
matter
of
how
we,
how
we
roll
it
out,
because
I've
been
trying
to
do
that
and
it's
it's
Jason.
J
At
this
point,
we're
talking
up
Jason
at
this
point.
We
are
talking
about
the
docs
that
are,
for
that
sake,
we're
not
talking
about
Doc's
for
the
rest
of
the
Kuban,
a
test
right.
Are
we
talking
about
the
CI
jobs?
For
the
sake
we
are
talking
about
the
features
for
that
sake,
you're
not
talking
about
things.
A
But
what
we,
what
we're
trying
to
do
is
I
mean
again.
This
is
what
we're
trying
to
do
is
provide
a
coaching
as
a
service
or
Docs
as
a
service
or
program
management
or
project
management
as
a
service
and
provide
that
to
six
I
mean
essentially
we're
trying
to
enable
SIG's
to
focus
on
their
core
concerns.
So
if
sig
note
is
writing
on
documentation
and
the
person
who
did
the
features,
maybe
not
super
comfortable
writing
Docs,
then
they
could
go
to
sig,
Docs
and
say
help
we
need
some.
J
A
J
To
offer,
but
then
there
is
only
a
bunch
of
us
who
are
doing
that
across
different
things
right
and
we
are
not.
Basically
that
model
is
not
working.
You
know
how
how
how
many
people
will
add
and
go
knock
on
to
get
their
CA
jobs
back
up
and
running,
or
you
know,
Josh
being
four.
You
know
they're
PRS
and
issues
and
labeling,
and
things
like
that.
So.
G
A
It's
more
than
that
it's
this
is
actually
a
systemic
problem
across
the
entire
project.
In
about
ten
different
lenses,
architectural
documentation,
program
management,
project
management.
What
is
your?
What
is
your
planning
process?
How
do
you
actually
detangle
dependencies
with
other
SIG's
I
mean
there's.
This
is
stuff
that
that
big,
big
it
shops.
You
know,
like
you
talking
like
the
development
teams
at
Ford,
or
you
know,
like
massive
skill,
agile
development.
A
These
are
these
are
patterns
that
have
been
solved
in
other
cases,
and
the
way
that
that
has
traditionally
been
done
is
to
not
try
and
pull
subject
matter,
experts
out
of
teams
and
make
them
do
things
that
they're
not
good
at
it's
really
to
try
and
empower
through
facilitation.
So
so
I
think
there's
a
model
here
that
we
can
leverage
and
find,
but
Tim's
concern
about
those
people
are
gonna.
Be
stretched.
Really
thin
is
something
that
we
need
to
find
a
way
to
address
a
hundred
percent,
and
so
we're
gonna
find
a
balance.
A
J
G
G
And
then
what
is
the
expectation
of
somebody
in
those
gaps
because
I'm,
not
even
sure
of
where
the
gaps
are,
how
they
affect
this
exam,
a
part
of
or
not
how
they
relate
to
I'm,
not
even
sure
how
that
is
because
it's
not
laid
out
like
we
talked
about
in
abstract
terms,
we're
talking
about
the
gaps
and
but
if
we
don't
know
the
gaps
are
that?
How
do
we
say?
Oh,
we
need
people
over
here.
G
Let's
go
mentor
somebody
or
find
people
interested
in
and
help
them
level
up
right
so
that
they
can
do
that,
find
somebody
who's
interested
in
this
stuff
and
get
them
engaged
in
it,
help
them
feel
comfortable
shifting
in
and
getting
the
support
they
need
until
they're
comfortable.
Then
how
can
we
even
do
that?
G
A
I
put
a
to-do
in
the
action
items
we're
gonna
have
to
move
on,
because
we're
gonna
run
out
of
time
to
identify
role,
gaps
document
and
find
liaisons
to
fill
those,
and
hopefully,
in
that
process
we
will
sort
out
some
of
these
concerns
for
sure
so
I'm
gonna
go
ahead,
move
on
in
the
sake
of
time
and
I'm
feeling
in
my
bones.
Having
done
many
of
these
rituals
before
that,
we're
probably
gonna
have
to
do
a
part
two
at
some
point,
which
is
always
less
attended.
A
So
let's
try
and
make
it
as
far
as
we
can.
This
time,
Lucas
had
a
point
here
about
not
seeing
the
value
in
both
the
code
slush
and
a
code
freeze
and
some
of
the
labeling
requirements
and
wondering
if
we
could
simply
simplify
that,
while
still
keeping
the
value
I
would
love
to
have
anything
you
just
weigh
on
in
the
sperm
and
if
that's,
okay,
Anthony,
if
I
could
put
you
on
the
spot,
because
I
know
you
have
feelings
about
this.
E
Yeah,
so
there's
two
things
here.
One
is
why
we
had
code
slash
in
addition
to
code
freeze,
I'm
gonna
get
the
second
one
first,
which
is
the
automation,
was
kind
of
overbearing,
and
that
was
just
a
trade-off
that
we
had
this
automation
written
already,
that
we
were
trialing
in
issues,
my
a
smarter
to
turn
it
on
for
PRS,
and
that
was
just
because
of
my
judgment
was
having
someone
he
shouldn't
be.
E
No,
it
was
overbearing
was
better
than
zero
automation,
which
was
making
it
a
lot
harder
for
the
release
team
in
the
past
to
see
and
have
visibility
into.
What's
going
in,
wasn't,
what's
not
getting
it
so
cuz
I
mean
send.
It
was
my
design
that
it
was
annoying
to
hit
yourself
in
because
we
wanted
to
I
wanted
to
intentionally
keep
that
barrier.
So
you're
only
get
anything
if
you
really
how
understanding
of
what
you're
doing
and
why
and
then
the
first
part
was
like
codes.
E
E
The
emergence
and
makes
them
submit
to
you
now
is
is
a
batch
of
a
hundred
things
that
just
made
the
cut,
and
so
what
I
wanted
to
do
was
the
making
that
process
either,
because
we
knew
it
would
be
right
up
against
the
holiday
and
so
I
insisted
code.
/
2
days
before,
which
was
saying
you
guys
are
working
on
things
that
important
for
the
going
into
the
race.
E
You
can
keep
working
everything
else
that
could
wait,
we're
going
to
force
you
to
wait
two
days
early
and
what
I
did
was
I
think
it
was
pretty
successful
that
the
submit
queue
was
free,
Muffit
empty
by
the
time
we
enacted
that,
and
then
only
things
that
would
have
made
freeze
were
in
the
queue
at
that
point
and
and
we
were
able
to
keep
that
you
from
getting
too
comments
on.
You
know
whether
that
was
better
or
worse
than
yesterday,
I'm
happy
to
discuss.
B
E
H
F
F
E
Co-Mingle
there
sometimes
they
happened
on
the
same
moment,
even
though
there
one
of
them
is
about
feature.
F
E
H
My
understanding
I'm
not
sure,
if
my
understanding
is
that
it's
just
a
matter
of
you
know
you
hit
code,
slash,
and
that
means
okay,
everything
that
has
been
approved,
I
can
still
merge,
modula-3
bases
and
the
like,
and
once
you
have
like
kind
of
cleared
the
backlog,
then
you
kind
of
enter
this.
The
freeze
portion,
where
you're
really
just
fixing
problems
that
blocking
release
you're
not
doing
any
work.
E
H
F
G
Can
can
I
make
up
maybe
a
suggestion
that
might
help
this
I
noticed
that
well,
first
of
all,
coming
from
a
lot
of
other
projects,
only
a
few
of
the
open
source
projects
that
I've
been
on
have
the
notion
of
code
slush
and
code
freeze.
So
a
lot
of
people
coming
in
may
not
have
noticed
or
not
pay
attention
and
may
not
be
used
to
it.
G
But
then,
when
I
go
to
look
at
like
our
documentation
like
on
the
community
site
and
I
search
for
code,
slush
I,
don't
find
it
or
in
kubernetes
cabernet
I'm,
not
finding
it.
So
the
difference
is
between
what
is
this
and
what
does
it
mean
in
I?
Don't
seem
to
see
it
documented
anymore,
so
people
who
aren't
familiar
with
it
or
familiar
with
it
in
our
context
or
it
just
hasn't
hit
him
in
the
face,
even
if
they
happen
to
occur
by
Nettie's,
might
not
know.
H
F
A
We
can't
we
can't
let
this
be
tribal
knowledge,
it
has
to
be
a
discoverable
and
it
has
to
be
right
out
in
front
of
community
that
includes
giving
a
demo
at
the
community
meeting
writing
to
the
death
list
doing
all
the
radiation.
We
need
to
do
around
this,
because
this
can't
this
is
this
is
too
critical
for
our
success.
To
not
have
it
be
very
clear
and
cut
and
dried
so
I'm.
F
Gonna,
pull
over
all
that
to
one
of
my
things
just
real
quickly.
What
you're
describing
sounds
like
the
job
of
cig
release,
a
special
interest
group
dedicated
to
the
release
process,
and
so
I
would
view
that
as
something
a
sick
should
do
not
you
as
a
single
human
being
who's
actively
interested
in
this.
F
Although
I
really
appreciate
the
effort-
and
my
concern
was-
although
I
really
liked
me
as
a
as
the
release
team
for
one
lying
meeting
weekly
well
ahead
of
burden
having
all
that
stuff
to
establish
a
cadence
and
gel
the
team
together,
it
also
meant
that
we
didn't
meet
as
sake
release.
I,
don't
know
whose
sake
release
is
apart
from
the
people
who
are
tactically
involved
in
getting
a
release
out
the
door.
F
My
impression
was,
the
sink
was
created
so
that
people
such
as
yourself
who
are
interested
in
de
tribal
izing
the
release
process
and
actually
documenting
it
once
and
for
all
and
making
it
reusable
could
do
that
without
being
down
in
the
weeds
and
involved
in
the
nitty-gritty
of
tactically
getting
a
lease
out
the
door.
But
in
practice
it
seems
as
though
we
all
just
focus
on
the
tactical
stuff
and
there's
nobody
left
behind
still
focusing
on
these
larger
big-picture
initiatives
to
improve
the
process
throughout.
F
It
concerns
me
I,
don't
know
where
we
magically
find
the
staff
of
people
who
have
the
knowledge
of
the
release
process
who
shouldn't
be
occupied
in
helping
it.
The
release
out
the
door
instead
be
focused
on
this
stuff
up
here.
So,
in
fact,
if
that
set
of
people
is
one
and
it's
Jase
right
now,
that's
I
mean
that's
the
state
of
today.
I
personally,
would
also
like
to
help
improve
this.
That's
why
I
documented
my
role
as
I
went
and
still
trying
to
work
on
tools
to
replace
my
role
with
a
small,
tiny
shell
script?
F
B
F
E
F
It's
just
the
same
problem.
We've
always
had
I'm,
not
sure
how
weird
how
we're
improved,
like
I
I'm,
trying
to
document
my
way
out
of
that
problem
and
I
kind
of
burnt
myself
out
through
about
three
different
releases
now
so
I
am
explosively.
Stepping
back
from
the
110
released
I
hope
to
helpfully
hopefully
improve
that
situation,
but
I'm
trying
to
figure
out
a
brainstorm
like
how
can
the
solution
to
this
not
be
heroes.
G
F
So
hopefully
the
next
person
can
can
pick
up
from
there,
but
it
also
creates
this
big
scary
impression
that
if
you
want
to
be
part
of
the
lease
you're
gonna
have
to
dedicate
a
significant
chunk
of
time,
not
just
for
the
release
that
you
were
part
of,
but
in
training
up
for
the
release,
like
I'm
hopeful
and
optimistic
that
maybe
chase
and
I
and
other
people
buckling
down
and
really
documenting.
This
whole
process
makes
it
more
consumable
and
reusable
by
those
who
have
the
subject
matter.
F
Expertise-
and
maybe
this
truly
is
just
we
have
to
get
over,
but
I
feel
like
I
fooled
myself
too
many
times
in
the
past
that
it's
just
this
hump
to
get
over
and
if
I
be
a
hero
and
put
in
the
effort,
then
things
will
be
better
and
it
usually
hasn't
worked
out
that
way
in
the
past.
So,
like
absolutely
your
point:
how
how
do
we
make
sure
that
those
Doc's
are
actually
consumable
and
not
just
a
wall
of
text
that
scares
people
away
I?
Would
how
do
they
be?
H
H
I
H
J
Maru,
that
was
about
two
years
ago
and
that
person
theory
is
still
around,
but
he's
not
he's
just
wearing
AI
is
employed
by
the
foundation,
but
you
know
the
other.
People
are
doing
the
actual
work,
especially
for
the
last
two
years.
There's
been
at
least
two
three
people
who
have
taken
over
from
theory
and
running
the
show
and
not
automating
everything,
so
yeah,
that's
kind.
So.
B
Really
one
thing:
I'll
say
it
my
experience
and
what
projects
indicates
that
people
who
actually
doing
doing
release
management
are
going
to
always
be
fewer
than
the
number
of
release.
Man,
people
we
need
on
release
dates,
and
so
we
need
to
recruit
people
to
the
release
team
based
on
other
criteria
than
just
you
want
to
do
it
one
way
and
I've
already
done.
A
That's
a
really
good
idea,
I'm
writing
that
down-
and
we
are
two
minutes
left
in
this
released
retrospective,
and
we
are
now
on
50%
through
these
things,
so
with
the
holiday
I'm,
not
really
sure
when
it's
gonna
happen,
but
we're
gonna
have
a
part
two
and
stay
tuned
on
scheduling,
for
that
I
will
try
and
get
the
word
out
on
when
and
how
we
do
that
just
to
to
put
a
bookmark
here
in
this
talk,
I
want
to
thank
everybody
for
extremely
positive
conversation
on
this
and
I
am
so
thankful
that
our
community
is
engaged
around
this
problems,
because
that's
precisely
how
we're
going
to
evade
some
of
the
anti
patterns
and
rocks
that
other
projects
have
steered
into
so
again,
thank
you
for
your
time.