►
From YouTube: 2022-08-08 Delivery group 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
So
welcome
everyone.
Here
we
go.
A
Hey
everyone
so
welcome
to
monday.
We
have
a
few
things
in
the
read-only
announcements
section
which
I'll
let
you
go
through
in
your
own
time.
The
only
big
thing
I
want
to
call
out
is
with
a
few
people
out
this
week.
A
There
will
be
less
of
us
around,
particularly
we
tripped
a
bit
before,
but
you
will
may
get
tagged
on
ruby
like
back
end
reviews,
if
needed,
we
have
other
options
as
well,
but
if
ruben
needs
to
merge
anything
we
may
be
able
to,
we
may
need
to
help
him.
I
am
completely
fine
with
us
merging
in
something
which
we
think
looks
good,
even
if
you're
like
I,
I'm
a
little
unsure
about
some
pieces
right
like
we
can
always
follow
up
in
the
next
few
weeks,
when
alessio
and
myra
are
back.
A
A
And
the
other
big
thing
I
want
to
just
mention
is
since
we're
on
the
first
call.
Congratulations
gabeck
huge
achievement
very
well
deserved
on
your
promotion.
A
Cool,
so
let's
jump
into
the
discussion
items
so
mckelly
and
I
are
continuing
to
kind
of
work
through
the
admin
side
for
the
team
split.
So
we've
now
got.
I
think
we
have
labeled
all
the
existing
delivery
issues,
so
you'll
have
system
or
orchestration
on
there
and
we'll
we're
continuing
like
again
just
working
on
the
triage
rules
so
that
we
can
get
that
on
on
future
issues
coming
in
as
well.
A
But
I'm
curious
to
hear
since
I've
got
you
all
face
to
face
is
as
we're
going
into
q3
and
we
have
okrs
we're
now.
Looking
kind
of
we
have
two
teams
and
we're
sort
of
working
on
our
separate
goals.
A
B
One
thing
that
might
be
slightly
tangentially
related:
I
guess
we
sort
of
have
the
team
split
and
we
have
the
epics
and
we
have
the
governing
okrs
as
well.
One
thing
that
I
think
that
I
I
would
at
least
personally
find
quite
interesting.
B
Is
that,
because
there's
a
lot
of
crossover
between
us
and
the
sort
of
combined
efforts
towards
okrs
as
well,
it
would
be
interesting
to
see
whether
on
like
a
weekly
or
a
monthly
basis
or,
however,
whatever
would
make
sense
how
progress
towards
the
completion
of
those
okls
was
being
furthered
by
the
work.
That's
actually
being
done,
like
sort
of
maybe
being
explicit
about
how
those
two
things
link
up.
A
Yeah,
that's
a
really
great
idea.
Pretty
great
one
thing
that
has
been
always
quite
disconnected,
I
guess
is
the
okrs
are
in
ali
those
get
updated
every
week,
but
I
suspect
not
very
many
people
go
into
ali
and
read
through
the
okrs
in
there
and
they're.
Actually,
even
more
perhaps
interesting
is
that
they
all
cascade
up.
A
So
when
we
check
in
a
contribution
on
one
of
our
okrs,
it
goes
up
and
it
contributes
to
the
platform
okrs
and
to
the
infra
of
okrs
right
up
through
to
the
to
sid,
ceo
okrs,
so
they're
very
deliberately
kind
of
lined
up
that
way.
So
there
is
quite
a
lot
of
information
in
there,
but
it's
a
little
bit
tricky
to
hunt
it
out
so
cool
yeah.
That's
a
really
good
suggestion.
A
So
let
me
have
a
little
think
about
that
I'll,
say
mckelly
and
I'm
chatting
about
quite
a
lot
of
this
stuff,
so
we'll
feed
them.
How
we
can
also
link
that
piece
of
information
in
as
well.
C
B
C
A
That's
a
great
question:
originally,
the
actual
motivation
was
to
help
people
who
weren't
the
dri
of
a
project,
no
kind
of
which
issued
most
useful
to
pick
up.
But
now
so
this
week's
one
was
the
first
one
where
I've
kind
of
thought.
We
can
actually
separate
out
and
have
two
separate
team
things.
A
But
I
guess
like
what
would
be
most
useful
like
do?
Do
you
want
it
to
be
further
broken
down.
C
A
C
C
Of
his
particular
okrs,
I'm
wondering
if
they'll
be
beneficial,
no
you're,
not
sir.
C
I
wonder
if
it'd
be
beneficial
to
drop
our
okrs
if
possible,
like
I
have
no
clue
how
that
ally
slack
integration
works.
I
wonder
if
that'd
be
beneficial
to
drop
into
the
g
delivery
channel,
I'm
not
sure
how
helpful
that
will
be
because
from
what
I
saw
this
morning,
it
links
to
an
okr
that
links
to
a
chart
and
there's
not
really
much
else
you
could
dive
into
there.
You'd
really
have
to.
A
A
C
B
A
I
I
do
agree
yeah.
I
absolutely
agree.
I
wonder,
like
I
almost
wonder
if
we
could
pop
if
we
should
consider
putting
something
in
the
platform's
slack
channel,
so
we
have
the
platform's
view
but
yeah.
I
have
to
admit
that
was
the
first
slack
integration
I've
seen
of
ali
things
coming
in
so
yeah
it
was.
It
was
pretty
nice.
I
think
it
was
a
nice
reminder
of
where
things
go.
So,
okay.
B
A
Great
thanks
a
lot.
What
I
will
do
is
I'm
gonna,
say
mckinley
and
I
continuing
to
work
on
this
stuff.
What
what
I'm
keen
that
we
get
to
is
where
you
have
very
distinct
kind
of
team
ownership
areas
so
that
you
don't
have
so
much
crossover
and
collaboration
like
that
will
get
easier
as
time
goes
on,
but
that's
what
I'm
hoping
we'll
be
able
to
reach
so
that
it
isn't
a
case
of
necessary.
Oh,
I
need
to
do
this
piece
of
work.
I'm
not
quite
sure.
A
Some
of
it
seems
like
it's
system
sums
orchestration,
I'm
not
sure.
If
it's
in
progress
like
we
have,
we
certainly
have
broad
enough
domain
and
problems
to
be
able
to
to
clearly
cut
this
up
for
the
team.
So
we're
continuing
to
work
through
on
that
stuff.
C
So
the
issue
in
the
epic
that
I've
linked,
I
would
like
for
the
people
that
are
interested
to
just
keep
tabs
on
this.
I
want
to
have
a
larger
discussion
during
our
wednesday
kubernetes
demo
meeting.
C
I
just
recently
watched
the
recording
from
last
week,
so
I've
got
some
improvements
that
I
need
to
make
in
general,
so
I'll
be
trying
to
work
on
that
throughout
this
earlier
this
week.
That
way,
we
could
have
a
larger
discussion
on
wednesday,
so
this
is
just
a
request
to
keep
tabs
on
it.
That
way,
we
could
have
a
beneficial
conversation
on
wednesday
instead
of
all
of
us
thinking
at
the
same
time,
not
really
knowing
what
to
do.
C
A
A
Is
there
any
room
to
do
something
to
the
monolithic
deployment?
I
think
is
a
huge,
maybe
right
now,
but
actually,
I
think
from
the
system
side.
You
probably
don't
need
to
be
constrained
so
much
by
that,
because
I
think,
in
terms
of
the
the
the
sort
of
visibility
and
the
sort
of
improvements
you
can
make
on
our
kind
of
deployment
capabilities,
don't
necessarily
have
to
be
linked
exclusively
to
self-serve.
So
keep
keep
that
as
an
option,
and
certainly
I
don't
know
how
we
would
split
up
the
actual
deployment
yet.
A
Awesome,
I
know
one
contribution
towards
that
stuff.
So
within
orchestration,
we've
had
one
discussion
of
a
kind
of
similar
nature
to
this,
which
we
had
a
couple
of
weeks
ago
before
alessio
went
out,
and
tomorrow
philly
myself
and
graham
have
another
similar
one
to
try
and
sort
of
look
at
it
from
the
orchestration
side.
What
I'll
do
off
the
back
of
that
meeting
tomorrow
is
get
our
sort
of
demo
discussion
playlist
set
up
so
that
those
recordings
can
all
live
in
there.
A
So
I'll
ping
that
out
to
you
like
at
some
point
tomorrow,
so
that
then
you
can
hopefully
feed
that
into
your
conversations
as
well.
A
A
C
You
have
the
next
one.
I
just
saw
that
you
open
up
the
retro,
but
I
was
just
wondering
if
we
could
get
a
what
we
did
in
the
last
quarter.
A
I
will
try
and
pull
it
together.
I
say
that
with
a
little
bit
of
the
try
is
very
heavily
emphasized.
I
will
pull
together
as
much
as
I
can
and
then
open
it
up
to
you
all
to
try
and
think.
Actually.
I
also
did
this
stuff
right,
so
it
won't
be
a
exclusive.
A
Awesome
so
over
to
release
management.
C
Yes,
things
were
relatively
cool.
Last
week
we
did
have
some
minor
interruption
late
last
week
due
to
an
incident,
but
overall
things
went
okay.
We
got
a
little
slowed
down
due
to
some
maintenance
work
that
was
happening
at
the
beginning
of
the
week,
but
nothing
nothing
terrible
in
my
opinion.
So
firstly
so
the
number
of
packages
you
know,
I
think
reuben
was
doing
a
fantastic
job
when
we
started,
but
that
we
had
to
pause.
C
Is
this
that
first
maintenance
yeah
so
there's
the
database
upgrade
that
was
happening
in
staging
the
os
upgrades,
so
that
kind
of
paul
saw
deploys
for
a
little
bit.
We
just
never
caught
up.
You
know
we
just
kept
building
more
stuff
and
then
console
underwent
a
upgrade
and
that
one
kind
of
spread
out
across
the
entire
week,
but
I
was
keeping
track
of
that
change
requests
and
later
on
learned
that
they
didn't
actually
need
to
make
changes
to
kubernetes.
C
C
And
then,
at
the
end
of
last
week,
we
had
a
incident
with
one
of
the
components
related
to
gitlab
shell,
where
the
container
build
mechanism
changed
slightly
to
reduce
the
size
of
the
image
and
a
couple
of
other
improvements
which
reduced
the
image
size
by
like
70
percent,
so
a
rather
hefty
improvement,
but
that
improvement
also
shined
a
light
on
a
bug
that
was
inside
of
our
helm,
chart
which
had
been
living
there.
For
who
knows
how
long?
C
So,
instead
of
reverting
the
change
to
c
and
g,
it
was
late.
In
my
day
a
revert
would
have
been
beneficial
because
we
would
have
had
a
new
package
ready
for
graham
anyways.
The
choice
was
just
to
go
ahead
and
fix
the
bug
inside
of
our
helm
chart,
because
that
was
the
easiest
mechanism.
It
was
quick
and
then
it
just
required
us
to
upgrade
our
chart
over
the
course
of
time.
C
That
was
still
risky
because
all
chart
upgrades
carry
a
certain
amount
of
risk,
but
this
was
prepared
just
in
time
for
graham
to
start
his
day
and
get
that
knocked
out.
So
as
far
as
the
amount
of
packages
we
promoted
were
certainly
lower
than
normal,
mostly
due
to
maintenance,
because
we
only
had,
I
think
one
incident
yeah.
I
think
this
was
one
that
was
fixed
relatively
quickly.
A
A
question
on
on
those
maintenance:
instead,
particularly
on
the
one
that
we
later
discovered,
didn't
need
us
to
block
stuff.
Is
there
anything
like?
Are
we
at
a
position
where
we
could
we
could
write
down?
Some
kind
of
you
know
general
guidelines
like.
If
your
change
does
this
this
and
this
you
don't
need
to
block
us
or
you
know,
do
we
know
things
well
enough
to
be
able
to
do
that.
C
C
Console
is
an
example
where,
off
the
cuff,
you
would
think.
Oh,
that's
going
to
be
harmless
because
they're
just
rotating
certificates
and
it's
not
going
to
touch
the
kubernetes
infrastructure,
but
it's
still
console
there's
going
to
be
leader
elections
within
that
service
and
you
don't
know
what
that's
going
to
do
to
the
infrastructure.
C
C
What
is
this
one
deployment
frequency
last
month
we're
on
par?
I
think
we
had
one
more
yeah.
We
had
one
more
than
last
week
comparatively,
but
we
did
okay.
Despite
you
know,
the
slow
ramp
up
for
the
beginning
of
the
week,
but
we're
still
on
par
with
how
often
we
deploy,
which
is
good,
lead
time
for
changes.
C
A
Yeah,
that's
an
interesting
one,
because
normally
what
I
think
you
see
on
this
one
is
say:
the
big
bumps
usually
are
an
indication
of
people
merge
stuff
on
the
friday
and
then
we
deploy
it
on
on
the
monday
is
most
likely
what
I
think
you
see
there.
So
it's
interesting
that
we
didn't
have
that.
A
C
A
C
A
C
A
One
thing
related
to
these
numbers
right
so
again,
I've
got
a
lot
more
sort
of
thinking
and
stuff
to
put
through
on
this,
but
these
are
the
I've
made
some
fairly
broad
kind
of
claims
in
the
self-serve
blueprint,
because
a
lot
of
these
things
that
we
talk
through
here,
not
the
packaging
one
but
the
other
graphs,
a
self-serve
team-
would
be
using
something
I'd,
ideally
they'd,
be
using
the
same
charts
as
us.
So
I
think
that's
where
we
can
start
to
try
and
make
some
guesses
of
okay.
A
This
stuff
is
useful
and
it's
showing
these
things
and
they
will
have
a
slightly
different
experience
than
us,
because
their
stuff
will
be
much
smaller
and
much
simpler,
but
I
think
we
can
perhaps
try
some
metrics
out
on
the
self-serve
teams
and
then
reapply
them
back
onto
auto.
Deploys.
A
Awesome
great
and
I
know
we've
got
a
couple
of
issues
on
the
delivery
board,
all
ready
for
kind
of
general
improvements,
so
well
good
great.
Is
there
anything
else?
Anna
wants
to
bring
up
on
this
recording.