►
From YouTube: 2021-08-10 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
B
B
Okay,
so
we're
at
time
so
first
off
mttp,
so
I've
just
got
18
hours
of
blockers
is
that
is
that
accurate,
henry
robert,
like
they
were
just
the
ones
from
earlier
in
the
week,
was
that
all
we
experienced
last
week.
C
For
blockers,
I
actually
need
to
check
what
we
did
last
week.
I
think
I
updated
the
at
the
beginning
beginning
of
the
week,
but
I
think
the
rest
of
the
week
we
didn't
have
any
blockers
as
far
as
I
remember
yeah,
that
should
be
correct.
Yeah.
B
Yes,
that's
good
news
cool
and
how
is
how
was
release
management
last
week?
So
mttp
is
reasonably
high.
Like
was
that
a
were?
We
did?
We
have
abnormal
stuff
going
on
last
week.
C
I
think
at
the
beginning
of
the
week
there
were
certain
issues
holding
up
deployments.
I
think
we
had
issues
with
the
security
release
and
then
then
also
with
merging
back
changes
right.
I
think
we
have
merge
conflicts
yeah
right.
I
need
to
look
back
for
that
first
there
and
there.
B
Okay,
yeah,
okay,
so
we
don't.
I
don't
know
if
we've
got
those
in
the
box.
Okay,
because
it's
gonna
say
like
let's
keep
an
eye
on
mttp
and
see
I'm
hoping
it.
It
comes
down
following
pcl,
but
let's
keep
an
eye
on
on
the
target
and
branches,
and
things
like
that.
C
I
just
checked,
I
think
I
updated
the
excel
sheet
with
deployment
blockers
last
week
and
I
think
the
headless
perfect
to
be
in
staging
being
down
being
a
blocker
for
a
while
bro
security
master
and
also
security
merch
reflects,
and
that
was
a
lot
of
hours
blocking
us
at
the
beginning.
I
think,
but
for
the
rest
of
the
weeks,
everything
went
fine.
B
Cool
okay,
great!
Well,
that's!
Hopefully
we
have
a
good
week,
so
I've
put
a
few
announcements
in.
I
will
leave
these
as
read
only
unless
anyone
wants
to
call
out
anything
around
those
awesome,
okay,
so
discussions
so
we're
quite
likely
to
start
hiring
quite
soon
for
additional
team
members,
which
is
good.
B
One
thing
I'm
curious
about
whether
anyone
has
strong
opinions
on
should
we
be
like
I'm
not
quite
sure
whether
how
this
kind
of
will
tie
in
through
cue,
sorry,
like
q1
and
sort
of
through
next
year.
So
it's
not
like
it's
necessarily
like
we
will
get
just
this
number
of
people
or
this
set
of
skills,
but
people
have
strong
opinions
on
what
skill
sets
or
time
zones
we
should
add
like
for
the
first
people
coming
in,
so
we
could
get
prioritized.
C
B
C
Oh,
I
think
this
is
depending
on
a
lot
of
things.
Right
I
mean
right
now
I
would
say,
having
one
more
sae
would
be
great,
but
on
the
other
hand
we
are
very
busy
with
web
migration
like
the
migrations.
Two
communities
are
a
big
task
for
us,
but
the
thing
is
when
this
is
done,
how
much
srevit
will
be
in
our
team
or
will
be
spread
over
to
the
rest
of
her
infrastructure
right?
If
we
don't
do
big
migrations
anymore,.
B
I
wouldn't
worry
too
much
about
that.
This
is
an
entirely
temporary
team
and
once
we
complete
our
remit
right,
but
it's
not
a
temporary
team
right
like
it
is
officially
a
temporary
team,
but
we
will
end
our
goal
when
everything
we
do
is
built
into
the
gitlab
product
and
any
developer
can
deploy
right.
That's
our
our
end
states,
so
we
are
temporary,
but
I
wouldn't
worry
about
yeah.
I
wouldn't
worry
about
the
state
coming
too
so
same
exactly
same
with
the
migration
right.
B
We
still
have
pages,
we
still
have
prefect,
we
still
have
italy
and
redis
and
h.a
proxy
are
kind
of
known
at
the
moment.
So,
like
you
know,
we
we
have.
We
have
more
than
a
year's
worth
of
work
to.
C
B
Cool
okay,
okay,
so
we'll
see
how
these
things
start
up
related
to
hiring
definitely
want
to
make
sure.
Well,
two
things:
I'm
going
to
need
you
to
be
involved
so
that
we
can
actually
run
interview
processes,
but
also
I
do
want
you
to
as
many
of
you
to
be
involved
as
possible,
because
these
will
be
our
teammates.
I
want
you
to
be
able
to
have
an
opinion
on
you
know
like:
are
they
gonna
fit
in
with
the
team?
Is
it
someone
you'd
be
happy
to
work
with?
B
Do
you
think
you'll
learn
stuff
from
them,
so
curious,
know
first
off
like?
Is
it
just
henry
who
has
done
training
and
led
an
interview
or
any
of
the
other
rest
of
you
at
that
stage?
Okay,
okay-
and
I
know
some
of
you
don't
want
to
interview.
It
may
be
that.
B
It
may
be
that
we
will
need
you
to,
but
I'm
happy
to
work
with
you
all
individually
on
those
things.
So
I'll
do
a
follow-up
interview
note
for
all
of
you
one-to-one
and
we
can
talk
about
that
stuff.
B
So
we
want
to
kind
of
streamline
our
process
so
that
candidates
don't
have
loads
of
interviews,
but
they
just
get
the
ones
that
matter,
but
that
we
can
it's
the
first
time
we're
going
to
be
hiring
externally
actually
into
the
team,
which
is
going
to
be
interesting,
not
to
say
actually
they'll,
definitely
be
external.
Once
we
get
the
process
up,
I'm
hoping
we'll
get
some
internal
applicants
as
well
right,
so
it
could
be
people
we
know,
but
still
they'll
go
through
the
process.
So
we
can
work
these
things
out.
B
Cool,
okay,
I'll,
follow
up
with
you
one
to
one
on
these
things.
So
thank
you
very
much.
B
I
don't
actually
know,
I
believe
so.
I
know
that
we
were
kind
of
penciled
down
for
q4
to
have
three
and
some
of
those
are
hopefully
coming
forwards,
based
off
the
pcl
and
all
the
work
we
have.
But
what
I
actually
don't
know
is
whether
all
three
move
forwards
or
whether
it
maybe
it's
one
in
q3
and
a
couple
in
q4
or
how
it
fits
together.
B
So
I'm
not
I'm
not
super
sure
I
don't
think
anything's
approved
just
yet,
but
just
so
that
when
it
happens
when
it
opens
it'll
be
sort
of
like
let's
begin
so,
I
just
want
to
make
sure
that
we
know
what
we're
going
to
do.
We
have
our
process
and
we
know
what
like
exercises,
we're
going
to
ask
people
to
go
through
and
actually
only
henry
is
trained
as
well.
B
B
Super
so
q3
okrs,
so
q3
is
all
about
hardening
okay
hardening
off
rollbacks
right.
So
this
is
a
super
handy
okr
for
us
at
this
quarter,
because
we've
got
lots
of
little
things
that
have
been
kind
of
going
along,
which
all
tie
nicely
into
this.
B
So
the
big
pieces
of
this
okay
are
are
stateless
migration
to
get
pages
of
web
fully
migrated,
and
it
is
also
to
kind
of
wrap
up
on
the
rollbacks
epic
that
we
started
already,
but
we
have
other
stuff
which
is
super
related,
which
is
about
metrics,
and
it's
about
coordinated
pipelines
and
kate
workload
tooling,
and
all
of
those
things
tie
in
quite
nicely
to
roll
back,
so
we're
definitely
pulling
stuff
in
from
other
epics
as
we
go
through
this
quarter
as
well.
But
one
thing's
really
interesting
about
rollbacks.
B
One
of
the
reasons
why
and
if
hardening
rollbacks
is
going
to
be
a
really
valuable
thing
for
us
to
do
is
I
think,
within
this
team
we
generally
feel
quite
confident
with
rollbacks,
like
our
tests
have
gone.
B
So
what
we
want
to
do
for
this
quarter
is
basically
move
that.
So,
if
one
of
the
big
things
is
if
we
can
get
a
regular
rollback
practice
in
place
and
compliance
can
see
that
that
will
reduce
the
risk
from
their
point
of
view
around
compliance,
so
it
was
already
something
we've
talked
about.
It
was
already
on
this
epic.
It
seems
like
a
really
great
place
to
start
out
to
just
try
and
put
a
bit
more
process
around
some
of
the
stuff
we've
done
already.
B
So
we're
two
bits
to
this.
This
issue,
one
is
staging
so
we've
talked
about
this.
We've
had
various
kind
of
ideas
and
different
things.
We
haven't
really
got
like
a
firm
process
in
place,
so
what
do
people
feel
would
be
a
great
way
for
us
to
make
sure
like
it
doesn't
matter
like
who
is
the
release
manager?
You
know
we
actually
have
a
solid
process
so
that
every
week
staging
rolls
back
at
least
once.
E
B
One
thing
I'm
unclear
on
is
when
things
fail
in
staging
whether
how
much
people
need
staging
to
be
in
that
stay
in
that
state
for
them
to
investigate.
Does
anyone
have
any
kind
of
recent
incident
thoughts
on
that.
D
E
C
B
D
C
E
I
wonder
if
we
shouldn't
rely
on
failures.
I
know
that
the
staging
fails
a
lot,
but
at
some
point
I
will
hope
that
staging
is
kind
of
stable
and
doesn't
fail
as
often
so
probably
I
don't
know,
I
was
considering
having
some
sort
of
alert
in
the
years
of
coming
through
this
channel
or
the
delivery
channel.
Basically
saying
that.
Okay,
this
package
is
rollbackable
or
whatever
can
you
pro?
C
It
might
be
a
great
time-
I
don't
know
at
night
right
in
apec
business
times
to
do
stuff
like
that,
because
then
not
much
is
happening
anyway.
We
don't
do
production
deploys
at
this
time,
normally.
Okay,
now
starting
with
green,
maybe
but
to
just
pick
this
time-
and
I
don't
know
once
or
twice
per
month
to
just
do
it
at
that
time.
B
I
kind
of
like
people
using
it
like
it
sounds
a
bit
harsh
like
sounds
like
me,
but
like
I
one
thing
I
think
will
I
think
is
I
mean
yeah.
I
guess
teams
are
testing
on
it,
but
it's
helpful
to
have
some
traffic
like
it
would
be
great
to
kind
of
see
kind
of
to
start
seeing
any
of
the
odd
stuff
I
guess
on
staging,
but
I
mean
certainly
I
guess
we're
not
probably
not
all
that
far
away
from
automating
a
rollback
and
then
apac
would
be
a
super
good
place
to
have
that.
B
So
yeah,
I
kind
of
like
your
idea.
Myra
like
it's,
that's
a
I
guess
it's
because
it
also
it
feels
kind
of
iterative
right
like
we're
going
to
need
to
have
that
for
production
deployments
at
some
point
as
well
like
something
similar
which
is
like
flagging.
B
This
thing
is
suitable
for
rollback
to
to
make
that
easy.
E
Yeah,
we
could
use
the
same
idea
for
production
because
I
was
reading
your
comment
about
stating
a
period
in
which
we
are
going
to
schedule
a
rollback,
but
that
cannot
work
because
of
incidents
or
pcl's
or
whatever.
So
perhaps
we
can
have
like
a
flagging
team
on
the
package
saying
that
okay,
this
package
can
be
rollback
and
we
can
apply
it
in
production
or
in
staging,
and
that
will
give-
I
guess,
a
larger
time
frame
to
test
things,
and
it
would
be
up
to
the
release
manager
to
do
that.
Of
course,
at
least
for
production.
E
B
B
All
right,
we
obviously
we'll
have
to
do
it
on
like
the
actual
staging
right,
because
I
guess
staging's
a
bit
different,
but
we
have
something
which
shows
like
state
that
the
I
mean
like
what
do?
I
don't
mean
it's
different.
I
mean
no,
it's
not
different.
Ignore
me
so
we'll
have
something
we'll
have
a
flag
where
we
we
indicate
that
this
package
is
suitable
for
rollback
and
then
once
we've
got
that
in
place,
we
can
put
something
like
a
process
in
place
where
release
managers
like
once
a
week
like.
B
I
wonder
if
we
just
add
some
stuff
into
the
release
issue
right,
and
so
you
could
have
like,
like
once
a
week
or
something
as
a
box
which
just
says
like
a
staging
roll
back
has
completed
and
you
could
just
you
could
just
mark
it
off
in
there.
B
And
then,
once
we've
got
that
in
place,
we've
got
staging
running
super
easy.
We
can
work
out
how
to
make
production
a
bit
more
of
a
straightforward
process:
yeah
awesome,
okay,
nice,
okay,
great!
Let
me
see,
I
see
if
we've
already
got
an
issue
for
that.
If
not,
if
we
haven't
gotten
already
then
I'll
collaborate
with
you,
we
can
get
what
your
vision
is
out
of
your
head
into
an
issue.
B
Okay
kind
of
relate
to
the
production
one,
so
we
had
a.
In
fact
we
still
have
a
change
issue.
We
may
have
just
closed
again
I'll,
reopen
it
so
release
managers
it'd
be
super
great.
If
we
could
try
and
get
the
production
roll
back
like
have
another
shot
this
week
see
what
else
is
scheduled
and
actually
see.
If
there's
a
a
day
this
week,
we
could
have
another
go
at
doing
that
as
a
general
kind
of
rule
of
thumb.
B
So
certainly
when
myra
and
I
were
kind
of
trying
to
do
it-
that
was
the
most
hopeful
looking
package
each
day
and
then
generally,
if
you
can
deploy
it
to
production
roll
it
back
if
you're
lucky
the
11
utc
one
is
quite
ready
for
production,
quite
close
after
so
you're,
not
kind
of
waiting.
You
don't
get
delayed
by
too
much
stuff.
C
Yeah,
I
think
you
should
give
it
a
try
should
work.
I
think
so.
We
still
have
a
petroleum
spending
right
now,
but
I
think
that's
not
very
urgent,
so
we
can
just
I
don't
know,
I
have
to
look
into
how
we
did
it
last
time
from
from
like
like
did
we
create
a
change
request
for
that?
I
guess
right.
B
For
the
yeah
there
is
one
there's
already
one
open.
Let
me
find
it
for
you,
oh
nice.
I
I'll
dig
out
the
one
that
so
there
is.
There
is
one
that
we
just
moved.
We
got
rescheduled
because
of
the
pcl,
so
we
just
need
to
schedule
on
a
day
that
that
works
for
you.
Basically.
B
C
B
Sounds
good
and
I'll
have
a
chat
with
you,
so
I
had
me
just
talk
through
so
I
think
it'll
be
good
for
us
to
get
a
sort
of
documented
process
of
how
we
end
up
with
a
package
ready
to
go
for
testing.
So
I'll
have
a
chat
with
you
there's
a
couple
of
options
we
can
use
to
set
that
up
on
that
package.
B
Super
awesome
great,
but
yeah
I'd
be
super
good
to
get
that
in.
If
we
can
so
great
nice
nice
thanks
a
lot
cool.
Let
me
see
sorry.
B
B
Cool
okay
super.
Thank
you
very
much
myra
over
to
you.
E
Yep,
so
you
probably
know
our
forever
problem
about
having
a
large
post
migration
that
is
going
to
take
30
or
40
minutes
to
be
executed
and
then
so
far
we
are
notified
about
it,
and
then
we
are
kind
of
bummed
because
well
the
larger
the
post
deploy
the
migration,
the
larger
the
deployment
duration,
and
that
makes
our
mttp
sad.
So
the
database
team
actually
created
an
async
index
creation.
E
I
think
it
got
deployed
last
week
and
I
don't
know
if
you
heard
about
it,
but
I
think
it
is
quite
cool.
So
basically
you
just
schedule
a
migration
that
creates
the
index,
but
the
index
is
not
created.
In
that
point
it
is
kind
of
a
schedule
to
be
created
during
the
weekend
along
the
same
time,
our
as
our
rate
index
task,
and
it
has
been
being
used
for
c,
creating
indexes
for
cie
yields
and
for
another
large
table.
B
Nice
thanks
yeah.
Definitely
so
last
week
we
talked
a
little
bit
about
this,
but
there
are
lots
of
migrations
coming
over
the
next
month,
six
weeks,
maybe
and
yeah.
So
this
is
super
great
example
like
they're,
going
to
attempt
to
do
as
much
for
this
over
the
weekends
to
avoid
blocking
things,
but
there
will
certainly
be
some
disruption
as
well,
so
we'll
see
how
it
goes.