►
From YouTube: Kubernetes Community 1.6 Retrospective 20170421
Description
We have PUBLIC and RECORDED weekly video meetings every Thursday at 10am US Pacific Time.
https://docs.google.com/document/d/1VQDIAB0OqiSjIHI8AWMvSdceWhnz56jNpZrLs6o7NJY/edit#
This is the 1.5 retrospective edition. With retrospective notes here - http://bit.ly/k8s16retro
A
B
Alrighty
everybody,
this
marks,
the
beginning
of
the
one
dot
fix
released
retrospective
and
I,
know
I,
probably
sound
like
a
broken
record,
because
I
say
this
every
time
we
have
these,
but
I
just
want
to
reiterate
for
everybody
here,
if
you're
new
or
not,
that
the
goal
of
this
process
is
to
implement
continuous
improvement
in
our
releases
and
it's
not
about
placing
blame
or
finding
included
what
wrong.
Or
why
did
anybody
do
this
or
that
it's
more
about?
B
What
are
the
specific
things
that
we
did
during
this
cadence
of
work
that
we
did
as
a
group
and
together
and
individually,
that
we
can
do
better
next
time?
And
if
there
was
something
that
maybe
we
couldn't
have
done
as
well
as
we
wanted
this
I'm?
Let's
call
those
things
out
and
and
make
sure
that
we
hold
ourselves
accountable
for
when
we
release
the
next
release
in
17.
B
These
are
the
rules
that
we'd
like
to
observe
to
make
sure
that
we're
productive
and
not
having
any
kind
of
finger-pointing
or
blame,
and
simply
those
are
just
that
if
you
fill
out
a
section
in
the
retro
document
itself,
but
just
make
sure
that
you
put
your
initials
by
it.
That
way,
you
can
speak
to
it
and
maybe
help
add
some
color
for
the
group
I.
B
Please
make
any
communication
you
have,
especially
in
terms
of
process
or
people
respectful
and
by
respectful
I
mean
that
you
are
looking
at
the
the
root
cause
of
maybe
what
happened
and
less
about
particular
feelings
or
faults
within
people
or
processes,
and
I
would
request
that
when
you're,
not
speaking,
that
you
meet
your
microphone
just
so
that
we
don't
have
errant
noise,
making
it
hard
for
people
to
hear
and
speak.
And,
lastly,
I.
B
Fist
means
I,
have
zero
confidence
and
awesome
so
I
there
will
be
links
as
we
get
down
through
the
retro
process
to
click
on
the
action
link
there
and
that's
a
vote
and
that
will
allow
us
to
I
do
a
vote
after
we
finish
each
section
and
kind
of
get
a
feel
for
for
everybody's
feelings
on
on,
where
at
so
without
further
ado
I.
What
I
like
to
do
in
the
beginning
is
look.
B
He
said
we
were
going
to
do
in
1.5
in
the
retro
and
did
we
actually
do
them
and
I
as
I
was
reviewing?
These
I
was
I
was
pretty
impressed.
There
is
a
a
continuing
track
record
of
the
community,
saying
they're
going
to
do
something
and
doing
it
and
it's
the
improvement
is,
is
very,
very
exciting
to
see
so
what
I'm
going
to
do
is
just
quickly
skim
down
these.
B
These
things
that
we
said
we're
going
to
do
and
15
for
16,
so
one
of
the
big
ones
was
more
non
Googlers
and
release
specific
roles,
replace
the
release
are
with
a
release
team
and
consider
a
feature
burn
down.
Meeting
before
code
complete
date
improve
released
scripts
to
be
able
to
to
be
usable
by
non
Googlers
and
publish
locally
builds
to
own
download
areas.
Image
registries
I
think
that
was
maybe
a
question,
but
really
it
was
about
being
able
to
improve
the
release.
B
Scripts
feature
owners
really
working
on
the
feature:
release
notes,
improved
test
info
repo
release,
timing,
confirmation
process
in
terms
of
how
it
got
coordinated
with
the
public
release,
candidates
and
release
timing.
So
what
I
feel
like
I'd
like
to
open
this
up
for
just
a
minute
to
anybody
in
the
room?
If
you
want
to
comment
about
some
of
these
things,
and
just
if
you,
if
you
feel
confident
that
we
did
some
of
the
user,
if
somebody
still
existed,
seven.
C
D
C
But
they
could
say
those
fast:
the
release
tricks,
it's
still
a
work
in
progress,
feature
owner.
We
still
need
work,
still
a
problem
with
having
a
bunch
of
outstanding
or
missing
box.
Pr
just
forget
it.
We
cycle
so
may
be
difficult
for
people
to
consume
in
artifacts
planet.
Seven,
application
ready
to
try
to
do
both
now
he
wants
Louise
knows
we're
still
difficult
to
generate
a
lot
of
time,
formatting
and
generating.
Then
at
the
end
of
the
cycle,.
C
E
And
because
picture
so
we
did
that
sensor,
just
maybe
going
every
weekend,
I
happen,
yeah,
it's
all
so
yeah
I
think
that
we
did
a
pretty
good
job,
replacing
the
team's
terms
of
percentage
with
outside
community
members
who
should
differ.
Chinstrap
s
really
give
you
a
good
job
there.
We
didn't
really
get
to
a
place
where
the
release
scripts
could
be
used
by
non
Googlers
right
now
and
the
anything
has
really
changed
there.
E
E
A
E
And
I
think
that
a
lot
of
the
lockers
here,
not
mr.
extract,
thank
you
for
one
who
spoke
more
sort
of
just
like
political.
We
need
to
figure
out
some
sort
of
way
to
manage
the
spirits
that
are
involved
in
the
release
process
and
some
of
these
types
of
release
infrastructure.
So
maybe
looking
into
what
they're,
just
all
Sophie
move
to
another
seat.
There.
A
Are
technical
issues
too
I
mean
and
I
mean
like
it's
just
it's
also
all
accident
of
history
I
mean
nobody.
You
know
did
this
on
purpose,
but
it's
things
like
the
Deb
in
the
after
a
baby
is
that
the
Devon
RPM
repose
for
the
super
Nettie's
packages
are
shared
with.
You
know,
Google
ones
that
are
used
for
the
the
Google
Cloud
SDK
right,
like
we
ously
need
to
untangle
that
it's
just
going
to
take
some
work
and
some
time
it's
not
really
yeah.
D
I
was
losing
more
than
political.
I
think
it's
an
issue
of
time,
because
it's
we
all
agree
that
these
are
the
right
choices,
but
we
also
then
all
agree
that
we
have
all
these
other
priorities
and
focuses
that
we
need
to
do
ahead
of
it
so
yeah.
This
is
the
nature
of
finite
time,
so
I'd
be
careful,
Holly,
political,
but
really
think
of
it
as
a
blocked
on
time
problem.
So.
B
B
So
what
getting
at
the
point
now,
where
we
sort
of
dug
into
what
we
welcome
our
what
we
did,
we
do
it
we
were
going
to
say
we
did
and
there's
a
little
button
there
that
says
action
vote
and
what
I'd
like
to
do
is
I'd
like
to
have
everybody
click
on
that,
and
hopefully
this
works
and
sort
of
confirm
either
you
strongly
disagree
or
you
have
a
range
of
feelings
up
to
strongly
agree
about.
I
feel
positive
about
how
the
1.6
release
went.
B
B
B
Alright,
that's
actually
pretty
positive.
That
means
that
we're
better
than
fifty
percent
of
us
feel
that
we're
we're
doing
pretty
good.
It's
well.
A
A
B
D
D
B
B
B
D
B
Think
these
things
are
pretty
self-explanatory
as
he's
not
so,
but
let's
go
and
go
through
these
real
quick
and
if
you
have
some
to
add
here,
go
ahead
and
if
you
don't
want
to
type
in
the
document,
you
can
just
say
that
verbally
and
I'll
capture
them
in
the
back
in
it.
So
release
launch
before
coupe
con
fantastic,
truly
across
organizational
release.
Success,
triage
backlog
of
flake
issues
down
to
zero
I
the
release
team
I
put
that
in
there
I
was
super
impressed
to
see
how
that
happened.
G
E
Just
other
things,
but
it's
definitely
it's
definitely
was
the
primary
thing.
I
was
doing
everything
else
to
decide
to
go
in
the
background,
so
I
don't
know
if
we
realistically
he's
up,
but
maybe
I
think
it's
probably
gotten
better.
Since
logically,
I
was
able
to
do
it
like
it
was
a
hundred
percent
my
time,
but
it
is
probably
70
DD.
Okay,.
C
C
B
Great
now
I
know
a
ton
of
people,
I
mean
damn
your.
You
did
amazing
work
in
this,
and
thank
you
so
much
for
for
that
I
that
that
was
quite
a
quite
an
endeavor
and
and
truly
appreciated.
I
know,
I've
heard
a
lot
of
really
great
feedback,
myselves,
just
something
about
about
what
you
did
so
are
there
other
people
that
people
in
this
meeting
would
like
to
recognize
or
call
out
is
doing
exceptional
work,
I.
E
Definitely
just
want
to
make
the
team
in
general,
especially
considering
everybody
had
most
people
on
the
team
had
never
done
in
released
before,
and
it
was
a
learning
experience
for
the
majority
of
us,
including
myself,
I.
Just
everyone
really
just
stepped
up
and
really
when
people
needed
good
need
to
be
things
that
people
figured
out
a
way
to
do
them.
I
was
really.
D
E
B
E
I
B
We,
it
might
be
something
that
we
hadn't
later
in
the
document
that
are
there
ways.
Can
we
capture
in
some
way
I
what
was
really
helpful
in
the
transition,
so
maybe
things
that
were
super
counterintuitive
or
things
that
you'd
maybe
took
longer
to
grok,
as
you
moved
into
the
role
from
0,
so
that
we
can
help
the
next.
The
next
release
team
come
up
to
speed,
faster
yeah.
B
E
B
B
B
J
In
terms
of
going
to
me,
this
is
like
a
great
credit
to
the
relief
team
like
they
made
already
happen,
and
it
works
despite
the
fact
that,
basically,
they
don't
have
a
lot
of
say
over
what
goes
into
released.
If
nobody
just
say
something
should
not
going
to
release
if
it's
not
ready,
for
example,
they
can't
roll
something
back.
I
think
we
talked
about
like
what
do
we
do
with
a
doc's?
We
had
like
a
check
box
at
one
stage
or
it's
like
what
do
we
do
if
the
dachshund
don't
land
in
time?
J
Do
we
roll
it
back?
And
second,
though
we
just
we
just
wait
longer
right,
that's
to
me
struck
out
as
bad
as
I
camping
that
which
I
think
I
think
it
is
a
thankless
task
that
does
not
have
a
lot
of
our.
I
guess
would
be
a
word,
but
the
ability
for
the
relief
team
to
say
that
feature
isn't
ready
to
be
the
people
that
say.
J
B
B
Can
you
hear
me
yeah
yeah
I
got
it
yeah
yeah,
so
I
totally
agree
with
that,
and
one
thing
that
is
an
idea
that
has
been
bounced
around
a
little
bit
is
the
idea
of
feature
branches.
One
big
problem
we
have
is
that
people
merge
stuff
directly
into
the
master
and
once
is
in
it's
very
difficult
to
extract
I
rip
things
out
in
the
past,
but
it's
becoming
harder
and
harder
for
anybody
to
do
that.
B
So
I'll
just
throw
that
out
there
as
an
idea,
I'd
be
looking
for
someone
to
try
as
an
experiment
with
the
future,
obviously
would
have
to
go
across
most
lebos
that
we
spent
at
ease
repo
and
I
just
github
god
I,
oh,
but
you
know
if
we
could
put
features
into
branches
review
changes
as
they
go
in
to
those
feature
branches
and
then
they
could
go.
No
go
call
I!
Think
some
things
would
be
a
lot
saner
at
least
Im,
but
I
agree
with
pretty
much
everything
that
Justin
said.
Okay,
we
release
branches,
Syrian.
K
On
the
best
art
to
it,
so
they
see
her
speaking
about
features.
So,
what's
they're
going
to
sing
right
support
me
when
my
work,
people
on
this
episode
also
fell
this
discretion
during
what
at
six
release,
forgetting
that
the
problem
that
some
of
the
features
from
match
their
kitchen
master
without
any
any
confirmation
as
it
is,
so
we
have
to
work
more
on
the
future
branch.
Send
this
process
it'll
yeah.
B
So
this
this
gift
into
a
little
bit
of
solutioning
and
I,
think
that
this
conversation
should
definitely
happen.
So
I
would
say
that
if
Brian
and
others
feel
strongly
about
feature
branches
as
a
as
a
proposal,
let's
write
up
a
PR,
a
knee
or
something
to
that
effect
in
and
capture
that,
because
that
there
is
a
there,
this
sort
of
almost
gets
into
the
the
Emacs
VI
world
about
each
franchise
versus
a
a
dirty
master.
So
let's
definitely
have
a
discussion
about
that,
because
I
think
those
would
be
great
I
think.
A
We
never
in
their
heart.
Well,
so
can
I
get
it
over
to
here.
I.
Think
related
to
this,
though,
is
that
an
alternative
to
do
this
is
actually
find
ways
to
break
stuff
out
of
core
and
actually
have
a
release
be
drawn
from
a
bunch
of
repose,
which
is
something
that
we
don't
have
support
for
so
I
think
an
action
on
my
item
here
would
be
to
improve
the
release
tooling,
so
that
we
can
do
things
like
like
to
a
coordinated
release
about
across
a
bunch
of
components.
No.
B
A
K
Alright,
I
won't,
I
would
try
learned
it
our
future
future
workflow
processes
to
not
finalized,
so
it's
so
under
on
the
final
stage,
but
it's
still
open,
I,
supportive,
tremendous
cuz
of
the
directors,
Brian
and
other
people.
So
if
you
have
any
situations,
the
document
is
to
open
it.
We
are
still
open.
Okay,
let's
put
your
suggestions
into
one
of
seven
release
and
we'll
start
more
than
most
with
it
could.
B
B
B
What
could
have
gone
better
list
is
ballooning,
which
is
good,
but
it
also
makes
me
worried
that
we're
probably
going
to
exceed
our
time
box
so
because,
because
we
have
a
lot
of
things
here,
I'd
like
to
kind
of
go
through
these
rapidly,
as
we
can
so
looks
like
Caleb.
You've
got
the
the
next
thing
about
complexity
and
what's
in
flight.
C
Across
the
entire
project,
isn't
it
and
way
too
that
there
are
it's
very
difficult,
also
figure
out,
what's
a
place
at
any
one
time,
so
making
sure
that
everything
arrives
at
off
of
us
at
the
right
time?
That's
because
we're
saw
works
to
improve
the
communication
and
collaboration
blows
come
on
yes,
so
many
people
tribute
to
do
so
many
different
time
zone
so
either
it's.
B
B
That
is
a
really
rare
problem:
fancy
since
you're
there
do.
You
want
to
just
cut
touch
on
the
next
one.
The
code
please
yeah.
E
So
just
I
think
one
of
the
things
that
quickly
became
apparent
was
there
was
just
no
way
for
us
to
actually
the
first
folk
freeze.
It
be
the
kind
of
thing
we're
like
we
would
go
to
bed,
Justin's,
really
students,
united
states
to
go
to
bed
and
then
things
would
get
put
in
submerged
queue
and
then
they
can
merge
overnight
and
we'd.
Wake
up
some
deeper,
so
I
think
we
just
need
to
figure
out
a
way
to
technically
make
the
recent
forcible
I.
Think
there's
a
couple
scratches.
E
E
You
know
slated
for
that
milestone
and
then,
at
the
last
minute,
when
you
should
be
reviewing
them,
they
can
I
get
lgtm
without
your
awareness
after
the
fries
yeah
yeah,
so
they're
just
sitting
overnight,
and
then
we
r
we
r
during
the
day
just
and
then
maybe
acquaintances
emerged
to
you
and
it
gets
impossible
to
manage
just
be
mad
at
me.
Coming
in
okay,.
B
Yeah
so
I
think
some
changes
to
governance
about
how
the
milestone
gets
used
on
PRS
would
help
a
lot
there
because
sameach,
you
does
have
a
mechanism
for
gating
you
everything
that
doesn't
have
the
milestone.
You
know
so
for
sure
it
doesn't
make
sense
to
use
milestone
before
the
code
freeze,
for
example,
so
yeah
we
can
take
this
outside
this
meaning,
but
I
think
there
are
some
changes
that
we
could
do.
That
would
help
there
definitely.
J
Yeah
I
think
this
is
related
again.
It's
like
it
just
seems
like
a
lot
of
a
lot
of
user.
Impacting
changes
went
into
the
one
release
and
we
could
consider
that,
but
I
feel
like
this
is
pretty
much
covered
by
what
we
just
talked
about
right.
If
the
reason,
besides
greasy
massive
power
to
decide
what
that
it
is
acceptable
and
they
decide
that
it
is
accessible
them,
I
think
that's
good
enough.
Yeah.
L
J
Yes,
very
much
so
it's
like
I
want
to
like
pick
on
any
just
to
give
our
things,
but
you
know
like
where
I
think
so
there
are
three
significant
changes
that
went
into
the
relief
and
any
one
of
them
could
have
been
enough
for
the
users
that
have
to
implement
them
and
I.
It
was
just
was
a
lot
for
these.
A
lot
of
your
users,
yeah.
L
I
think
this
ties
into
like
characterizing
changes
as
they're,
going
in
as
far
as
impacting
users
and
action
required
and
how
flows
into
release
notes.
If
we're
thinking
about
this
holistically,
we're
saying
as
a
result
of
this
change,
what
is
it
you're
gonna
have
to
do,
how's
it
going
to
impact
them
or
break
them
that
ties
together
stuff
throughout
the
release,
better
I
hope,
yeah.
B
So
this
kind
of
thing
has
been
discussed
in
sig
p.m.
which
respected
teachers
process,
so
I
suggest
a
cig
release
in
sig
p.m.
had
some
kind
of
joint
discussion
about
this,
because
I
definitely
agree
that
this
is
a
challenge
and
we
somehow
need
to
tie
back
like
what
realistically
can
be
accomplished.
You
know
I
think
tracking
is
definitely
not
sufficient.
We
also
need
some
sort
of
due
diligence
on
these
things
like
whether
it's
a
reasonable
for
all
these
things
kind
of
push
in.
B
H
D
A
Like
we
can
go
into
details
on
the
on
the
PM
there,
but
you
know
there's
a
C
and
I
had
some
breaking
changes,
wasn't
clear
how
to
actually
fix
that
the
six
ended
up
being
worse
than
the
curing.
We
didn't
catch
it
because
it
went
in
before
the
RC
and
everybody
was
busy
getting
ready
to
food
con,
so
they
weren't
able
to
test
this
stuff.
This
was
all
compounded
by
like
the
EDA
use
for
cube
admin
broke
and
as
they
came
back
on,
nobody
was
checking
him.
A
B
B
That
okay,
Jacob
awesome,
there's
a
couple
more
hair
feel
you
want
to
cover
those
up.
H
H
L
B
So
in
the
past,
what
we
had
done
is
we
opened
up
master
when
the
number
of
PRS
we
wanted
to
cherry-pick
dwindled
to
manageable
levels.
Like
often
we
would
cut
the
branch
and
then
there
would
be
hundreds
and
hundreds
of
PRS
and
you
need
to
get
with
would
need
to
be
terrific,
so
we
just
rolled
forward
instead,
but
once
that
gotten
to
like
a
dozen
for
every
couple
days
or
something,
then
it
seems
more
practical
to
reopen
all.
B
The
flick,
triaging
I
thought
there
was
something
that
was
going
to
be
automated,
there's
a
knot,
the
kisser
well,
their
health
signals
in
terms
of
failing
tests,
which
includes
flakes
and
open
critical
bugs,
and
things
like
that,
and
definitely
dashboards
to
monitor.
Those
things
are
one
signal,
but
also
just
in
terms
of
vetting
the
PRS
that
we're
going
into
master
and
identify
whether
those
are
actually
critical
to
the
release
or
not,
and
this
comes
back
to
thing
that
dan
mentioned
that
stuff
was
just
getting
merged,
even
though
the
freeze
was
in
place.
B
If
we
could
just
look
at
you
know
how
many,
if
we
could
trust
that
the
things
getting
merged
were
actually
needed
for
the
release,
we
could
monitor
the
rate
of
merges
and
once
that
started
to
dwindle,
to
kind
of
more
like
cherry
things
that
would
be
feasible
to
cherry
pick
individually,
then
we
can
potentially
open
up
master
again,
so
I
think
automation
could
help
as
well
as
some
sort
of
process
around
vetting
PRS
to
make
sure
the
right
things
were
going.
Okay,
make
a
note
of
that,
and.
L
It
just
as
we're
planning
the
ones
haven't
released,
saying
you
at
what
point
do
we
want
to
reopen
master
like?
Is
it
a
number
of
issues?
Is
a
number
of
people
working
on
blocking
issues
just
trying
to
balance.
You
know
people
making
work
easier
for
people
who
are
working
on
the
release
and
being
work
easier
for
people
who
are
waiting
for
the
next
release.
So
now.
I
In
the
proposal
for
the
17
timeline,
I
actually
adjusted
setting
that
as
kind
of
a
hard
date
depending
on
when
you
want
to
make
the
release,
because
it
actually
acts
as
a
tool
to
quiet
down
the
release
branch.
When
you
increase
the
barrier
to
I
know,
you
have
to
carry
fake
everything
and
that
really
helps
with
this
issue
of
controlling
what
goes
into
every
square
inch.
So
I
don't.
A
We
want
it
if
we
want
people
to
be
more
deliberate
about
checking
stuff
in
late
into
the
cycle.
We
can
put
up
roadblocks,
we
can
put
up
gates
and
approvals
or
we
or
we
can
just
say
that
if
you
merge
stuff
out
of
turn,
you
get
a
warning
and
then
you
get
your
committer
bit
limit.
I.
Think
you
know,
and
just
be
clear
in
this
release
cycle
is
going
to
hold
the
line
right.
B
Tooling
wives,
it
does
become
very
hard
to
track
whether
the
things
that
need
to
go
into
release
actually
are
in
the
release.
So
just
be
cognizant
of
that
as
well.
I
will
be
built.
The
cherry
pick
dashboard
and
have
the
terrific
labels
and
things,
but
it
does
become
very
hard
to
make
sure
that
all
the
right
things
get
cherry
picked.
A
B
D
B
L
E
I
think
part
of
the
problem
is
it's
really
and
there
were
things
at
fixes,
I,
don't
believe
work,
I,
don't
think.
It's
saying
that
case.
We're
talking
about
here
that
use
personal
email
do
but
there's
other
cases
where
things
came
in
as
bugs.
I
still
believe
her
features
changes
and
I
think
it
probably
just
tend
to
be
dat
better
definition,
for
what
is
a
bug
fix
your
pledge,
expectable
a
trick
degrees
just
so
that
we
can
buy
a
clear
set
of
rules.
E
So
I
think
it's
great
that
we
can
probably
narrow
down
the
definition
of
bug
fixes
feature
at
the
end
of
the
day.
After,
like
same
just
lots
of
releases
in
general,
it
there's
always
going
to
be
some
judgment
calls,
and
I
feel
that
the
I'm
curious
people
think
that
the
release
manager
is
the
one
responsible
for
these
or
scientist
ii
of
the
release.
So
I
feel
like
they
kind
of
get
51
percent
of
the
note
and
that
you
know
they're
generally,
these
things
happen
after
future.
E
Please
wear
these
questions
come
up
anyway,
the
release
the
managers
in
or
leads
a
relief
team.
It's
usually
the
one
that
is
aware
of
the
overall
intricacies
enviable
release
and
probably
has
information
to
make.
Those
calls
is
up
and
I've
actually
get
on
the
receiving
end.
We
told
know
this
is
going
to
go
in
I,
see
this
more
as
a
feature,
but
you
know
I
think
judgment
will
have
to
be
exercised,
however,
for
we
get
away
from
that
I
just.
M
Thought
issue
I
have
on
that
life
in
this
is
Erica
some
awesome
time.
The
release
lead,
isn't
the
one
man
responsible
for
supporting
the
issue
that
then
is
opened
in
the
field
in
response
to
that,
and
whereas
the
component
owner
is
going
to
be
the
one
handling
the
customer
fire
when
it
happens.
So
if
you
have
a
way
of
at
least
balancing
that
a
little
clearer
so
that
certain
things
going
with
a
code
based
and
I'm,
not
sure
any
kromaggs
are
so
large,
I
don't
have
nice,
apply
the
knowledge
or
wherewithal
to
know.
L
L
Is
making
the
definitions,
crisper
and
making
impact
clearer?
So
when
a
bug
comes
in
like
laying
out
impact
to
this
component
back
to
the
whole
product
and
back
to
the
release
like
so
that
the
release
manager
has
the
tools,
they
need
to
weigh
the
risk
and
way
the
impact
of
not
including
the
fix?
Yes,
I,
I.
G
Wanted
just
from
my
experience
we
need
to
remember
this
is
a
very
large
community
right.
So
at
the
end
they
are
probably
so
how
good
people
that
have
some,
even
if
it's
a
bug
fix
so
it
is,
and
we
decided
the
end
of
1.3,
which
sizes
we
don't
have
blockers
for.
This
is
right.
There
is
no
features
that
block
the
release.
So
unless
core
functionality
is
not
working,
it
might
be
that
a
new
feature.
E
And
Derek
I
I,
completely
sympathize
with
you
and
I
I
understand
your
position,
but
also
you
know
the
release.
Folks
are
generally
reasonable
and
if
they
see
something
that's
in
the
sig
that
is
going
to
be
stabilizing
that
component,
you
know,
that's
that's
when
you
actually
do
escalate.
You
have
these
conversations
I'm,
hoping
that
it's
a
minority
of
items
in
the
first
place
and
then
from
that
minority.
You
know,
he's
a
further
minority
where
you
know
that
this
really
hurts
the
stability
of
the
system.
Yes,.
M
I,
don't
think
we've
I,
don't
think
we
could
ended
up
in
a
state
in
one
that
sticks
were
there
was
anything
the
outcome.
Wasn't
the
desired
outcome,
like
I,
think
I.
Think
it's
more
like
this
is
how
the
first
place
where
we
felt
some
tension
and
when
you
get
tension
the
community.
Just
when
you
don't
have
a
clear
way
of
knowing
how
to
dissolve
the
attention,
that's
problematic,
I
guess
the
other
thing
is
I'm.
Not
only
sure
that
we're
always
one
hundred
percent
consists
on
that.
Like
I'm.
M
L
H
E
Sounds
like
a
good
topics
delve
into
for
the
lease
igg2,
but
I
also
think
the
exceptions
process
is
Derek
said
you
know
just
having
you
know,
not
at
the
moment
of
tension,
trying
to
develop
a
process
or
figure
out
what
the
right
way
to
do.
This
is
probably
also
really
helpful.
It's
not
the
right
time
to
try
to
figure
out
the
rules
it
gives.
Your
question
fell.
We
didn't
use
that,
but
it
sounds
like
it
would
be.
Really
helpful.
I
definitely
push
you
put
that
as
a
suggestion
for
the
next
release.
Okay,.
G
L
L
L
L
Maybe
this
is
just
me,
but
I'm
used
to
like
calling
names
like
so-and-so
is
responsible
for
status
on
this
so-and-so
is
responsible
for
status
on
this
and
I
didn't
it
didn't
seem
like,
as
much
of
that
happened
and
there's
this
kind
of
a
general
all
right.
Let's
just
all
look
at
the
blocking
issues
and
when
response
word
is
distributed
like
that,
it
doesn't
end
of
work
that
well.
In
my
experience.
B
L
Not
on
that
one,
the
the
next
one
again,
there's
there's
a
lot
of
noise,
and
some
of
us
was
like
process
changes,
tracking
things
via
milestones
or
via
labels
or
via
priorities
or
via.
Who
knows
what
and
I
appreciate
the
difficulty
of
kind
of
changing
process
midstream,
but
there
were
a
lot
of
bulk
moving
of
issues
into
the
milestone
and
considering
things
blocking,
and
I
would
like
to
prioritize
how
we
track
blocking
issues
early
in
the
release
so
that
we're
not
doing
it
at
the
very
end
of
17,
again
saying.
Alright,
we've
got
600
issues.
D
L
G
L
So,
knowing
knowing
how
we
should
be
using
milestones
like,
even
even
as
we
were
using
things
at
the
end
of
16,
a
lot
of
stuff
just
got
bumps
to
17.
So
now
the
ones
on
the
milestone
contains
tons
of
things
which
I'm
pretty
sure
we'd
be
happy,
releasing
17
without
so
knowing
how
we're
how
we're
intending
to
use
milestones
and
labels-
and
we
should
do
that
soon.
So
we
have
a
good
picture
of
17
as
the
chick
stuff
yeah.
B
E
See-
and
we
saw
Easter
touch
with
us
when
we
talked
about
bugs,
but
just
not
having
a
clear
definition
of
what's
a
bug
in
which
market
that
there
are
some
new
changes
that
were
feeling
of
isolation
that
got
birds
as
bubs
after
code
freeze
and
then
does
the
exceptions
process
because
of
that
and
I
think
it
just.
You
need
to
figure
out
like
what
is
the
maximum
contact
complexity
that
constitutes
above
that
above
it
needs
to
go
through
some
absurd
process,
just
because
currently
bug.
E
If
right
now,
we
just
sort
of
crushed
the
features
owner
but
I
feel
like
there
were
some
cases
that
there
were
actual
and
improvements
that
were
not
necessarily
I,
wouldn't
consider
them
about
that
were
merged,
so
I
think
she's
having
clear
definitions
gives
a
lot
of
times.
It
just
came
down
to
a
sort
of
the
really
seems
judgment
than
the
feature
under
such
manner
and
just
hard
to
sort
of
come
to
anything.
E
If
there's
no
guidelines
above,
what's
in
there,
how
often
did
you
have
to
do
that
in
isolation,
and
how
often
were
you
I
do
know
that
sometimes
in
different
time
zones
and
get
lgtm
do
maybe
when
these
managers
into
where?
But
how
hard
was
it
to
find
like
a
cig,
lead
or
authority
to
talk
to,
or
were
you
in
the
least
lead
position
just
kind
of
getting
morning.
M
Well,
I
love,
my
color
looks
Michael
know
where
I
think.
In
this
particular
case
there
was
confusion
open.
There
was
confusion
where
there
were
things
that
in
signal
we
discussed.
If
we
should
open
exceptions
for
or
not
and
I
think
they
were
issued,
they
were
exception,
request
open
for
things
that
I,
don't
think
needed,
exception
request
and
at
least
across
dawn
and
myself,
I
think
I
introduced
a
lot
of
confusion
and
I.
E
M
D
M
E
B
B
If
you
could
just
make
a
quick
note
in
that
in
the
dock
into
the
17
improvements
plan,
just
generally
covering
those
two,
those
two
cases,
Derek
looks
like
you're
next
yeah,
so
I.
M
Think
this
release
there
were
some
changes
that
went
in.
That
I
think
are
exposing
some
challenges
and
maybe
the
cube
81
is
related,
I'm
not
sure,
but
in
some
cases
there
were
instances
where,
like
no
changes
couldn't
get
merged
because
they
exposed
issues
and
like
a
cop's
tool
that
was
blocking
the
merger
and
so
like
it's
in
some
ways
it
felt
like
you
were
powerless
to
know
how
to
fix
it
or
understand
why
it
should
be
blocking,
and
when
I'm
wondering
is
if
some
of
these
in
dollar
tools
came
to
be
like
temporarily.
M
Disabled
for
a
period
of
time,
during
the
release,
so
that
until
that
sig
is
able
to
respond
to
that
feature,
change
because,
right
now,
it's
like
it
was
surprising
to
me
when
trying
to
get
some
of
the
node
allocatable
and
node
Siegert
apology
stuff
laid
out
that,
like
it,
was
exposing
problems
and
installed
two,
and
I
think
it
was
like
good
does.
It
was
clear
that
it
was
going
to
close
in
a
calm
and
install
tool,
but
it
kind
of
like
introduced
the
schedule
la
that,
like
nobody
had
accounted
for
or
couldn't
see
and
like.
J
M
I,
just
I
think
it
was
just
surprised
to
me
right
and
then
I
had
not
when
I
think
about
like
in
some
ways
we're
all
considering
an
open
source
community
and,
like
you
dedicate
time
to
things.
But
then,
when
you
get
these
spikes,
you
get
frustrated
about
and
I
think
having
real
ways
of
like
saying
this
is
a
reasonable
spike
that
we
need
to
allow
and
I
shake
to
go,
respond
to
and
as
a
consequence,
disabled,
something
or
not
like
it's
something
we
should
discuss,
especially
as
we
add
more
and
more
things.
M
M
We're
tools
and
then
I
think
the
other
issue
I
had
here
related
with
some
of
the
node
allocatable
rollouts
was
sometimes
there's
a
tendency
that
went
up
when
like
something
goes
in
and
it
might
have
exposed
a
bug
in
a
downstream
test
or
PR.
But
the
the
decision
is
to
kind
of
disabled
the
thing
that
fixed
an
underlying
bug
in
a
ver
allowing
the
existing
bug
to
continue
to
exist,
and
so
that
goes
back
to
my
ideas
like
like
I,
think
when
whether
it
was
cops
doing
something
that
didn't
quite
seem
right
and
meaning.
M
The
wanting
me
to
have
that
bail
to
disabled
until
cops
codes
and
fixes
their
problem
or
in
the
rollout
of
the
new
secrets.
Apology,
I
think
we
discovered
one
of
the
EDB
test
was
leaking,
was
leaking
memory
or
something
early
thing
was
leaking.
Some
resources
can't
recall
right
now
and
like
well.
I
had
a
valid
PR
that
when
I
and
I
had
to
also
go
and
write
a
revert
PR
to
take
it
out
very
near
the
end
of
the
release.
M
M
And
then
the
last
one
was,
but
when
we
have,
we
have
this
like
mad
rush
of
getting
stuff
to
the
feature
free
state,
and
I
don't
know
how
we're
going
to
fix
that.
But
we
also
have
a
issues
where,
just
by
the
nature
of
the
codebase
oftentimes,
we
like
have
rallying
points
to
certain
files
that
cause
realize
conflicts
and
stuff.
So
like
the
cube,
loop
was
really
bad
at
this.
M
The
expectation
was
that
everything
that
was
supposed
to
be
in
her
future
freeze
was
already
merged
but
like
if
a
developer
had
gone
on
vacation
or
at
a
customer
support
issue
or
just
had
a
busy
day
at
work
that
day
and
wasn't
able
to
go
on
release
APR.
It
I
think
we
need
to
set
some
expectations
on
like
how
long
after
the
future.
M
Three
states
do
we
expect
to
let
the
merge
to
drain
and
right
now,
that's
a
bit
fuzzy
and
so
I'd
like
to
get
clarification
on
that,
so
that
when,
if
PRS
are
missing-
and
someone
has
to
like
you
know,
be
out
of
the
office
for
a
half
a
day
or
a
day,
it
might
not
be
able
to
babysit
a
PR
24-7
got
like
everybody
knows
how
to
get
overlapping
back
back
in
coverage,
and
so
just
I
think
we
need
to
think
that
group
is
going
to
have
obviously
live
mas.
You,
okay,.
B
D
B
Is
great
well,
since
you
are
sort
of
a
stopping
point
here
for
a
moment
if
we
could
have
everybody,
do
the
last
there
that
the
action
here
which,
if
you
scroll
down
and
says
I,
feel
positive
about
how
the
1.6
release
went
and
vote?
If
you
strongly
disagree
or
if
you
go
all
the
way
to
being
strongly
agree,
just
so,
I
can
get
a
blush
of
what
how
people
felt
about
1
dot
six.