►
From YouTube: 2022-04-26 GitLab.com k8s migration 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
Awesome,
let's
begin,
I'm
not
sure
if
we
have
others
here,
we
go
awesome.
So
let's
begin
welcome
everyone,
sorry
for
the
short
notice,
re-schedule!
Yesterday
I
I
didn't
notice.
I
had
an
interview
booked
over
the
meeting
time
so
anyway
we
get
bonus
because
we
also
now
have
alessio.
So
you
know
there
are.
There
are
also
perks
right,
awesome.
So,
in
the
announcements
we've
got
quite
a
few
people
with
time
off,
which
is
awesome.
We
also
have
a
couple
of
our
people.
B
Who've
been
off
are
returning
next
week
as
well,
so
lots
of
lots
of
things
coming
and
going,
which
is
great,
so
this
is
the
last
week
of
q1
and
firstly
I
again
I
just
apologize.
I
am
desperately
behind
on
okrs
and
standing
out
the
retro
issue
for
the
end
of
this
quarter,
so
we'll
get
that
sorted
out
as
soon
as
we
can,
but
one
thing
that
will
be
involved
in
those
and
maybe
just
a
reminder,
so
maybe
we
can
like
tweak
our
results.
B
A
little
bit
is
at
the
beginning
of
this
quarter.
We
set
ourselves
a
couple
of
retro
actions
and
they
are
listed
just
above
this
agenda
item.
So
one
was
about
completing
two
issues:
to
reduce
toil
for
release
managers,
I'm
going
to
pull
the
full
list,
but
there
were
definitely
three
when
I
last
looked
through
kind
of
big
changes
that
we've
made
the
other
one,
though
I
think
we
might
be
not
so
close
to
completing.
B
Just
as
a
reminder
which
was
around
the
discussion
was
around
the
kind
of
uncertainty
of
getting
help
from
quality
and
when
to
use
an
incident
and
when
not
to
do
it,
use
an
incident
and
we
decided
on
an
action
of
reviewing
our
own
run
book,
and
so
we
could
help
each
other
on
that.
So,
if
you
haven't
reviewed
that
wrong
book
in
the
last
three
months,
please
have
a
little
read
through
it
in
the
next
like
three
three
and
a
half
days,
so
we
can
complete
this
this
goal.
B
Are
there
any
questions
around
that?
I'm
not
going
to
add
ask
any
comments
on
the
state
of
the
end
of
this
quarter
because
I
feel
like
it's
not
going
to
be
our
finest
wrap
up
of
the
quarter
because
of
lots
of
lots
of
things
going
on
and
lots
of
team
change,
but
but
that's
okay.
Has
anyone
got
any
questions
like.
C
Are
those
issues
the
only
ones
that
are
we
supposed
to
complete,
because
I
recall
that
we
did
complete.
C
B
I
grabbed
these
some
weeks
ago
and
they
were
the
three
but
yeah
you're
right.
We
have
quite
a
long
list,
so
I
do
intend
to
get
a
full
picture
because
I
think
we've
changed
quite
a
lot.
This
quarter,
okay,.
C
B
B
Awesome
so
where
kelly
and
I
have
been
working
very
hard
and
with
input
from
many
of
you
as
well-
and
we
have
proposed
a
team
split
issue,
so
thanks
for
those
fast
questions,
one
to
one
thanks
for
the
comments
on
the
issue
so
far,
but
also
wanted
to
open
it
up.
If
anyone
has
any
questions
or
things
they
want
to
discuss
in
this
meeting
today,.
C
I
I
see
that
you
already
wrote
a
comment
answering
some
questions.
So
probably
you
already
answered
my
question,
but
in
terms
of
occurs
and
goals,
when
we
have
two
teams,
I
assume
that
each
team
is
going
to
have
its
own
nokia
and
then
that
okr
is
going
to
somehow
fulfill
like
the
major
pr
for
delivery
in
general,
or
is
that
going
to?
How
is
that
going
to
work.
B
Yes,
that's
a
fantastic
question
and
I've
literally
just
added
on
the
comment
and
description
a
little
bit
of
a
guide
on
timing,
because
that
show
is
that's
something
we
didn't
have
included
on
there.
So
the
main
thing
that
we
are
keen
to
get
in
place
is
an
agreed
kind
of
direction
for
splitting
the
team.
There
are
some
really
big
gray
areas,
and
that
is
known,
but
also,
hopefully
gives
us
opportunity
to
move
things
around
a
bit.
B
But
the
main
thing
we
want
to
get
in
place
is
have
some
structure
get
the
reporting
lines
so
that
we
can
start
working
towards
those
once
we
have
those
bits
in
place
and
we
kind
of
have
agreed
ideas
for
the
teams.
Michael
and
I
have
a
bunch
of
work
to
do
on
the
admin
side
of
things.
So
that's
going
to
probably
take
us
quite
a
bit
of
time,
but
for
your
question
mara
about
the
goals,
what
I'm
expecting
from
q3
so
for
q2
it'll
be
same
as
we've
done
previous
quarters.
B
I
think
probably
our
big
goal
will
be
split.
The
teams
successfully
will
be
a
key
okr
for
us,
and
then
we
have
some
most
likely
some
wording
to
be
confirmed,
but
some
goal
around
reducing
release,
manager
toil
or
something
like
that
so
game
and
skelbeck
have
been
thinking
about
kate's
workloads.
B
We've
got
some
ruben's
got
a
poc
on
kind
of
tracking
deployment.
Stuff
unlessio
has
been
thinking
about
that.
So
these
things
all
kind
of
come
together.
A
lot
of
people
have
mentioned
that
it's
just
harder
to
be
a
release
manager.
So
I
think
that
probably
gives
us
enough
stuff
to
work
with
on
q2.
We
just
need
to
put
some
structure
in
and
figure
out
words
for
the
future,
though
for
q3.
B
Yes,
what
I
think
we'll
end
up
with
is
two
teams.
Our.
What
we've
been
trying
to
do
is
give
two
teams
that
have
really
distinct
kind
of
ownership.
So
you
may
end
up
overlapping
a
bit
on
in
terms
of
the
what
that
is,
but
I
think
that's
true
for
what
we
have
right
now
say:
release
tools.
It
has
distinct
purposes
and
there's
a
bit
of
an
overlap
that
may
still
exist,
but
each
team
will
have
a
clear
goal
of
what
it's
working
towards.
B
B
There
will
be
overlaps
on
that,
but
what
we'll
find
in
q3,
I
think,
is
we
will
each
team,
I
hope,
will
have
an
independent
okr
there
may
be
overlap
between
who
works
on,
contributes
to
different
ones,
but
they
will
fit,
hopefully
with
what
the
sort
of
top
priorities
are
for
each
team.
For
that
quarter,
there's
quite
a
lot
of
things
circulating
around.
You
know
we
could
pick
automating
back
ports
or
we
could
pick
cluster
recreation
or
yo.
There's.
D
B
And
whether
they,
where
they
feed
up
to
is
the
other
thing,
so
all
of
our
work
feeds
up
into
the
platform
strategy
so
that
cascades
down
we
currently
have
the
delivery
strategy.
B
A
B
That's
true
yeah.
I
don't
expect
so
scarborough,
because
I
think
we
will
have
to
remain
close
to
each
other
like
we
will
depend
on
each
other,
both
sides.
We
will
also
work
with
each
other
in
release
management,
so
I
I
think
we
will
still
want
to
you
know,
maintain
very
regular
contact
and
certainly
for
the
bigger
celebrations.
Many
more
people
is
always
better
in
a
celebration,
so
those
ones
are
easy.
We
should
just
celebrate
with
as
many
people
as
we
can
get,
but
I
think
even
things
like
this
meeting.
B
For
example,
we
can
talk
about
what's
a
good
way
to
to
use
the
times
that
we
currently
have
scheduled
in,
so
that
you
know
we
do
have
the
knowledge
share.
You
do
get
the
chance
to
have
input
into
the
other
team,
but
also
it's
not
just
feeling
like
you're
wasting
your
time,
so
those
bits
to
be
figured
out
but
yeah.
I
think
we'll
still
talk
to
each
other
quite
a
bit.
B
We're
not
scaling
the
team
in
terms
of
adding
lots
more
people
right
now,
so
it's
not
like
more
people
than
you're
currently
talking
to
it
just
hopefully
means
that
we're
not
trying
to
keep
track
of
like
eight
different
projects
within
one
team
right.
You
could
just
have
three
or
four,
for
example,.
B
Up
to
you
honestly,
to
be
determined
what
people
would
prefer
to
use
this
time
for
like
we
could
leave.
As
is
see
how
that
is,
release
management's
always
going
to
be
our
kind
of
touch
point,
so
there
will
always
be
things
that
are
relevant
across
both
teams.
B
One
team
making
a
change
could
affect
a
lot
of
things
in
release
management,
so
there
will
be
some
benefit
to
knowledge
share
or
we
could
shift
this
and
just
make
it
a
purely
social
cool,
with
less
kind
of
like
specific
team
things
or
make
it
more
like
intentionally
delivery.
So
I
think
I
don't
know
we
can
figure
it
out,
but
if
people
have
ideas
we
can
certainly
like
try
things
out.
C
What
about
release
manager,
rotation,
starting
with
q3?
Are
we
going
to
take
one
team,
one
person
from
one
team
and
another
person
from
one
team,
or
perhaps
I
am
just
thinking
ahead,
but
I'm
not
sure
if
we
have
given
some
thought
about
that.
B
We
will,
if
we
can.
Yes,
that
would
be.
The
ideal
is
because
then
we
get
like
we,
we
have
sort
of
both
teams
get
to
continue
with
sort
of
the
same
sort
of
number
of
people
and
we
get
maximum
knowledge
sharing
and
you
get
to
work
with
someone
you're,
not
working
with
day-to-day.
So
that
would
be
the
ideal.
B
It
may
not
always
be
possible
at
especially
at
the
moment
with
the
team
as
size.
It
is
so
priorities
for
planning
and
release
management
are
people's
availability,
so
you
know
I
expect
you
all
to
continue
to
have
lives
and
plan
vacations
and
things.
So
that's
always
going
to
be
the
top
thing.
After
that,
we've
got
time
zones
and
then,
after
that,
if
we
can
meet
things
beyond
those
two
that
yes
absolutely.
B
E
I
have
a
an
upside
down
question
because
I'm
not
used
to
the
fact
that
I'm
involved
in
a
team
split
very
often
in
my
career
field,
are
there
questions
that
I
should
be
asking.
B
D
E
B
I
think
the
the
main
thing
is
to
know
that
this
is
a
proposal
and
there's
a
lot
of
things
we
haven't
figured
out,
so
I
would
say
less
so
what
questions
should
you
be
asking,
but
more,
please
do
keep
questioning
things
and
raising
up
if
things
don't
seem
to
fit
or
seem
odd,
because
there
will
be
a
lot
that
we
have
to
work
out
as
we
go
through.
B
B
So
release
managers
welcome.
Welcome
to
your
welcome
to
your
month.
B
I
haven't
had
time
to
update
deployment
blockers,
which
probably
indicates
how
bad
this
process
is,
that
there's
some
serious
overhead
on
it,
but
just
as
a
kind
of
quick
question,
as
is
always
customary
in
this
meeting,
is,
is
there
anything
that
we
need
to
take
action
on
based
on
your
experiences
so
far,.
C
C
That
is
sort
of
a
problem,
because
if
it
fails
one
job,
then
the
whole
pipeline
is
retried
instead
of
the
single
job
that
only
happens
on
staging
canary
because
it
is
the
only
q,
a
jobs
that
we
still
have
there.
All
of
the
others
are
still
executed
on
the
coordinated
pipeline,
so
in
the
coordinated
pipeline,
if
it
fails,
we
only
need
to
retry
the
job
now
the
whole
pipeline,
which
is
faster,
and
it
will
be
ideal
if
we
could
move
q
a
from
staging
canary
to
the
coordinated
pipeline.
C
We
started
some
months
ago,
but
we
stopped
because
there
was
this
ugly
bug
about
bridge
jobs
in
the
in
the
in
parent
pipelines
not
being
able
to
be
triggered.
But
if
we
could
transmit
that
job
that
issue
it
will
be
very
nice.
I
can
link
it
into
the
document.
B
I
would
suggest
for
this
one
as
it's
not
on
our
current
okrs.
B
We
should
try
and
wrap
it
into
our
future
okrs,
but
otherwise,
I
think,
let's,
let's
have
this
as
a
known,
optimization
like
we
can
certainly
make
pipelines
faster
by
doing
this
work,
but
let's
not
try
and
squeeze
this
in
this
week,
since
we
do
have
very
limited,
we
have
only
reuben
for
this
week
and
then
we're
waiting
for
robert
to
return
and
get
up
to
speed
before
we
have
any
more
back
end
capacity.
B
So
I'm
really
keen
that
we
get
the
post
deployment
migrations
completed,
because
that
is
also
causing
the
baking
time
message
to
be
inaccurate,
which
you
hit
upon
seo.
So
I
think
that
one
is
more
immediately
painful,
but
I
do
appreciate
that
this
this
is
going
to
be
a
good
one.
We
will
need
to
have
a
chance,
I
think
in
q2
to
group
up
the
what
are
all
the
things
that
are
causing
us
pain
or
making
release
management
harder.
B
This
is
a
great
example,
so,
let's,
let's
keep
this
one
in
mind
for
a
q2
improvement.
C
A
C
A
B
Get
an
issue
because
I
know
we
talked
about
how
wide
extending
that
is-
and
I
recall
on
the
issue
find
the
issue,
but
I
I
remember
saying
that
it
was
only
the
post-deploy
migrations
and
that
solving
the
post-deployment
migration
problem
would
remove
at
least
most
of
this.
If
that's
not
the
case,
if
there
is
actually
a
bug,
we
need
to,
I
think,
look
at
getting
that
fixed.