►
From YouTube: 2021-06-07 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
B
A
Hello,
how's,
your
how's
your
day
going.
You
see,
sunshine
behind
you,
she's
good,
hey
job.
B
Yeah,
it's
great
I'm
in
my
co-working
space,
finally
again,
which
I
I
think
wasn't
there
since
a
few
months
already
and
now
it's
starting
to
be
great
to
go
out
of
home
and
working
somewhere
else.
It's
really
cool.
A
C
A
Have
you
have
you
like
got
back
into
traveling?
Have
you
like
mastered
it
again.
C
It's
hard
to
say
I
got
like
very
bored
very
quickly
on
the
airplane
I
was
like.
This
is
maybe.
C
A
Yeah
everyone
in
london's
like
because
now
we've
got
pubs
and
restaurants
and
things
open
people
are
like,
oh
my
god,
I've
forgotten
how
to
use
these
things
like.
I
was
reading
an
article
in
the
paper
this
morning
and
we
have
qr
codes
everywhere
for
our
track
and
trace.
Apps
and
also
pubs
and
restaurants,
are
using
qr
codes
so
that
you
get
like
at
table
service,
and
she
was
saying.
Oh,
I
just
spent
20
minutes
like
trying
to
order
a
pint
from
the
nhs
track
and
trace
website.
A
So,
let's
get
started
so
I've
dropped
in
mttp
just
one
little
thing
I
want
to
note
on
that,
like
I
think
the
actual
mttp
target
is
completely
unsurprising
after
last
week
we
are
now
seeing
deployments
on
here.
I'm
gonna
follow
up
and
just
dig
into
where
those
are
being
tracked
from
I'm
not
sure
what
the
count
is,
and
it
looks
like
it's
probably
right,
but
I
just
want
to
double
check
that
it's
actually
production
deployments
on
there,
so
I'll
double
check
on
that
one.
A
For
you
as
well
a
few
announcements
is
there
anything
on
there
that
anyone
wants
to
discuss,
follow
up
on.
A
Nope,
okay,
awesome,
so
first
discussion
item,
so
robert
may
win
on
this
one
for
literally
sending
me
an
mr
like
a
minute
ago,
but
yeah.
It's
like
got
quite
a
lot
of
release.
Docs,
I
think,
are
either
a
bit
out
of
date
or
very
out
of
date
or
we've
got
new
tools
that
we
haven't
got
in
there.
So
just
as
we
kind
of
look
at
getting
graham
trained
up
as
well
as
for
the
rest
of
us
as
well,
but
be
good
to
get
those
updated.
A
D
A
How
about
or
would
it
make
what
about
so?
I
guess
there
are
two
times
right
when
this
stuff
is,
it's
super
easy
to
make
docs
updates.
One
is
you've,
just
literally
made
a
tool
change
right,
so
that's
one
and
the
other
is,
I
suppose,
like
either
as
a
release
manager
or,
as
you
finish,
being
a
release
manager.
It's
when
it's
super
fresh.
D
I
prefer
that
I
think
if
we
made
that
as
part
of
the
acceptance
criteria
for
the
work
that
we
do,
that
would
be
tremendously
helpful.
Like
not.
Every
piece
of
work
is
going
to
invoke
a
documentation
change,
but
certainly
some
of
it
will-
and
I
think,
that's
probably
going
to
be
the
easiest
way
to
keep
our
documentation.
A
Updated
so
could
we
make
sure
we
add
that
into
reviews,
if
you're,
if
you
review
something,
obviously,
if
you
make
a
tool
change,
please
try
and
remember
to
update
the
docs.
Also,
if
you're
reviewing
a
tools
change,
please
could
you
check
there
is
documentation
as
well.
A
Really
stocks
yeah
for
sure
yeah.
I
was
going
to
have
a
a
little
play
around
and
see
whether
we
might
actually
want
to
think
about
structuring
the
docs
differently
and
have
them
more.
Like
you
know,
I'm
deploying
or
like
deployment
failed
or
like
I'm
dealing
with
an
incident,
because
I
think
they're
kind
of
different.
At
the
moment
we
kind
of
just
have
a
pretty
much
long
list
of
things,
but
maybe
you're
actually
more
like
dealing
with
certain
events
that
have
different
types
of
docs,
yeah.
A
Okay,
how
about
one
other
suggestion
then,
which
is
if
someone
asks
a
question
subscriber,
can
I
chat
a
little
bit
about
this
last
week
like
if
someone
asks
a
question
like
try
and
respond
with
the
doc,
because
there's
a
couple
of
things
about
our
docs,
I
think,
which
is
one
is
like
we
either
haven't,
got
them
or
the
other
one
is
they're
really
hard
to
find.
So
if
you
can't
easily
find
your
answer
in
the
docs,
that's
also
a
really
good
indicator.
Even
if
it's
in
there
right.
A
Would
somebody
be
willing
to
update
the
mr
template?
That's
a
good
practical
suggestion.
A
E
A
A
A
A
Okay
cool,
but
please,
if
you
do
have
a
bit
of
spare
time
this
week,
I
know
scarbeck's
reading
a
lot
of
other
documentation,
but
if
you're
not
reading
any
other
documentation,
please
find
an
hour
also
just
check
over
our
release,
tools,
docs
and
see.
If
there's
anything
that
you
can
see,
that
could
be
updated.
I
think
there's
an
awful
lot
of
stuff.
We've
changed
this
year,
so
awesome
and
then
b.
I
wanted
to
just
give
a
little
bit
of
a
visibility
on
this
one.
A
So
thanks
for
everyone
for
effort,
so
far,
opening
up
incidents
handling
all
the
toil
that
comes
from
this
stuff
and
also
retro.
So
I
know
it
does
add
work.
There
are
I've,
put
my
an
idea
in
the
deployment
blockers
reporting
things
which
might
help
us
like
reduce
some
of
this
toil
it
may
not.
But
for
now
I
wanted
to
just
say:
please
keep
going
on
this
stuff
like
in
the
next
couple
of
weeks.
A
I
think
we
will
see
a
lot
of
it
because
it's
14.0
also
lots
of
people-
are
watching
this,
because
it's
14.0
and
we're
seeing
lots
of
interruptions.
So
people
are
reading
this
stuff
and
like
it
is
raising
a
lot
of
visibility
of
the
pain.
So
even
though
it
might
seem
a
bit
pointless
to
have
to
keep
raising
incidents,
please
do
that
and
we
can.
We
can
hopefully
automate
a
lot
of
this
stuff
quite
soon.
A
Awesome
c
is
used,
go
back.
D
So
we've
had
this
interesting
situation
where
we've
got
a
we've,
got
a
a
change
to
a
feature
that
is
trying
to
be
pushed
into
a
patch
release
which
goes
against
our
policy
and
I've
had
to
escalate
this
to
amy,
I
feel
like
we
have
a
gray
area
internet
in
our
documentation,
where
we
don't
clearly
define
what
a
bug
actually
is,
and
I
think
the
person
who's
been
trying
to
push.
D
I
think
the
situation
where
this
warrants
a
patch
release
for
the
safety
of
our
customers
is
warranted,
but
the
method
for
which
this
violates
our
policy
is
not
warranted.
So
I'm
curious
as
to
what
language
we
could
use
and
maybe
also
improving,
release
tools
to
help
us
police
items
that
have
the
pick
label
to
ensure
that
we're
picking
the
right
items.
D
Another
example
was
a
similar
merge
request
to
this,
where
the
pick
label
was
added,
but
it's
not
actually
fixing
a
bug.
It's
just
changing
some
language
inside
of
the
documentation
inside
of
our
code,
which
should
not
have
been
picked,
but
is
fine
because
it's
similar
to
a
documentation
change
by
by
chance,
but
I
think
we've
still
part
of
the
situation
where
people
are
overusing.
D
The
term
bug
in
this
case
to
apply
it
to
a
process
or
procedure
that
would
negatively
impact
customers,
but
that's
not
what
our
policy
dictates
and
I
think
we
need
to
modify
our
language
to
make
that
more
explicit.
That
way,
we
prevent
situations
where
we're
trying
to
push
something
in
place
unnecessarily,
or
vice
versa.
We
allow
it
because
currently
I'm
trying
to
push
back
on
this
because
it
it
is
a
change
to
the
feature
and
how
it
is.
D
D
A
I
think
it
might
be
interesting
to
have
a
look
at
like
I
think
it
sounds.
A
I
wonder
if
it
would
be
enough
for
chat
ops
to
validate
the
labels
on
things
kind
of
so
kind
of.
Like
you
know,
when
we
do
security
mergers,
we
get
kind
of
additional
information
about
the
the
mrs.
I
wonder
if
something
like
that
would
be
helpful,
where
it's
kind
of
like
you
have,
because
what
I'm
wondering
is
in
a
typical
patch
release,
what
mixture
of
things
are
we
actually
putting
out
I'd
be
wondering
whether
every
mr
actually
has
a
bug
label
on
it?
A
Normally,
I
suspect
it
may
not
either
just
because
it
didn't
get
added
or
docks
things,
or
I
wonder
what
combination
of
different
things
we
have
in
there.
D
Well,
release
tools
is
definitely
going
to
be
looking
for
the
pick
label
and
there's,
I
think,
there's
some
other
validation
making
sure
it
may
have
emerged
as
another
item,
but
I
don't
think
we're
looking
specifically
for
feature
or
bug
labels,
and
I
think
if
an
issue
is
labeled
bug
and
it's
got
a
pick
label
and
it's
been
merged,
I
think
it
should
be
safe
to
be
pushed
into
that
patch
release.
D
But
then
I
would
need
to
know
or
understand
why
a
feature
label
was
added
to
said
issue
or
merge
request
to
validate
that.
It's
not
calling
out
that
hey.
This
is
a
feature
of
gitlab
but
more
like
this
is
fixing
a
bug
in
a
feature
or
something
just
to
make
sure
that
we're
not
doing
the
wrong
thing.
When
we're
doing
pics,
I
don't
want
to
add
unnecessary
administrative
burden
to
the
persons
that
are
putting
together
the
merge
request.
But
I
also
don't
want
to
make
it
hectic
for
us
to
try
to
trace
that
backwards.
D
A
A
F
Do
we
still
generate
not
winning,
I
think
at
some
point
we
were
kidlaff
or
someone
who
were
generating
the
regression
labels
and
I
think
we
had
regressions
tied
to
each
milestone.
F
A
Label
would
it
be
worth
as
opening
an
issue
and
just
running
a
quick
like
review
of
like
say
the
last
five
ten
patches.
However,
whatever
number
seems
sensible
have
a
look
at
what
labels
were
on
the
mrs
that
went
into
those
and
see
if
we
can
actually
see
like?
Are
there
some
clear
ones?
We
can
definitely
cut
or
others
that
we
could
add
in
that
would
help
us
group
those
things.
D
B
I
have
one
question:
do
we
use
severity
labels
on
on
patches?
B
B
D
A
A
D
A
D
A
Cool
thanks
for
raising
that
up
go
back.
Let's
see
we
can
do.
A
But
I
also
agree:
let's
have
a
think
about
what
we
can
say
on
that
on
the
bug
fixes
thing
on
the
actual
maintenance
docks
again.
It
might
be
interesting
to
see
what's
in
there,
but
maybe
we
should
turn
that
to
be
like
regressions
or
something
and
actually
have
it
where
people
have
a
special
case
where
they
come
to
us
with
like
hey.
This
is
a
bug
fix,
but
it's
not
a
regression
and
we
can
have
a
conversation
there.
D
A
D
D
F
Well,
we
should
probably
exclude
dangerbot
from
prep
branches.
There
is
no
reason
for
awesomeness
yeah.
I
mean
that's
not
absolutely.
F
I'm
not
sure
how
easy
it
is,
but
it
should
be
an
issue
on
the
gitlab
product.
We
probably
need
to
modify
like
a
rule
on
the
gitlab
ci
jumble
to
avoid
triggering
danger
bot
on
prep
branches.
D
A
That
will
be
passed
yeah.
I
think
my
suggestion
is
a
good
one,
though,
because
the
what
it
the
danger,
bot
addition
for
changelogs
was
really
just
to
kind
of
remind
developers
and
like
kind
of
be
a
bit
of
a
helping
hand.
I
think
if
we
don't
have
that,
it's
not
the
end
of
the
world
right,
everybody
should
know
of
them
and
there's
documentation,
but
yeah
I'd.
Rather,
we
weren't
having
to
manually,
merge
things
in
myra.
A
F
Avoid
running
danger
or
specific
rules
in
danger
when
targeting
the
stable
branch,
so
we
can
probably
extend
that
to
also
use
the
same
sort
of
rules
for
prep
branches.
Okay,.
A
A
Perfect
job.
G
Thanks
I'll
keep
mine
short
because,
most
out
of
time
I
just
wanted
to
link
to
the
deployment
related
incidents
and
any
help
you
guys
can
give
for
helping
to
like
close
them
out
would
be
appreciated,
yeah
I'd
like
them
to
have
timelines
and
great
directions
as
well.
Amy.
To
your
point,
I
think
that's
a
good
point
to
make.
I
think
the
problem
here
is
that
maybe
the
eoc
doesn't
know
even
who
to
bother.
G
I
guess
I
can
tell
them
to
talk
to
the
release
manager
and
the
developers
involved
in
some
cases.
It's
not
like
really,
you
know
it
depends.
I
guess,
on
the
incident,
but
like
what
what
I've
been
seeing
is
like
a
lot
of
these
instances,
just
stay
open
for
weeks
and
then
we've
moved
on
to
other
things
and
there's
such
a
backlog
that
we
have
to
close
them
before
we
get
them
fully
fleshed
out.
A
Yeah,
so
I
think
I
suppose
it
depends
what
you
mean
by
the
for
the
types
of
incidents
the
release
related
like
so
I
think
generally,
when
we
are
expecting
that,
if
we
raise
the
incident,
then
we
will
close
it
out.
Is
that
what
you
are.
G
G
Formalize
that
a
bit
more,
I
don't
know,
I
think,
there's
some
gray
area
between
incidents
that
like
may
maybe
a
release
manager
open,
you
know,
declares
an
incident
and
then
it's
infrastructure
related,
it's
not
like,
but
there's
other
ones
that,
like
I
don't
know,
the
merge
train
is
blocked
and
it
has
nothing
to
do
with
infrastructure.
G
I
I
don't
know,
but
if
you
can
just
keep
these
on
your
radar
and
help
to
triage
and
close
them,
that
would
be
very
helpful.
A
Do
you
want
to
work
with
me
on
that
one
in
that
case
jeff,
because
I
think
perhaps
some
of
these
get
closed
out
quicker
than
I
would
expect,
because
I
think
what
we
see
for
a
lot
of
these
instances,
there's
a
lag
as
we
kind
of
get
development
involved
and
like
quality,
and
so
I
think
sometimes
it's
more
that
it's
not
that
they've
been
abandoned,
but
there
is
more
stuff
we
should
do.
So
if
you,
if
you
think
that's
the
case,
then
like
yes,
assume
we'll
handle
these.
A
If
you
think
anything
has
been
neglected,
then
give
me
a
ping
and
I'll
I'll
check
in
on
that
one.
So,
for
example,.
G
Yeah
I
mean
there's
there's
I
think
the
oldest
is
two
weeks,
but
there
are
a
couple
of
those
plus
a
couple
that
were
created
last
week
and
don't
don't
look
at
the
updated
time?
Look
at
the
created
time.
That's
what.
G
What
I'm
looking
at,
maybe
we
need
a
root
cause
for
tooling,
and
that
would
help
signal
like
okay.
If
it's
tooling,
then
we
send
it
over
to
the
release
manager.
If
it's
infrastructure,
then
you
know
the
the
eoc
can
handle
it
but
yeah.
Let's
talk
about
it,
see
what
works.
A
B
Yeah,
I
would,
I
would
suggest
often
we
open
these
kind
of
incidents
with
saying
you
see,
please
don't
care,
it's
deployment
related
right
and
in
this
case
it's
clear.
It's
not
the
eoc
who
should.
A
B
Ownership
and
in
this
case,
maybe
assign
yourself
as
a
release
manager
to
this
incident
at
least
additionally,
so
you
know
you
are
at
it
and
and
own
it,
and
the
ufc
can
still
be
owner
of
this
one
or
we
remove
him
or
she,
if
you
think,
it's
not
necessary,
but
I
think
adding
your
surfacing
assignment
makes
sense
in
every
case.
A
Yeah
cool
okay:
let's
catch
up
with
that
one
job
and
see
what
we
need
to
put
in
place
to
make
that
happen.
A
Awesome
skybeck.
A
So,
there's
a
really
good,
it's
not
sure
it's
linked,
but
there's
a
really
quite
a
good
explanation
in
the
issue
that
myra
is
working
through
as
well,
maybe
murray
you
can
drop
the
link
in
which
kind
of
shows
it
quite
nicely.
What
to
expect
one
thing,
maybe
for
myra
you
to
have
a
think
about
and
perhaps
chat
to
alessio
about
is
graham
raised,
a
great
point
that
the
naming's
really
confusing,
because
in
his
mind
he
talked
we're
talking
auto
deploy
branches
and
he
wasn't
really
sure
why
we've
named
it
coordinated
deployments.
E
Yeah
yeah,
okay,
I
guess.
F
It
is,
from
my
perspective,
a
bit
weird
to
name
it
how
to
deploy
pipelines,
because
not
everything
in
the
coordinated
pipeline
is
related
to
an
auto
deploy
pipeline.
We
have
the
omnibus
tagging
and
the
helm
tagging
and
the
deployments
I
mean
the
deployments
are
sort
of
spawned
from
up
to
deploy
pipeline,
but
I'm
not
sure
perhaps
it
is
in
my
head
to
call
it
after
deploy
pipeline
when
it
is
not
referring
to
enough
to
deploy
branch.
D
A
Okay,
that
makes
sense,
in
which
case
I
think
we
definitely
have
some
docs
updates,
because
I
think
we
talk
a
lot
about
auto
deploys
which
makes
sense,
but
now
we're
kind
of
wrapping
those
in
something
higher
up,
which
I
think
is
going
to
be
hard
for
people
to
come
in
on.
But
that's
fine,
that's
a
separate,
separate
topic
anyway.
Awesome
so
stop
the
recording.