►
From YouTube: 2022-12-13 Delivery Group: Ruby 3 Rollout
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).
B
All
right
so,
on
the
first
point,
I
just
wanted
to
give
you
like
the
context
and
the
status
of
what
is
happening
with
the
Ruby
tree
version
and
well.
There
is
the
main
epic
that
I
have
Linked
In
the
documentation,
the
main
epic
and
the
main
effort
is
owned
by
the
application
performance
scheme,
and
basically
the
effort
of
upgrading,
gitlab.com
and
self-managed
to
Ruby
tree
is
split
into
four
different
stages.
B
The
first
one
is
the
preparation
which
is
done
by
now,
and
the
second
one
is,
it
is
called
the
master
Pipeline
and
it
is
basically
a
test.
The
git
love
canonical
pipeline
against
Ruby
3.
They
are
currently
in
that
stack
and
the
next
step
is
Bad
Touch
and
distribution,
and
finally
cell
SAS
and
self-managed
rollout,
and
that
is
where
we
come
in
in
that
in
that
stage
there
is
a
dedicated
epic
for
that
one,
but
it
is
not
very
updated.
B
I
think
it
is
some
sort
of
placeholders
to
gather
all
the
requirements
to
gather
all
that
information,
so
that
is
kind
of
the
broad
perspective
of
the
Ruby
tree
effort
for
the
SAS
rollout
plan.
There
is
right
now
A
pre-checklist,
with
all
the
required
staff
before
the
production
roll
out.
This
is
also
owned
by
the
application
performance
team
and
it
is
basically
there
are
several
levels,
but
among
the
Surfers
it
is.
B
B
B
We
don't
have
a
process
for
that,
so
the
update
is
going
to
be
very
manual
if
I
I
am
imagining
this
and
we
can
Define
it
later.
But
basically,
when
the
kubernetes
pipeline
it
starts
to
execute,
we
are
going
to
kind
of
stop
all
the
Clusters
and
then
just
play
one
job
at
a
time.
Let
it
be
for
a
certain
time
measure
it
somehow
and
then
move
on
to
the
next
cluster.
So
that
is
basically
the
idea.
B
A
Have
some
questions
so
about
the
in
production?
Right
is
the
one
where
we
are
participating
and
I
see
that
it's
pretty
is
pretty
empty
and
I
saw
that
a
lot
of
these
activities
that
are
actually
listed.
These
epic
here
are
actually
also
part
of
the
Ruby
3
checklist
activity
that
you
just
listed
there
right
so
actually
see
the
same.
Exact
criteria
listed
in
both
I
have
a
question
about
developers,
use
Ruby
3
by
default.
What
does
it
mean
in
practice.
B
C
B
A
B
A
A
B
D
A
Because
I
just
want
to
be
sure
that
you
know
we
are
not
any
Gap
in
some
gaps
and
people
give
like
some
green
lights
on
some
older
environments
that
has
been
deployed
functionally
wise
and
then
they
say:
oh
everything
is
working
and
then
there
was
a
regression
a
little
deployment
since
we
are
not
controlling
any
automated
rollout
there
to
these
environments,
it's
kind
of
a
manual
upgrade.
You
know
if
I'm
quite
sure
that
it's
easy
to
introduce
some
blind
spots
on
some
weeks
releases
or
something
like
that.
B
E
Sorry,
or
maybe
more
usefully
would
be
to
when
I,
maybe
to
ask
about
what
the
sign
off
like
what
what
I
guess
like
what?
What
will
we,
what
will
happen
before
they
basically
say
to
us
like
we're
good
to
go
like
maybe
maybe
that's
kind
of
what
we're
asking
right,
which
is
how
long
will
this
thing
have
been
successfully
passing
on
whatever
their
test
environment
or
what
tests
would
have
happened?
E
A
Yeah
yeah
sure
another
question
that
actually
comes
up
now
with
the
with
Amy's
point.
So
this
is
for
sure
it's
not
the
same
architecture.
We
are
using
in
production,
but
you
know
it's
kind
of
closing
up.
Are
we
running
any
kind
of
an
endurance
test
on
these
10K
environment
and
why
I'm
asking
that
I'm
asking
that
about
understanding
memory?
Footprint
of
you
know
Ruby
3
against
Ruby
2..
B
A
Okay,
I
mean
it's
just
like
you
know:
I'm
I'm.
What
I'm
afraid
of
is
that
there
are
some
libraries
built
from
like
bindings,
C
code,
bindings
and
so
on,
and
then
we
start
to
have
some
memory
leaks
for
whatever
reason,
we
should
not
be
impacted
very
badly
about
that,
because
I'm
quite
sure
that
kubernetes
I
mean
we
have
to
deploy
continuously.
So
our
pods
don't
have
long
life.
But
it's
probably
something
also
to
look
for
from
the
application
performance
team.
A
A
C
E
A
I
think
is
a
good
idea,
especially
now
it
lights.
You
know
over
these
points
that
might
have
brought
up,
and
also,
in
light
over
this
question,
that
we
need
to
look
for
answers.
I
think
like
having
issue
to
be
sure
that
we
have
you
know,
sign
off,
and
things
or
activity
that
we
need
to
do,
especially
for
the
deployment
in
isolation.
Probably
is
a
is
something
that
is
worth
it
to
have
unhappy
for
that.
E
E
Yeah
for
sure-
and
that
might
give
us
a
place
as
well
to
make
sure
the
bits
that
are
very
much
delivery
so
like
metrics
and
actually
having
a
like
scarbox,
got
a
kind
of
great
comment
about
the
rollout
plan,
but
we
should
probably
get
that
you
know
into
his
own
issue
or
something
you
know.
So
we
know
exactly
what
we're
going
to
do.
We
could
pop
up
those
things
on
our
Epic
yeah.
Certainly.
A
E
How
about
we
I
mean
we're
going
to
have
holidays
anyway,
so
I
mean
we're
probably
looking
kind
of
early
January
mid-January
anyway,
is
the
next
reasonable.
So
how
about
we
take
a
check
in
then
and
then
I
think
we,
it
might
hopefully
it'll
become
more
clear
because
I
guess
what
we
really
don't
know
is
when
the
rollout
is
likely
to
happen
exactly
and
I
think
those
are
the
pieces
where
sinks
will
be
more
valuable,
as
we
kind
of
figure
bits
out
like
maybe
some
bits
we
can
do
async.
E
Who
wants
to
be
the
dri?
I
say
this
with
some
so
I
know:
Jenny
you're,
currently,
release
manager,
Mayra
you're
about
to
become
a
release.
Manager
you're
also
already
a
dri,
and
you
have
the
most
knowledge
on
this
project,
but
you
two
will
be
working
together
right
so
like
just
do
just
who
would
like
to
take
on
the
work.
B
Yeah
I
can
be
dri,
I,
don't
mind,
I,
think
this
I
see
this
like
a
tangential
kind
of
Epic
that
is
moving
on
and
I
just
need
to
keep
an
eye.
So
right
now
it
is
not
taking
a
lot
of
my
attention,
I
guess
well
as
soon
as
time
progresses
and
around
February
on
March.
This
is
going
to
take
more
time,
but
right
now,
I
think
I
am
okay.
We've
been
dri
and
Jenny,
of
course,
can
also
be
the
arrived.
That's
okay
with
her.
We
can
both
be.
D
D
E
Yeah
I
agree
absolutely
what
we
might
find
you
so
it'll
probably
take
a
little
bit
of
figuring
out
as
we
go,
but
what
might
be
useful
is
if
we
see
part
of
those
discussions
to
be
like
something
we
really
need
to
care
about.
We
can
put
an
issue
on
our
working
epic.
So,
for
example,
like
you
know,
confirm
we
have
sign
off
like
confirm.
We
have
the
sign
off
requirements,
or
you
know
something
like
that.
E
It
won't
necessarily
generate
work
for
us,
but
it
could
just
be
a
prompt
for
us
to
be
keeping
track
that
we're
moving
along
with
this
project
as
well,
because
I
think
the
big
risk
of
this
project
is
because
it's
got
a
hard
deadline
of
March
I.
Think
the
big
risk
is
development
is
running
quite
late
at
the
moment,
like
they're
kind
of
original
deadline
date
was
mid-December,
so
they
are
running
like
several
months
behind.
What
I
think
is
quite
possibly
going
to
happen.
E
Is
they'll
get
sort
of
moving
into
February,
mid
late
February,
and
then
it
will
be
a
right
we're
done.
This
has
to
roll
out
tomorrow.
So
we
don't
want
to
be
kind
of
scrambling
at
that
point,
so
we
probably
just
want
to
make
sure
we
are
progressing
anything
we
need
to
be
thinking
about
alongside
them.
A
D
E
E
B
It
will
be
well
the
rollout
itself,
I'm
positive,
that
we
should
use
Auto
deploy,
but
around
the
coordination
I'm
inclining
to
use
a
PCL,
even
though,
if
it
is
a
bit
disturbed
the
story
for
the
deployment
activities,
but
I
think
it
is
our
best
choice,
because
if
something
goes
wrong
we
can
roll
back
and
we
can
disable
Canary.
We
have
strategies
to
keep
gitlab.com
healthy,
so
that
is
one
and
another
one
is
that
well,
basically,
our
job
is
to
deploy
to
gitlab.com.
B
A
Yeah
I'm
I'm
sure
that
you
know
functional
requirements
are
going
to
be
met
right.
We
have
all
these
pipelines
for
QA
and
everything.
That's
what
I'm
afraid
of
is
the
non-functional
ones.
It
also
goes
back
to
the
to
my
questions
that
I
asked
before
right
is.
Are
we
gonna
be
sure
that
when
we
are
so
I
guess
this
is
gonna
go
through
Canary
right,
yes
and
I
think
this
is
probably
something
that
we
need
to
understand
if
we.
B
The
other
idea
will
be
to
deploy
to
well
to
start
measuring
from
the
beginning,
so
it
will
deploy
to
a
stage
in
Canary
and
then
measure
it
somehow
that
way,
and
then
after
that,
allow
it
to
move
on
to
production,
Canary
and
then
we'll
ensure
that
quality
is
green
and
that
it
is
a
stable
and
all
the
metrics
that
we
require
to
measure.
Let
it
sit
for
probably
more
than
30
minutes
and
I.
B
A
B
We
could
do
that,
but
let's
keep
in
mind
that
if
we
have
a
PCL,
that
means
that
deployments
are
going
to
be
stopped
until
we
finish
this
and
I
would
really
like
to
well
avoid
doing
that,
because
all
of
the
consequences
that
it
has
I'm
not
sure
if,
like
one
day,
is
too
much,
we
will
probably
do
it
like
in
a
couple
of
hours
as
as
long
as
we
know
exactly
what
to
measure
and
what
to
look
for
I
think
it
should
be
fine.
Okay,.
E
C
D
C
E
A
The
other
thing
is
just
like
right
now:
Canada
I
think
is
getting
a
bit
less
than
five
percent
of
the
traffic
yeah
and
keeping
it
for
a
short
amount
of
time.
Is
it
building
at
five
percent
enough
static,
statistical
significance
of
having
the
right
amount
of
traffic
that
is
actually
eating?
All
the
whole
pattern
features
to
be
sure
that
this
is
working
properly.
So
that
was
my
question
about
extending
production
candle
for
a
bit
longer,
and
that
was
also
depending
on
the
fact
of
how
long
it's
going
to
be
our
PCL.
E
A
E
That's
what
we
need
to
figure
out
like
I,
think
we're
probably
going
to
be
the
key
people
for
that,
like
from
our
from
a
organization
point
of
view,
the
shortest
possible,
because
nothing
else
can
take
place
in
that
time,
which
is
so
disruptive
from
a
development
point
of
view.
It's
going
to
be
as
long
as
possible
so
that
they
can
be
as
confident
about
this
change.
So
I
think
we
end
up
being
the
kind
of
mediators
on
that
on.
How
can
we
balance
that
risk
and
keep
it
I?
E
Think,
there's
probably
some
things
we
could
do
so,
for
example,
we
could
do.
We
could
do
the
staging
changes
without
the
PCL.
We
could
just
manage
that
within
delivery
around
how
we
handle
deployments
and
then
just
have
the
PCL
to
cover
production
changes,
but
I
think
we
probably
do
need
to
know
like
what,
because
the
worst
case
would
be.
If
we
say
okay
great.
We
think
this
looks
good.
We
want
to
continue
on
with
deployments
now.