►
From YouTube: 2022-08-10 GitLab.com k8s migration APAC/EMEA
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
A
Okay,
so
I
think
it's
just
ask
scrams
actually
on
public
holiday,
so
our
quiet
week,
our
quiet
week,
continues
I
copied
over
the
announcements
into
into
today's
agenda.
So
to
have
a
look
through.
The
one
I
particularly
want
to
just
mention
on
is
Juan
C,
so
do
recommend,
like
all
of
you,
making
some
time
to
go
through
this.
This
is
kind
of
one
of
sits.
A
Okrs
is
to
get
a
thousand
people
certified
on
this
either
then
has
cascaded
down
through
the
through
the
department,
so
it
does
also
feed
into
infra
okrs
as
well,
but
I
would
recommend
it.
I
went
through
it
last
week.
It
took
me
around
two
hours,
but
I
have
to
admit.
I
did
a
heap
of
context.
Switching
so
I
saw
Max,
saying
it
took
him
20
minutes,
so
it's
somewhere
between
those
two
and
it's
very
much
around
our
credit
value.
A
So
you
will
know
a
lot
of
it
already,
but
what
I
did
really
like
about
it
was.
It
has
some
really
good
context
about
the
whys
of
the
credit
values
and
some
of
the
bits
that
in
particular,
they're
ones,
around
kind
of
like
iterations
and
and
sort
of
planning
work,
and
things
like
that
super
relevant.
All
the
conversations
we're
going
through
right
now.
A
You
know
there
was
a
lot
of
stuff
about
like
optimizing
for
like
quantity
of
decisions
made
and
things
like
I
was
like
oh
okay,
yeah
like
we,
we
can
certainly
I
think
apply
that
as
we
go
through
a
lot
of
the
self-serve
decision
making.
So
yeah
really
recommend
making
a
bit
of
time
and
actually
going
through
that,
like
it,
was
pretty
pretty
lightweight
and
and
very
useful.
A
Awesome
so
one
thing
I
had
on
the
discussion
items
is
I
have
been
writing
things
in
the
self-serve
blueprint.
I
am
not
pulling
this
from
any
great
Vault
of
self-serve
knowledge.
I
am
literally
just
emptying.
My
brain
in
there
so
feel
free
to
join
in,
like
there
is
no
wrong
answer.
A
There's
lots
of
discussion
still
to
be
had
and
lots
of
holes
to
poke
in
that
stuff
and
we'll
we'll
figure
this
stuff
out
together,
but
one
bit
I
did
drop
in
and
I
I'm
curious,
like
I
guess
this
is
a
little
sort
of
Standalone
enough
piece
that
we
could
perhaps
discuss
usefully
here
is.
We've
talked
a
lot
over
the
past
few
years
about
the
right
metrics
to
have
us
release
managers
to
sort
of
indicate
how
things
are
going.
We've
got
mttp,
but
you
know
we
know
on
its
own.
A
That's
not
enough
of
a
metric
to
really
help
us
optimize
on
our
pipelines,
and
things
like
that
and
I
was
thinking
that
for
the
stage
groups,
it
will
be
a
good
thing
for
us
to
in
addition
to
that,
giving
them
a
deployment
pipeline
also
help
them
have
a
set
of
metrics.
That
they
can
use
like
the
benefits
of
self-serve
deployments.
Is
the
teams
have
ownership
of
changes
going
out
so
giving
them
metrics
that
they
can
then
use
to
be
able
to
optimize?
Those
changes
going
out
feels
like
a
unuseful
thing
to
have.
A
In
addition,
now,
I
did
a
bit
of
thinking
about
this,
and
durometrics
seem
to
be
the
answer
to
this
right,
so
they
give
the
kind
of
complete
view
of
your
kind
of
team
in
terms
of
deployment,
frequency
and
lead
time
change
failure
rate.
You
know
all
of
those
things
which
actually,
if
you
were
a
single
team,
pushing
out
on
an
independent
pipeline,
you
actually
have
complete
control
of
like
they're,
not
totally
helpful
for
us,
as
as
release
managers,
because
we
can't
optimize
on
some
of
these,
but
I
wondered
what
your
thoughts
are
well
like.
A
Does
that?
Does
that
make
sense
or
like?
Would
you
other
other,
maybe
like
additional
or
is
there
a
better
way
that
we
could
actually
kind
of
I
guess
guide
team,
so,
like
I'm
thinking,
we
would
be
able
we
would
go
to
them
and
sort
of
give
them
a
here's.
What
you
need
to
think
about
with
deployments,
like
you
know,
small
batch
sizes
are
good.
These
things
are
good.
Here's
a
deployment
pipeline
that
will
meet
your
needs,
and
here
are
some
metrics
or
a
dashboard
or
something
where
you
can
actually
see.
B
I,
don't
think
this
is
a
Dora
metric,
but
I
do
find
it
useful
as
a
release
manager.
So
in
the
delivery
dashboard
in
grafana,
we
have
some
charts
showing
how
many
changes
have
not
been
deployed
to
each
environment.
C
A
A
C
A
A
A
They
came
about
from
the
book
accelerate,
which
is
a
super
book,
and
it
is
all
around
kind
of
ASAP
measuring
and
improving
team
health.
So
it's
not
specifically
about
deployments,
but
it's
about
overall
team
health
and
what
they
found
was
that
there
are
various
stages
in
teams,
lives
around
kind
of
deployment
frequency
and
how
painful
those
deployments
were
and
kind
of
how
much
like
reactive
work
went
on
following
a
deployment
that
actually
was
really
like
closely
correlated
to
overall
team
happiness
and
and
sort
of
ability
to
deliver.
A
So
I
came
up
with
these
four
metrics.
It's
called
the
door
I'm
at
well,
I,
don't
know
if
they're
always
called
Dora
match
in
GitHub.
We
call
them
the
Dora
4
metrics
and
together
they
give
you
an
overall
view
of
of
how
things
are
going,
so
we
use
some
of
them.
So
we
have
lead
time,
which
is
one
of
our
release:
manager
metrics.
A
This
is
a
Dora
metric
and
deployment
frequency
is
a
Dora
metric,
but
as
well
as
kind
of
like
measuring
they
like
how
fast
you're
going
and
how
much
stuff
are
you
pushing
out,
there's
the
counterbalance
of
and
how
many
things
broke
and
how
much
reactive
work
did
you
have
to
do
following
pushing
all
that
stuff
out,
so
those
are
kind
of
the
the
bits
that
go
on
there.
The
kind
of
the
counter
side.
C
I
think
having
Dora
metrics
would
be
really
would
be
really
valuable.
Actually,
even
it's
just
sort
of
a
a
well-established
standard
or
Norm
of
things
that
are
generally
useful
to
track.
I
think
from
both
sides
for
also
stage
groups
and
teams,
and
and
for
us
as
well
the
one
that
I
don't
know
would
be
I,
don't
know
if
it
would
be
particularly
helpful,
maybe
not
at
least
for
our
context
is
mttr.
C
It
might
help
in
terms
of
how
we
do
rollbacks
and
how
all
that
is
coordinated,
but
the
mttr
metric
as
a
whole
is
that
there's
like
a
lot
more
that
goes
into
what
that
metric
might
report
Beyond?
How
quickly
can
what
delivery
provides
teams
facilitate
the
role,
those
rollbacks
and
those
recoveries?
Here,
that's
the
only
one
that
I
don't
know
whether
it
would
be
immediately.
You
saw
I
mean,
maybe
it
might
be,
but
things
like
deployment
frequency
and
you
know
fail
fail
rate
of
changes.
A
That's
kind
of
what
I
was
there
kind
of
thinking
along
those
lines
as
well
yeah
like
it's
almost
like
giving
people
enough
indication
that
it
leads
to
conversations
right
like
I
kind
of
think
that
a
lot
of
the
the
benefits
for
giving
teams
I
mean
essentially
giving
them
more
work
right.
We're
giving
them
do
your
own
deployments
and
and
take
that
on,
but
the
benefit
for
them
is
the
opportunity
to
kind
of
optimize
their
workflows
and
their
code
they're
checking
in
and
stuff.
So.
A
Yeah,
they
probably
wouldn't
be
able
to
affect
mtti
you're
right.
Oh
my
secret
one
for
us,
though
I
guess
right,
because
they're
sort
of
the
ultimate
Improvement
to
that
will
be
as
being
a
detector
problem
more
quickly.
A
I
have
a
faster
rollback
pipeline,
I
guess
and
maybe
the
two
things
so
maybe
they're
good
for
us,
but
actually
less
for
the
team.
Yeah.
A
Cool
okay
super
helpful
yeah
go
ahead.
B
A
It's
a
really
good
question:
I
actually
don't
know
and
I
certainly
don't
know
in
terms
of
the
Dora
4
metrics
that
we
have
built
into
the
product.
I
I,
don't
I,
don't
know
that
I've
seen
that
configured
well
for
any
of
our
projects.
C
C
So
that's
like
it
focuses
purely
around,
like
customer
impacts
in
terms
of
time
to
recover,
rather
than
us,
detecting
a
problem.
It's
like.
If
the
customer
impact
started
an
hour
before
we
detected
the
problem,
then
we're
already
we've
already.
You
know
an
hour
of
that
recovery.
Time
has
already
elapsed,
at
least
at
least
in
terms
of
what
I
think
I
think
of
what
the
door
Matrix
do.
I
could
be
totally
wrong.
Speaking
of
like
top
my
head.
A
I
think
I,
guess
that
makes
sense
from
a
deployment
point
of
view
right
because
that's
actually
a
number
we
do
kind
of
know
like
if
you're
in
a
deployment
Pipeline
and
we
we
detect
a
problem
it.
It
should
be
possible
to
count
from
the
beginning
of
the
you
know
this
time
you
started
deploying
to
that
stage.
So
I
guess
that
makes
a
bit
of
sense
cool.
Okay,
so
it
feels
like
it'll,
be
a
useful
direction
for
us
to
kind
of
explore.
So
at
the
moment,
I.
A
Don't
think
I'm
not
sure
about
you're
going
to
have
to
open
an
issue
because
I
think
we're
actually
going
to
have
to
investigate
this
a
bit
at
the
moment.
I,
don't
think
stage
groups
can
pull
useful
Dora
Matrix
on
their
projects
because
of
the
way
we
have
deployments
set
up
and
the
monolithicness
I
I'm
gonna
take
into
that
a
little
bit
more.
But
after
when
I've
had
a
quick
look,
I'd,
never
trust
the
numbers,
especially
and
I
know
we
don't
have
we
don't
get
some
of
the
numbers.
A
I
know
things
like
that:
change,
failure,
rates
and
stuff
don't
track
in
there,
because
deployments
are
completely
disconnected
from
the
actual
projects.
So
there's
some
some
pieces
in
there,
but
it
does
feel
like
it
could
be
a
good
one
for
us
to
kind
of
figure
out
from
our
side
like
we
might
need
to
change
the
way
we
track
things
or
there
could
be
some
work.
A
I
can
actually
work
out
if
that's
true
or
not,
but
it
might
be
that
we
have
a
little
bit
of
setup
work
on
our
side
and
then
we
could
encourage
the
stage
groups
to
get
this
get
this
included
in
in
their
deployments.
A
A
A
It
if
it's
useful,
like,
if
you
think,
there's
going
to
be
or
if
you'd
like
to.
B
We
had
a
lot
of
blocks
today.
Maybe
I'll
just
show
that
one
dashboard.
B
So
last
week,
I
think
the
week
before
that
was
pretty
good.
We
had
hardly
any
anything
blocking
deployments,
but
this
week
it's
just
Wednesday
and
we've
already
had
four
so
yeah,
not
so
good
other
than
that.
B
This
is
a
pretty
standard,
I
think
on
August
3rd
we
managed
seven.
Otherwise
it's
around
six.
A
B
B
A
A
Oh
I,
don't
think
I
have
any
I
know.
We've
got
a
couple
of
sort
of
like
tooling
and
general
bug
thing
type
of
bug,
things
that
will
improve
release
Management
on
the
board,
so
yeah
I
think
we're
actually
eight
one
I,
just
called
out
like
Ruben
like
great
great
work
recently,
like
I,
think
of
of
all
the
months
I've
seen
go
by
like
I'm,
loving
the
the
amount
of
kind
of
tooling
improvements,
you're
bringing
in
alongside
kind
of
release
management
like
that's.
That's
a
super
way
to
kind
of
spend
your
time
on.