►
From YouTube: 2021-05-24 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).
A
C
C
So
you
have
a
little
look
so
still
tracking
on
the
blockers.
We
said
in
march
when
we
dropped
mttp
to
24
hours
when
we
get
two
weeks
without
incidents.
C
We'll
do
that
since
then,
we've
had
one
week
without
incidents,
so
I
won't
be
dropping
this
just
yet,
but
we
are
continuing
to
monitor
and
track
on
those
things,
but
it's
still
it's
looking
very,
very
healthy,
given
incidents
right,
so
I
think
the
data's
probably
caught
up
by
now
I'll
double
check,
but
our
review
at
the
end
of
this
week
I
mean
we
know
we
this
week
is
not
instant
free
because
we've
already
had
an
incident,
but
we'll
take
a
look
and
keep
tracking
on
that
stuff.
So.
A
C
B
C
It's
probably
like
midweek
yeah,
but
I
think
it'll
still
have
the
big
one
in
it,
but
actually
the
thing
that
we're
really
seeing
visibly
here
is
the
impact
of
the
additional.
We
now
have
four,
we
do
like
four
branches
and
actually
the
timing
of
those,
I
think,
is
quite
effective
and
I
think,
since
we
started
doing
that,
we've
we've
seen
quite
a
big
improvement
on
mttp.
A
A
C
I
think
it's
the
eight,
the
the
seven
am
one
is
quite
an
impact
for
one
to
squeeze
that
in
earlier.
I
think
that
had
quite
a
big
impact
on
things,
but
I
don't
know
absolutely
sure,
because
I
haven't
analyzed
it
super
close.
But
that's
my
impression
is
that
we
I
mean
mttp
actually
overall
looks
very
healthy.
If
you
look
back
over
the
year,
which
maybe
says
a
lot
about
incidents
we
have
always,
but
certainly
at
the
moment
it
could
be
better.
I
think
so.
B
I
usually
do
at
least
in
the
morning
the
morning
one
is
around
100
200,
then
the
mid,
the
the
second
in
the
morning
less
than
100,
and
then
I
just
I
get
too
tired
to
continue
looking
but
yeah.
So.
C
C
C
Yeah
cool
and
then
there's
various
announcements
I
won't
get
through
any
of
them
unless
anyone
particularly
wants
to.
Let's
go
up
for
the
unpausing.
Usually
we
do
it
well
at
some
point
on
on
the
monday
morning,
sunday
night
monday
morning
for
the
umpus.
B
Yes,
so
I
was
going
to
ask
regarding
the
new
jihoo
process.
If
we
are
still,
we
still
have
no
access
to
the
issue,
and
so
we
go
through
you
or
okay.
C
Yes,
please
do
yeah
for
this
one.
I've
asked
I've
added
a
note
to
the
issue
to
point
out.
You
don't
have
access
so
discussing
what
to
do
about
that,
but
yeah,
please,
for
this
month,
just
feel
free
to
give
me
a
ping
at
the
appropriate
time.
B
B
C
Month,
it's
yeah
that
is
being
reviewed.
Yes,
I
hope
it
gets
decided
soon,
but
yeah
for
this
one,
and
unless
you
let's
go
at
your
point
as
well
once
we
know
the
timing
and
where
to
go,
we've
got
access,
we'll
just
automate
this
so
cool.
C
So
on
discussion
item
last
week
we
had
interesting
problem
on
friday,
where
we
had
an
environmental
problem
that
hit
us
on
release,
which
we
didn't
see
until
we
put
the
release
candidate
on
there
now
in
places,
I've
run
in
the
been
in
the
past,
where
we've
actually
had
fairly
infrequent
test
runs
on
an
environment.
We've
run
them
a
bit
more
regularly.
So
what
do
you
think?
Should
we
run
the
release
test?
C
Suite
say
at
the
same
time
we
cut
the
branch
or
a
couple
of
days
before
we
intend
to
run
the
tests
on
the
new
release
candidate,
and
then
it
maybe
wouldn't
have
in
this
case,
but
at
times
maybe
it
will
cut.
It
will
highlight
environmental
problems
that
we
could
be
fixing
ahead
of
the
release
candidate.
A
A
We
already
do
that
in
staging
and
canary
on
a
regular
cadence,
like
I
think,
they're
daily,
if
not
more
often,
but
for
the
release,
and
since
we
could
probably
run
that
say,
weekly
or
something
and
that
should
suffice.
I
would
imagine.
C
A
C
I'll
open
up
an
issue
we
can
do
that
just
might
separate
out
the
what's
the
release
candidate
problem
versus.
What's
a
release
environment
problem.
B
Yeah,
because
this
is
a
problem
that
happened
late
in
the
evening,
the
the
one
that
robert
was
there,
you
were
looking
at
the
regular
expression.
Is
that
one?
Yes.
B
There's
it
was
an
email
removed
from
the
regular
expression
was
not
matching.
If
I
remember
so
that
one
was
just
specific
to
pre,
so
it
was
not
about
rc
ver.
It
was
in
that
case,
was
I
mean
doing?
An
extra
rc
would
not
wouldn't
have
saved
us
from
this
problem,
because
it
was
just
deploying
debris.
Okay,
fine
on.
B
Yeah
exactly
so
on
the
erc
aspect
of
this
problem.
So
no
not
the
problem
that
we
had.
I
had
a
com
I
think
was
starting
with
yorick.
I
don't
remember
regarding
something
else.
I
had
a
proposal
to
run
regular
erc
creation
from
previous
stable
branch
so
that
we
exercise
the
full
rc
pipeline
more
often,
instead
of
just
two
days
before
the
release
that
you
never
know
what
can
happen.
So
I
just
give
you
an
example
here,
which
is
so
it's
easier
to
figure
out
what
I'm
talking
about.
B
Instead
of
waiting
for
the
18th
to
run
the
14.00,
we
start
doing
2
13.12.1,
whatever
rc
number
x
right
now,
so
I
mean
right
now:
it's
not
important
because
we
did
last
week,
but
maybe
next
week
we
run
another
c
for
the
current
stable
branch
so
that
it
doesn't
generate
random,
stable
branches
or
things
like
that.
It's
the
14.
is
untouched,
but
we
still
test
the
release
pipeline
and
everything
for
erc
candidates
and
as
well
as
the
enviro,
the
the
environment
yeah,
which
is,
is
pretty.
A
B
It's
an
empty
package
because
it's
from
the
stable
branch
there
is
nothing
on
the
stable
branch
is
exactly
the
same
package
that
is
already
running
there
with
a
different
name.
So
the
only
change
is
the
version
file.
Okay,
never
mind
that.
I
mean
it's
it's
important.
It's
an
important
distinction
right,
yeah.
B
Kind
of
no
risk
it's
just
testing,
there's
always
risk,
but
as
interior
is
just
testing,
release
tools,
pipelines
and
so
the
deployer
and
release
tools.
C
I,
like
the
idea,
I
think
anything
we
can
do
to
separate
out
the
just.
The
number
of
question
marks
that
come
in
on
that
last
week
would
be
good.
One
thing
I
will
have
to
do
is
just
tie
that
into
the
jihu
process,
so
just
give
them
a
heads
up
on
at
these
dates.
This
stuff
happens
and
here's
what
they
need
to
do,
which
I
can
absolutely
do
do
you
know
if
we
already
have
an
issue
for
this
celestia,
I
know.
Maybe
I.
B
C
Find
but
just
literally
like
a
kind
of
a
here's,
what
we
want
to
do
and
here's
what
will
get
created
super
simple
and
then
I
can
ping
the
jihu
team
on
that
one
because
yeah.
I
think
this
is
a
good
idea.
If
I
is
there
anything
else
that
we
want
to
prioritize
so
that
I've
updated
the
priorities
and
the
board
already
has
a
bunch
of
these
things
and
robert's
already
cracking
through
a
ton
of
them
already.
A
I
created
a
tiny
issue
this
morning.
It's
a
small
quality
of
life,
improvement
related
to
environments
being
locked
because
that
deployment
may
fail
and
the
fact
that
we
need.
A
C
Makes
sense,
I
think
yeah
for
this
month,
don't
be
shy.
Any
of
those
things
don't
feel
like
it
has
to
be
the
big
justification.
If
we
can
see
improvements
that
will
make
release
management
easier,
drop,
an
issue
in
give
me
a
shout
and
let's
see
what
we
can
do
with
those.
C
And
also
well
done
for
everyone
last
week
like
great
team
effort,
great
release,
management
and
saturday
was
not
stressful
at
all,
which
I
was
hugely
relieved
throughout
so
yeah.
Thank
you
well
done.
A
A
C
Awesome
myra.
You
have
next
one.
E
Yep
thanks,
so
I
wanted
to
discuss
what
is
everyone's
workflows
to
discuss,
to
unblock
team
members
because
well
on
the
back-end
side,
now
that
we
are
down
by
one
team
member,
I
am
receiving
multiple
pings,
whether
they
are
individual
pings
or
whether
they
are
group
beings.
E
I
think
responding
within
the
24
hours
is
quite
acceptable.
48
hours
might
be
ok,
but
more
than
48
hours.
That
means
that
I
am,
I
am
blocking
someone
that,
and
that
is
something
that
I
don't
want
to
do
so
yeah.
Basically,
that
is
my
workflow
checking
my
to-do
list
prioritizing
my
mentions
and
well
respond.
A
I'll
follow
a
similar
procedure,
but
there
are
certain
times
where
usually
I'll
try
to
quickly
read
up
on
what
the
actual
issue
is
like
amy
pings
us
all
the
time
on
things,
but
it's
unreasonable
for
me
to
drop
everything
I'm
doing
and
respond
to
everything
she
pings
me
on
within
24
hours,
so
stuff
like
that
I'll
just
try
to
figure
out.
Can
I
respond
later
and
if
I
can
that's
precisely
what
I
end
up
doing
is
just
I'll
leave
it
in
my
to-do
list
for
a
longer
period
of
time.
A
B
Yeah
I
have
a
similar
one
as
well,
so
I
think
that
the
problem
for
for
you
myra,
is
more,
is
excessive,
yeah,
it's
more
strong
because
you
also
have
maintainership,
so
you
get
database
maintainer
pings,
you
get
rails,
maintainers
ping,
you
get
our
pings,
you
get
delivery,
pings
and
then
things
assigned
to
you
directly
for
review
either
by
the
team
or
outside
of
the
team.
So
this
is
a
lot
of
things
coming
to
your
way.
B
So
if
you
are
not
already
doing
consider
having
rotation
with
your
status
or
you
put
the
the
red
dot
or
the
light
bulb,
so
just
for
a
couple
of
days,
you
get
less
things
coming
your
way.
This
I
mean
this
is
so
this
is
an
extra
suggestion,
but
I
do
scan
through
to
do's
like
you
and
if
it's
a
group
mention
it
goes
below
in
my
priority
list.
If
it's
a
direct
mention,
then,
if
it's
from
our
teams
or
not,
then
I
try
to
handle
things
in
different
way.
A
Myra
consider
hiring
an
assistant.
E
Well,
thank
you.
Everyone
for
your
ideas,.
D
C
I'm
gonna
say
yeah.
I
I
when
you're
like
oh
a
day,
is
a
long
time,
I'm
like
lucky
people
who
only
have
to
wait
a
day
for
me.
E
Well,
I
think
if
all
of
us
aim
to
answer
each
of
us
based
on
priority
and
within
less
than
24
hours,
then
I
think
we
should
be
fine
and
unblock
everyone.
So
that's.
E
E
Well,
I
have
the
next
point
yeah.
I.
B
Just
want
to
add
something
to
this
one
very
quickly,
so
at
least
for
me,
if
I'm
blocking
someone
just
ping
me
because
I
try
to
prioritize
accordingly,
but
sometimes
you
just
quickly
look
at
something.
Maybe
this
can
wait,
and
maybe
this
can't
wait
so
no
problem
at
all.
If
something
is
important,
if
something
is
a
blocker
and
you
need
a
quicker
answer,
just
ping
me,
I
mean
I'm
just
giving
this
as
a
general
advice.
B
So
if
I
need
something
I
usually
ping
someone
and
please
don't
see
this
some
kind
of
route
or
me
trying
to
just
go
over
your
priorities,
I'm
just
making
you
aware
that
this
is
important
and
because,
maybe
with
the
to-do,
this
is
not
very
clear.
So
just.
C
E
Okay,
so
the
next
one
is
that
I
noticed
that
the
security
release
is
scheduled
for
this
friday
and
this
friday
is
5
million
friends
day.
So
we
probably
need
to
move
it,
and
also.
I
noticed
that
the
new
changelog
workflow
that
requires
for
the
changelog
to
be
in
the
commit
instead
of
the
file
we
have.
E
I
don't
know
how
it's
called,
but
it
is
some
sort
of
rule
that
it
is
going
to
prevent
merging
merchandise,
with
a
changelog
on
security
and
on
canonical,
so
that
is
actually
going
to
interfere
on
the
automatic
merging
of
security,
merge
requests
and
we
probably
need
to
give
them
some
more
time
to
developers
to
actually
readjust
their
merch
quest
and
get
them
approved
again
and
whatever
so
yeah.
So
your
thoughts
about
rescheduling
this,
I
already
have
an
issue
for
updating
the
security
release
process.
B
A
A
Unless
everyone
has
any
comments,
I'll
just
adjust
it
to
monday,
which
I
believe
is
the
31st.
C
And
in
terms
of
the
helping
developers
with
the
new
changelog
stuff,
like
I
mean
uric,
is
around
responding
to
stuff
in
development
channel.
If
there's
anything,
we
can
do
on
our
side
in
terms
of
like
making
it
visible
to
people,
what
stuff
is
failing
the
merge,
then
that
would
be
good,
but
I
think
otherwise,
let's,
let's
get
eureka-
you
know
like
handhold
people
through
he
is
responding
to
stuff
and
help
them
help
them
know
what
to
do.
C
B
Something
on
this
as
well,
so
if
we
are
still
aiming
for
monday,
because
friday
I
mean
friday
is
five
minute
friend's
day,
so
nobody
will
be
working
regardless
right.
So
I
think
we
are
still
kind
of
late,
because
tomorrow
we
should
start,
but
if
nothing
will
be
merged,
because
everything
has
problems
with
changelogs
and
things
like
that.
C
C
C
Actually,
that's
a
good
point
in
terms
of
actually
my
it
might
be
good
to
get
that
done
like
as
soon
as
you
can,
and
then
you
can
use
that
as
the
kind
of
basis
for
the
message
right
and
feel
free
to
use
the
notify
command
and
just
broadcast
it
around.
But
just
tell
people
we
updated
the
process
based
off
this.
You
need
to
update
your
back
ports,
they
will
fail,
as
is,
and
then
they
can
all
just
take
action.