►
From YouTube: 2021-03-22 Delivery team weekly
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
B
It
was
pretty
nice,
it
was
pretty
nice
pretty
pretty
chilled
out,
but
it's
always
nice
to
have
a
long
weekend
today,
yeah
that
was
good.
B
I
was
reading
an
interesting
book
about
a
guy
who
went
and
lived
in
a
forest
for
four
years,
which
sounds
quite
appealing
at
this
stage
in
lockdown,
actually
being
like
in
a
in
a
forest,
for
you
know
just
doing
your
thing
for
four
years,
so
that
was
good,
hey.
B
A
B
B
Awesome.
Well,
let's
start
so,
I'm
just
going
to
quickly
mention
the
announcements
are
pretty
read
only,
but
I
try
to
mention
a
couple
of
things.
So
it's
a
shame
scarborough.
It's
not
here
because
I'm
gonna
say
on
the
mttp.
I've
left
it
as
a
year
just
because
it's
quite
a
lot
more
work
to
break
this
down
into
a
smaller
view.
So
at
the
moment
in
periscope
we
have
a
year
of
data,
so
everything
is
just
automatically
a
year
so
dig
in
in
in
periscope.
B
If
you
want
to
look
closer,
but
it's
looking
pretty
pretty
good,
which
is
is
good
to
see.
Hopefully,
some
of
the
changes
that
eric
robert
you've
made
over
the
last
few
weeks
like
we'll
see
mttp
kind
of
adjust
a
little
bit
there,
but
it's
looking
pretty
good
and
then
on
the
announcements.
Congratulations
release
day
always
exciting
and
this
can
be
offline,
but
just
like
do
is
there.
I
don't
know.
Is
there
already
a
security
release
plan.
B
Oh
okay,
so
let's
go
ahead
and
do
that
and
then
we
can
like
let
ping
me
when
you,
whenever
there's
a
plan
and
I'll,
let
jihu
know
as
well
cool
and
then
both
mario
and
I
are
out
tomorrow.
B
Cool-
and
then
I
just
put
in
fyi
here
that
broken
master
mirrors
now
exists
thanks
to
myra
for
pushing
this
one
and
getting
it,
but
it
gives
some
good
visibility
of
when
our
mirrors
are
breaking,
but
also
without
adding
a
ton
of
noise.
So
if
you're
not
aware
of
that,
already
then
take
a
look
cool
and
then
over
on
discussion.
So
I
think
we're
super
close
to
like
making
some
fairly
big,
hitting
some
big
milestones
this
week
just
wanted
to
make
sure
we're
kind
of
all.
B
On
the
same
page,
so
registry
henry's
done
a
super
job
of
getting
registry,
pretty
much
up
and
running
now
on
pre.
So
thanks
for
that,
henry
I've
put
the
epic
in
there.
It's
not
super
super
linked
into
our
boards
and
things.
Yet,
just
because
most
those
tasks
don't
exist
in
delivery,
so
but
just
for
everyone
else
for
some
visibility
on
what
henry's
up
to
and
then
on
the
api
service.
B
We
are
pretty
close
to
getting
this
through
onto
canary,
so
the
tasks
are
on
the
board
for
the
next
steps
of
that,
but
skabeck
started
off
vetting
deployments
in
staging
at
the
end
of
last
week
and
all
being
well.
We
should
have
cleared
all
the
blockers
on
logs
and
all
the
sort
of
pieces
that
have
been
holding
us
up.
B
So
hopefully,
api
service
will
hit
canary
this
week
and
then
also
roll
back
so
leslie
and
I
went
through
billboard
this
morning
and
got
all
sort
of
next
up
tasks
for
coordinate
deployments
and
on
rollbacks.
B
So
I
think
we're
well
set
up
for
not
only
the
next
piece
of
work,
but
also
demos
for
the
next
couple
of
weeks
to
go
through
some
of
those
failure
scenarios.
So
take
a
look
at
those
things.
If
you're
picking
up
tasks,
please
pick
them
up
off
the
board
based
on
their
priority.
So
we
do
have
lots
of
nice
to
haves,
but
also
we've
actually
got
quite
a
few
pieces.
That
would
be
great,
sir,
get
moving
forwards
on
the
either
registry
api
or
rollbacks.
B
Awesome
are
there
any
questions
on
that.
B
Nope
mara,
over
to
you.
D
Yep
thanks
amy,
so
I
was
reviewing
an
mr
last
week
that
renames
a
model
from
a
to
b
so
to
speak,
and
we
don't
have
guidelines
for
that
process
on
the
development
side.
So
I
do
wonder
if
renaming
a
model
could
cause
a
mixed
deployment
problem
when
this
merge
request
reaches
canary,
but
it
doesn't
reach
production
and
well,
I'm
not
sure.
I
am
probably
too
paranoid
about
this,
but
the
merge
request
is
kind
of
big
it.
D
Is
it
also
renames
all
the
all
the
appearances
of
the
model
in
throughout
our
code
base
and
the
model
appears
to
be
used
in
two
ways
like
when
we
execute
a
pipeline?
A
worker
is
enqueued
and
this
worker
triggers
our
service
that
executes
the
model
and
on
the
merge
request,
widget.
We
have
a
section
on
the
merch
request,
page
that
executes
a
service
that
uses
this
model.
C
It's
generally,
if
we
store
the
exact
class
names
in
sidekick
jobs
or
in
the
database
table
renaming.
That
is
basically
hell,
because
you
have
to.
C
From
the
top
of
mad,
if
you
want
to
do
it
reliably,
you
basically
have
to
keep
the
old
model
as
it
is,
introduce
the
new
one,
rename
all
that
data
in
some
way
and
then
the
next
release.
I
think
you
can
kick
out
the
old
model,
because
if
you
just
have
a
dummy
class
and
it
will
still
try
to
use
that
one-
it
will
blow
up
in
case
of
psychic,
you
could
do
something
like.
Oh
when
we
fetch
the
job.
C
We
can
say-
oh
I'll,
look
at
this
argument
if
it's
this
change
it
to
that,
but
it's
gonna
require
somebody
to
actually
write
that
logic.
C
E
E
So
yeah,
I
also
wrote
some
notes
under
your
question,
but
basically
is
israeli
as
yorkshire.
So
as
long
as
we
are
talking
about
ids,
everything
is
fine,
because
every
process
has
its
own
definition
of
the
class
and
we
look
on
the
right
thing,
but
the
when
we
start
passing
strings
that
represent
class
names
and
things
like
that
across
process
boundaries,
then
it's
held
and
so
yeah
there's
no
easy
answer.
You
really
need
to
take
a
look
of
how
we
are
using
this.
D
Yeah
yeah,
those
are
good
points,
so
I
just
checked
and
the
merch
request
was
already
merged
and
I
think
it
is
on
canary
right
now.
So
I
hope
it
doesn't
cause
anything,
but
thank
you
for
chiming
in.
C
C
D
Yep,
coming
not
good
at
multitasking,
okay,
so
so
I
think
14.0
is
getting
closer
and
closer,
and
I
just
wonder
if
we
have
a
place
to
put
all
the
issues
that
are
going
to
well
break
something
because
it
is
a
breaking
change
release
and
I
just
spotted
two
that
might
require
release
manager
coordination.
The
first
one
is
that
gitlab.com
instance.
The
default
branch
is
going
to
be
renamed
from
master
to
main.
D
It
is
only
going
to
apply
for
new
projects
not
for
existing
projects,
but
I
guess
the
rename
it
itself
might
be
done
by
release
managers
and
also
postgres
is
going
to
be
upgraded
to
12.0,
which
in
this
case
we
might
need
to
coordinate
a
specific
deployment
like
we
are
going
to
build
a
package
specific
for
this.
I
don't
know,
but
I
wonder
if
we
have
a
place
to
write
down
such
items.
E
B
There
may
be,
what
sort
of
thing
are
you
expecting,
so
the
branch
one
is
being
handled
by
daniel
right,
maybe
they're,
being
handled
issued
by
issue,
but
I
don't
know
if
someone
points
me
to
what
we
did.
We
have
certainly
for
13.00.
E
E
Daily
basis,
so
I-
and
so
there
was
a
coordination
issue
where
every
group
could
just
write
breaking
changes
and
preparing
communication
plans
and
things
like
that:
okay,.
B
Let
me
see
if
I
can
find
one
I'll
be
amazed
if
there
isn't
something
so
yeah.
That's
a
good
point.
I
think
I've
heard
a
lot
of
product
people
talking
about
breaking
changes,
so
there's
certainly
an
awareness
that
you
know.
That
is
the
the
release.
So
let
me
follow
up
on
that.
One.
E
So,
regarding
postgres,
if
I
remember-
because
I
think
we
had
another
one
in
13.00-
is
not
really
a
special
package
because
we
start.
If
I
remember
basically,
we
upgrade
the
library
ahead
of
time,
because
the
if
you
compile
with
the
next
jam,
you
can
just
connect
to
the
old
one,
no
problem,
but
then
what
happens
is
that
there
is
a
migration
planning
happening.
So
basically
some
someone
from
datastore.
E
B
I
think
okay
cool
henry:
do
you
want
to
verbalize.
A
Yeah
so
I
mean
for
the
database
upgrade
to
postcross
12.
I
think
it
will
be
just
be
done
during
a
maintenance
window
at
night
time,
whether
the
desktop
steam,
I
think
it's
even
scheduled
for
april
already
yeah,
I'm
not
sure.
A
To
do
it
at
this
time,
but
we
will
be
on
on
12
for
a
while
until
we
release
14
gitlab
14
right.
So
I
wouldn't
expect
a
lot
of
things
to
change
for
us
in
this
case
right.
So
it's
just
that
we
require
this
database
now
to
be
used,
but
it
should
already
be
in
place
running
with
13
something
before
we
go
to
14.
So
I.
B
B
Cool
okay
sounds
good
cool;
okay,
let's
follow
up
on
that
one
and
see
what
we
need.
C
Actually,
I
have
one
while
we're
all
here,
so
we
have
these
lovely
notifications
that
we
are
apparently
sending
to
f
upcoming
release
that
indicate
the
they
say
something
like
oh
production
deployment
reached
g
prop
migrations,
whatever
percentage.
Apparently,
these
aren't
actually
deploys.
As
far
as
I
just
found
out,
we
seem.
C
Yeah,
that's
a
little
annoying
I'd
like
to
know
what
we're
going
to
do
about
that,
because
I
thought
we
just
finished
the
deploy.
No,
we
are
still
deploying
to
canary
because
we're
apparently
sending
stuff
that
looks
like
we're,
deploying
when
apparently
we're
not.
C
I
have
no
clue
like
I
got
the
message,
so
I
went
into
the
incident
channels.
Basically
hey
you
know,
there's
an
incident.
This
thing
is
telling
me
you
know.
Is
this
deploy
a
blocker?
Sorry
if
this
incidence
of
blockers
stop
the
deploy-
and
they
were
like-
oh
yeah
sure,
but
then
it
went
so
fast,
I
basically
couldn't
stop
it
in
between
stages.
So
I
just
let
it
run,
and
I
was
already
kind
of
scratching
my
head,
because
the
giddily
deploy
took
like
five
minutes,
whereas
normally
it
takes
like
50.
C
yeah,
because
it's
a
dry
run
yeah,
and
so
now
it
looks
like
we're
basically
dry
running
stuff
but
telling
people
no.
This
is
an
actual
deploy
when
the
actual
deploy
failed.
When
I
was
thinking
that's
the
next
deploy
because
of
this
notification
thing
yeah,
I
guess
I'll
create
an
issue,
because
this
is
yeah.
This
is
annoying
slightly
pissing
me
off.
B
Yeah
go
ahead
and
create
the
issue
and
stick
it
straight
on
the
board
york.
Let's,
let's
get
that
side
out.