►
From YouTube: GitLab 15.6 Kickoff - Enablement:Application Performance
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
Hey
my
name
is
Gabe
Weaver
I'm,
the
acting
PM
for
the
application,
Performance
Group
and
I'm
joined
here
today
with
CZ
who's,
the
engineering
manager
for
the
team.
We're
going
to
be
talking
about
our
top
priorities
for
15.6.
We're
really
excited
this
release
to
continue
our
efforts
on
updating
support
for
Ruby
to
version
3.0
little
context
here.
The
Ruby
2.7
end
of
life,
which
we're
currently
running,
is
expected
in
March
of
2023,
which
means
no
security
patches,
no
ongoing
support.
B
If
we're
not
kind
of
upgraded
by
then
we're
going
to
run
into
a
whole
lot
of
trouble.
So
the
application
performance
team
has
been
focusing
on
doing
a
dependency
or
an
audit
of
all
the
dependencies
for
Ruby
3
compatibility.
It's
a
huge
effort,
there's
a
ton
of
gems
that
we
use.
We
need
to
understand
what
will
break
if
we
do
upgrade
to
Ruby
3D
what
supported?
B
What's
not
and
then
15.6
we're
going
to
kind
of
extend
the
help
call
for
help
here
because
of
the
the
size
and
the
number
of
gems
that
need
to
be
audited
to
other
development
teams,
to
make
sure
that
we
can
do
a
quick
it
to
see
if
there
is
visible
support
for
Ruby
3.
If
there's
not
what
remediation
actions
we're
going
to
need
to
do
if
we
need
to
swap
out
gems
with
something
else
that
is
compatible.
B
That's
to
the
investigation
that
we're
trying
to
get
support
from
with
all
the
other
teams,
specifically
for
the
team
in
this
release.
We're
also
going
to
be
collaborating
with
several
other
teams
to
make
Omnibus
gitlab
build
with
Ruby
3,
and
this
is
really
important
thing
that
we
need
to
tackle.
There's
also
an
interesting
like
contradictory,
where,
like
we
want
to
run
our
main
pipelines
against
the
version,
that's
ongitlab.com
and
production,
which
is
ruby27,
we
also
need
to
be
able
to
start
running
pipelines
for
Ruby
3..
B
It's
a
to
cost
prohibitive
to
run
parallel
pipelines
at
the
same
time
for
every
code
change
so
how
we're
going
to
work
around.
That
is
we're
going
to
focus
on
getting
the
GDK
of
running
on
Ruby
3
is
the
default
so
that
way,
when
we
developers
open
merge,
requests
and
run
pipeline
against
their
branches,
it
will
actually
be
running
against
the
Ruby
3
and
then,
when
we
actually
merge
merge
requests
into
the
main
branch,
the
main
branch
will
run
a
continue
to
run
on
Ruby
two
seven.
B
So
that
way,
we
can
maintain
compatibility
between
two
as
we're
working
on
the
shift
and
upgrade
to
Ruby
3
as
a
default.
Moving
forward.
A
Anchor
Gabe
so
I'm
going
to
cover
the
rest
of
the
work,
definitely
plan
for
the
next
Milestone.
So
we'll
continue
our
the
investigates
Puma
long-term
memory
use
work,
so
we
have
added
a
ability
to
collect
more
metrics
and
alcoholic
reports
to
help
us
troubleshooting
a
GitHub
instance
memory
and
performance
issues,
but
in
all
and
that's
required.
The
SSH
access
to
the
web
server
instances
to
get
the
report
and
so
oftentimes
the
developers
have
to
ask
help
from
SRE
team
who
has
access
permission
to
the
servers.
A
Now
we
are
looking
at
how
we
can
simplify
the
process
and
that
this
issue
that
we
made
is
we
are
going
to
automatic,
upload
the
reports
and
to
Google
cloud
storage
and
make
it
available
for
engineers.
So
the
work
already
started
from
from
poc
in
155
will
continue
to
finish.
The
final
implementation
of
the
reports
are
model
in
1506..
A
Another
work
that
we
will
do
in
the
1506
is
continual
fine-tuning
psychic
memory
killer,
so
oftentimes
we
run
into
the
oom
events
on
our
servers
when
the
psychic
run
out
of
the
memory,
so
we
introduce
more
metrics
and
edit
logging
to
help
us
better
understand
and
what
happens
when
those
events
happened.
So
we
want
to
find
a
good
spot
where
the
psychic
memory
killer
will
restart
our
psychic
profiles
smoothly.
A
So
that's
that's
not
a
work
that
we
are
going
to
do
in
the
15-6
other
than
what
we
discussed.
There
are
a
few
additional
issues
we
may
look
into
in
the
next
muscle.
The
first
one
is
to
go
out
the
kilometric
exporter
for
GitHub
reels
project,
and
also
we
want
maybe
to
have
a
better
documentation
for
the
GitHub
exporter
security
release
process.
A
B
Nope
I'm,
looking
forward
to
the
work,
we're
doing
it's
important
and
it's
going
to
be
great
for
the
practice
hole
and
for
the
developers
across
the
entire
organization
is
working
on
gitlab,
so
I'm
stoked.