►
From YouTube: 2022-08-01 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
Okay,
everyone's
here,
so
let
us
begin
so
welcome
everyone
first
of
august
and
q3
so
super
exciting
halfway
through
this
year,
so
we've
got
some
read-only
announcements
there
that
you
can
all
look
through
in
your
in
your
own
time
on
the
discussion
stuff.
So
it's
more!
I
guess,
like
I'm,
opening
up
for
discussion,
if,
if
you
like,
so
as
we
go
into
q3,
we
are
now
working
as
two
teams,
but
two
very
closely
related
teams
working
on
the
same
problem.
A
So
we
have
got
open
an
issue
with
proposed
ways
of
working
these.
We
will
continue
to
be
reviewing
throughout,
particularly
throughout
this
quarter,
but
you
know
longer
term
as
well.
So
please
keep
sort
of
letting
us
know
if
you
have
ideas
or
ways
that
we
can
improve
on
this.
The
rough
idea
for
this
quarter
is
going
to
be
to
probably
keep
things
fairly
similar
to
how
they
have
been,
but
use
this
as
a
little
bit
of
a
way
to
test
out.
A
How
are
the
team
boundaries
working
for
us
so
certainly
not
expecting
that
we
have
everything
right
and
it
might
be
that
you
feel
like.
Oh,
I'm
really
limited
in
the
sort
of
problems
I
want
to
work
on
because
they
all
sit
with
the
other
team
or
oh,
I
found
like
90
of
the
issues
I've
picked
up
have
been
from
the
other
team
right.
That's
absolutely
fine!
Please
go
ahead
and
work
on
the
things
that
make
the
most
sense
for
you
to
work
on.
A
We
both
have
okrs
set
up,
like
both
teams
have
okrs
set
up,
so
primarily
that's
what
we
want
to
achieve,
but
at
the
same
time
we
will
be
keeping
checks
on
like
if
it
turns
out
90
of
all
work.
For
these
two
okrs
is
currently
sitting
with
one
team.
We
will
probably
adjust
boundaries,
so
don't
be
limited
by
how
we
have
things
set
up.
A
Just
use
that
as
a
guideline
one
thing
that
will
be
a
little
bit
more
difficult
is,
you
will
possibly
feel
like
you,
have
less
visibility
of
things
that
are
going
on
than
you
previously
did
so
you're
all
certainly
encouraged
to
take
part
in
all
of
the
discussions
and
decisions,
and
things
propose
things,
as
you
have
been
doing
in
terms
of
actually
being
able
to
keep
in
touch
with
what's
happening
and
what's
moving,
we
will
be
following
along,
so
this
is
in
a2,
we'll
be
following
the
guidelines
of
our
handbook,
so
they
state
that
every
issue
in
epic
will
belong
to
one
of
our
two
parent
epics,
and
these
will
be
showing
the
updated
status
from
child
epic.
A
One
of
these
is
a
little
bit
nicer
than
the
other,
which
is
entirely
my
fault,
because
I
only
updated
one
epic.
Let
me
show
you
the
nicer
one,
so
our
nicer
epic
is
the
release
velocity
one,
which
is
the
one
I
put
the
automation
on.
So
what
this
is
actually
doing,
is
it
automatically
is
pulling
in
epics
based
on
their
labels?
A
So
anything
that
you
have
sitting
in
here
with
the
infra
in
progress
label
will
start
pulling
in
here
and
it
will
show
you
who
the
dri
is.
It
will
show
you
like
links
into
the
epic
and
it
will
also
pull
out
the
summary,
which
is
why
the
kind
of
positioning
and
format
of
your
summaries
on
your
epics
is
super
important.
A
A
So
this
is
this
one
and,
alongside
this,
the
not
so
updated
because
we
haven't
yet
automated
it,
but
we
will
epic
is
the
the
kubernetes
one
right,
so
everything
that
either
of
our
two
teams
working
on
will
bubble
up
into
these
two
epics?
A
The
other
thing
I
will
quickly
show
you
is
the
other
piece
we
have
related.
Is
our
board
and
update
what
we?
What
you'll
now
see
going
on
we're
going?
To
probably
start
out
just
unless
someone
disagrees
on
the
issue
based
on
feedback
so
far,
we
will
continue
working
on
this
one
board
and
what
you'll
see
is
that
issues
will
start
to
move
away
from
having
the
team
delivery
label
and
they
will
start
to
be
showing
the
the
orchestration
or
system
label.
A
So
this
one
is
a
little
bit
more
for
info.
It
gives
you
a
way
of
seeing
what
other
people
are
working
on
and
it
gives
you
a
way
of
picking
things
that
most
make
sense
for
your
team
and
the
dri
sort
of
the
projects
and
epics
and
things
that
you're
driving
on
as
well.
But
at
the
same
time,
please
don't
feel
like.
Oh
I'm
working
on
the
wrong
thing,
so
rubio,
for
example,
doesn't
matter
that
you're
working
on
an
issue
labeled
as
orchestration.
B
A
Absolutely
yeah,
I
can
certainly
show
you
how
that's
done
so
we
are.
We
are
making
taking
or
making
use
of
some
automation
that
rachel's
put
in
place
that
all
of
the
platform
ems
have
adopted.
So
it's
used
on
all
the
platform
teams
that
kubernetes
epic
is
the
only
epic
inside
platform
that
isn't
using
this
automation.
A
So
I
can
give
you
a
walkthrough,
but
roughly
what
we've
tried
to
do
is
set
it
up,
so
that
it's
built
on
top
of
the
guidance
that
everyone
has
been
given
in
platform
around
weekly
epic
updates
from
the
dri
to
allow
us
to
bubble
those
things
up,
and
then
we
kind
of
have
a
shared
structure.
So,
yes,
I
can
certainly
show
you
that
let
me
see
if
I
can
quickly
find
the
link
to
it
in
case.
Anyone
else
is
interested.
A
And
actually
this
is
intro.
It's
an
interesting
repo,
because
scalability
have
a
lot
more
automation
in
place
than
we
do,
but
the
scripts
are
all
in
here,
so
they
certainly
can
give
some
interesting
ideas
which
is
related
to
some
of
the
release
management
stuff
about
bubbling
up
info
and
taking
advantage
of
labels
and
structure
of
issues
and
epics
to
to
make
their
lives
a
little
bit
easier,
easier.
C
I'll
roll
through
this
hopefully
shares
great.
C
So,
as
far
as
the
number
of
packages
that
we've
tagged
per
day,
we're
you
know
still
on
par
with
what
we
normally
accomplish.
In
my
opinion,
we
did
get
kind
of
a
slow
start
as
far
as
how
many
were
promoted,
because
one
the
security
release
and
two,
I
struggled
to
get
the
schedule
working
in
a
useful
format
for
my
working
hours,
so
we
had
to
adjust
it
twice
to
account
for
that,
as
we
could
see,
reuben
is
doing
a
fantastic
job
this
morning.
C
So
far
as
far
as
our
deployment
frequency,
I
think
we're
on
par
with
what
we
pretty
much
do.
So
I
don't
think,
there's
anything
to
comment
on
about
this
one
and,
lastly,
our
lead
time
for
changes
again,
a
little
slow
start.
I
suspect
this
is
probably
due
to
the
security
release
as
well
as
the
scheduling
thing
I
was
trying
to
fix
for
myself,
but
you
know
we
got
back
to
our
target
at
near
the
end
of
the
week,
so
I
think
we're
doing
pretty
good.
C
So
far,
I
do
think
we
will
see
a
minor
hit
to
mttp
at
the
beginning
of
this
week
due
to
changes
that
are
coming
from
two
different
areas
in
reliability.
C
So
I
will
be
pausing
autodeploy
a
little
bit
later
today,
due
to
a
change
for
console
related
certificates
that
are
expiring
and
then
tomorrow
I
think
reuben
is
going
to
pulse
auto,
deploy
near
the
end
of
his
day
in
preparation
for
some
postgres
work
that
is
occurring
and
then,
during
my
time
as
release
manager,
I
will
be
re-enabling
autodeploy.
So
there'll
be
at
least
two
occasions
this
week
that
we
are
purposely
or
intentionally
pausing
all
the
deploys.
B
So
I'll
just
add
last
week
at
the
start
we
lost
a
few
packages
because
of
incident
7509
and
then
in
the
middle
of
the
week,
because
of
just
the
the
work
that
has
to
go
into
the
security
release.
I
think
we
missed
like
a
couple
of
packages,
and
today
we
missed
like
three
packages,
because
a
cng
pipeline
was
failing,
so
so
yeah,
so
even
once
it
was
fixed.
You
know
the
pipeline
will
keep
failing
until
you
make
a
new
tag
on
cng,
so
we
have
to
just
discard
three
pipelines:
yeah.
A
Nice
great
great
great
analysis
of
all
that
stuff
is
the.
Is
there
anything
like,
particularly
for
that
one
this
morning,
maybe
ruben
for
the
cng?
Are
there
any
corrective
actions
that
could
be
taken.
B
A
Okay,
great
yeah
yeah,
I
mean,
if
it's
helpful,
to
put
an
issue
like
a
release
issue
in
and
and
record
that
and
then
like
can
open
up
a
discussion.
It
could
throw
up
some
some
possible
improvements.
C
Okay,
I
think
I've
got
one
idea
as
a
corrective
action.
This
was
something
this
was
an
issue
I
created.
I
don't
know
two
or
three
weeks
ago.
Let
me
find
it
real,
quick,
it's
it's
one
where
I
discovered
that
our
autodeploy,
the
release
pipeline
automatically
checks
for
our
helm
chart
builds.
C
We
should
probably
change
that
when
I
find
the
issue
I'll
link
it
in
here,
I'm
struggling
to
quickly
find
it.
A
Awesome
yeah
yeah
ruben,
if
you
wouldn't
mind
getting
a
release
to
shoot
open
with
that,
so
we
can
pull
all
those
things
together.
That
sounds
like
it
sounds
like
a
good,
a
good
opportunity
for
us
to
make
things
a
bit
a
bit
tighter.
A
A
I
think
where
we've
got
enough
kind
of
traction
around
the
ground,
the
charts
we're
using
and
they
are
you
know,
showing
they're
useful,
like
it's
certainly
great,
to
hear
that
that
you
can
see
on
the
chart
when
the
schedule's
not
quite
working-
and
you
know
you
need
to
adjust
the
schedule,
like
that's
exactly
the
point
of
these
charts.
So
that's
that's
really
great
to
see.
A
I
know,
there's
a
heap
of
manual
work
around
this,
so
see
what
you
think
on
this
proposal.
Fine,
if
you
hate
it,
let
me
know
or
if
you've
got
ideas
for
how
we
can
do
this
in
a
better
way.
But
what
I
really
would
love
to
see
is
that
we
don't
have
to
be
manually
annotating
a
chart
and
we
don't
have
to
be
manually
pulling
things
together
right
like
if
we
could
put
some
automation
around
this
some
way.
A
Awesome
is
there
anything
that
release
managers
you'd
like
us
to
see
us
doing
like
in
the
next
few
weeks?
Is
there
anything
we
should
be
bringing
in
aside
from
that
issue,
you
mentioned
scabac.