►
From YouTube: Kubernetes 1.8 Release Retrospective Part 2 20171006
Description
We have PUBLIC and RECORDED weekly video meetings every Thursday at 10am US Pacific Time.
https://docs.google.com/document/d/1VQDIAB0OqiSjIHI8AWMvSdceWhnz56jNpZrLs6o7NJY
A
All
right,
hi
everybody
thanks
for
joining
us
today
and
the
second
installment
of
the
one
point:
aid
community
release
retrospective.
My
name
is
Paris
I
work
at
Google
I'm,
going
to
be
going
through
the
retrospective
guide.
Today,
if
you'd
like
to
follow
along
yesterday,
we
went
through
the
follow
up
from
the
last
retro,
which
was
one
point
seven.
We
also
did
half
of
the
went
well
in
1.8,
so
that's
exactly
where
no
I'm,
sorry
what
caught
we
actually
went
through.
What
could
have
gone
better
in
1.8
about
halfway
through
that?
A
C
A
A
C
So
this
was
a
kind
of
immediately
on
release.
We
ran
into
reports
of
upgrade
scenarios
and
restart
scenarios
and
just
sort
of
their
scenarios
outside
the
the
1
e
2
e
test
that
we
had
that
kind
of
required,
some
scrambling
and
some
quick
action
and
we're
still
kind
of
working
through
some
of
those
items
and
in
some
cases
the
fixes
were
doc
fixes.
C
A
C
D
A
E
A
D
So
documentation
of
rolls
is
just
really
not
good,
like
there's
absolutely
nothing
for
the
lead,
so
it's
pretty
much
whenever
I
can
come
up
with
soon
to
do.
For
that
and
thankfully
the
branch
manager
I
think
Ashley
has
really
good
documentation.
Although
I
wish
Adam
was
on
the
call,
so
he
could
speak
to
that
and
yeah.
So
we're
gonna
try
and
continue
that,
but
it
definitely
needs
a
lot
of
work.
So
that
might
be
something
if
we
want
to
put
that
as
it
to
do.
D
I
don't
know
who
can
actually
volunteer
for
that,
but
that
would
be
definitely
something
to
put
in
there
and
the
forever
read
tests
is.
Oh,
my
gosh
I
wish
Aaron
was
on
the
call,
so
these
are
tests
that
that
are
sort
of
flaky
from
the
get
and
don't
don't
ever
get
better,
yet
they're
considered
important
and
sometimes
they
wind
up
in
blocking
status.
Even
so,
we
just
need
a
policy
on
that
figure
out
what
to
do
about
that.
D
A
A
A
D
So
please,
so
this
submit
queue
status
is
better
and
actually
this
might
not
even
be
as
appropriate
with
the
new
test
grid.
Dashboard
for
this,
so
I
I'd
say
that
the
maybe
this
is
already
either
or
better
slash
fix.
This
came
from
a
long
time
ago
before
that
was
really
in
place,
so
I've
great
testing
schedule
planning.
So
this
was
the
thing
the
the
schedule
plan
that
we
have
in
place
and
actually
there's
full
requests
out
there
right
now
for
the
1/9
schedule.
D
Is
you
actually
need
to
to
think
about
the
implications
of
these
upgrade
tests
and
how
the
fact
that
the
people
are
supposed
to
be
working
on
these
in
some
cases,
can't
in
other
cases,
requires
a
lot
of
input
from
sakes
that
may
be
busy
doing
feature
work
or
their
work.
So
basically
it's
an
unfunded
mandate
and
that's
that's
a
big
problem
for
the
release
process.
This
is
time
after
time
is
the
thing
that
causes
the
most
agony.
D
D
So
this
is
opinion.
Basically,
we
need
to
solidify
the
p.m.
sake,
release
alignment
as
soon
as
possible,
so
that's
essentially
for
1.9.
We
need
to.
We
need
to
get
on
the
same
page
about
this,
because
we're
gonna
run
into
the
same
problem
again
and
it
was.
It
was
very
uncomfortable
having
this
sort
of
false
start
with
the
press
about
what
are
we?
What
are
we
delivering
and
I
felt
like?
Maybe
we
didn't
give
the
best
impression
like
it's
like
you
guys,
know
you're
doing
it's
like.
Yes,
we
do.
We
know
we're
doing
it's.
D
So
we
just
cut
them
anyway,
which
is
what
everybody
else
has
done
for
every
release
thus
far,
and
we
just
need
to
figure
out
is:
are
we
gonna
do
them
or
we
can
not
do
them?
Does
Kubb
ADM
still
need
those
tests
against
etc?
I
would
love
to
have
sequester
lifecycle
weigh
in
on
the
value
and
importance
of
those
from
a
release
perspective.
If
those
do
give
us
a
valuable
insight
in
terms
of
the
Antigo
infrastructure,
and
can
we
cut
the
branch?
D
D
B
B
First
of
all,
with
the
release,
notes
and
release
seems
so.
Luckily,
our
general
rules
process
have
moved
to
much
better
shape
than
we
had
a
year
ago,
for
example,
when
we
have
established
this
concept
of
death
release
our
early
streams,
so
it
would
be
great
if
you
move
forward
who's
dead
and
like
to
some
enhancement
of
that
she
will
have
a
discussed
used
in
the
end
it
actually
Jessie.
Oh
yes
speaking
about
rates
right
now
and
speaking
about
early
+,
6
p.m.
alignments.
B
That's
also
I,
don't
want
to
say
that
we
had
some
problems
with
this,
so
I
would
oppose
here.
So
we
we
were
good
with
our
like
blog
post,
without
messaging
to
we,
with
the
press
releases
to
some
articles,
newspapers
and
so
on,
but
it
wasn't.
It
was
only
the
issue
of
the
right
messaging
that
we
have
so
we
we
simply
have
to
start
working
on
that
since
the
day
first,
but
not
the
end
of
your
listen.
B
B
B
G
A
D
H
Not
entirely
sure
it's
just
like
individual
SIG's
responsibility,
it's
kind
of
a
tragedy,
his
problem
and
I
would
say
that
maybe
sig
testing
should
be
at
least
leading
the
effort
in
making
sure
that
the
infrastructure
is
in
place
because
all
the
common
stuff,
the
people
who
depend
on
I,
mean
anyone's
saying:
that's
they're
not
going
to
do
that.
They
don't
have
the
resources
and
time
and
mandate,
but
nobody
does
right
now,
but
I
I,
really
I'm
gonna
bring
that
up
at
the
next
think
testing
meeting.
Hopefully
we
can
try
to
address
that
so.
D
Yeah,
so
this
I
took
a
shot
at
writing
this
up,
and
it
was
something
that
he
or
and
I
had
kind
of
worked
on,
because
people
were
wondering
what
is
the
stabilization
release?
What
is
a
feature,
release
and
and
I
wrote
it
up
a
lot.
There
was
a
lot
of
commentary
and
there's
a
link
there,
but
basically
I,
don't
think
we
ever
reached
consensus
and
it
was
sort
of
like
well
I
guess.
The
steering
committee
needs
to
weigh
in
on
this,
because
is
this
really?
D
D
To
say
that
you
know
what
we
need
is
a
really
good,
stable
nucleus
and
basically
try
and
enrich
the
ecosystem
so
that
all
this
great
stuff
that's
happening
can
be
independent
of
the
movements
and
machinations
with
the
core
api's.
So
I
mean
III.
Think
that
in
retrospect,
I
almost
want
to
just
delete
that
document
and
say
you
know
that
may
have
been
something
when
you
need
to
worry
about
two
releases
ago,
but
I'm
not
sure
that
it
still
applies.
H
Heard
an
opinion
it's
kind
of
uninformed,
but
from
my
sort
of
ignorant
sort
of
perspective
on
stabilization
versus
feature
a
lot
of
times.
There
just
isn't
clear
objectives.
It's
like
this
is
a
stabilization
release.
We're
not
gonna,
do
new
features
but
then
like
what's
like
as
a
project
and
even
just
on
the
individual
sig
level.
What
are
they
actual
stable
stability
problems?
What
are
the
problems
that
are?
You
know
preventing
people
from
you
know
using
humor
Nettie's
in
production
without
operational
overhead?
H
That's
unreasonable
or
you
know,
buggery
it's
rotaries
or
whatever,
and
it
seems
it's
just
I,
just
kind
of
uncoordinated.
It's
not
like
I'm
gonna.
The
objective
is
this
and
we're
gonna
achieve
it.
It's
just
like
its
amorphous
we're
going
to
do
stabilization,
which
means
we're
just
gonna,
do
less
features
and
we're
gonna
focus
on
non
feature.
Work,
but
I,
don't
know
that
that
necessarily
achieves
any
field
goal.
H
B
I
could
comment
and
it
so
how
what
would
have
been
done
before
was
the
first
relay
system.
For
example,
given
at
this
hundred
six
in
decorative
one
was
the
first
like
officially
a
stabilization
release,
so
we
asked
all
the
six
to
refocus
their
scope
for
the
next
iteration
for
the
next
release,
from
working
under
near
features
and
on
the
near
functionality,
but
working
their
existing
features
and
to
enhance
the
existing
functionality.
B
As
you
know,
we
have
two
three
stages
or
features
it
has
alpha
stable
and
betas,
and
we've
asked
for
one
of
the
six
to
force
people
more
on
moving
alpha
features
to
betas
and
betas
to
stable
and
not
working
on
office.
For
this.
For
this
so
officer
excellent,
something
years,
I
was
an
experimental
encircle.
It
was
our
definition
of
destabilization.
Release.
B
I
can
agree
that
it's
totally
synthetic
and
it
can
be
outdated
at
the
moment,
because
I
have
we're
moving
towards
separation
or
new
clothes
from
everything
else,
and
now
the
most
of
the
future
work
is
being
done,
not
not
in
the
core
of
Cuban
artists,
but
in
some
external
components.
So
we
have
to
also
work
this
dis
concept,
I'm,
not
sure
that
we
have
to
completely
move
away
from
stabilization
versus
feature
around
it
releases,
but
we
have
to
enhance
this.
This
definitions.
H
Yeah
my
suggestion
wasn't
to
like
we
don't
want
to
focus
on
stabilization,
mm-hmm
I,
think
it's
more
that
it
would
be
preferable
to
have
like
more
visible
or
more
accessible
metrics
on
like
what
stabilization
means.
So
we
can
actually
move
towards
that
versus
I'm
working
on
a
feature
that
is
stable
or
moving
towards
its
stable.
Well
to
me,
that's
a
little
bit
nebulous!
That's
all
yeah.
B
I
agree:
I
drink.
Also,
remember:
we've
been
working
on
feature
entity
releases,
but
when
declarant
did
this
release
is
not
so
focused
on
stabilization
as
the
purest
one.
We
had
the
situation
with
1.7
before
so
some
people
from
community
and
some
people
from
external
resources,
like
from
from
some
use
websites
very
considering
that
we
are
working.
So
this
release
of
cabinets
won't
be
stable
at
all,
and
that's
also
the
simple
of
the
bed
messaging
and
we
have
to
also
like
you're
fine
I,
we're
working
from
for
the
few.
I
Sort
of
amorphous
in
terms
I
mean
I'm,
also
kind
of
coming
at
this
from
not
having
been
here
very
long.
But
it
seems
to
me
that
if,
if
we
sort
of
had
a
a
goal
ahead
of
time
that
it
would
be
a
you
know,
the
the
whole
the
least
themes
issue
would
be
easier
to
deal
with,
but
not
to
make
it
kind
of
artificial.
But
more
like
the
community
might
be
more
coordinated
in
what
everybody's
trying
to
achieve.
Instead
of
just
sort
of
everybody
going
around
and
doing
whatever
they
think
is
most.
I
D
D
It
feels
like
a
missed
opportunity
because
we're
not
really
out
there
pounding
the
pavement
talking
to
cluster
operators
to
figure
out
what's
new
and
I
know
because
I'm,
the
co-lead
of
cig
cluster
ops,
that
that
that
sig
is
dying
on
the
vine
because
we're
not
getting
enough
user
input
into
the
project.
So
I
feel
like
a
huge
opportunity
for
us
here
is
to
enhance
our
our
product
chops
and
say:
how
do
we
get
a
like
a
Net,
Promoter
Score
for
communities?
How
do
we
understand
what
our
user
base
actually
needs?
D
How
do
we,
how
do
we
synthesize
all
that
information,
bring
it
in
as
a
product
voice
and
get
it
into
the
6-2
work
and,
and
that
to
me
is
I
think
the
next
frontier
of
where
we
need
to
go,
and
it
really
aligns
with
what
you
just
said:
it's
like
what
what
are
those
things
that
we're
missing?
We
were
if
we're
in
an
echo
chamber,
we're
missing
those
things
we
got.
I've
got
to
widen
the
net
and
get
more
voice
and
find
out
what
those
real-world
problems
are
I'm.
J
A
A
All
right
now,
next
topic,
I,
don't
think
I
saw
Nikhil
on
the
line.
Nikhil
last
call
all
right:
I'll
go
ahead
and
read
the
cables
so
Nikhil
mentioned
that
verify
that
features
have
expected
tests
before
code
freeze,
especially
bata
features.
We
realize
later
that
some
features
were
missing
tests,
but
it
was
too
late
by
then
a
week
before
release
to
turn
them
off
probable
solution
go
through
all
features
a
day
after
the
code.
Freeze,
internal
features
which
weren't
able
to
get
any
tests
merge
any
comments
on
that.
A
J
A
F
K
These
are
the
three
things
that
I
think
would
really
help
for
documentation
in
1.9.
First
is
that
we
have
a
single
source
of
truth,
about
which
features
will
need
Docs
and
I
think
this
is
the
same
as
saying
we
need
a
single
source
of
truth
for
what
the
features
are,
because,
as
I
remember,
we
had
a
spreadsheet
that
listed
features,
but
all
the
features
weren't
in
that
spreadsheet.
K
Until
later
in
the
game
and
I
think
I
heard
people
saying
we
need
to
get
a
single
place
where
we
know
what
features
are
and
so
along
the
same
lines.
You
know
whatever
that
place
is
that
can
be
this
single
source
of
truth,
about
which
features
need
Docs
and
early
in
the
game
I'd
like
to
have
them
all
marked
as
either
Docs,
yes
or
Docs.
No,
so
we
have
a
clear
picture
up
front
about
which
things
will
need
documentation.
K
The
next
is
that
I
didn't
feel
like
I
knew
how
to
communicate
what
the
deadlines
were
and
what
we
needed.
I
have
these
these
Google
Groups
that
I've
listed,
but
if
anyone
can
help
me
know
what
other
forms
of
communication
I
should
use
to
communicate
the
fact
that
we
have
documentation
deadlines
coming
up
and
what
we
expect.
That
would
be
useful.
L
One
thing
that
Steve
I
think
having
individual
owners
for
each
of
these
features
is
incredibly
useful.
I
know
you
were
pinging
groups
like
Sid
groups
and
Google
groups
trying
to
get
people
to
respond
yeah,
it's
you
were
doing
the
same
thing
and
this
sort
of
like
this
Chase
is
just
so.
It's
such
a
time,
sync
for
all
of
us,
so
having
a
single
owner
of
each
feature
that
we
can
reach
out
to
and
get
informational,
and
even
if
they're,
just
doing
coordination
would
help
us
out
so
much.
K
D
B
Say
the
primary
place
where
you
can
ask
people
for
the
dogs
and
for
them
is
the
issue,
so
in
the
spreadsheet.
Every
feature
is
linked
to
the
future
issue
on
the
futures
repo.
So
there
should
be
the
primary
place
where
we
are
asking
people
about
something
if
they
don't
respond
to
us,
we're
moving
with
slack
email
grabbing
them
on
the
street
and
so
on.
What.
K
Thanks
yeah
that
we
could
do,
but
we
want
to
do
next
time-
is
auto-generate
the
ref
pages
much
earlier.
This
just
sort
of
slipped
slipped
to
my
mind
and
I
ended
up
asking
the
few
people
who
knew
how
to
do
this
to
do
it
at
the
last
minute.
So
I
would
like
more
of
us
to
know
how
to
do
it
and
to
do
it
earlier.
Okay,
that's
it
for
me,.
L
B
D
D
If
you,
if
you're
a
company
that
you
you
have
your
spreadsheets
through,
is
gone
like,
for
example,
although
the
retro
Doc's
I
had
four
one
three
one,
four
one,
five
so
forth,
where
on
the
dais
dais
drive
and
when
Dan
Scott
bought
by
Microsoft
that
stuff
all
got
retired
and
I
had
to
convert
it
to
PDFs
and
do
inch
of
stuff.
So,
whereas
github
is
an
enduring
source
of
truth,
so
we
got
to
figure
out
how
to
work
best
with
with
github
and
in
Caleb
Caleb
is.
D
B
Yeah,
that's
that's
an
issue
because
we
are
trying
to
solve
two
questions
from
one
hand.
We
are
trying
to
solve
the
question
of
visualization
and
is
a
consuming
of
of
some
information,
and
here
Google,
Docs,
Google,
Spreadsheets
and
other
sources
may
help
us,
but
the
actual
datastore
from
github
right.
So
the
actual
features
data
to
be
as
a
ways,
early
snow
link
to
a
specific
feature.
B
Together
with
all
information
about
the
feature,
you
start
on,
get
it
up
on
the
features
paper,
but
for
there
is
a
visualization,
we
are
moving
that
information
up
moving,
but
gotten
that
information
today
or
to
the
spreadsheet,
and
we
are
using
that
spreadsheet
as
a
primary
source
of
easy,
visualization
and
easier
consuming
of
the
data.
Unfortunately,
this
process
is
still
not
automated.
It's
to
cross,
like
modern
media,
to
find
a
proper
solution
and
we
still
haven't
found
one.
So
as
this
process
is
completely
male,
sometimes
some
data
can
be
inconsistent
out
of
sync.
B
F
H
D
A
D
Right
these
are
all
just
blatant
opinions,
obviously,
but
I
think
we
should
just
buy
by
policy,
make
the
code
freeze
longer
so
I
think
having
it
the
link
that
it
was
worked
out
really
well
and
I.
Don't
think
there
was
any
downside
that
may
not
necessarily
be
true
when
things
are
really
bumping,
but
for
right
now,
I
I
think
that
we
should
just
plan
on
things
going
not
well
and
and
if
it
goes
great,
then
we
can
let
up
early.
But
let's
not,
let's
not
be
aspirational
on
trying
to
make
it
short.
D
That's
because
there's
a
lot
that
happens
there
I
felt
bad
for
all
the
people
standing
up
test
and
Brett
and
Adam
put
a
put
a
very
interesting
little
thing
there,
which
is
should
freeze,
be
enforced
instead
of
being
on
the
honor
system
and
I
I
say
absolutely.
It
should
be
enforced.
The
the
fact
that
people
can
just
add
add
the
milestone
to
things
was
a
consistent
problem
and
required
a
lot
of
oversight
by
the
release
team.
That
was
was
hard
and
I'd
love
to
see
return.
H
We
will
about
four
one
nine,
so
there
was
a
manager
update
that
was
released
yesterday
that
enforces
sig
approval
for
any
issue
in
the
milestone,
as
the
next
step
is
going
to
be,
requiring
once
we're
in
slush
or
freeze
that
you
don't
merge
things
that
don't
have
associated
issues
that
have
sig
approval.
So
we
will
have
that
yay.
H
Is
that
he
won't
even
put
the
label
on
and
currently
that
is
a
huge
list
of
people
that
are
in
the
cig,
maintainer
group
github
group.
We
can.
We
know
that
down
or
as
appropriate
and
maybe
even
limit
it
to
specific
SIG's.
Currently,
it's
just
a
huge
list,
so
anybody
who
is
on
that
approved
list
can
approve
issues
for
any
SIG's,
but.
D
Okay,
so
a
lying
product
architecture,
CN
CF,
release
team
from
day
one
day
one
has
already
come
and
gone
we're
not.
We
all
do
all
these
program
level,
things
all
the
program,
level,
people
and
sakes
and
stuff.
We
need
to
be
in
lockstep
around
the
release
and
we're
not
so
we
got
to
do
that
and
so
add
that
as
it
to
do
for
me
and
I'm
happy
to
continue
that
work
finalize
the
release
team
earlier,
hey
look
at
that.
D
D
We
work.
We
took
a
long
time
on
the
1.8
release
to
get
that
filled
up
and
it
was.
It
was
very
hard,
a
lot
of
stuff
flagged
as
result
I'm
document
the
release,
the
lead
role,
I'm
gonna,
do
that
try
and
lower
the
burden
of
individual
roles.
I
tried
to
do
that
as
much
as
I
could
like.
For
example,
the
docs
people
were
struggling
with
contacting
people
and
also
handling
the
job
of
the
docs,
so
I
jumped
in
to
try
and
do
the
all
the
the
summoning
of
people,
the
new
Doc's.
D
But
frankly
we
need
people
too.
We
need
more
hands
on
deck
to
help
with
some
of
these
individual
roles
when
they
get
really
really
tight,
because
Jennifer
and
Radek
aput,
in
literally
an
all-night
or
on
docks,
and
that
is
not
I-
don't
want
to
encourage
heroism
in
the
community.
We
heroism
is
not
to
our
benefit,
it's
great,
that
people
step
up
and
do
the
things,
but
we
can't
be
asking
people
to
sacrifice
in
that
way
for
the
community.
D
A
D
Joining
sig
release
is
good,
so
anybody
can
shadow
any
of
the
roles.
So
there's
a
secondary
role,
pretty
much
for
all
the
rules,
and
so
the
best
thing
you
can
do
is
just
to
be
a
secondary
and
so
that,
for
example,
you
know
Caleb
and
I
could
could
switch
off
because
we're
in
different
time
zones,
so
Caleb
would
oftentimes
do
things
after
hours
when
I
wasn't
able
to
or-
and
so
there's
there's
just
basically
a
trade-off
there.
So
joint
stick
release
get
yourself
on
that.
The
spreadsheet
is
a
secondary
and
go
from
there.
B
They're
speaking
about
the
formal
requirements,
I
suppose
that
the
primer
person
has
to
be
a
genetic
variation,
member
at
least
or
endure
here,
because
we
have
to
do
require
some.
You
have
tools
that,
like
it,
gives
our
instruments
and
hearing
permissions
you
can
only
have
as
now
as
a
cabinet
organization
member,
but
speaking
about
your
desire,
you
can
be
like
typical,
contributed,
given
Edison
simply
have
some.
D
Yeah
I
think
the
lead
role
is
slightly
different.
The
lead
role
is
is
requires
a
relatively
high
exposure
to
things.
So,
if
somebody's
interested
in
knowing
what
what
that's
about,
typically
by
policy,
we
we
ask
people
to
have
been
in
a
really
cycle
before
if
they,
if
they're
lead
in
some
capacity,
and
also
the
lead
from
experience,
I
will
tell
you
is-
is
like
managing
a
very
large
project
with
lots
and
lots
of
moving
pieces.
So
it
requires
extremely
sharp
project
management
skills.
So
that's
that's
definitely
what
I
would
say
is
a
precursor
to
that.
A
D
H
Think
having
continuity
is
super
important,
I'm,
not
I,
mean
I
think
as
much
as
like
making
sure
that
we
just
don't
have
all
the
knowledge,
and
you
know
a
limited
set
of
people's
heads.
That's
part
of
it.
The
other
part,
though,
is
avoiding
burnout,
looks
like
I.
Well,
I
can
do
the
job.
Nobody
else
wants
to
do
the
job,
and
so
it
kind
of
enforces
turnover,
but
in
terms
of
maintaining
continuity,
the
whole
idea
behind
having
like
secondaries
was
to
have
both
shadows
was
to
try
to
have
some
continuity
by
allowing
people
to
work
together.
H
It
sort
of
gained
that
knowledge
on
the
job,
but
where
they're
not
totally
responsible
and
I
I,
think
that
pattern
I'm,
not
sure
it's
really
played
out
I
mean
I,
was
the
shadow
for
1/7,
with
the
intent
of
leading
4,
1
8
and
for
personal
reasons.
I
couldn't
do
that,
but
even
then
it
was
actually
hard.
I
mean
Don
certainly
tried
to
give
me
a
lot
of
responsibility,
but
it's
like
it
as
a
release
manager.
H
Today,
you
end
up
having
to
just
be
you're
the
locus
for
everything
and
it's
really
hard
for
anybody
else
to
step
in
and
be
that
I
don't
know
I
guess.
My
point
is
I
think
there
needs
to
be
a
better
culture
of
sharing
responsibility
and
sort
of
delegating,
and
as
far
as
I
can
tell
that's
just
really
it's
proven
difficult,
I'm
interested
in
you
know.
If
there's
ways
we
could
encourage
that
better.
D
Yeah
I
agree:
I
I
was
lucky
because
caleb
is
a
is
a
veteran
of
many
releases.
So
when
I,
when
I
needed
something
done,
I
basically
could
say
Caleb.
Can
you
can
you
mind
the
fort
while
I'm
gone
and
he
just
stepped
up
and
did
it
so?
But
but
that's
rare
I
mean
and
right
now
is
real
I
mean
I'll.
Tell
you
after
the
release.
I
literally
had
two
days
where
I
could
basically
do
nothing.
D
M
D
I
think
sig,
release
as
a
whole
is
helping
that,
but
I
do
believe
that
we
have
this
core
of
people
that
is
sort
of
deep
in
the
trenches
and
and
it's
it's
hard
to.
We
want
to
have
more
people
with
us,
but
it's
it's
hard
and
it
takes
multiple
releases
to
do
that.
Like,
for
example,
Jennifer
wasn't
even
really
gonna
be
a
primary
in
this,
and
she
went
up
getting
drafted
into
a
tremendous
amount
of
work
and
now
she's
like
I,
want
to
do
the
next
one
because
of
everything.
I
learned
the
last
time.
D
It's
like
I
understand,
I
mean
if
I
was
the
lead
for
window.
I
would
like
I
would
do
so
many
things
differently,
because
I
waste
a
lot
of
time,
creating
spreadsheets
and
dragging
this
and
hey.
Let's
do
a
Kanban.
It's
like
none
of
that
really
mattered
the
stuff.
That
really
matter
was
a
bunch
of
stuff,
I,
wouldn't
think
the
matter.
So
now
it's
you
know
it's
hard
to
it's
hard
to
know
what
to
do
and
how
to
how
to
get
sig
release
more
filled
out.
D
H
Honestly,
not
sure
sig
releases
mandates
should
be
my
continuity,
so
much
as
enabling
like
making
it
easier
to
I
mean
cuz
I.
Think
of
like
the
release
team
a
lot
of
its
relationships,
it's
knowing
people,
it's
communicating
with
people
sig
release,
can't
really
help
with
that.
It's
it's
just
an
interpersonal
thing
where
I
think
sig
release
can
make
an
impact,
is
in
formalizing
process
or
implementing
automation,
to
allow
the
release
team
to
focus
more
on
the
interpersonal
stuff
more
on
the
facilitation
stuff
and
less
on
the
like
a
manual
yeah.
D
H
Mean
that's
part
of
it,
but
I
mean
I
think
we
could
go
a
lot
further
and,
like
some
of
it
is
like
maybe
say,
release
should
be
responsible,
for
you
know
making
sure
that
we
have
like
leadership
around
upgrade
testing
or
other
kinds
of
testing
like
there's
all
kinds
of
things
that
are
like
long-term
coordination
that
don't
necessarily
like.
We
definitely
don't
want
to
do
it
at
the
end
of
the
release.
We
wanted
to
be
an
ongoing
thing.
This
is
constantly
maintained
and
you
know
someone's
always
on
top
of
it
and
the
challenge
with
releases.
H
H
Maybe
I
mean
yeah,
maybe
just
big
stuff
around,
like
getting
a
quality
release
out
I
mean
it's
just
the
tragedy
of
the
common
stuff,
the
stuff
that
nobody
else
cares
about,
so
the
release
teens
that
ends
up
doing
and
they're
so
busy
doing
other
things
that
they
can't
possibly
do
a
lot
of
these
toys.
Justice
all.
A
D
We
I
would
love
to
see
SIG's
start
from
the
very
beginning
of
every
release,
adding
to
their
release
notes
what
they
intend
to
accomplish.
What
is
the
committed
work
for
the
release
cycle
and
then,
if
they
don't
make
those,
then
somebody
is
on
point
to
go
in
you
know
at
the
end
of
when
code
freeze
happens,
pull
them
out
and
not
have
this
fire
drill
at
the
end
of
the
release.
D
If,
if
SIG's
don't
know
what
they're
committing
to
until
way
late
in
the
release,
that's
a
problem-
and
that
indicates
a
lack
of
planning
and
and
other
things
around
the
management
of
those
things
they
could
indicate
other
problems
like
missing
tests
or
maybe
not
the
maturity
of
of
code
exposure
and
smoke
tests
and
all
that
so
I
want
to
see
these
things
in
the
release.
Notes
like
right
out
of
the
gate,
I
think
there's
no
reason
why
we
couldn't
have
a
solid
release.
Notes
draft
literally
the
first
or
second
week
of
release
just.
H
M
A
D
A
D
B
Yeah
drug
residue
wasn't
fun.
We
we
also
have
turned
wolves
like
our
people,
who
are
working
on
the
writing,
documentation
and
so
on
to
Truvia
release
notes
as
well
today
the
ways
with
p.m.
work,
because
it
was
market
in
the
world
and
and
so
on.
So
we
have
to.
We
have
to
receive
the
final
version
of
the
release
notes
before
we
push
them.
B
L
Know,
there's
a
couple
pieces
of
this
that
Jennifer
and
the
rest
of
sweet
dogs
into
joining
about
part
of
its
training.
People
who
are
submitting
features
to
give
us
higher
quality
release
notes.
So
we
don't
have
to
do
a
lot
of
churn
with
them
and
then
the
the
other
part
is
sort
of
hammering
down
a
set
process
for
getting
release,
notes
getting
them
in
having
them
merged.
L
K
Something
else
I
heard
both
Jennifer
and
Radek
express
a
lot
was
that
they
would
like
to
see
the
release
notes
in
separate
files.
So
the
really
release
notes
for
1.8
would
have
their
own
file
and
will
release
notes
for
1.9
I
think
they
felt
a
little
discouraged
that
the
work
they
had
done
was
in
a
big
file
that
had
a
lot
of
other
things
in
it
and
they
felt
like
that,
made
it
less
visible.
D
We
just
need
to
be.
We
need
to
be
on
top
of
all
these
deadlines
constantly
and
get,
and
let
people
understand
why
why
we
have
the
deadlines,
what
it
means
the
project
if
it
doesn't
get
mad
cuz
basically,
I
mean
this
is
probably
a
gross
over
generalization.
Beldo
anyway,
I
would
say
that
probably
50%
of
the
work
came
in
after
any
given
deadline.
L
It
doesn't
seem
like
they're,
actually
any
consequences
for
missing
deadlines.
Therefore,
nobody
cares.
I
mean
I
hate,
putting
it
that
bluntly
but
I.
You
know
we
stay
at
this
before
there
really
aren't
like
do
we
actually
gate
features
they
don't
get
in
under
deadline
now.
So
it's
an
engineer.
It's
like
it's
more
of
a
suggestion.
Actually.
L
You
know
I
leave
that
up
to
the
people
here,
but
it's
it's.
You
know
at
some
point.
You
have
to
say
if
you
didn't
get
it
by
this
time,
your
feature
doesn't
get
launched.
I
mean
that's,
that's
a
pretty
typical
thing
at
Google.
If
you
don't
have
tests,
it
doesn't
go
out
the
door
and
if
you
don't
Docs,
it
doesn't
go
the
door
like
it's
like
that
is
not
unreasonable,
I
think.
But
we
have
to
make
that
explicit
and
clear
to
people
that
there
are
consequences
for
not
getting
your
your
futures
completed
on
time.
So.
H
Maybe
I
mean
obviously
this
requires
for
the
discussion,
but
my
my
suggestion
would
be.
There
needs
to
be
kind
of
like
a
soft
deadline
that
basically
replicates
what
we
have
today
and
then
a
hard
deadline
shortly
after,
but
with
enough
of
a
lead
time
to
evaluate
whether
things
are
actually
done.
If
they're,
not,
then
they
don't
get
included,
you
don't
get
a
chance
to
do
more
work
because
right
now
it's
kind
of
like
there's
a
deadline
and
but
there's
no
process
to
evaluate,
what's
been
done
or
not
done.
D
D
L
Approving
them
and
merging
them
I
mean
at
a
certain
point
when
it
comes
to
like,
like
we
were
still
getting
features,
and
there
was
debates
over
whether
or
not
features
needed
Docs
up
through
the
launch
and
even
after
the
launch,
we
discovered
that
there
were
features
that
went
out
that
claimed
that
they
didn't
need
Docs,
that
needed
Docs
and
that's
not
that's
not
good
I,
don't
feel
good
about
that
dude.
So
this
thing
talks
team
doesn't
feel
good
about
that.
L
D
A
Erin
on
the
line,
no
anybody
Austin.
Okay,
all
right!
Well,
we
are
wrapping
up.
Then
the
last
items
are
from
Erin,
so
I'll
go
ahead
and
read
those
and
looks
like
he
actually
has
some
some
links
on
there
as
well.
If
you're,
following
on
on
the
dock,
but
sig
testing
will
be
working
on
metrics
and
alerting,
is
part
of
1.9
to
provide
faster
signal,
the
test,
Oprah's
misbehaving
or
jobs
or
family.
H
G
D
Like
the
release
I
put
in
the
last
second
know,
so
I've
been
working
with
the
testing
crew
at
Google
and
we
come
up
with
a
proposal.
I
wrote
it's
basically
going
to
hopefully
put
a
Status
page
up
for
testing
it
for
us.
So
we
know
the
things
are
being
worked
because
essentially
the
strategy
right
now
is
just
everybody
hits
slash
retest
over
and
over
again
and
floods,
the
in
testing
in
frustrating-
or
you
know
with.
D
If
your
test
doesn't
pass
and
your
PR,
you
can
click
on
status
that
kid
SIA
or
whatever
and
I'll
say
oh
yeah.
Well.
This
would
make
Hugh's
currently
having
trouble
with
this
test.
It's
being
worked
by
so
and
so,
and
you
know,
ETA
is
like
two
hours
or
four
hours
to
fix
that,
or
one
of
that
is
those
are
all
the
variables
in
there
will
be
subbed
out,
but
essentially
we
will
provide
some
easy
way
for
contributors
to
know
what
the
status
of
the
testing
is.