►
From YouTube: 2021-07-19 Delivery team weekly EMEA/AMER
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).
B
A
I'm
just
going
to
start
an
apology
actually
because,
as
I
as
I
joined
this
meeting,
it
always
occurs
to
me
it's
monday.
It's
the
first
point
in
the
day
I
was
like
this
morning,
so
apologies
that
the
weekly
priorities
message
will
be
late,
I'll,
try
and
do
it
later
today,
but
it
might
be
tomorrow.
So
apologies
for
that,
but
in
more
regular
news,
mttp
is
looking
stunning,
so
great
work.
A
Everyone
thank
you,
myra
for
being
a
super
relief
manager,
buddy
and
also
super
exciting,
like
so
we're
seeing
here.
What
we're
seeing
is
a
combination
of
kubernetes
and
bridge
jobs,
meaning
deployments
are
fast
like
real,
fast
and
adding
in
graham
as
well
to
the
to
the
rotation
is
actually
meaning
that
we're
we're
less
impact.
A
So
I
think,
once
we
see
this,
we
can
start
to
standardize
that.
But
what
we're
now
getting
is
a
lot
more
flexibility
around
being
able
to
deploy
earlier
or
later,
or
there
was
one
day
last
week
where
graham
kicked
off
a
deploy
like
right
at
the
end
of
his
day,
which
was
like
way
before
I
started,
but
you
know
we're
getting
we're
just
being
blocked
up
less
on
this
stuff.
So
that's
very
exciting
and
it
gives
us
lots
more
kind
of
opportunities
to
to
keep
pushing
the
stuff.
So
what.
C
Like
what
are
we
hitting
we
are
hitting,
I
think
it
is
eight
hours.
A
Nice
so
so
yeah,
it's
looking
pretty
pretty
smart.
What
we
will
we'll
keep
pushing
on
the
stuff
and
say
like
I,
I
think,
scarbeck
summed
it
up
nicely
like
six
hours,
is
the
next
one
right,
but
I
did
lower
the
official
four
yeah.
I
did
lower
the
official
target
back
down
to
12,
even
though
we
don't
have
two
weeks
without
incidents
just
because
last
week
we
had
the
key
metrics
meeting
I
was
like.
A
Is
this
gonna
look
super
weird:
if
we're
like
yeah
our
goal
is
24
hour
hours
and
we're
smashing
through
like
12
or
13
hours,
so
we
can
keep
monitoring
that,
but
it's
it's
looking
really
super
for
july.
A
Sir,
so
awesome
so
let
me
see
so
I
just
left
the
out
of
office.
Things
on.
I
won't
go
through
each
week,
but
just
so
you're
aware
of
those
so
discussion.
So
one
thing
I
had
on
my
mind
this
morning
was:
I
was
just
casually
reading
through
some
of
the
incidents
that
myra
had
mentioned
in
our
handover,
and
I
was
like
okay
here
are
all
these
things
that
are,
there
were
conversations
taking
place,
left
right
and
center
around.
Oh,
we
should
make
sure
we
get.
A
This
revert
into
the
release
or
what
should
we
do
about
the
release?
I
was
like
wow.
There
are
no
release
managers
pinged
on
this.
Those
ones
are
fine
because
we
saw
them
and
we
got
them.
But
does
anyone
have
great
ideas
like
on
what
we
can
do
to
actually
would
reduce
the
gap?
I
guess
between
these
things
right
because
there
must
be
a
load
of
stuff
that
slips
through
the
cracks
where
people
are
having
conversations
coming
up
with
deployment
strategies
but
for
some
reason,
just
not
pinging
release
managers.
A
The
special
caveat
on
this
one
is
without
adding
manual
work.
So,
yes,
we
could
go
through
incidents
or
we
could
go
through,
mrs
whatever,
but
we
already
have
a
ton
of
work
right.
A
Yeah,
it's
a
great
point.
No,
it's
actually
the
truth.
Okay,
no,
we
don't
provided
it's
handled
appropriately.
I
think
it's
where
the
so
say,
for
example,
this
one
I
had
this
morning
we'll
end
up
totally
fine
because
of
deployments
going
smoothly,
at
least
so
far
today,
but
we
had
already
announced
the
guaranteed
commit.
So
in
theory
we
could
14.1
could
be
thursday's
deployment
and
I'm
not
sure
I
hope
people
realize
that,
but
I'm
not
sure
if
people
realize
that.
A
But
you're
right
in
actual
reality
like
so
I
guess
the
the
sort
of
longer
term
thinking
about
this
stuff
is
this
process
is
going
to
become
fully
automated
right
and
the
release
train
will
just
begin
and
it
will
just
pick
up
whatever
it
has
and
it
will
package
it
and
release
it,
and
at
that
point
like
it,
it
will
have
what
it
has.
So
I
guess
I'm
kind
of
thinking
like
what,
but
I
love
starbucks
point
note:
should
we
also
have
stuff
in
here
to
to
help
people
understand
like
more
about
this.
D
I
guess
if
the
concern
is
about
making
sure
that
we
do
or
do
not
have
the
correct
stuff
into
the
latest
release.
Maybe
I
don't
know
if
this
is
possible,
but
I'm
brainstorming
if
a
revert
occurs
and
it's
within
a
time
range
leading
up
to
the
window
where
we
start
announcing
the
final
date,
maybe
we
could
drop
a
message
from
dangerbot,
saying
hey.
D
D
And
we'd
have
to
define
what
that
window
is,
and
we'd
have
to
make
sure
that
dangerbot
could
recognize
that
this
is
a
reverb,
I'm
sure
there's
another
scenario
where
someone
may
revert
something,
but
it
won't
happen
in
a
revert,
merge
request.
It
would
happen
because
they
revert
say
a
portion
of
it.
So
the
word
revert.
E
A
Oh
okay,
okay
got
it.
You
just
mentioned.
There
was
an
incident
and
it
had
been
resolved
and
I
was
like
okay
I'll
just
take
a
look
and
then
I
saw
this
whole
thing
and
it
was
like
hey.
We
so
we're
going
to
need
to
revert
this
and
we
did.
I
was
like
whoa,
okay,
like
yeah.
That's
I
literally
just
stumbled
across
it,
which
is
what
made
me
think.
I
wonder
how
many
of
these
things
we
just
don't
see
at.
E
A
Guess
a
question
for
you
reuben,
as
someone
who
actually
goes
through
this
process
outside
the
team
is
like.
Is
it?
Is
it
clear
from
from
your
developer
experience
of
not
asking
you
to
talk
to
everyone,
but
like
once,
we
start
announcing
the
like
guaranteed
commits,
and
things
like
is,
is
the
is
the
process
clear.
G
So
it
takes
a
bit
of
time
to
properly
understand
it.
So
it's
usually
multiple
readings
of
the
release,
documentation
where.
G
The
guaranteed
commit,
and
then
the
candidate
commit
yeah,
usually
a
few
times
where
you
have
to
ensure
that
some
merge
request
of
yours
is
included
in
a
release.
So
then
you
really
read
the
documentation
a
few
times.
Then
it's
understandable,
okay,
if
there's
any
way,
we
can
make
it
clearer.
It
would
certainly
help.
B
G
Was
asking,
are
you
talking
about
the
merge
request?
66305,
the
one
with
enable.
E
A
A
So,
at
the
at
the
moment,
all
of
the
mrs
are
are
merged
and
actually
on
production.
So
I
think
it
will
end
up
being
fine,
but
it
yeah
it's
it's
close.
That's
that's
the
only
thing:
okay,
well,
hey
ruben!
This
is
going
to
be
a
super
good
one
for
you,
whilst
you're
here
with
us,
is
actually
to
like
help
us
work
through
like
how
can
we
like
what
do
we
need
to
take
out
the
documentation
to
make
it
shorter
and
easier
to
understand?
A
And
what
do
we
need
to
add
into
like
announcements
and
things
like
that?
So
actually
people
can
can
understand
this
a
bit
easier
because
yeah,
it's
it's,
certainly
complicated
because
yeah
in
an
ideal
world,
everyone
would
just
self-serve
this
and
we'll
just
know.
Here's
what's
happened
and
here's
what
needs
to
happen
next
or
know
when
they
can
ignore
it,
so
that
we
can
go
on.
G
Yeah,
I
think
we
have
spoken
this
during
a
one-on-one.
You
mentioned
that
there
was
probably
an
issue
where
we
want
to
edit
the
documentation,
sort
of
make
it
more
clear
and
maybe
shorter.
A
Yes,
I
need
to
get
that
set
up
and
do
that
but
yeah.
I
absolutely
there's
a
couple
of
things
like
so
reorganizing
things
so
that
we
can
make
it
easier
to
find
stuff,
but
also
really
want
to
had
a
few
people
mentioned
to
me
last
week.
I'm
related
to
the
release
actually,
but
just
generally
that
release
tools
is
quite
hard
to
drop
in
on
and
or
like
the
release.
Docs
are
quite
hard
to
drop
in
on
and
get
like
a
short
overview.
A
I
think
that'd
be
a
really
good
thing
that
we
can
add
in
which
is
like
you're,
not
the
release
manager.
You
don't
need
to
know
all
of
this
thing,
but
you
do
need
to
understand
enough
about
what
we're
trying
to
do
to
actually
put
the
stuff
together.
So
yeah
I'll
get
some
issues
created
ribbons
because
I
think
that
would
be
you're
well
equipped
to
help
us
with
this
stuff
because
basically
you're
the
target
audience
so
get
going
on.
A
That
awesome
cool
and
then
I
guess
on
that,
like
I
say
I
think
it's
well,
it's
just
going
to
be
education.
I
guess,
as
we
as
we
go
through
these
things,
we'll
have
to
just
keep
reminding
people
to
ping
release
managers
and
we
can
start
pointing
them
to
more
documentation.
F
Probably
an
unpopular
opinion
would
be
that,
should
we
be
notified
about
that,
I
mean
probably
that's
the
reason
why
we
have
batch
releases.
If
there
is
an
s1p1,
we
should
probably
be
aware
of
it
because
there
might
be
an
incident
related.
So
I
wouldn't
worry
too
much
about
those,
but
if
it
is
an
s2
or
an
s3,
then
those
can
be
included
in
a
batteries.
A
Yeah
generally,
they
can
they,
as
always,
migrations,
are
the
challenge
right
like
as
every
time
so
yeah,
but
as
always
we're
very
much
relying
on
people
assessing
the
risk
accurately
labeling
them
so
the
same
one
I
was
looking
at
here
has
no
severity
labels,
so
it's
not
going
to
help
us
okay.
Well,
I
say
I
think
we
should
like.
I
don't
want
to
add
in
manual
work.
So
I
think
these
are
ones
where,
when
we
find
we're
doing
manual
work,
we
should
try
and
see.
A
If
there's
anything
we
can
do
or,
as
I
say,
let's
just
educate
and
and
hope
we
don't
have
to
do
stuff
like
this.
A
Awesome
cool
and
then
the
second
thing.
This
is
a
slightly
unstructured
comment.
I
don't
just
give
a
bit
of
visibility,
though,
so
I
am
planning
to
add
a
comment
into
the
q3
okrs.
A
Actually,
sorry
missing
my
link
so
that
we
can
get
these
I'm
trying
to
work
out
the
the
wording
that
will
sort
of
fit
these
in.
So
the
main
change
I'm
going
to
do
is
to
tie
this
closer
to
our
strategy
stuff
but
I'll
add
an
issue
onto
the
add
a
comment
on
the
issue
so
that
graham's
got
like
all
the
same
context
as
well.
So
there's
two
things
I
want
to
change
here,
so
I
don't
think
the
actual,
like
tasks
will
will
really
change.
A
I
think
like
we
know
what
we
need
to
do
for
kubernetes.
We
know
we
need
to
do
around
mttp,
but
I
do
want
to
tie
this
to
our
strategy
so
I'll
frame
it
around
rollbacks
and
that's
the
kind
of
big
q3
thing
we
have
is
hardening
rollbacks,
so
we
can
pull
those
things
together
and
then
the
other
one
that's
just
come
up,
and
this
will
be
quite
likely
to
be
a
platform
level.
A
A
So
it's
very
unlikely
we'll
be
able
to
lift
and
shift
any
of
the
remaining
things
that
are
not
like
we're
not
already
like,
except
for
pages
right
so
redis
and
italy,
and
all
of
these
things
are
likely
that
we're
gonna
have
to
do
some
like
planning,
try
and
move
them
see,
what's
involved,
work
with
distribution,
so
we'll
try
and
set
up
an
okr
which
actually
gets
us
into
a
good
place,
so
that
q4
we
can
actually
like
start
picking
up
and
tackling
some
of
these
things.
A
So
I
don't
think
it's
any
different.
Like
yeah,
I
think
it's
exactly
what
we've
been
talking
about
with
italy
and
perfect,
but
and
also
read
this
as
well.
A
And
one
thing
which
we'll
have
to
think
about
is,
I
won't
put
it
in
the
okr,
but
we
need
to
think
about
is
the
big
challenge
that
myra
and
I
have
had
in
the
last
couple
of
weeks-
is
scheduling
in
a
production.
Rollback
is
incredibly
difficult,
so
we're
going
to
need
to
find
a
way
around
that
in
order
to
actually
achieve
our
rollback
strategy.
A
Basically
we're
going
to
need
to
be
able
to
roll
back
a
bit
more
frequently,
but
it's
not
super
easy
to
schedule.
These
things.