►
From YouTube: GitLab 12.6 Kickoff - Source Code and Gitaly
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
Hi
I'm
James
Ramsay
senior
product
manager
for
source
code
and
get
early
groups
of
the
credit
stage
of
the
DevOps
life
cycle
here
at
get
lab
and
I
have
five
features
I'd
like
to
share
with
you
today
and
that
will
be
working
on
the
twelve
point:
six
release
of
get
lab
which
will
be
released
on
December
22.
The
first
improvement
I'd
like
to
share
is
to
do
with
syntax
highlighting
differ
itís
for
word,
request,
suggestions,
mode,
request,
suggestions,
make
it
really
easy
to
provide
actionable
feedback
when
performing
a
code
review.
A
Instead
of
describing
the
change
to
the
author
that
you
think
is
necessary,
you
can
simply
propose
the
change
and
the
author
can
review
the
change
and
click
apply
with
one
six,
adding
it
to
the
merge
request.
However,
today
the
diff
highlighting
is
very
basic
and
limited,
and
so
certain
changes
are
hard
to
understand
a
detect.
A
We
simply
show
the
first
line
in
red
in
the
second
line
in
green,
but
if
someone's
made
a
hard
to
notice
adjustment
to
spelling
or
added
a
comma
here
or
something
like
that,
it
can
be
hard
to
spot
so
word,
diff.
Highlighting
will
make
it
very
easy
for
you
to
see
what
changes
being
proposed.
So
you
can
accept
it
with
confidence.
Then
this
change
is
coming
to
get
LabCorp
in
twelve
point.
Six.
The
next
improvement
I'd
like
to
share
is
to
do
with
how
we
load
dips
in
the
merge
request.
A
Engineers
spend
a
large
part
of
their
day
performing
code
reviews
and
for
long
manage
requests
with
lots
of
changes.
Loading.
The
merge
request
page,
can
take
a
little
while
today,
while
the
merge
request
is
loading,
the
page
often
is
unresponsive,
so
you
can
scroll
and
start
reading
the
diff.
You
have
to
wait
for
everything
to
load,
so
in
12.6
we
want
to
improve
the
way
the
browser
responds
and
renders
the
content.
So
that
is
immediately
interactive.
A
You
can
start
scrolling
the
diff,
even
if
it
hasn't
fully
loaded
and
start
your
review
right
away,
and
so
this
should
make
minute
requests,
feel
much
more
responsive
and
enjoyable
to
use
and
we're
going
to
do
this
by
restructuring
the
Dom.
The
way
it's
loaded
to
reduce
memory
and
CPU
usage.
Quite
the
next
improvement
also
to
merge
requests
and
the
dips
is
to
request
in
line
or
parallel
diffs
individually,
rather
than
both
of
them.
A
So
in
1206
we're
going
to
be
improving
performance
by
sending
about
half
the
data
when
we
load
the
dish,
and
that
should
also
speed
up
the
browser,
because
the
browser
has
less
data
to
task
and
make
the
page
feel
responsive
faster.
So
these
are
two
wonderful
improvements
that
should
impact
every
user
of
gitlab
when
they're
using
merge,
requests
and
making
them
much
more
enjoyable,
and
both
these
changes
are
coming
to
get
LabCorp.
So
every
user
of
get
lab
will
benefit
from
these
performance
improvements.
A
The
third,
the
fourth
change,
sorry
that
I'd
like
to
highlight
is
to
do
with
improved,
get
pack
file
reuse.
The
giddily
group
is
going
to
be
working
on
this
and
the
reason
we're
going
to
be
working
on
this
is
with
modern
software.
Development
heavily
relies
on
continuous
integrations,
so
whenever
you
push
a
commit
you'll
see,
I
pipelines
will
kick
off
and
run
a
whole
suite
of
tests
to
make
sure
that
the
code
you've
changed
works.
This
is
great,
but
for
large
applications.
A
This
can
take
quite
a
while
because
you
might
have
hundreds
of
thousands
of
tests
for
a
big
application,
maybe
even
millions
so
running.
Those
could
take
a
really
long
time.
That's
not
very
effective,
and
it's
really
annoying
for
engineers.
It
really
slows
down
the
feedback
cycle
reduces
velocity,
so
what
most
teams
do?
Is
they
run
the
tests
in
parallel?
So
there
might
be
a
hundred
different
CI
servers
that
spin
up
in
parallel
and
run
the
tests
at
the
same
time.
A
But
if
you
spin
up
a
hundred
CI
tests
at
the
same
time,
each
one
of
those
typically
has
to
clone
the
repository.
This
creates
a
really
high
load
on
the
get
lat
server,
particularly
the
giddily
server,
increasing
memory
and
CPU
usage,
making
the
clone
slower
and
also
degrading
performance,
all
the
other
get
operations
that
might
be
happening
on
that
project
or
other
projects
that
are
on
the
same
git
reset.
A
So
git
has
this
wonderful
feature
called
pack
file
reuse.
So,
instead
of
dynamically
assembling
the
response,
when
you
clone
a
repository,
it
will
stream
the
pack
file
directly
from
disk
if
it's
been
correctly
packed
and
so
we're
working
on
a
range
of
upstream
improvements
to
get
itself
and
we'll
be
making
sure
those
improvements
are
available
in
git
lab
and
we
hope
to
ship
this
in
12.6
or
at
least
verify
and
test
these
improvements
to
reduce
the
the
problem
of
parallel
CI
tests.
A
We
know
this
is
impacting
a
number
of
our
customers,
we're
also
seeing
it
on
a
couple
of
projects
from
gitlab
comm.
So
this
is
a
really
exciting
and
high-impact
improvement
for
large
projects.
We
have
heavily
parallelized
CI
tests,
so
really
exciting
performance
improvements
here
and
finally,
the
fifth
item
I
wanted
to
share
is
an
update
on
our
progress
on
H,
a
giddily,
so
Gilly
is
how
we
scale
git
repositories
at
git
lab
and
we've
been
working
on
making
this
service
highly
available
for
our
customers.
A
We've
been
working
on
set
up,
creating
the
reverse
proxy
replication
and
in
this
12.6
development
cycle
we
focused
on
introducing
a
basic
version
of
failover,
and
this
is
all
working
towards
MVC
that
we
hope
to
ship
in
2020
in
March.
I'll.
Keep
it
continue
to
keep
you
updated
every
month
when
we
do
these
kickoff
calls
on
our
progress
and
hopefully
be
able
to
share
a
demo
soon
of
the
the
whole
cycle.
Once
we've
completed,
all
the
basic
components
need
to
demonstrate
replication
and
failover.