►
From YouTube: 2023-03-28 Delivery & Development: Rails 7 Upgrade Sync
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
Yes,
so
I'm
gonna
start
again,
so
this
is
the
range
7
upgrade
sync
press.
The
refs
call
is
the
kickoff
to
try
to
understand
what
are
the
requirements
from
the
team
to
allow
this
upgrade,
which
is
the
timeline
that
would
be
fit
the
best
the
team
and
also
fit
like
delivery
with
the
Quran
duties
that
we
have,
and
there
is
that
we
see
associated
with
that
and
understanding
which
more
or
less
is
the
requirement
coming
from.
A
If
there
is
any
git
lab
requirement
for
when
these
two
roll
out
this
one
or
if
we
can
push
it
to
a
different
Milestone
and
which
is
the
which
are
the
extend
the
ex
this
piece
of
work
that
I
still
like
standing
and
that
needs
to
be
completed
before
rolling
this
out,
I
don't
know
Sean.
If
you
want
to
start
to
give
us
a
brief
overview
where
this
is
at
and
then
I
can
start
with
some
question
coming
from
delivery
and
also
the
question
from
other
people
from
there
yeah.
B
C
B
C
C
Honestly,
I'm,
maybe
a
should
be
a
grunt,
a
test
engineer:
yeah
I,
just
wonder
what
he
thinks
thinks
about
it.
So
I
think
we
should
ask
for
Quality
perspective
and
and
yeah
some
exploratory
testing
should
be
done,
but
maybe
not
on
such
a
large
scale,
as
we
did
for
Ruby
3,
because
for
Ruby
3
it
was
like
company-wide
initiative
yeah,
and
it's
like
like
a
lot
of
effort.
D
And
I
think
also
one
issue
with
like
exploratory
testing
is,
like
the
I
mean
your
instinct
as
a
developer
or
someone
who
wants
to
test
something
would
be
like
to
test
the
most
obvious
use.
Cases
right
are
the
most
Pro.
You
know
the
most
critical
ones
like
creating
an
issue
for
our
team
or
something
like
that
and
for
these
things
these
are
already
actually
covered
by
our
speaker.
E
So
I
wanted
to
add
them.
This
and
I
want
to
say
that
the
way
we
rolled
out
the
Ruby
tree
upgrade
is
very
intensive
in
term
of
engineering
resource
needed,
and
it's
something
that
we
should
avoid
as
much
as
possible.
So
we're
talking
about
at
any
time
at
least
four
or
five
Engineers
following
the
sun
on
this
thing
for
three
days
where
this
had
the
effect
of
slowing
down
mttp
for
everyone
else
of
the
company,
so
nothing
was
shipped.
E
We
had
to
rush
a
security
release
because
we
had
the
security
release
the
week
before
and
we
risked
out
not
doing
that
and
it
was
an
extremely
stressful
moment.
So
we
should
avoid
this
type
of
thing.
So
I
will
try
to
address
the
things
in
the
opposite,
which
is:
do
we
think
that
is
safe
to
roll
back?
E
So
so
we
could
do
something
more
like
on
day
x,
we're
gonna,
run,
post
deployment,
migration
and
say,
merge
the
Ruby
7
raid,
7,
sorry
upgrade
and
the
next
deployment
or
the
second,
the
one
after
that
will
start
rolling
this
thing
out
and
we
monitor
it.
We
monitor
what
is
happening
and
if
something
is
clearly
related
to
rail
7,
we
revert
and
we
rolled
back,
revert
and
or
so
try
to
address
the
things
fixing
forward
as
we
prefer.
It
really
depends
on
the.
How
big
is
the
problem.
B
With
the
with
the
Ruby
3
upgrade
so
I
I
completely
hear
what
you're
saying
there
Alicia
it's
yeah.
We
don't
want
to
kind
of
have
to
go
for
that,
every
time
we're
doing
a
version
bump
actually,
but
what
in
retrospective
was
that
necessary
I
mean?
Did
we
need
to
kind
of
put
that
much
effort
into
it?
Were
there
problems
that
came
up
during
the
rollout
that
we.
B
Yeah
because
I
guess
you
know
so
I
mean
you
know
right
after
this
there'll
be
the
whenever
this
goes
in.
In
fact,
it's
a
blocker
for
the
Ruby
3.2
upgrade,
and
so
you
know
and
then
possibly
there'll
be
well
most
likely.
The
rail
7.1
will
be
released
soon,
and
so
probably
then
we'll
do
the
Royal
7.1
upgrade
you
know.
So
so
you
know
we're
probably
going
to
have
a
cycle
of
well
at
least
three
major
changes
to
the
Ruby
system.
B
One
question
about
the
rails
upgrade
for
for
if
we
I
mean
what
I
guess,
we've
got
like
the
Wales
gems
and
then
whatever
the
dependency
gems
need
to
be
updated.
But
maybe
this
has
already
been
done,
but
could
we
you
know,
update
all
of
the
dependencies
that
are
non-rails
ahead
of
time
and
just
put
them
into
a
regular
merge
requests
where
possible,
where
the
depend
where
these
versions
line
up?
Is
that
something
that
would
because
that
would
then
lower
the
whole
surface
area
around.
B
D
E
So
what
I
want
to
say
is
that
if
everything
goes
smoothly,
we
just
had
a
lot
of
manual
work
and
we're
kind
of
losing
a
couple
of
hours
here
and
there
to
get
things
back
in
motion.
So
there
is
a
lot
of
extra
work
at
the
end
to
make
sure
that
by
re-enabling
the
regular
process,
we
are
not
an
advertently
rolling
back
the
rail
7
migration,
because
it's
a
possibility.
E
B
E
What
I'm
saying
is
something
like
as
an
example
in
gem
file.
You
can
have
groups
yes
right,
so
I,
don't
know
if
it's
possible,
but
maybe
can
we
have
something
like
the
regular
group
is
with
the
rails.
Seven,
but
then
you
can
just
do
bundle,
install
and
say
rails
raid,
7
group,
or
something
like
this
testing
rail
7,
and
this
will
switch
the
the
gem
file,
so
it
will
install
real
7
instead
of
real
six
and
then
you,
basically
you
have
the
same
tests
with.
E
E
But
if
this
is
possible,
then
we
it
kind
of
boost
our
confidence
in
what
we're
doing
so
I'm
thinking
about
the
rails,
the
Ruby
tree
as
an
example,
we
started
changing
the
CI
images,
B4
changing
merging
the
change
in
Omnibus
and
CNG
to
actually
build
the
production
images
on
on
Ruby
tree
right.
So
we
were
already
running
pipelines
on
CI
on
Ruby,
3
and
Ruby
7
and
sorry
Ruby
2.7.
For
a
long
time,
just
to
say,
okay
CI
is
running,
CI
is
working.
E
D
Yeah,
it's
not
as
easy
to
do
this
because
of
the
bunch
of
code
changes
needed,
but
for
the
current
Mr
we're
like
rebasing
it
on
master
and
running
CI
pipeline.
So
it
should
be
similar.
I
I,
don't
know
if
we're
running
the
package
job
which
is
like
optional
I,
think
right
now,
but
we
could
do
that
right
and
like
we
make
it
rebase
regularly
make
sure
it's
always
green.
For
you
know
few
days
or
something
run,
the
package,
jobs
and
I
think
it
should
have
the
same
effect
as
what
we're
wanting
right.
E
B
E
If
we
want
to
deploy
in
isolation
without
going
down
and
manually
tuning
the
process,
so
just
in
isolation,
we
should
count
for
basically
it's
a
full
day
of
manual
work
from
delivery
right,
so
you
mean
the
release.
Manager
began
his
shift
and
just
his
day
is
all
about
making
sure
this
process
gets
in,
the
things
are
merged
and
things
are
deployed,
and
the
next
package
is
not
rolling
back
so
come
think
the
rollout
timing
and
everything
we
looking
around
eight
12
hour
window
to
make
this
change.
E
A
B
A
I
mean
this
is
just
like:
it's
not
a
lot
about
male
intervention,
but
it's
like
slowing
down
everything
else
right.
So
this
is
something
that
we
are
actually
working:
delivery,
RSU
in
particular
working
on
something
that
we
could
in
the
future
use
for
this
kind
of
use
cases
of
this
big
upgrades
and
so
on.
But
it's
not
something
that
we
have
already
now,
but
is
the
reason
why
I
also
touched
in
the
other
0.3
to
understand,
which
is
the
best
timeline
for
this
because
16
before
16.0,
it's
too
much.
A
E
B
I
think
I'm
not
involved
with
the
Ruby
3.2
project,
but
we
can.
We
can
get
some
dates,
but
the
I
think
one
of
the
drivers
of
Ruby
3.2
is
it's
perceived
to
have
a
very
big
performance
pump.
So
there
might
be
a
push
in
the
language
itself,
so
there
might
be
a
big
push
to
to
incorporate
that
I.
Don't
know,
I
think
it
is
going
to
be
a
fairly
big
upgrade
as
well,
though
I
actually
have
another
question
about
the
rails.
Upgrade
I.
B
Think
I
asked
this
in
an
earlier
call
that
you
know
one
of
the
big
changes
between
rails.
Six
and
seven
was.
It
was
the
way
the
assets
were
handled,
but
we're
not
we're
not
exposed
to
that
right
because
we're
just
going
to
see
a
quick
repacker,
we're
not
using
anything
new.
Is
that
a
quick
statement.
D
B
Okay,
so
to
answer
that
question
about
Ruby,
3.2
I,
guess
we
need
to
engage
with
that
team,
so
yeah.
So
to
answer
your
question,
Mikhail
I
think
the
from
my
perspective.
It's
it's.
You
know
we
release
it
when
we're
ready
and
the
only
the
only
blocker
or
the
only
dependency
is
the
Ruby
3.2
upgrade
whenever
that's
going
to
be
so
if
it
makes
sense
to
delay
it
a
couple
of
Milestones,
that's
I
think
that's
fine.
B
A
D
A
A
E
I
was
going
to
say
more
or
less
the
same
thing
and
I
will
also
give
another
thing
to
think
about,
which
is
that
this
type
of
a
great
is
likely
going
to
introduce
extra
complexity
on
all
the
security
releases
and
batch
releases
for
three
months,
because
basically,
we
will
end
up
developing
fixes
for
range
seven
a
shimming
day,
even
if
they
clearly
back
back
portable,
stable
branches,
they
may
not
behave
the
same
right.
So
also,
this
is
kind
of
a
timing
is
important
here
and
around
a
major
release.
E
A
D
B
E
Yeah
and
another
thing
that
I
wanted
to
mention,
because
we're
briefly
touching
on
Ruby
3.2
I,
think
the
biggest
pain
point
for
the
3.0
upgrade
was
the
breaking
changes
which
I
don't
think
there
are
in
3.2
right,
because
it's
not
a
measure.
So
there
may
be
some
say
there
are
optimization.
Maybe
things
are
changing,
but
it
should
be
more.
C
One
one
not
regarding
Ruby
is
3.2
I
believe
there.
There
are
no
hot
requirements
here
that,
for
example,
review
3.2
depends
on
rail,
7
or
rail
7.1.
It's
mostly
like
done
to
do
things
like
gradually
yeah
we
perform
through
B3
update.
Now
we
want
like
rail
7.
Here
we
have
our
window
to
perform
rail
7
upgrade.
There
were
some
concerns
about
like
breaking
changes.
The
the
sandbox
that
was
fixed
in
either
in
rail,
7
or
rail
7.1.
C
That
would
make
Ruby
3.2
update,
upgrade
smoother
yeah
a
more
safer,
but
it's
not
like
a
hard
requirement,
so
yeah
or
so
maybe.
If,
for
example,
we
can
do
it
in
16.1,
for
example,
yeah
we
can
like
tentatively
schedule
on
16.1
and
then
postpone
it
if,
for
example,
if
we
see
a
huge
out
of
patch
much
requests
and
Bug
fixes,
just
just
a
suggestion,.
B
Just
another
variable
you
know:
rails
7.1
is
in
re-release,
it
could
be
released,
I
mean
sometimes
they
take
a
while
to
release
the
releases.
You
know,
but
they
might
actually
release
it
soon,
and
would
we
this
or
would
we
pick
that
up
if
we're
going
to
be
going
after
16.2?
Would
we
consider
just
going
directly
to
7.1
no.
C
For
example,
the
version
like
the
minor
version
of
rails
is
released
like
a
seven
point,
zero
point
five
is
released,
then
it
would
be
great
and-
and
one
note,
regarding
the
requirements
for
upgrade
I.
Remember
one
team,
maybe
Henrik
helped
me
or
as
a
package
team
yeah
where
we're
relying
on
the
features
from
rail,
7
yeah,
and
they
wanted
to
introduce
like
watch
in
our
current
version
in
order
to
support
some
feature
from
rail
7.
So
they
were
really
enthusiastic
about
rail
7
upgrade.
D
E
A
D
E
E
Instead
of
just
committing
to
this
thing,
it's
more
of
something
like
we
develop
a
simple
process
to
have
this
thing
done
and
then
you
can
coordinate
with
release
manager,
say,
say:
oh
there's,
no
extra
work
for
today
everything
looks
quiet.
I
can
give
you
a
time
window
to
run
with
this,
and
maybe
we
give
you
just
in
theory.
This
can
give
you
two
to
four
hours
of
production
traffic
with
your
changes.
E
But
again
we
need
to
be
extra
sure
that
the
then
we
can
run
it
can
run
in
parallel
with
a
rails
6
deployment,
because
you
have
a
canary
and
Main
stage
and
all
those
things,
and
also
knowing
that
the
next
deployment
will
revert
back
to
to
Ruby
6.
think
about
it.
I'm
just
saying
this
could
be
an
option
because
it's
just
one
merge
request,
and
this
is
something
that
if
we
have
maintainers
that
are
approving
the
current
state
of
the
merge
request
and
say
this
could
be
merged.
C
It
sounds
super
interesting
yeah
to
me,
I'm,
just
one
one
situation,
maybe
if
it's
possible
to
have
this
proposal
written
yeah
in
the
in
the
Epic
yeah.
That
would
be
great
and
yes
or
maybe
with
some
links
because
yeah
I'm
hearing
about
it
like
the
first
time
that
sounds
super
interesting
and
yeah.
That
would
allow
us
to
experiment
with
it.
It.
B
C
B
A
B
A
Okay
sounds
good,
so
as
action
items,
if
we
have
a
couple
of
minutes,
do
we
want
to
set
these
another
I
mean
we
are
still
far
but
probably
a
meeting.
Another
meeting
like
this
in
four
weeks
to
understand,
if
you
are
in
sync,
would
be
probably,
and
then
we
adjust
the
Cadence
yes,
depending
on
the
need.
Okay,
yep
for
sure
someone
need
to
find
out
the
timelines
for
a
weekly
upgrade,
and
then
we
spoke
about
something
we
Grant
from
QA
to
understand.
A
If
the
test
Suite,
they
want
to
run
for
exploratory
testing
which,
to
which
extent
needs
to
be
run
or
how
they
want
to
do
that
and
reach
out
to
Marius
and
pick
up
his
family
name
to
understand
timeline
for
the
CI
feature
that
the
CI
team
needs
to
release
Sean.
You
already
put
your
name
there
and
yeah
unless
it
is
coming
up,
it's
changing
how
to
deploy
on
the
Epic
I
guess.