►
From YouTube: 2020 07 23 Database Team Retro
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
All
right,
thanks
for
joining
this
is
the
database
team
decided
that
at
the
end
of
each
milestone,
we
wanted
to
do
a
quick
synchronous
retro
to
make
sure
that
the
retros
were
meaningful
for
us
and
that
we
can
invade
the
major
themes
for
the
engineering
wide
retrospective.
We
have
seeded
some
of
the
topics
in
here
in
our
retro
issue
and
we're
going
to
talk
about
some
of
the
other
topics
in
here.
So
andrea's
patent.
Do
you
have
anything
else
you
want
to
add
to
any
of
these.
B
B
Maybe
I
can
start
vocalizing
my
the
only
comment
I
added
before
I
thought
we
were
making
good
progress
and
I
mean
we're
still.
We
still
move
the
the
migration
or
merging
now
to
the
next
milestone,
but
it's
done
like
it's
in
production,
so
I
think
that
still
still
counts
for
for
the
last
master,
because
we
did
most
of
the
work
back
then
right,
yeah,
so
yeah
pretty
happy
about
that.
It
seems
to
work.
Fine,
I
felt
we,
it
was
a
bit
sort
of.
B
There
was
a
perceived
risk.
I
think
with
merging
that-
and
I
think
some
some
of
that
came
from
the
fact
that
we
were
sort
of
building
up
to
that
point
right.
We
were
even
though
we
were
merging
code
changes
before
regularly
in
nice,
small
chunks,
and
that
was
really
good.
That
code
wasn't
live
right
so
or
it
wasn't
been
used
until
that
point.
B
So
I
think
that's
where
some
of
the
perceived
just
came
from
at
this
point
to
you
know,
merge
the
migration
and
then
trigger
all
the
things
that
we
prepared,
but
it
worked
out
fine,
so
pretty
good.
A
I
think,
looking
through
the
issues
that
closed
that
were
part
of
the
13-2
milestone,
I
really
like
the
documentation
and
handbook
updates
that
were
added.
I
think
everybody
contributed
to
that,
but
particularly
honest.
He
did
a
good
job
of
organizing
a
lot
of
our
docs
and
making
sure
that
areas
were
covered
that
weren't
previously
covered.
So
I
really
like
the
progress
we've
made
in
the
handbook
and
making,
I
think
the
database
review
section.
I
think
he
made
it
its
own.
A
A
I
don't
want
to
put
you
on
the
spot
andreas,
but
I
will
you
do
want
to
share
the
comment
you
made
with
me
about
the
friday
push
and
how
we
decided
to
delay
instead
of
risking
pushing
the
migration
and
the
code
out
last
friday,
because
we
had
that
chat
in
in
the
database
channel.
Then
you-
and
I
talked
about
it
later
on
about
yeah.
B
Sure,
yeah
yeah
for
sure
I
felt
I
felt
this
was
a
really
good
move
for
us
to
to
allow
that
and
to
don't
pressure,
the
team
to
sort
of
ship
that
in
the
milestone,
even
though
we
could
have
right,
I
mean
we
didn't
break
anything,
so
we
could
have
done
that.
But
we
didn't
know
at
that
point
or
it
was.
B
You
know
there
was
this
perceived
risk
from
from
the
migration
and
even
though
we
wanted
to
get
it
in
in
the
milestone,
there
was
no
pressure
to
actually
do
so,
and
you
could
rather
consider
the
bigger
picture
and
realize
that.
Well,
there
was
some
trouble
going
on
with
the
deploys
already
and
unrelated
to
us,
but
or
to
that
change.
B
But
there
was
some
some
trouble
there
and
there
was
already
pressure
for
the
release
managers
to
finalize
the
release
and
all
that-
and
we
didn't
want
to
add
on
top
of
that,
so
allowing
us
to
let
that
sort
of
slip
end
quotes
to
the
next
mods.
And
I
think
that
was
a
really
good.
B
A
B
And
that's
from
coming
from
the
yeah.
I
think
that
the
work
that
we
did
for
for
the
preparing
that
partitioning
migration
is
a
good
example.
We
added
two
things
happened,
one
was
related
to
us
and
the
other
one
is
not
really,
but
it's
the
same
scheme.
We
we
added
separate
database
schemas
for
the
first
time,
and
there
was
some
reported
issue
after
the
release
where
a
customer
ran
into
permissions
problems
because
of
that
so
on
their
installation.
B
They
didn't
have
the
right
permissions
to
actually
successfully
execute
that
migration
and
similarly-
and
that
was
actually
unrelated
unrelated
to
our
team.
But
there
was
a
similar
change
where
we
enabled
an
extension,
postpose
extension,
and
to
do
so,
you
gotta
have
super
user
rights
and
there
was
that
sort
of
that
change.
That
was
we
merged
it.
At
some
point,
we
realized
that.
Well,
not
everybody
has
to
use
the
rights.
We
have
to
do
this
differently.
We
rewrote
that
and
then
on
the
retry
of
the
emr.
B
There
was
still
some
confusion
or
some
we
were
still
unsure
like.
Is
it
going
to
work
or
is
it
going
to
blow
up?
We
didn't
really
know
in
all
the
details,
and
one
point
I'm
getting
at
is
something
that
we
don't
do
is
actually
execute
migrations
in
ci
with
a
with
an
unprivileged
user.
B
Well,
one
of
those
cases
with
the
extension
if
we
were
using,
if
you
were
doing
the
same
thing
as
with
omnibus.
B
Yeah,
we
should
already
have
an
issue
about
just
a
second.
B
We
don't
know
or
sorry
we
know
why
it
fell,
but
not
why
it
wasn't
that
that
state.
So
apparently
that
was
a
was
an
omnibus
installation
single
note,
pretty
standard
but
longer
lived.
So
it
wasn't.
You
know
we
did.
B
We
don't
know
when
they
started
to
use
gitlab,
but
that
was
a
while
ago
and
they
were
following
all
the
updates,
the
major
ones
and
when
they
installed,
the
latest
release
turned
out
that
their
database
user
they
were
using
for
migrations,
was
not
the
owner
of
the
database
and,
as
such,
it
didn't
have
permission
to
add
to
create
a
schema,
whereas
in
a
really
standard,
omnibus
install-
and
that
goes
back
to
I
tested
as
with
nine
five.
So
quite
a
while
at
least
that
user
is
the
owner
of
the
database.
B
B
So
ci
wouldn't
have
helped
in
that
case,
but
it's
sort
of
the
problem
that
we
we
deal
with,
like
not
only
our
own
installation,
but
also
like
very
many
different
ones,
that
we
don't
control
and
there
are
even
ones
that
are
that
have
a
long
history
of
stuff.
C
B
You
following
that
conversational
slack
that's
happening
with.
I
think
it
was
aurora
in
that
case.
B
That's
one
one
on
database
channel
where
they
really
see
strange
things.
B
B
And
another
thing
related
to
ci
and
testing
migrations
is
the
fact
that
we
don't
test
for
no
downtime
upgrades,
even
though
that
is
exactly
what
we're
doing
on
gitlab.com
right.
So
at
least
to
my
knowledge,
maybe
that
changed
recently,
but
a
couple
of
months
backs.
We
didn't
back.
We
didn't.
B
A
If
it's
a
suggestion
for
improvement,
we
probably
should
create
a
tracking
issue
for
it,
so
to
at
least
either
confirm
that
it
happens
or
point
out
that
it
should.
A
B
I
think
we
have
taken
a
couple,
or
at
least
one
issue
that
was
maybe
not
clear
enough
or
actionable
enough.
That
was
the
the
workload
analysis.
So
where
do
you
start
or
how
do
you
even
get
into
that?
Have
we
now
pushed
it
out
a
little
bit
more?
B
So
that's
at
least
looking
back,
that's
something
we
are
already
getting
better
at,
because
I
I
felt
like
reviewing
the
the
list
of
issues
in
the
milestone,
putting
the
deliverable
label
that
makes
a
lot
of.
B
C
C
Or
I
guess
I
had
the
issues
for
the
the
conflict-free
schema
version,
one
that
actually
it's,
I
think,
there's
two
milestones
now,
but
you
know
I
don't
I
don't
know,
I
would
say
necessarily
it
didn't
go.
Well,
it's
just
sort
of
changing
priorities
to
some
extent,
but
I
think
that's
an
area
that
we
can
improve,
at
least,
which
is
what
I
expanded
on
here
to
there.
Let's
just
try
to
keep
a
focus
on
if
we
have
a
larger
initiative
that
we're
working
on
like
partitioning.
C
We
should
be
not
really
picking
issues
outside
of
that
initiative,
or
maybe
we
need
to
do
yeah,
maybe
depending
on
how
we
split
the
work
maybe
like.
If
two
people
are
focused
on
something,
then
the
other
person
is
kind
of
picking
up
the
random
issues
or
we
have
like
a
mouse
and
where
we
work
on
something
big
and
then
the
next
milestone.
We
work
on
kind
of
more
random,
just
some
way
to
keep
it
a
little
bit
more
organized,
so
we're
not
trying
to
do
both
at
the
same
time.
A
Many
of
the
folks
indicated
they
like
to
have
a
couple
of
side
issues
kind
of
in
the
queue
they
like
to
have
the
big
initiative,
but
they
like
to
have
like
smaller,
maybe
single
tasks
that
are
just
kind
of
in
the
queue
so
that
if
they
maybe
get
into
analysis,
paralysis
or
they're,
just
stuck
on
the
bigger
initiative,
they
can
switch
context
for
a
little
while
and
just
kind
of
work
on
something
else.
So
they
can
come
back
with
a
fresh
view
on
the
bigger
initiative
and
that's
kind
of
what
I
was
thinking.
A
The
database
team
was
doing
as
well
right.
We
have
the
big
initiative,
but
then
there's
some
onesie,
two
z
issues
that
they
can
work
on
on
the
side
if
they
want
to
switch
context.
So
is
that
kind
of
what
was
going
on
with
this
conflict-free
versioning,
or
did
you
feel
like
you
were
a
little
too
fragmented?
There
were
too
many
different
topics
for
you
to
bounce
around
on.
C
Yeah,
I
think
I
picked
it
up
for
that
thinking
that
I'll
have
time
to
work
on
it,
but
then,
once
I
really
got
into
the
work
that
I
was
doing
and
it
just
sort
of
fell
by
the
wayside,
because
I
didn't
really
take
the
time
to
like
fully
switch
over
to
that,
and
it
was
just
really
the
one
issue
that
was
really
different
than
everything
else
that
I
was
working
on
in
the
milestone.
C
So
I
just
kind
of
kept
kicking
it
down
the
road
and
saying
well,
I'm
busy
with
other
stuff
right
now
so
yeah.
I
think,
having
like
a
side
issue
is,
can
be
good.
Maybe,
but
maybe
those
are
just
ones
that
we
don't
work
deliverable
or
we
say
like
it's:
okay,
if
it
slips
the
mouse
on,
because
it's
not
a
high
priority.
A
Yeah,
did
we
mark
that
often-
and
I
have
a
section
for
stretch,
goals
in
the
planning
issues,
but
I
don't
know
how
well
we
use
that.
A
B
For
this
particular
one,
we
blocked
some
time
for
today
to
actually
merge
it,
so
that
works
out,
and
it's
all
done
right
can
close
both
issues.
C
B
B
Sort
of
related
to
the
delivery
level,
I
thought
maybe
it
would
be
useful
to
not
tag
issues
as
a
deliverable
that
we
only
push
into
the
milestone
after
the
fact
right
after
milestone
started,
because
that
also
gives
you
an
idea
at
the
end
of
the
milestone
that
you
see
like.
I
have
this
10
deliverables,
and
then
there
are
10
other
tasks
that
we
picked
during
the
milestone.
A
B
Yeah
I
mean
in
this
case
you
could
say
that.
Well,
we
had
an
issue.
We
were
breaking
that
down
so
that
that
issue,
the
original
issue
got
moved
out
of
the
milestone
and
the
next
you
know
the
smaller
one
that
moved
in.
So
that
would
probably
be
fine.
It's
still
the
same
same
work,
and
that
sounds
very
interesting.
B
A
Because
so
there's
a
bot
out
there
that
will
fill
this
stuff
in
later
on,
like
I
certainly
didn't
do
this,
but
it'll
count
the
total
number
of
deliverables
total
issues
closed.
We
didn't
miss
any
deliverables
with
this
milestone
because
they
were
all
marked
as
we
went
through
the
milestone,
but
next
milestone
we'll
see
what
the
delta
is.
A
One
question
I
was
going
to
ask,
and
you
know
I
have
to
answer
it
now.
You
can
think
about
it.
Other
teams
have
done
their
own
custom
template
around
these
retrospectives,
so
it
doesn't
always
have
to
be
the
same
format.
We
can
tailor
it
to
what
we
want
interesting
addition
that
I've
seen
other
other
teams
do.
Is
you
know
what
do
we
want
to
celebrate
from
this
milestone?
What
cool
feature
did
we
ship?