►
From YouTube: Kubernetes SIG Release (1.17 retro) 20191217
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
E
D
F
F
So
we're
we've
actually
taken
action
to
resolve
this
now.
So
there's
a
PR
we're
working
on
to
add
that
kind
of
clarity,
but
we
found
out
that
you
know
the
release.
Notes
need
to
be
merged
before
we
push
the
Big
Green
Go
button,
so
I
don't
think
it
was
in
your
notes
either
Gwen
and
it
seemed
to
be
a
thing.
We've
learned
for
the
first
time,
which
was
kind
of
fun
and
unfortunately
it
required
a
lot
of
work
for
a
Tim
to
fight
the
tide
that
were
so.
There
may
be
other
things
that
are.
F
B
F
B
D
D
D
C
D
So
everyone
on
our
at
least
I,
feel
everyone
on
those
issues
that
is
part
of
the
release
team.
Has
that
power
right
once
the
enhancement
moves,
past
enhancements,
freeze
kind
of
everyone
holds
that
that
that
issue
in
their
hands
right,
because
they're
they've
got
to
check
it
for
docs
deadlines
or
release,
notes
or
what-have-you.
So
I
think
anyone
can
do
it.
Whoever
gets
to
it
first
is:
you
can
can
go
for
it.
B
G
D
I
almost
feel
like
once
the
you
know,
once
the
release
starts
there
I
mean
once
enhanced.
Entry's
is
done
like
not
that
their
part
is
over,
but,
like
I
think
you
know
you
you
all
recognize
during
the
meeting
set,
it
was
like
hey
or
enhancements
great
towards
the
end
of
the
cycle
is
kind
of
like
aren't
Hansen's
green.
That's
like
yes,
they're
green,
because
we
settled
that
portion
of
the
cycle.
D
H
B
C
B
C
B
J
I
It
would
it
be
worth
adding
in
like
an
asia-pacific
friendly
time
zona.
If
we
were
in
the
situation
again
with
a
different,
he
would
no
matter
what
area
of
release
team
you're
on
if
there's
some
sort
of
timezone
differential,
maybe
as
a
search
getting
down
to
crunch
time,
it
doesn't
have
to
be
a
packed
I'm
friendly
for
the
entire
release
cycle.
But
when
it's
down
to
this,
you
know
crunch
time,
it
might
be
a
good
idea
to
have
that
sync
yep.
B
B
I
D
Yeah
I
think
that's
fine,
I
would
say
yeah
towards
the
end
of
the
release.
Everyone
who
is,
if
you
were
a
shadow,
if
you
were
you
know,
if
you're
a
shadow
if
you're
lead,
like
really
just
to
reiterate,
feel
empowered
like
this
is.
This
is
literally
part
of
your
job
to
be
able
to
say
no
to
people
towards
the
end
of
the
cycle,
whether
we
have
to
kick
out
issues
or
or
docks
or
release,
notes
or
enhancements.
What-Have-You
like
that
is
that
it
is
part
of
the
the
gig
so.
B
E
I
Yeah
thanks
Bob,
so
we
operate
pretty
much
in
the
entire
release
cycle:
syncing
master
to
a
release
branch.
Typically,
this
is
probably
the
easiest
part
of
the
release
cycle
because
it's
literally
a
copy-
and
we
were
even
talking
about-
maybe
towards
the
end
of
the
release
cycle,
just
cutting
directly
from
master
this
new
branch.
What
we
ended
up
saying
those
are
the
Chinese
localization
team,
we're
operating
out
of
the
release
kind
of
the
new
future
release
branch.
I
So
the
solution
moving
forward
is
kind
of
cutting
out
the
loconut
kind
of
actually
cutting
out
the
localization
teams
from
using
a
future
release
branch
for
their
dev
work
and
when
they're
working
on
top
of
it,
they
won't
be
merging
into
the
release.
Branch
they'll
be
cutting
a
new
branch,
making
their
iterative
changes
and
then
merging
in
as
a
milestone
and
it'll
make
this
whole
problem
go
away.
I
So
it
turned
out
to
be
a
communication
issue
with
the
way
Chinese
localization
was
occurring
and
I
think
we
have
a
handle
on
fixing
this
moving
forward
and
then
a
side
note
on
that.
I'd
really
like
to
work
with
the
release,
team
and
automating
out
a
lot
of
the
get
responsibility
from
Docs.
Put
that
more
on
the
release
engineering
and
try
to
find
a
solution
there,
where
Docs
can
focus
entirely
on
technical
review,
peer
reviews
enhancements
getting
in
all
the
technical
docs
and
not
worrying
about
becoming
a
guru
overnight.
D
Yeah,
so
we
talked
about
this
a
little
bit
with
a
branch
fast
forward
tool
in
the
last
release.
Engineering
meeting
I
think
that
I
guess
I,
guess
that
a
few
of
the
release
engineer
should
probably
become
more
familiar
with
the
docs
workflow
to
figure
out
how
we
can
help
out
Jim
is
you
are
part
of
the
release
manager,
says
group
as
well?
Can
you
work
to
figure
out
what
we
can
be
helping
out
with
outside
of
the
branch
passwords
yeah.
I
Absolutely
I
really
think
that
that
branch
fast
forward,
it's
gonna,
be
a
lot
of
fast
forwarding
and
merging
synchronizing.
Those
branches,
so
I
think
we
solve
it
in
one
spot
will
be
good
to
kind
of
roll
that
to
the
other
areas
of
sigdoc,
but
I,
agree
and
I'm
from
the
release
engineering
meeting
we
had
I'm
already
taking
ownership
of
this
and
I
already
had
a
few
open
issues.
I
I
D
D
Websites
are
kind
of
basically,
so
the
idea
here
would
be
to
create
to
create
intend
tests
for
the
release.
Engineering
tooling
like
and
then
be
able
to
blast
the
repo
without
fear
of
consequence
in
it
being
actual
kubernetes
content
so
Tim.
This
was
the
issue
that
you
were
tagged
on
and
you're
like
wait,
hold
on
and
then
I
think
I
think
Sasha
kind
of
rounded
up.
What
should
what
kind
of
the
intent
of
that
issue
was?
So
that's
nothing
right
now.
D
K
Hey
Murphy,
I'm
doc,
you
know
I
have
a
concern
about
how
we
can
sink
the
PR
from
the
Kas
PR
to
the
docks
PR,
because
currently
when,
when
we
decide
to
push
down
the
K
ap
PR
for
for
the
next
realist,
then
we
still
need
to
check
whether
the
PR
for
the
docks
is
already
pushed
down
to
the
next
milestones
or
not.
So
this
is
kind
of
like
double
past
that
maybe
can
be
automated.
Somehow.
I
K
Then
we
still
need
to
check
the
docks,
be
alright.
The
placeholder
we
are
that
we
are
having
and
I
was
wondering
if
it's
possible
to
like
sing
sing
between
the
docks,
PR
and
the
PR
for
the
queue
Burnitz
itself
may
be
using
label,
or
something
like
that.
So
that
way,
when
we
decide
to
remove
the
milestone
for
the
queue
Burnett's
repository,
then
the
the
docks
we
are
for
for
that
specific
feature
is
also
being
removed
from
the
milestones.
Oh.
L
M
D
C
So
one
one
possible
thought
there:
if
there
is
an
open,
K
website,
PR
listed
in
the
spreadsheet
it'd
be
essentially
if
it,
if
it
gets,
kicked
over
to
the
remove
from
milestone
tab,
you
could
get
a
list
of
all
the
docs
PRS
from
there
and
then
you
at
least
have
something
that
should
be
a
list
of
things
that
should
be
closer
removed.
Yeah.
D
I
was
going
to
say
that
I
worry
about
automating,
that
bit
too
heavily.
There
is
some
value
in
having
the
human
interaction.
I
do
think
that,
like
Bob
was
saying,
if
we
get
something
that
can
at
least
give
you
a
report,
do
a
dump
of
what
could
be
actionable
yeah,
but
I
were
I
worry
a
little
bit
about
how
not
having
a
human
look
over
that
and
say:
okay,
this
really
should
be
removed.
I
do
like
the
idea
overall,
like
I,
want
to
make
sure
there's
less
work
for
y'all
when,
if.
B
There
were
way
for
this
to
be
part
of
the
process
from
the
very
beginning,
right
we
ask
someone
when
they
open
a
pull
request
against
KK.
Hey
is,
does
his
need
ducts?
Is
this
a
user
facing
change?
Does
this
need
dogs
right
anyway,
I'm
just
thinking
out
loud
here,
but
but
it's
it's
generally
good
practice
that
if
you
write
code,
you
make
Doc's
to
go
with
it
and
in
our
case
the
complicated
ways
we
have
a
whole
separate
repo
for
the
website
than
two
separate
separate
from
the
mono
repo
of
the
code
right.
B
D
Yeah
and
we
do
it
in
kind
of
a
different
way,
I'm
there.
There
are
plenty
of
things
that
we
merge
in
for
a
milestone
that
doesn't
necessarily
isn't
necessarily
attached
to
enhance
in
an
enhancement
which
means
it
doesn't
get
the
same
level
of
rigor
in
terms
of
people
tracking
you
down
to
do
docks
so
I
think
we
should
should
we,
we
hack,
open,
initiated
knack
on
ideas,
kind
of
I,
think.
M
One
other
input
from
my
end
would
be
green
and
stiff,
and
so
whenever
we
go
with
the
new
enhancements
tracking,
so
one
other
issue
we
face
is
that
we
go
to
each
and
every
enhancement
and
ask
them.
Does
this
need
Docs?
Like
the
first
question
we
ask?
Is
it
does
it
need
dogs,
so
the
enhancement
owner
comebacks
in
next
2
to
3
days
and
saves
me
that
ok,
it
needs
the
docs,
then
I
will
read.
M
Then
I
will
put
a
message
saying
there
is
open
a
PR
against
kubernetes
slash
website
so
that
it's
taking
more
time.
So
whenever
we
put
slash,
milestone,
1.18
or
something
like
that,
it
should
then
in
there
ask
ok
when
you're
targeting
to
this
release.
Does
this
needs
a
Docs
and
I
should
be
able
to
see?
Ok,
this
needs
a
dog,
so
it
is
in
hand
like
it
is
reducing
my
efforts
of
waiting
for
48
hours
just
to
know
that
it
meets
a
dogs
or
not.
Maybe
this
kind
of
things
might
definitely
help
to
know.
D
D
My
initial
thought
when
I
was
doing
enhancements
was
like:
do
we
need
a
label
for
all
of
these
things
that
people
need
like
needs
kept
needs?
You
know
it
needs
kept
update,
needs
in
stock
update
needs
blah
blah
blah,
because
these
are
like
things
that
should
be
assumed.
It
does
add,
friction
at
the
front
part
of
the
process
for
enhancements
at
least
figuring
out
three
setting
labels
or
you.
J
D
But
I
would
I
would
assume
if
we
said,
needs
dots
and
it
always
needs
dogs
unless
the
docs
are,
unless
it's,
even
if
even
if
you're
moving
from
like
beta
to
stable
right,
you
still
have
to
say
that
your
thing
is
graduating
from
beta
disable
right
from
alpha
to
beta.
You
go
like
okay.
Well,
this
thing
is
on
by
default
now,
right,
depending
on
what
kind
of
changes
it
could
be
valuable,
we.
D
We
do
it's.
Some
of
some
of
the
configuration
is
I.
Do
I
do
urban
ed
expiry
Nettie's
right
now
the
plug-in
is
configuration
expensive,
like
not
to
say
that
we
couldn't
do
this
for
the
enhancements
rate,
just
anything
that
can
potentially
change
because
we're
running
into
this
right
now
with
the
issue
triage
ideas,
anything
that
can
potentially
change
the
contributor
experience
for
a
large
swath
of
people
needs
to
be
carefully
carefully
considered.
So
I
think
we
should
do
an
issue
for
this
and
make
sure
we
expound
on
all
those
ideas
before
leaving.
L
E
All
right,
then,
for
the
sake
of
time,
I'm
gonna
say:
let's
move
on
to
the
next
item
in
the
retro,
we've
got
Jeremy
Rickard,
who
I
don't
believe
is
on
this
call,
but
his
item
there
was
there
were
a
few
items
that
ended
up
missing
code,
freeze
and
needed
exceptions
and
last
minute
scrambles
to
remove
include
things
on
the
milestone.
I,
don't
know
if
there's
anyone
I'm
from
I
think
this
is
from
the
enhancements
area.
That
would
like
to
speak
to
this.
C
B
B
C
Other
thing
is
I
know
with
one
of
them:
the
metric
stability
one.
There
was
just
some
confusion
around
that
one,
and
that
was
mostly
with
the
main
person
that
was
working
on.
It
was
believed
based
out
of
China.
So
there
was
some
turnaround
time
on
getting
questions
back
and
forth,
and
things
like
that
and
locking.
D
That
one
in
so
one
of
the
suggestions
that
was
made
and
I
don't
know
where
it's
documented,
so
I
don't
know.
If
someone
wants
to
document
this
earth,
maybe
I
can
do
it
is
what
if
we
brought
back
kevin
flush
and
started
the
milestone
restrictions
ahead
of
code
freeze,
that
would
mean
that
people
would
be
more
on
their
toes,
because
the
bots
wouldn't
let
them
merge
things.
A
D
B
D
A
D
B
H
D
B
So
I
am
pretty
sure
I
granted
all
the
requests
for
exceptions
and
I
think
they
were
totally
cool.
Like
two
enhancements
exceptions,
code
phrase
exceptions,
one
of
those
was
because
there
was
confusion.
The
other
one
was
because
wait.
No,
we
are
actually
like
really
really
close.
Please
can
we
get
this
in
and
the
six
chairs
were
on
board
with
it.
B
I
thought
the
process
is
working
well,
I
looked
back
and
I
saw,
which
exception
had
not
been
granted,
and
those
were
all
things
that
were
mostly
the
byproduct
of
someone,
not
realizing
that
we
were
on
a
schedule
and
being
like.
Oh,
it
looks
like
I
can
get
an
exception,
but
you
know
there
was
no
work
started
stuff
like
that.
It's
usually
pretty
obvious
and
I
believed
that
both
the
exceptions
that
I
did
grant
made
it
as
features
so
again,
I
think
this
process
works
as
it
is.
So
we
didn't.
C
D
C
B
J
E
B
It
is
not
enough
to
just
schedule
a
meeting
and
then
so
well,
it
is
not
enough
to
informally
ask
people
in
public.
Is
this
meeting
time?
Okay
for
you
or
let
me
know
if
it
doesn't
work,
because
people
don't
want
to
be
the
odd
one
out,
and
so
that
was
on.
That
was
on
me
that
I
didn't
take
individual
hesitation
to
go
against
the
grain
into
account
and
yeah
make
make
a
doodle
ask
people
come
up
with
a
better
plan.
It
is.
B
It
is
tied
a
little
bit
into
I
believe,
there's
an
action
item
on
what
we
will
do
differently
about
just
restructuring
their
meeting
times
in
general
and
I
should
have
done
a
better
job
here.
I
do
think
that
moving
the
meeting
time
from
10:00
a.m.
to
9:00
and
I
think
that
was
the
case
in
116
as
well
helped
more
people
but
I,
don't
think
it
was
enough.
B
A
Did
in
my
cycle
that
was
relatively
painful
for
some,
but
also
drove
positive
benefit
for
some
was
we
had
that
that
Monday
meeting
at
the
time,
and
then
I
also
did
a
much
earlier
meeting
on
Tuesday
I
think
it
was
6:00
a.m.
my
time
or
something
like
that
or
7:00
a.m.
I?
Don't
know
it
was
much
much
earlier
to
become,
notably
before
the
end
a
day
in
in
Europe
at
least
and
I.
A
Think
that's,
that's
something
that's
unfair
to
require
of
overall
release
lead,
but
if
it's
possible
somewhere
within
the
team,
to
figure
out
how
to
have
mere
meetings
and
then
the
key
is
that
somebody
is
in
both
to
sort
of
notice,
trends
and
patterns
and
convey
information
between
the
two,
whether
it's
the
release,
lead
or
other
leads,
or
or
even
shadows,
but
to
get
cross-pollination
between
them
so
that
you
don't
end
up
with
divergent
sub
teams
within
the
team.
That
is
something
to
consider
finding
a
way
how
to
practice
that
suit.
D
I
think
that
this
also
happens
post
your
cycle.
There
was
I
can't
remember
who
at
the
moment,
but
I
think
there
might
have
been
a
lead
shadow
or
two
who
held
like
a
friendly
meeting
so
yeah
we
should.
We
should
get
it
in
dots.
Well,
I!
Think,
your
your
Dobson,
sorry,
no,
your
your
Doc's
update
includes
some
of
that
already
yeah.
B
That's
a
bad
way
to
put
that,
but
but
but
wait
if
we
have,
if
we
have,
if
everyone
talks
with
their
shadows
and
shadows,
live
in
a
different
time
zone,
run
a
meeting
in
that
time
zone
report
back
to
their
lead.
That
can
also
just
help
fill
in
some
of
those
gaps.
It'll
be
a
little
bit
more
brittle
in
terms
of
communication
force,
maybe
but
I
think
it'll
get
more
people
in
the
loop
and
have
a
better
time.
B
B
I
kicked
out
the
sig
meeting
several
times
and
it
was
really
hard.
It
was
just
hard
to
set
up
first
thing
on
a
Monday
morning
after
dropping
off
my
kid
at
school,
and
then
I
had
to
wait
until
nine
o'clock
exactly
and
then
so.
Basically,
for
the
first
several
weeks,
the
meeting
always
started
late
and
I
was
always
scrambling
for
the
key.
It
might
be
better
to
not
have
them
adjacent.
D
B
D
Was
that
wasn't
that
was
only
part
of
it,
but
also
I
do
not
like
Monday
meetings
so
I'm
going
to
+1
this
we
had.
We
had
a
poll
that
went
out
and
and
I
will
be
doing
another
poll
for
sig
release.
We
gotta
fold
that
one
out
and
somewhere
between
fifty
plus
of
you
voted
for
Monday
meetings,
early,
which
I
was
very
surprised
about.
So
I
set
the
meeting
for
Monday,
but
it
sounds
like
it's.
It's
not
the
greatest.
D
It's
less
bad
for
me
because
I'm
on
the
East
Coast,
but
the
West
Coast
is
usually
groggy
pants
during
this
meeting.
So
let's,
let's
let's
work
on
it
for
for
118
we
can.
We
can
move
the
meeting
so
leap
on
I'm
just
going
to
caution.
I
don't
want
to
get
in
the
habit
of
going
crazy
with
moving
our
meetings
too
much.
So
once
we
set
this
once
we
set
this
ole,
please
actually
vote
on
the
poll.
D
The
things
that
we
will
choose
will
be
something
that's
useful
for
that,
like
something
that's
convenient
for
the
sig
chairs
to
sit
to
be
at
so
we
can
actually
record
the
meeting
and
moderate
it
and,
and
second
it's
going
to
be
the
top
choice
that
people
choose
great.
So
so,
please,
when
that
poll
comes
out,
do
vote
on
the
poll
because
it
is
like
we
don't
we
don't
create,
simply
create
the
meetings
based
on
everyone's
feedback.
B
The
the
meeting
the
meeting
ID,
though,
has
nothing
to
do
with
the
account.
Unfortunately,
you
can
have
a
different
meeting
ID
and
still
take
the
pick.
The
other
meeting
out
that
was
that
was
that
was
the
real
problem.
I
was
like
I.
Have
my
own
meeting
link
what
is
even
happening,
but
because
it
is
the
same
zoom
account.
It
will
end
the
other
meeting.
D
That
is
so
I
think
that
was
something
that
we
were
hacking
on
living
you
Tim
and
I,
got
in
a
zoom
or
jumped
on
and
off
of
zooms
and
tried
different
things.
So
we
should
someone
should
document
this.
This
sounds
contribute
see
that
only
one
meeting
can
happen
at
a
time,
because
this
is
probably
useful
information
for
everyone
and.
C
E
A
N
C
G
D
Yeah
and
as
a
person
who
runs
a
sequester
lifecycle,
meeting
like
the
first
thing
I
had
to
do
is
make
sure
there
were
absolutely
no
conflicts
anywhere
near
the
meeting
in
the
calendar
before
we
said
it,
so
that's
yeah
I
think
it's
I
think
it's
really
just
I
yeah
I!
Guess
it's
being
more
organized
with
some
of
that
stuff,
but
I
think
we
have
like
so
few
conflicts,
but
we
can
do
a
bit.
E
B
Yeah
I
saw
that
a
lot
of
this
was
addressed
in
the
in
the
template
in
the
new
onboarding
template
for
release
needs
and
release
managers,
so
this
may
already
be
in
the
works
for
fix,
but
I
struggled
having
to
so.
It
was
just
kind
of
this,
like
so
cuz
I
set
up
calendar
permissions.
What's
the
calendar
called
where
do
I
find
the
calendar
who
doesn't
ride
if
this
calendar,
who
do
I
talk
to
okay,
it's
the
sig
leads
all
right.
They
have
to
enable
me.
Okay,
now,
I
have
to
learn
how
to
calendar
correctly.
B
D
B
That's
part
of
my
big
PR
I
added
zoom
and
challenger
links
as
part
of
basically
my
dog
said
schedule,
a
handlebar
meeting
with
the
previous
lead
and
the
sig
needs,
and
that
never
happened,
and
so
I
put
it
on
the
I
put
it
on
the
on
the
template,
like
okay,
part
of
it,
so
I
took
that
out
of
the
handbook,
basically
put
more
bright
flashers
on.
Do
the
template
make
sure
this
issue
is
filed
for
these
permissions
yeah.
D
And
so
part
of
the
template
was
also
like,
because
you
naturally
won't
have
permissions
for
some
of
these
things.
So,
by
having
the
template
and
by
having
an
issue
open,
it's
assigned
to
someone
who
might
write
and
they
can
they
can
go
through
the
check.
Listen
to
me
I
would
I
would
just
be.
Can
you
be
explicit?
I
know
it
said,
like
zoom
something
and
calendar
requirements.
Can
you
be
super
explicit
about
the
calendars
you
need
and
it's
really
just
a
release
Cal
so
making
sure
the
person
has
access
to
it.
I'm,
not
sure.
A
Of
the
things
that
we
tried
to
do
because
I
ran
into
these
issues
a
year
and
a
half
ago,
it
seems
like
it's.
It's
been
an
ongoing
issue,
but
we
try
to
initially
document
this
in
a
way
that
was
deliberately
just
referring
over
to
the
contributors,
but
I
think
that
what
you're
highlighting
win
is
that
that
was
the
wrong
approach,
because
that's
focused
on
sig,
chairs
and
rare,
where
this
is
a
regular
occurrence
and
somebody
who
is
not
a
sig
chair.
C
E
E
B
B
It
part
of
this
is
just
communicating
what
we
expect
and
part
of
the
issue
is
also
that
not
everything
that
goes
into
KK
is
necessarily
tied
to
an
enhancement
right.
So
it's
not
necessarily
something
that
we
as
a
teen
track,
but
it
I
definitely
came
across
a
thing.
That
was
an
enhancement,
and
somebody
told
me:
oh
it's
not
tied
to
a
milestone.
We
can
just
like
it's
fine,
we
just
do
it
whenever
and
not
just
like,
then
why
do
you
I
want
to
hand
I?
Don't
it's
so
nice.
C
B
It
was
but
these
are,
these
are
cultural
attitudes
in
the
project
that
I
wrote
down
here
for
sick
urbex
and
steering
to
realize
that
this
is
an
issue
about
the
release
team
deals
with
this
is
you
that
individual
contributors
deal
with?
This
is
an
issue
that
a
lot
of
people
encounter,
and
it's
not
really
for
us
to
fix.
So
this
is
a
no
op
for
us.
I
think
what.
B
D
A
D
B
B
D
Yeah
at
some
point
parents
did
a
and
Contra
backs,
did
a
sweep
of
that
mailing
list
to
make
sure
that
people
were
on
it.
There
was
also
the
the
the
chairs
need
to
know,
email
that
was
going
out
and
the
people
behind
the
community
alias
made
sure
to
explicitly
add
everyone,
as
like
their
individual
email
addresses
instead
of
the
group,
because
people
weren't
responding
to
the
individual
to
the
group
email
like
unless.
C
D
D
We
won't
approve
things
that
look
like
features
unless
there
is
some
crazy,
crazy,
good
reason,
and
even
even
then
Tim
is
like
our
Tim
has
been
our
master
gatekeeper
for
a
bunch
of
cycles,
just
putting
the
ban
hammer
down
on
on
features
that
that
have
been
disguised
as
bugs
sometimes
so.
I
think
I
think
that
we
have
a
bit
of
a
safety
valve
at
the
patch
relief
level,
but
we
do
need
to
make
sure
that
you
know
before
it
hits
post
zero,
that
there
are
some
gates.
E
E
B
Mostly,
it
says
it's
it
in
my
handbook,
up
until
the
PRI
opened,
that
I
should
expect
to
work
on
weekends
as
a
release
lead
and
while
I
want
to
make
the
choice
to
when
of
when
you
work
free
to
everyone.
Hey
I,
work
from
home,
I
set
my
own
hours
and
I,
don't
like
putting
that
wording
into
a
handbook
and
I,
don't
like
setting
the
example
of
working
on
a
weekend
which
is
partially
tie
it
to
my
request
to
move
the
release
meeting
to
a
Tuesday
and
also.
B
D
If
so,
I
would
I
would
love
if
you
have
an
opportunity
to
call
out
explicit
things
that
we
did
because,
like
I,
sometimes
poker
hook
around
at
things
on
on
the
weekend
or
late
nights,
I
don't
make
decisions
on
things,
though
so
like.
If
it's
something
that's
waiting
to
merge,
I
may
release
it,
but
if
it's,
it
won't
be
a
decision
made
without
the
group.
So
if
there
are
explicit
things
in
the
process
that.
D
Yeah,
that's
not
meant
to
that's
not
meant
to
tell
anyone
to
work
on
the
weekend
like
if
I
have
a
review
time.
I
will
sweep
the
repo
right
and
it,
and
it's
usually
it's
if
it's
usually
reviewing
content.
So
like
that,
for
my
side,
that's
gonna
keep
happening
because
that's
when
I
have
time
to
do
it,
but
I'll
also
like
don't
think
that
you
have
to
be
the
person
to
approve
it
right.
Just
because
you
get
tagged
for
the
approval.
B
Basically,
I
don't
know
if,
if
somebody
I
started
with
this
a
lot
working
on
the
west
coast
right,
because
if
somebody
on
the
East
Coast
meets
Monday
morning,
their
review
time,
that
does
mean
I
have
to
either
wake
up
really
early
or
start
working
on
Sunday
night
if
I
want
any
input.
So
this
might
not
be
a
release
process
related
thing,
but
it's
it's
yeah
I,
don't
get
to
it
until
my
day
starts
and
it's
over
it
done
and
I'm,
like.
Oh
I,
think.
D
Yeah,
so
there's
also
so
what
I
do
person,
because
I
I
feel
this
to
you
especially
like
if
we're
dealing
so
I
deal
with
a
lot
of
the
release,
engineering
people
who
are
working
on
PRS
in
immediate
time
and
then
hoping
to
get
things
moving
on,
maybe
the
test,
infrasonic
osteen
right
so
stuck
in
the
middle,
if
I
think
there's
something
that
I
should
explicitly
review.
I.
D
Think
a
few
of
you
have
seen
this
I
put
hold
for
my
review
on
the
PR
right
and-
and
that
means
that
means
at
some
point
like
this-
is
something
I
feel.
Maybe
some
feelings
about
and
want
to
review
it
and
usually
y'all
will
ping
me
and
go
like
hey.
Was
there
a
reason
you
held
this
like?
Are
we
ready
to
go
and
that
will
that
will
trigger
someone
going
back
and
maybe
me
taking
a
quick
sweep
of
this?
Yes,
this
has
been
adequately
reviewed.
Okay,
let's,
let's
merge
this
in,
like.
A
D
Well,
I
mean
well,
let's
I,
understand
what
you're
saying,
but
I
don't
think
things
are
just
flying
in
over
the
weekend
is
like
it's
not
happening
during
the
week
and
it's
like
it's,
the
I
think
it's
a
symptom
of
like
the
release
team
lead
having
to
deal
with
all
the
things
right.
So,
like
your
subscribe
to
all
the
things
you're,
looking
at
all
the
things,
I
yeah,
the.
B
B
D
E
All
right
folks,
we
are
about
two
minutes
now
over
our
regularly
scheduled
time
for
the
SEC
release
meeting
so
I
want
to
let
folks
know
if
anyone
needs
to
drop,
don't
feel
like
you
have
to
be
held
captive
on
this
call,
because
it's
going
long,
please
leave.
If
you
need
to
for
this
item,
do
we
feel?
Are
there
so
things
folks
want
to
say?
Or
do
we
want
to
move
on
to
figure
out
when
we
want
to
talk
about
what
we
will
do
differently
in
118
I.
B
G
Sorry
I
thought
you
were
gonna,
see
something
else
yeah,
so
actually
in
the
issue
that
I
put
it
that
I
put
up
in
the
notes
there
is
I
just
resumed.
Every
single
conversation
was
ready,
end
of
May
the
was
had
and
was
relating
in
any
way
to
go.
A
to
code
freeze
force
testing
for
the
quick
TLDR,
a
which
is
a
really
big
recommendation
from
the
people
from
the
people
working
on
testing
phrase
that
a
code
freeze
wouldn't
actually
be
a.
G
They
wouldn't
recommend
it.
They
wouldn't
recommend
at
this
freeze
every
single,
every
single,
every
single
tool
that
we
rely
for
for
CI,
for
testing
everything.
It
is
essentially
deployed
every
and
deployed
every
single
day
and
wholly
holding
changes
for
multiple
weeks.
It
will
possibly
introduce
really
complex
problems
whenever
the
cold
freeze
was
over
they
and
that
what
that
was
but
wait.
That
is
one
a
big
point.
The
other,
a
big
issue
that
they
brought
up
is
a
cover.
Nay,
this
is
only
one
consumer.
G
D
D
This
is
so
I.
Don't
think
we
were
ever
implying
that
we
should
freeze
all
of
tests
infra.
We
were
saying
that
changes
to
the
things
that
can
affect
a
relief
kubernetes
release
should
be
considered
strongly
right
before
before
making
that
change
the.
If
we
cannot,
if
we
cannot
like
distill
that
down
to
a
few
changes,
what
that
could
be
I,
don't
think
this
would
ever
happen,
but
because
you're
right
there
are
more
like
kubernetes
is
not
the
only
consumer
proud,
so
asking
them
to
freeze
things.
D
L
D
D
If
someone
is
interested
in
doing
this,
make
make
it
tighter
right
give
them
give
them
things
that
we
we
don't
want
them
doing
like
changing,
release
branched
out
right,
like
right,
I'm,
saying
like
I'm
saying,
like
you
know,
tighten
tighten
the
scope
of
this
doesn't
say
like
don't
make
any
changes
and
test
in
for
it,
because
that
that's
not
reasonable
right,
tighten
the
scope
and
say
like
these
changes.
These
changes
can
affect
our
release
process
in
the
following
ways.
We
would
like
to
would
like
to
see
if
it's
possible
and
I
think
it's
you
know.
D
G
Will
that
actually
be
reasonable
to
your
aid
of
it,
for
example,
to
a
testing
traffic
I?
Don't
know
what
to
call
it.
A
I've
been
a
I
was
using
testing
for
very
deliberately
but
a
free
from
the
release
branch
jobs,
because
if
I,
if
I
get
an
issue,
if
I
get
an
issue
happens
or
something
of
the
sort
for
what
a
for
whatever
reason,
you
know,
for
example,
a
couple
I
don't
know.
If
this
was
this
release
or
a
couple
releases
ago,
the
people
from
closer
API
that
were
working
on
the
Google
provider,
essentially.
L
G
Yeah
they
they
broke
all
of
way
all
of
GCP
and
that
that
affected
the
taste
testing
in
between
coats.
If
something
of
that
sort
happens,
we
will,
we
could
possibly
be
getting
a
different
signal
from
just
the
released
jobs.
I
asked
as
compared
to
every
single
a
as
compared
to
a
continuous
intense
grid,
and
it
will
make
it
a
little
bit
more
complicated
to
actually
be
able
to
the
ballgame
come
back
to
testing
furnace
for
help.
N
G
And
on
the,
on
the
other
hand,
if
you,
if
we
just
continue
with
and
again
sorry
for
the
buzzword,
but
it's
a
first
thing
that
comes
to
mind
if
we
continue
working
with
testing
friendo
and
do
everything
more
devops
ish,
like
you
know
they
test,
everything
will
equate
that's
tested
in
production.
If
we
see
something
funny,
then
let's
roll
it
back.
The
more
see
the
more
signal
that
we
have,
the
more
the
more
things
that
we
can
break
the
faster
that
we
can
actually
a
look
of
a
look
and
look
into
issues.
Yeah.
D
So
if
you
want
to
see
an
issue
like
that,
you
can
check
that
out.
So
it's
like
we
just
have
to
be
aware
that,
like
changes
to
the
system
can
potentially
be
devastating-
and
this
was
this
was
down
to
essentially
the
way
of
get
described,
works
and
and
reg
exes,
of
course,
so
I
I'm,
not
this
is
tricky
there
there's
so
many
things
that
are
involved
in
the
system
that
aren't
in
any
way
isolated.
D
G
B
G
Is
it
sorry,
sorry
for
interrupting,
really
quick
question?
He
said
by
any
chance
the
issue
that
you're
talking
about
the
one
about
running
and
to
end
tests
on
non-synthetic
clusters?
Yes,
okay,
so
in
that
case,
I
got
the
one
and
okay
so
world
courts.
Thank
you
thank
you
and
on
the
most
wall
for
changing
the
title.
So
next
one
improving
million
times
for
nine
u.s.
time
zones
sounds
good
and
actually
started.
The
conversation
already
with
a
with
the
118
leads,
so
hopefully
more
things
to
come
in
there.
J
G
Is
interested
on
hearing
a
long
ramble
on
this
one
but
Alena
and
I.
We
were
discussing
this
and
we
were
hoping
to
bring
it
up
with
Niklaus
and
the
rest
of
the
release
team
and
by
the
end
of
the
day,
there
should
be
an
issue
with
more
details
on
this.
So
next
one
no
need
to
add
a
scalability
like
liaison
role
to
the
release
team,
Stephen
a
kind
of
make
sense,
a
communication.
What
her
communication
was
good
and
need
more
discussion
between
liberals
who
use
spreadsheets
to
work
together
on
ways
to
improve
tools.
G
Automation,
I
love
this
one.
Thank
you
very
much
for
adding
it
turn
the
role
handbooks
and
process
synchronization
play.
Also,
if
someone
has
anything
to
say,
please
just
interrupt
me
yeah,
so
Thunderball
handbooks
and
processing
Crenn
ization
points
to
shift
more
courier
release
workshop
master
at
4:00
p.m.
Pacific
put
more
finish
them.
D
G
G
G
Moving
on
the
next
one
determine
what
communications
see
a
signal
report
coming
from
Alvina
a
pod
can
be
informal,
a
synchronous
and
which
need
to
be
more
formal
reports
and
what
frequency
I
think
this
got
a
little
bit
from
both
between
the
two
of
us
but
related
to
them
related
to
a
previous
communication
of,
say,
signal
reports.
So
moving
on
to
the
next
one
aim
for
a
more
efficient,
withdraw
meeting
time
box
discussion
very
pragmatically,
allow
it
to
continue
or
agree
to
move
it
to
move
it
onto
an
issue.
L
D
Yeah
so
I
mean
we
did
a
lot
of
discussion
post
retro
we
had
several
retros
of
retros.
I
spoke
to
some
of
the
people
who
were
on
the
retro
as
bystanders
I
had
a
long
conversation
with
Quinn
about
the
stuff
as
well,
and
then,
by
that
time,
I
was
gonna,
have
a
conversation
with
Tim
and
Tim
was
like
I'm
sitting,
one
more
email
and
I'm
out
of
the
door,
so
I
think.
Overall,
there
is
a.
D
There
is
kind
of
a
balance
that
we
have
to
strike
in
these.
My
personal
feeling
is
that
when
we
talk
about
something,
this
dock
is
essentially
what
the
emeritus
adviser
will
be
using
and
what
the
people
who
are
tagged
on
the
dock
will
be
using
to
scrape
together
notes
to
understand
what
they
need
to
do.
Next,
improve
I
think
that
we
we
owe
it
to
them
to
make
sure
that
those
notes
are
as
complete
as
possible
right
so
I
have
a
bit
of
a
problem
with
cutting
off
a
topic
too.
D
D
Like
I
noticed
in
the
first
session,
we
were
moving
things
down
lower
in
the
dock
to
talk
about
later
and
I'm
like
we're
talking
about
it
now,
we
should
just
finish
talking
about
it
and
then,
and
then
like
be
done
with
it,
give
people
enough
context
to
write
that
issue
if
they
need
to.
But
in
addition
to
that,
the
there
was
a
feeling
there's
a
feeling
that
we
were
not
able
to
so
so
one
to
make
the
register
more
efficient,
we're
talking
about
spending
less
time
on
the
individual
items
for
the
retro.
D
But
at
the
same
time
there
is
a
another
issue
about
giving
making
sure
that
shadows
have
the
space
to
to
provide
feedback
on
during
the
retro
right,
and
sometimes
that
may
mean
the
more
senior
people
like
myself,
shutting
up
right,
saying
less
words
to
give
them
that
space
and
the
you
know
this.
That
was
kind
of
led
to
the
issue
that
you
know
that
was
opened
around
having
a
separate
shadow
retrospective
right,
I
I
go
in
and
I
were
talking
about.
This
and
I
was
like
I
personally
hate.
D
This
idea,
the
I'm,
a
sorry
hate
is
a
very
very
strong
word,
don't
mean
hate,
I,
think
that
having
a
separate
retrospective
divides
the
audiences
right.
The
whole
idea
of
the
retrospective
is
to
be
open
and
inclusive
and
allow
people
to
share
their
opinions,
and
that's
one
of
the
many
reasons
that
we
hold
it
at
the
community
meeting.
So
everyone
can
feel
like
they
can
get
involved
in
this
right.
D
We
need
to
do
separate
work
to
make
sure
that
shadows
feel
like
they
can
provide
that
voice
during
these
meetings
right
and
that
should
be
happening
throughout
the
cycle.
I
think
that
that's
something
that
you
know
as
I
think
when
you
already
put
this
on
the
issue,
but
that's
something
that
we
could
have
so
the
the
Meredith's
advisors
and
I
were
talking
about
having
more
frequent
touch
points
throughout
the
cycle,
with
shadows
to
make
sure
that
they
feel
like
they
have
the
tools
that
they
need
to
to
succeed.
Right.
B
We
communicate
about
waiting
times
and
make
it
possible
for
people
to
communicate,
not
just
personally
not
just
by
opening
their
mouths,
but
also
by
writing
things
down
somewhere
or
responding
to
a
poll
or
asking
somebody
in
private
different
will
communicate
in
different
ways.
We
want
to
have
different
venues
for
people
to
be
heard
overall.
My
comment
about
the
the
retro
being
more
efficient
was
a
matter
of
degree
and
a
matter
of
takes
up
the
most
speaking
time.
D
So
this
was
kind
of
the
idea
behind
the
Clare
Clare,
locky
and
I
were
chatting
about
this
and
we're
like
okay
well,
who
should
run
threat,
show,
and
we
were
we
were
saying
like
okay.
Well,
maybe
the
Emeritus
advisor
puts
together
a
set
of
candidates
or
something
and
then
you're
like
wait.
Maybe
the
Emeritus
advisor
should
be
the
retro
moderator
a
first
resort,
because
they
have
a
lot
of
the
context
that
they're
talking
about
in
these
issues.
D
So
when
it
looks
like
like
we're
about
to
say
the
same
thing
four
times
they're
like
wait,
we
know
about
this
issue.
It's
documented
already
like.
Let's,
let's
see,
look
like,
let's
move
on
to
the
next
one
I
think
they
would
have
the
appropriate
context
to
do
that,
and
something
of
that
form
is
already
being
documented
for
the
update
of
the
EI
handbook.
D
I
think
Clare
has
done
a
second
revision
of
it,
so
I'm
going
to
do
another
pass
on
that
and
get
that
version
to
your
previous
point
about
people
communicating
different
ways
and
that's
a
super
super
good
point.
What
if
we
allowed
people
to
also
submit
some
sort
of
anonymous
feedback?
As
items
for
the
retro
doc
right,
if
there's
something
you
feel
like
you
could
fix,
then
you
don't
want
to
put
your
name
on
it.
D
D
D
G
Couple
quick
comments
on
on
all
that.
Also
a
troll,
a
troll
in
the
mouth
there
for
a
a
for
I
want
a
I
want
to
get
a
different
wave
different
point
of
views
so
for
the
people
on
the
point
of
people,
communicate
a
people
communicate
differently
and
all
that,
and
also
really
related
to
the
conversation
that
we
had
a
little
a
little
earlier.
G
Bringing
code
slash
back
or
something
of
the
sort,
one
of
a
one
of
the
things
I
was
thinking
that
it
might
be
really
useful,
is,
for
a
part,
a
advertiser
retrospective
little
bit
more
sort
of
a
advertiser
retrospective.
At
least
you
know
once
every
week
for
a
once
every
day,
once
every
two
weeks
make
sure,
let
me
make
sure
that
people
are
getting
in
there.
G
L
G
We
should
really
strive
for
I
think
is
having
the
retrospective
read
like
with
like
a
story.
For
example,
if
you
try
to
go
back
to
about
it
with
a
retrospective
from
114,
a
ghost
Lodge
it's
mentioned
once,
and
there
is
just
a
we
got
rid
of
cosmos.
There
is
a.
There
is
very
little
context.
You
actually
have
the
I
actually
have
to
go
through
a
couple
issues
through
the
113
retrospective
to
get
a
little
bit
a
of
a
better
idea
with
having
issues
and
getting
there.
G
Why,
instead
of
the
what
we're
gonna
do
it
I
would
be.
That
will
also
be
a
really
cool
and
awesome,
also
with
a
really
quick
comment
on
the
other
thing,
for
the
shadow
retrospective
thing
that
I
do
out
there,
so
the
big
idea
and
I
should
probably
work
on
the
boarding
is
not
to
separate
the
shadows
from
the
leads
and
just
to
a
they
say.
The
shadow
retrospectively
thing
that
our
a
the
thing
that
I
was
the
thing
that
I
was
thinking
is
to
have
one
retrospective
just
be
about
the
shadowing
experience.
G
If
you
know
for
if,
for
example,
a
lot
of
a
lot
of
the
issues
that
we
have
discussed
in
the
previous
to
a
release-
art
a
CI-
how
to
manage
dogs,
how
to
merge
those
things,
but
you
know,
can
I
give
another
platform
for
people
to
say.
I
was
doing
release
notes
in
I.
I
have
no
idea
what
was
happening
like
who
shall
I
ask
push
you
like
contact.
G
What
documents
relate
with
and
just
have
a
just
it
just
kind
of
gathered
like
a
lot
of
information
that
might
be
useful
for
a
for
shadows
to
learn
how
to
how
to
do
the
role,
how
to
be
part
of
the
community
and
also
to
get
together
together
a
lot
of
information
for
leads.
You
know,
because,
besides
being
able
the
digital
age
your
job
for
being
elite,
you
also
have
to
be
a
relatively
good
at
mentoring,
mentoring,
others
in
a
mentoring
and
doing
a
mentoring
and
doing
your
job
are
not
necessarily
the
same
skills.
D
So
this
is
kind
of
what
I
were
trying
to
leave
you
with
these
touch
point
meetings,
doing
more
touch
point
meetings
throughout
the
cycle
having
you
know
having,
and
that
would
be
more
team
feels
but
I'm
wondering
if
it's
valuable
to
do
is
try
to
isolate
the
items
that
are
on
the
retrospective
dock,
because,
like
between
between
this
and
the
current
way,
we
run
it.
Do
we
need
to
change
the
way
where
you
run.
It
doesn't
need
to
be
a
longer
meeting.
The
initial
one
needs
to
be
a
longer
meeting
like
if
we're
like.
D
If
we're
saying
we're
going
to
more
widely
publicize,
it
I
guess
like
I,
imagine,
there's
going
to
be
an
influx
of
more
things
that
will
pop
up
on
this
dock.
So
we
need
to
be
cautious
of
that
too,
because
we're
already
feeling
like
we
don't
have
the
space
to
do
it
and
we're
breaking
it
up
into
multiple
meetings.
So
we
have
to
be
cautious
about
the
way
we
move.
I
think
that
if
we
were
to
try
and
and
separate
out
what
is
a
team
issue
alright
or
what
is
it
like
a
section
issue?
D
What
is
something
that
is
contained
within
the
release
team
and
use
the
time
that
we
have,
for
these
touch,
point
meetings
to
focus
on
that
stuff
and
trying
to
figure
out
what
is
something
that
is
a
broad
retrospective
item
for
the
community?
It's
process
improvement.
It's
you
know
it's!
It's
a
process,
improvement
yeah!
If
we
focused
on
those
during
the
retrospective
I,
think
that
we
would
we
would
move
faster.
D
A
G
That
I
was
having
you
know
it
may
be,
it
may
be
separating
the
topics,
it's
something
that
we
can
and
that
we
can
have
multiple,
that
we
should
definitely
have
multiple,
a
multiple
opinions
for,
for
what
topics
do
we
discuss?
What
topic?
Do
we
just
mention
and
make
sure
to
create
to
open
up
an
issue?
It's
a
community
community-wide
projects
or
even
released
new
projects,
issues
or
even
release
team
issues.
So
definitely
we
should
definitely
I.
G
Think
she'll
definitely
be
this
concern
in
retrospective
put
some
other
things
that
might
be
a
little
bit
more
game
center
might
might
be
useful
to
this
cause
every
now
and
then
because
for
some
a
you
know,
maybe
if
we,
if
we
get
really
good
at
division,
maybe
the
other
teams
are
not
a
word
that
there's
there's
a
certain
bit
of
information
or
they
certain
a
type
of
process
that
they
can,
that
they
can
use,
they
can
rely
or
take
a
they
can
acquire
for.
So
a
for
some
other
reason.
D
So
yeah
so
well,
what
was
going
on
in
my
head
is
like
if
we
did
a
separate
retrospective,
what
if
we
did
that
team
centric
one
first
right
and
then
led
into
the
community-wide
one,
my
god,
both
of
them
are
still
recorded.
You
know,
but
the
the
team
centric
one
would
happen.
Maybe
on
the
release
team
meeting
slot
or
the
sig
release
slot
right
and
then
we
would
move
to
the
community
slot
to
round
out
the
community-wide
topics.
L
J
D
Will
I
locky
some
stuff
lucky?
There's
me
some
stuff
I
think
one
of
the
things
is
collating
the
items
and
the
retrospective
buck
and
turning
this
into
a
set
of
a
eyes
on
github,
and
then
we
can.
We
can
start
linking
that
stuff
back,
but
yeah
we've
got
I
would
like
to
say
we
have
time
as
we're
going
into
you.
D
H
N
G
D
So
the
so
just
to
clarify
and
I'll
clarify
in
your
review
as
well
when
the
the
proposal
is
not
to
do
the
release
on
Tuesday.
The
proposal
was
to
do
the
release,
not
on
Monday,
that
that's
it
right
so
so,
like
you're,
free,
diffused,
yeah
you're
free
to
choose
the
day,
just
make
sure
that
if
it's,
if
it's
Monday,
then
people
shift
their
schedule.
You
know
people
start
trending
towards
the
weekend,
so
to
prep
for
it
so
yeah,
it's
just
not
Monday
was
the
only
thing.
I
was
suggesting
sure.
D
I
want
to
make
sure
that
so
I'm
I'm
thinking
right
now,
who
has
to
do
stuff
I,
might
start
expanding
the
the
writes
on
the
repo
so
that
more
people
have
write
access.
But
Tim
will
talk
about
that
because,
right
now
the
person
who
creates
the
issue
is
the
person
who
gets
to
edit
the
description.
That's
why
I
want
Lockheed
open
it.
So
if
we,
if
we
change
what
the
so
by
default,
if
you
open
an
issue,
you.
D
Right
or
or
a
repo
admin
or
someone
with
I,
don't
know
if
it's
right
or
admin
access,
I
think
it's
right.
Access
has
access
to
edit.
The
issue
right,
so
I
just
want
to
make
sure
like
I
can
edit
it
just
fine,
but
but
you
know,
if
I
create
the
issue
or
you
create
the
issue.
Lucky
won't
necessarily
be
able
to
touch
it
right.
So
I
want
okay.
D
B
L
D
A
Was
a
weak
implementation
detail
I
think
that
we're
not
stating
there
is
that
we
often
do
a
bullet
list
in
the
description
of
the
issue.
So
for
somebody
to
go
in
and
edit
the
description
and
mark
the
checkbox
in
that
bullet
list
is
complete.
They
have
to
have
edit
pros,
which
means
they
have
to
have
opened
it.
Not
somebody
else.
I.
D
The
emeritus
adviser
for
118,
so
he's
going
to
be
so
we're
okay,
okay,
so
I
think
the
additional
context
that
you're
missing
is
the
emeritus
advisors
and
I
had
a
chat.
Last
two
Fridays
ago
at
this
point
about
the
expanding
the
the
purview
of
the
emeritus
advisor
role,
to
include
making
sure
that
we
actually
do
the
things
that
we
said
we're
gonna
do
in
the
previous
retro,
okay,.
B
D
A
D
All
right
well,
thank
you
all
for
hanging
out
for
extra
time
to
make
sure
that
we
got
through
this
I
actually
really
appreciate
not
having
to
put
any
additional
items
to
yet
another
meeting
as
we
move
into
the
holidays.
Yeah
awesome
job.
What's
left
of
the
team
now
for
117,
thank
you
for
all
that
you
do
and
just
helping
us
out
not
just
on
the
team
but
being
good
humans
seriously.