►
From YouTube: 2021-12-09 Enablement Retrospectives 14.5
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
Let's
give
it
one
more
minute
to
maybe
some
others
will
be
able
to
okay.
A
Okay,
let's
get
started,
no
craig
won't
be
able
to
join
us
today.
So
hello,
everyone
today
is
december
9th.
This
is
a
enablement
14.5
release
retrospective
and
first
of
all
notice.
The
negatives
back
to
his
yoga
place.
So
welcome
back.
A
Okay,
let's
get
started
we'll
start
from
the
actions
follow-up,
so
craig
is
not
here,
but
I
will
verbalize
his
action
item.
There
was
one
for
him
suggestion
that
try
an
earlier
time
to
see
if
we
can
get
non-management
participation.
Yes,
so
I
actually.
I
should
paste
my
comments
here.
A
I
forgot
to
adjust
this
in
this
this
instance,
but
actually
I
made
a
one-off
change
for
the
january
retro
pushed
out
to
the
13th
because
of
the
holiday
and
also
moved
up
to
the
8
a.m:
pst
or
4
p.m.
Utc,
we'll
see
how
that
works,
and
then,
depending
how
that
works,
we
may
alternate
the
the
time
to
accommodate
the
difference
of
time
zones.
So
that's
what
where
I
I'm
thinking.
A
So
that's
the
item
crossed
out
and
the
next
one
was
me
and
just
a
blog
poster
for
the
db
migration
tools.
Why
is
red?
Yes
g8?
So
it's
not
yet
yet.
So
we
will
keep
this
but
alex.
Are
you
okay
to
carry
this
on.
A
D
A
B
Sure
I
wasn't
sure
if
this
comment
up
here
was
something
from
alex,
but
I
can
go
yeah.
I
think
participation
was
a
little
better
this
time
around,
but
still
pretty
light.
B
We,
we
did
hold
a
mini
retro,
so
I
just
opened
a
separate
issue
when
we
closed
our
single
command,
single
promotion
command,
epic-
and
I
thought
that
yielded
some,
some
pretty
valuable
insights
and
I
think
in
general,
remembering
to
hold
these
many
retros
and
and
rcas
when
signific
like
right
after
significant
work
is
closed,
so
prompting
discussion
around
the
specific
work
can
generate
more
participation
than
asking
for
general
feedback
about
the
milestones.
B
So
it's
one
of
those
things
that
that
it's
valuable
but
have
to
remember
to
do
it
when
when
the
time
is
bright,
so
I
think
we'll
keep
trying
that
see
how
that
goes.
C
For
us,
I
feel,
like
we
got
kind
of
a
late
start
on
our
retrospective
overhaul,
so
I
I
think
that
maybe
made
it
a
little
bit
lighter
than
it
otherwise
would
be,
but
we
actually
already
have
comments
coming
in
on
the
14
6
retro.
So
I
I
think,
we'll
have
more
stuff
more
participation
in
that
one.
I
hope.
A
That's
cool
okay,
steven
and
dj
on
the
item.
You
have.
E
Yeah,
so
what
we,
what
we
didn't
do
here,
is
we
didn't
log
an
issue
to
follow
up
on
this,
so
that's
something
I'll
take
on
and
go
ahead
and
do,
but
even
without
that,
we
did
make
some
related
progress,
this
release,
so
the
team
had
in
the
same
vein
to
document
and
technical
requirements.
We
did
add
an
issue
template
to
our
team
tasks
that
really
outlines
what
we're
looking
for
when
we're
making
those
technical
decisions
which
will
feed
into
then
documenting
them.
E
The
piece
we're
missing
is
still
the
process
for
like
where
and
how
to
document
them
once
we've
made
those
decisions,
but
we
are,
we
are
in
a
better
place
for
that
and
I'll
I'll,
add
I'll,
add
open
an
issue
for
this,
so
we
can
get.
This
worked
on
closed
out.
A
Great
cool,
okay:
we
have
many
items
checked
off.
So,
let's
move
on
to
to
what
went
well,
let's
just
go
around.
I
was
verbalized
for
craig's
items,
dj
with
you
or
yeah.
E
Yeah,
so
for
what
went
well
with
the
build
distribution
team,
so
this
in
14
5,
we
were
able
to
quickly
validate
that
our
existing
packages
for
fortune
5
were
going
to
work
well
on
alma
linux.
There
was
a
lot
of
you
know,
communication
and
investigation
around
this,
but
that
took
a
little
bit
of
time,
but
when
it
came
to
the
you
know,
when
we
came
to
a
decision
of
what
we
wanted
to
validate,
the
validation
went
very
quickly,
and
that
allowed
us
to
also
include
support
for
this.
E
A
little
earlier
than
anticipated,
we
had
anticipated
that
14
5
would
have
been,
would
be
like
a
beta
support
for
this,
but
we,
the
the
validation
we
managed
to
get
early
enough
to
say
that
you
know
14.5
was
was
the
you
know,
full
ga
support
for
it,
so
that
went
well
and
over
to
you
alex.
C
Yeah
one
of
our
our
big
win
for
the
last
milestone,
which,
in
general,
our
the
team
kind
of
agreed
that
last
milestone
was
just
like
really
good
for
us,
but
our
big
win
was
a
overall
like
very
impactful
on
the
size
of
the
database.
We
managed
to
reduce
the
total
size
by
two
terabytes,
and
this
was
through
a
combination
of
a
few
different
things.
A
big,
a
large
part
of
that
was
the
the
the
final
implementations
for
the
time:
decay
retention
strategy
for
the
web
hook.
C
Log
partitions
and
we've
finally
started
expiring
that
data,
so
that's
pretty
exciting.
We
also
did
some
other
clean
that
some
some
bloat
reduction,
so
that
was
that
was
exciting
too.
A
Okay,
next
one
thank
you.
Thank
you
next,
one
from
craig,
so
a
great
engagement
from
the
release
on
our
raw
plan
of
the
working
conversation
project
and
from
dylan.
The
comment
is:
this
is
going
to
be
key
to
identifying
blockers
or
conflicting
work
early
and
shipping
on
time,
I'm
seeing
great
questions
and
it
shows
that
people
are
understanding
how
the
plan
will
impact
the
other
teams.
So
that's
a
great
progress
over
to
you
cc.
D
Yeah
for
the
global
search
team,
the
team
made
a
great
improvement
on
search
performance
through
a
series
of
actions
for
the
memory
team.
We
were
able
to
make
good
progress
on
both
redis
and
also
the
psychic
matrix
excitation.
E
B
So
for
geo,
one
comment
from
douglas
about
the
single
promotion
command
work,
validating
the
command
with
get
the
lab
environment
toolkit
against
our
reference.
Architectures
gave
us
confidence
to
release
the
new
command.
In
addition,
we
could
find
and
fix
minor
issues
that
would
be
hard
to
find
out
if
we
didn't
have
this
tool
in
place
to
more
easily
test
on
different
architectures
and
then
a
comment
from
ocuti.
A
Cool
okay:
let's
move
on
to
what
didn't
go!
Well,
so
stephen,
starting
with
you
as
a
first
item.
F
What
didn't
go?
Well,
I
think
I
alluded
to
this
on
our
staff
meeting
earlier.
The
kubernetes
122
support
start
sort
of
ballooned
as
the
further
we
got
into
it,
and
then
it
was
one
that
we
ended
up,
not
completing
in
the
previous
release
and
we
pushed
it
into
current
release,
we're
still
actually
working
on
it.
Getting
the
last
pieces
aligned.
There
were
several
like
large
changes
that
needed
to
happen.
F
We've
got
most
of
that
ready
to
go
so
it
should
land
in
this
release,
but
it
did
have
to
get
pushed
into
this
release.
So
that's
that's
basically
it
the
crux
of
it.
There.
F
Yeah
I
spoke
with
dylan
about
it.
119
I
believe,
is
going
to
be
our
our.
You
know,
low
point
for
version
wise,
and
so
it's
mainly
like
open
shift
the
new
version
of
openshift.
If
we
want
to
get
certified
on
there,
opengif49
supports
kubernetes
one
two
two
and
so
for
us
to
be
certified
and
on
the
the
the
marketplace
we
have
to
be
able
to
support
that.
That's
that's
been
the
big
push
I
think
123.
F
I
talked
to
jason.
It
looks
like
it.
Changes
between
122
and
123
are
much.
You
know
very
minor
compared
to
getting
to
122.
and
so
we're
suspecting
that
it'll
be
a
light
lift.
Once
we
get
everything
working
on
122.
cool.
E
Yeah
so
another
thing
that
didn't
go
well
in
distribution
was
we
in
fourteen
five
did
not
ship
a
mattermost
update,
so
typically,
we
bring
in
a
new
mattermost
feature,
update
with
every
gitlab
feature
update
every
every
month.
This
previous
release,
the
mattermost
update,
was
large
they're
moving
to
a
new
major
version
and
the
that
involves
a
lot
of
extra
steps
and
the
you
know
even
the
starting
point
to
that
came
in
basically
too
late
to
make
it
in
to
the
release.
E
A
No,
no
for
me
any
questions:
okay,
I'll
verbalize,
a
quick
item,
so
the
phase
three
of
the
decomposition
deployment
actually
took
longer
than
anticipated
and
resulting
in
one
milestone
sleep
in
our
timeline.
So
the
whole
project
now
is
one
milestone
or
one
behind
the
schedule.
A
Any
any
questions.
D
So
for
the
global
search,
there
was
one
time
that
our
air
budget
dropped
to
15
overall
availability,
even
though
it
turned
out
it's
not
because
of
us.
It
was
because
some
exception
in
the
aerobatic
framework
change.
It
reminded
us
that
we
didn't
have
a
good
knowledge
of
how
the
error
budget
was
calculated.
A
D
B
Yeah
we
ran
into
some
unexpected
test
failures
after
the
mr
to
enable
secondary
proxy
was
merged
to
master,
requiring
the
mr
to
be
reverted
and
and
the
flaky
tests
addressed,
and
that
was
after
already
addressing
some
kind
of
flaky
tests
in
in
the
mr
itself
and
and
thinking
it
was
okay
to
merge
and
then
and
then
discovering
some
other
issues
after
it
actually
was
merged,
so
caused
the
feature
to
slip
14-5.
But
we're
back
on
track
to
to
announce
it
in
6..
F
Yeah,
similar
in
theme
to
our
previous
one,
the
kubernetes
122
upgrade,
has
really
shown
us
that
we've
got
a
lot
of
manual
testing
happening
to
validate
things,
and
so
one
of
the
things
that
we'd
like
to
do
is
you
know,
rely
less
on
manual
testing
and
get
more
more.
Automated
coverage
happening
for
these
common
upgrades
that
we
need
to
do.
A
So
do
we
what's
our
plan?
Is
there
an
issue
to
track
this,
and
is
there
any
discussion
with
the
qe
to
you
know
to
run
up
here?
I
believe.
F
A
E
Yeah,
so
one
of
the
other
things
we've
identified
for
improvement
is
related
to
providing
updated
packages
for
new
versions
of
distributions.
So
you
know,
one
of
the
things
we've
identified
is
that
you
know,
as
a
new
new
version
comes
out.
Typically,
that
also
is
signaling
that
there's
going
to
be
a
version
that
we're
currently
supporting
that's
going
to
reach
its
end
of
life
and
that
we
really
need
to
prioritize
and
shrink.
E
There's
overlap
between
those
two
versions
with
git
labs
packages,
meaning
that
there's
a
period
of
time
in
which
we're
providing
packages
for
both
the
old
version,
new
version,
so
that
our
users
have
you
know
the
best
opportunity
to
upgrade.
A
Okay,
oh
verbalized
craig's
coming
here,
so
tightening
up
the
feedback
loop
with
our
infra
partners.
A
Actually
the
bystander
effect
was
observed
while
deploying
the
phase
three
changes,
so
it
cost
us
some
time
there,
but
we
already
have
a
plan
going
forward
for
faster
feedback.
So
the
plan
was
getting
a
closer
interaction
with
all
the
stakeholders
and
also
we
just
established
a
stand
up
with
with
the
major
stakeholders
on
the
decomposition
project.
So
we
have
a
mitigation
plan
here.
A
Okay,
cece.
D
So
terry
mentioned
that
in
the
retrospective
issue-
and
there
is
a
link
to
the
issue
that
we
closed
during
that
release
and
but
that
link
is
only
pointing
to
the
gitlab
org
group
so
for
our
team
in
the
you
know,
14.5
release.
We
also
worked
on
some
of
the
change
requests
on
the
elasticsearch
infrastructure
set,
which
we
took
under
the
github
com
user
group.
D
A
Yeah
so
move
rubik's
rear,
okay,
so
the
ruby
rubic
upgraded.
Maybe
you
also
need
to
follow
up
with
the
distribution
team
to
make
sure
you're
coordinated.
D
B
Yeah
this
one
came
from
fabian
from
the
product
perspective
when
defining
the
single
command
epic.
He
had
created
a
large
number
of
small
issues
and
it
ended
up
not
being
necessary
to
really
have
all
those
issues
because
they
ended
up
being
closed.
A
bunch
of
them
ended
up
being
closed
with
by
douglas
with
a
single
or
just
a
couple.
B
Mrs,
so
you
said,
you
learned
that
it
makes
much
more
sense
to
start
epics
with
a
small
number
of
issues
that
are
well
defined
and
coordinated
with
the
engineering
team
and
then
we'll
always
open
up
more
when
needed
and
that's
more
efficient,
and
I
think
that
is
is
a
also
something
I
guess
kind
of
goes
along
with
improving
on
iteration
and
and
looking
at
mvcs
and
not
trying
to
over
plan
in
epics.
B
So
definitely
something
we'll
we'll
keep
in
mind
for
breaking
down
future
epics
and
then
the
the
next
item,
something
that
akiti
commented
on
as
she's
was
using
rolling
out
feature
flags
she's,
noticing
that
since
it's
just
one
feature
flag,
rollout
issue
template
that
covers
both
enabling
and
removing
the
feature
flag,
she
was
kind
of
having
to
do
some.
B
Weird
stuff
to
to
work
around
it
if
she
wanted
to
track
it
over
two
milestones,
so
she
was
creating
two
issues
from
the
same
template
and
then
one
for
enabling
and
one
for
removing
the
feature
flag.
So
it's
kind
of
a
small
annoyance,
but
we're
just
want
to
get
some
feedback
on
if
there
are
any
better
ways
to
to
track
the
feature
flag,
rollout
across
two
milestones
without
needing
to
to
carry
over
the
same
issue
or
kind
of
clone
the
template.
So
if
suggestions.
B
They
would
be
probably
have
a
pretty
wide
ranging
effect,
so
I
think
it
would
be
a
good
thing
to
get
if
there
are
any
suggestions
for
this
from
the
team
or
others
get
some
input
across
development.
B
There
are
a
couple
of
people
I
can
think
of
already
who
have
taken
a
particular
interest
in
rollout
type
of
processes.
Like
michelle
gill
comes
to
mind,
I
think
she
had
made
an
update
to
the
handbook
page,
so
I
think
I'll
put
it
as
an
action
item
to
follow
up
with
the
team
for
for
ideas,
but
also
follow
up
with
michelle,
and
maybe
anyone
else
who's
been
involved
in
roll
out
discussions,
roll
up
process
discussions.
A
So
we
are
going
pretty
well
and
it's
already
end
of
the
the
agenda
and
no
questions
looks
like
we
had
a
very
nice
release
across
some
pickups
but
identified
how
we
improve,
and
I
summarized
the
several
action
items
for
for
next
retro.
So
cd,
you
have
one
suggestion
there.
Please
make
an
improvement
to
the
template
I'll
link
to
the
template
here.
So
just
make
an
imr
to
improve
the
template,
and
I
have
a
item
that
just
a
reminder
to
all
the
managers.
A
Please
afford
the
invite
to
your
team
members.
Yes,
I
didn't
expose
everybody
and
you
hadn't
even
have
all
the
yens
to
follow
that.
So
please
go
ahead
if
you
haven't
afford
it
yet
and
summarize
steven
from
the
improvement
proposals.
So
let's
check
the
operator,
testing
automation
and
get
it.
B
A
Sounds
good,
okay,
that's
the
end
of
our
retro
for
14.5
and
the
meters
here
mitch.
You
are,
you
have
something
to
say,
welcome.
A
A
Thanks
for
attending
okay,
that's
all
for
the
14.5
enjoy
the
rest
of
your
day.
Everyone.