►
From YouTube: GitLab 15.7 Kickoff - Enablement:Gitaly
Description
Planning Issue - https://gitlab.com/gitlab-org/gitaly-planning/release-planning/-/issues/5
A
Hello,
everyone
and
welcome
to
the
kickoff
for
gitlab
15.7.
This
is
the
giddly
kickoff,
and
this
is
the
planning
issue.
We're
looking
at
right
here.
As
always,
I
will
link
the
planning
issue
in
the
YouTube
video
below.
So,
if
you're
interested
in
coming
and
commenting
on
any
of
the
issues
or
epics
discussed
here
or
on
this
issue
itself,
we
welcome
that
sort
of
collaboration.
A
As
a
note,
we
do
have
some
capacity
limitations
in
the
15
7
time
frame
due
to
the
United
States
Thanksgiving
holiday,
as
well
as
some
of
our
team
members
being
out
for
the
second
half
of
the
Milestone,
so
we
have
sized
this
Milestone
accordingly,
we
would
believe-
and
though
we
are
planning
ambitiously,
we
hope
to
accomplish
some
of
these
goals
this.
This
milestone,
one
of
the
best
features
that
we've
really
been
working
on
recently
is
figuring
out
how
safe
CPU
cost
through
offloading
clones.
A
This
is
going
to
save
significant
CPU
resources,
as
well
as
allowing
pack
objects
to
do
much
less
work,
and
it
will
also
allow
us
to
serve
these
bundles
through
other
sources
such
as
a
CVN.
If
we
were
to
desire
to
do
so,
we
have
this
epic
here
where
we
are
discussing
how
this
is
going
to
look
for
us
and
how
we
would
handle
this.
This
is
not
something
we're
necessarily
going
to
complete
in
15
7,
but
we're
going
to
spend
a
decent
amount
of
time,
focusing
on
this
and
planning
the
effort
and
starting
this
work.
A
A
A
second
theme
that
we're
really
approaching
here
is
how
to
increase
the
speed
of
adoption
for
new
and
get
features.
There's
a
lot
of
hurdles
here.
Upstream
git
does
not
release
on
a
monthly
Cadence
like
gitlab
does
and
therefore
trying
to
time
certain
git
features
being
released
in
a
newer,
Git
Version
and
our
own
internal
Milestone
workflow
becomes
somewhat
difficult.
A
There's
another
thing:
that's
slowing
our
workflow
down
right
now,
which
is
the
inclusion
of
libgit2,
which
performs
in-memory
operations
for
some
of
our
gate,
commands
we're
working
on
ways
of
eliminating
the
dependency
on
Libya
2,
as
this
would
allow
us
to
speed
up
our
adoption
and
reduce
complexity
with
adoption.
We
would
no
longer
have
to
wait
for
git
to
release
a
feature
and
that
feature
to
be
incorporated
back
into
libgit2.
A
We
have
a
epic
detailing
the
deprecation
of
Libya
2
within
giddly.
This
is
not
intended
to
be
a
a
feature
that
people
will
see
or
a
Improvement.
That
will
be
visible.
It
should
all
happen
behind
the
scenes,
but
the
sum
total
of
the
work
here
will
allow
us
to
then
iterate
more
quickly
with
newer
features
that
come
down
through
get,
which
is
an
improvement
for
all
of
our
customers
and
ourselves
included.
A
A
Community
maintained
project
was
amazing,
we're
lucky
to
have
certain
developers
on
our
team
which
contribute
Upstream
to
get,
and
we
want
to
figure
out
how
we
can
best
utilize,
these
team
members
and
their
contributions
to
get
to
allow
us
to
continue
making
progress
around
scalability
and
performance
improvements
for
large
mono
repos
We've
outlined
this
epic
here,
where
we
discuss
some
of
the
support
we're
looking
to
have
again.
This
is
stalled
out
for
a
bit
and
we're
looking
to
kind
of
Bring,
It,
Back
and
figure
out
a
way
to
proceed
here.
A
A
Finally,
we
have
a
great
opportunity
for
some
bug
fixes.
Here.
We've
worked
closely
with
our
software
engineering
test
to
figure
out
which
of
these
bugs
we're
going
to
try
to
tackle.
We
have
gone
and
worked
through
some
of
these
already
and
there
are
some
that
we
are
planning
on
implementing
in
15
7
in
our
roadmap
and
on
our
issue
board,
which
is
linked
at
the
bottom
of
the
above
issue.