►
From YouTube: 2022-07-25 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
So
this
is
25th
of
july
2022,
delivery
group
weekly,
welcome
everybody
and
good
morning
or
good
afternoon
or
wherever
you
are
so
we
have
a
few
announcements
this
week,
aquin
is
going
to
be
out
unless
you
out,
as
well
until
august
17
and
I'm
gonna
be
out
from
august
5th
to
august
12th
just
be
in
mind
with
that.
B
In
addition
to
that,
we
have
a
new
results
for
the
pulse
survey
for
q2
of
financial
year
2023.
There
is
the
link
on
the
agenda
to
the
presentation.
B
There
are
some
results
there
in
addition
to
that,
just
to
mention
that
the
platform
is
actually
having
their
own
kind
of
survey
on
this
kind
of
information,
so
we're
actually
trying
to
be
a
bit
more
glamorous
there
and
so
on
see
if
you
remember
that
was
sent
in
q2
and
it's
going
to
be
another
one
sent
probably
a
month
or
so.
So
we
are
trying
to
look
at
that
a
bit
more
closely,
so
to
have
a
better,
also
understanding
of
the
needs
of
the
platform
team
members.
B
C
B
Add
these
two
discussion
points
to
today's
agenda.
One
is
the
first
one
is
the
fastboot.
So
in
the
last
weeks
me
and
amy
worked
a
lot
to
find
possible
solutions
for
dates
and
locations
and
so
on,
so
we
actually
make
added
to
the
document
only
some
of
them.
So
we
also
added
some
solutions,
even
for
for
florence,
on
the
same
day
that
we
were
proposing,
because
alessio
might
have
some
problems
to
join
the
case,
it
was
a
bit
out
of
florence,
but
also
his
imploring
is
gonna,
be
a
bit
tricky.
B
In
addition
to
that,
we
have
the
one
for
berlin
with
two
dates.
Another
date
was
the
end
of
august,
so
the
week
after
contribute.
B
In
theory,
I'm
not
sure
if
this
would
be
a
day
that
would
have
worked
for
everybody,
but
there
was
a
lot
of
problems
with
finding
an
overlap
with
for
everybody,
everyone's
availability
and
also
trying
to
keep
the
costs
low.
So
flights
are
in.
A
B
B
We
are
not
intending
to
cancel
this
fastboot
proposal,
but
we
are
actually
probably
trying
to
maybe
refine
a
bit
more
the
content
and
trying
to
also
push
it
a
bit
further
in
in
the
year,
maybe
around
the
end
of
the
year,
or
something
like
that
or
the
beginning,
and
try
to
push
it
to
that
moment
also
to
to
be
able
to
get
a
bit
further
out
from
the
visiting
ground.
That,
yes,
has
them
here
just
approved,
and
so
maybe
people
can
try
to
also.
B
Now,
in
addition
to
that,
clearly,
the
cost
of
the
visiting
grant
are
much
lower
on
the
our
facebook
proposal,
so
we
should
be
able
to
some
strong
content
and
strong
goals
they
want
to
achieve.
In
that
any
comments
on
that.
Anyone.
B
B
So
if
we
are
finding
some
synergies
or
in
the
goal
that
we
want
to
work
on,
maybe
something
that
is
around
such
a
deployments
and
having
like
both
orchestration
system
working
together
that
in
one
week
I
think
it's
it's
going
to
be
probably
very
beneficial.
In
addition
to
that,
I
think
it's
going
to
be
very
good
for
everybody
to
meet
all
together,
because
at
the
end
we
are
still
one
team
and
I
think,
at
the
end
it's
important
that
we
all
get
to
know
each
other
together.
E
C
Be
the
evolution
of
that,
and
this
is
actually
to
kind
of
repeat
a
little
bit
of
what
mckelly
is
saying.
Is
we
don't
want
you
all
to
miss
out
on
having
the
chance
to
use
the
visiting
ground
like
if
we
do
a
fast
boot
in
this
quarter,
we'll
be
using
that
visiting
grant
at
the
moment
it
doesn't
look
like
we'll
be
able
to
get
something
together
in
time
that
fits
this
grant.
C
So
that's
kind
of
why
we're
now
we'll
say
for
sure
we
won't
be
trying
to
put
a
fast
boot
in
for
q3,
but
strongly
encourage
you
all
to
take
advantage
of
this.
If
of
this
grant,
if
you
want
to
in
q3,
but
no,
I
wouldn't
assume
it's
going
to
be
extended.
I
believe
this.
This
is
a
a
q3
specific.
A
B
I
added
also
another
point
to
the
discussion
of
today,
so
we
got
me
an
emmy
last
week
by
steve
about
a
couple
of
incidents
that
happened
during
the
soft
pcl
of
the
release
day.
B
So
there
were
some
discussion
from
jar
from
myself
and
from
amy,
maybe
to
try
to
try
to
establish
maybe
a
single
source
of
truth
for
pc
ads,
so
that
can
be
created
by
tooling
and
also
like.
Where
can
people
can
know
where
this
kind
of
when
the
pcl
dates
are
set,
and
maybe
build
some
automation
around
that?
So
there
is
a
I
don't
want
to.
B
I
mean
I
didn't
want
to
propose
a
solution
there,
but
I
wanted
to
maybe
have
more
of
a
discussion,
but
probably
involving
chat
ups
and
having
singles
also
through
there
to
build
automation,
probably
could
be
something
very
useful
and
that
can
be
shut
off
can
be
used
both
to
understand
if
there
is
a
pcl
ongoing,
but
also
like
all
the
various
commands,
maybe
check
automatically.
The
pcl
is
ongoing
in
the
moment
that
a
feature
flap
is
going
to
be
flipped
or
other
activities
in
production
can
and
can
happen.
B
Clearly,
not
everything
is
going
through
chatups,
so
crs
sometimes
are
executed.
You
know
outside
of
chat
ups
and
so
on
a
possible
solution.
There
would
be
to
introduce,
maybe
in
the
approval
list,
just
to
make
it
a
bit
heavier
the
execution
of
a
chat,
ops
command
to
understand
if
you
are
under
a
pcl
or
not,
and
to
be
sure
that
this
is
like
a
agreed
from
everybody.
B
A
C
I
was
just
gonna
comment
right.
I
was
literally
gonna
just
say
around
hands
of
ownership,
so
there's
a
piece
that
very
much
falls
on
us,
which
I
have
on
my
list
to
open
nmr
for
which
is
our
handling
of
deployments.
So
that's
quite
a
straightforward
bit.
C
Then
there
is
a
kind
of
shared
ownership
which
does
fall.
It
falls
on
everybody,
but
perhaps
a
little
bit
heavier
on
delivery,
which
is
around
feature
flags.
So
there
is
no
real
single
owner
of
feature
flags,
but
certainly
delivery
benefit
the
most
from
everybody
else
using
them.
So
that's
where
it
does
as
good
to
also
kind
of
help
out
in
this
case,
in
terms
of
crs,
I
think
that's
infra
and
maybe
a
little
bit
more
reliability.
So
I
don't
think
we
necessarily
have
to
drive
the
the
resolution
of
that.
B
D
D
C
At
the
time
the
issue
was
raised,
it
was
suspected
a
deployment
may
be
the
cause
it's
been
confirmed
since
then
that
it
wasn't
so.
I
think
the
urgency
from
outside
has
dropped
a
little,
but
it
still
highlights.
Certainly
it
still
highlights
a
gap
which
actually
do
they
do
have
a
pcl
on
the
22nd.
I
think
there
is
real
benefit
to
us.
C
Having
that
actually
one
suggestion
I'm
to
make-
and
my
perhaps
see
if
you
have
a
strong
disagreement
with
this,
is
I
actually
wonder
if
we
should
not
like
deliberately
not
run
post-deploy
migrations
at
any
point
around
that,
because
one
of
the
things,
although
in
this
case
the
incident
wasn't
deploy
related
one
of
the
early
questions
was
like.
Could
we
roll
this
back
and
unfortunate
timeless
achmed
had
literally
just
run
the
post
deployed
migrations?
So
I'm
thinking
that
perhaps
on
the
22nd
we,
you
know
there
are
some
benefits
to
non-risky
changes
taking
place.
C
I
think
we
still
want
deployments
and
I
said
to
steve:
there
is
a
lot
of
benefit
for
us
deploying
because
otherwise
we
can't
do
a
patch
release,
but
perhaps
we
we
do.
We
do
still
make
use
of
the
soft
pcl.
B
Just
to
add,
on
top
of
what
you
just
said,
scarbec,
if
you
look
also
cr
that
actually
started
the
problem
due
diligence
here,
there
is
not
been
done,
so
no
change
approval
or
change
to
the
technician.
Reviewers
has
been
checked
the
boxes.
C
So
if
people
have
more
ideas,
one
thing
I
was
going
to
suggest
because
I
think
feature
flags
do
benefit,
is
if
reliability
were
able
to
get
pcls
into
some
centralized
location.
C
We
could
potentially
update
our
production
health
check
and
add
in
there,
just
as
information
hey,
there's
a
pcl
in
place,
you
wouldn't
need
to
do
anything
to
override
it,
but
if
you
were
deploying
it
would
just
give
you
a
prompt
and
a
developer
could
have
the
same
information
which
is
like
hey
a
pcl
is
under
under
like
operation,
and
we
then
trust
individuals
to
go
check
out
what
that
means
and
get
the
required
approval
before
they
proceed.
A
A
D
How
about
I
start
and
if
myra
says
I
did
anything
wrong
with
my
sharing
of
knowledge.
She
could
be
like
john
you're
very
wrong.
D
Let's
see
last
week,
I
feel
like
the
number
of
packages
we
tagged
was
a
little
off
we're
like
a
little
like
more
than
50
percent
off
the
beginning
of
the
week,
but
then
we
caught
up
nicely
near
the
tail
end
of
the
week.
I
think
we
had
some
incidents
at
the
beginning
of
the
week
that
was
probably
leading
towards
this,
but
we
got
there
at
the
end
of
the
week,
which
is
very
good
right.
C
C
So
that
makes
sense,
but
I
don't
have
anything
at
all
for
for
that
middle
of
the
week.
So
could
you
it
might
be.
That's
fine,
but
would
you
mind
just
double
checking
that
we
haven't
missed,
missed
something?
This
is
going
to
be
super
important
this
month,
because
mttp
is
really
high,
which
is
explainable,
but
it
does
mean
that
we
will
have
to
explain
that
in
the
next
key
metrics
meeting.
A
D
So
the
other
one
we're
looking
at
is
the
deployment
frequency.
Last
week
we
averaged
3.8
per
day,
which
I
think
is
pretty
good.
I
think
that's
pretty
much
an
alignment
with
where
we
usually
are
like.
D
E
Nope,
I
think
it
shows
that,
like
the
weekend
is
shown
there
like
july
23rd
and
july
24,
which
we
didn't
have
and
that
we
are
slowly
decreasing
again
in
july,
25th.
D
Whatever
the
last
one
was
the
lead
time
which
looks
like
this
and.
D
C
D
Yeah,
it
does,
or
at
least
when,
like
in
the
middle
of
the
week
when
we
heard
we're
less
than
50
percent
of
promoting
packages
during
that
week,
but
we're
still
like
near
our
target.
So,
like
I
don't
know,
if
there's
a
you
know,
we're
off
by
three
hours.
C
And
I
think
I
mean
so
you
know
this
week
is
a
little
bit
less
relevant
because
I
know
scarborough
and
ruben
have
already
discussed
it,
but
this
is.
This
is
the
point
to
sort
of
say
we
need
to
change
the
frequency
or
we
need
to
fix
this
or
if
I
had
three
engineers
swarmed
on
this
thing,
that's
really
been
blocking
us.
It
would
be
great.
So
that's
what
we
like.
C
For
the
I
mentioned
the
key
metrics
meeting,
so
we
will
certainly
put
an
update
in
for
mttp
over
this
last
month.
I
realized
one
thing
that
we
that
has
massively
impacted
this
month,
that
we
didn't
mention
on
any
of
our
package
sort
of
tagging
graphs
over
the
previous
weeks
when
we
discussed
it,
which
is
graham,
was
out
for
two
weeks
and
actually
you
can
see
a
really
big
impact
on
the
mttp
monthly,
it's
the
highest
we've
had
since
november,
and
that
will
largely
be
because
there
were
no
apac
deployments
plus.