►
From YouTube: GitLab 12.5 Kickoff - Create: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
So
we
have
tackled
that
by
breaking
apart
the
request
to
retrieve
that
information
from
the
server
into
multiple
parts,
and
the
first
aspect
was
changing,
how
we
download
the
list
of
changed
files
to
populate
the
file
tree
and
provide
other
kinds
of
statistics
in
the
merge
request.
So
we've
implemented
that
API
as
part
of
this
change,
which
we've
been
working
on
in
12.4
and
the
interface
work
is
continuing
and
we
expect
that
to
be
completed
quite
soon
early
in
the
12.5
development
period.
A
The
other
aspect
is
loading
the
diff
contents
themselves,
so
that
is
the
syntax
highlighted
summary
of
the
changes
currently
reloads
that
all
in
one
giant
response
to
the
interface
and
when
that
when
there's
a
hundred
files
changed
and
ten
files
and
each
of
them,
the
response
is
large.
It's
over
a
megabyte,
often
multiple
megabytes,
and
this
means
that
the
page
doesn't
really
have
any
useful
information.
A
The
next
improvement
also
relates
to
the
merge
request,
interface,
and
it
particularly
relates
to
what
happens
when
multiple
people
are
working
on
the
same,
merge
request
at
the
same
time.
So
if
I'm
reviewing
a
merge
request
and
about
to
click
the
merge
button
and
someone
else
pushes
a
change.
Currently,
the
merge
button
grows
out,
which
is
good.
A
If
we
want
to
prevent
the
merge
and
in
some
cases
we
do,
but
in
other
cases
I
might
have
been
the
user
that
pushed
the
change
and
I
wanted
to
push
the
change
and
then
immediately
click
the
merge
button.
One
scenario
where
this
is
increasingly
common
is
where
people
are
using
suggested
changes.
So
if
I'll
ever
suggested
change
on
a
merge
request
proposing
to
fix
a
typo
in
a
code
comment
make
one
small
little
tweak
as
the
final
reviewer
of
that
manage
requests.
A
I
want
to
be
able
to
accept
those
changes
which
are
tiny
and
then
click
merge.
If
there's
CI
pipelines,
it'll
only
merge
if
the
pipeline
succeeds,
but
I
want
to
be
able
to
just
click,
accept
and
then
click,
and
today
that's
not
possible.
So
what
this
change
will
do
is,
rather
than
simply
blocking
the
merge
button.
A
A
If
you
write
a
detailed
long
description
and
you've
got
all
the
features
turned
on
related
to
auto
dev,
ops
and
CI,
the
sub
navigation
is
well
below
the
fold
of
the
page,
so
it's
somewhere
off
the
bottom
and
I've
got
to
scroll
to
find
it.
And
then,
if
there's
a
lot
of
discussions,
I
might
quickly
end
up
in
the
discussions
and
have
to
scroll
back
up
searching
hunting
for
the
sub
navigation
to
get
to
the
changes.
This
is
frequent
feedback
and
really
annoying.
A
So
one
of
the
changes
that
we've
been
exploring
and
testing
and
we've
had
very
positive
feedback
from
those
tests
is
to
move
the
navigation
above
the
description,
and
this
will
mean
that
it's
easy
to
get
to
as
soon
as
you
load
the
page.
This
other
navigation
will
be
visible
and
easy
to
click
to
get
from
A
to
B.
A
What
we've
heard
is
when
people
are
wanting
to
do
a
code
review
they're
wanting
to
look
at
just
the
code,
they're
really
wanting
to
focus
in
and
be
not
be
distracted
by
having
the
merge,
widget
and
description
above
the
changes
tab.
It
makes
the
height
of
the
page
much
longer
and
bigger
than
the
actual
useful
area
for
that
task.
This
means
that
if
you
quickly
scroll
to
get
to
the
top
of
the
diff,
you
end
up
scrolling
past
the
top
of
the
changes
and
ending
up
in
the
description.
A
Moving
the
merge,
widget
and
description
into
that
tab
and
then
keeping
the
commits
pipelines
and
changes.
Tab,
nice
and
focused
so
we'll
be
excited
to
hear
everyone's
feedback
when
we
launch
this
and
we'll
be
continuing
to
iterate
on
the
merge
request,
interface
to
really
improve
the
usability,
continue
to
improve
the
performance
and
make
gitlab
the
best
tool
for
code
reviews
and
finally,
I'd
like
to
give
an
update
on
high
availability
for
giddily.
A
This
is
a
project
that
we've
been
working
on
for
a
little
while
and
still
has
a
little
while
to
go
yet
until
it
becomes
generally
available.
But
when
an
instance
of
administrator
or
an
organization
is
using
git
lab
in
a
self
hosted
environment,
so
you're
running
your
own
get
lab
server
and
get
lab
is
often
really
critical
for
the
productivity
of
teams
and
businesses.
If
get
labs
down,
you
can't
deploy
a
new
version
of
your
application
and
so
that
that
could
be
really
problematic
if
a
serious
vulnerability
or
bug
comes
up
and
get
labs
down.
A
Suddenly
you
can't
deploy
so
high
availability
is
really
important,
and
so
we
want
to
make
high
availability
work
out
of
the
box.
We've
get
lab,
and
so
what
we're
doing
is
we're
implementing
support
for
this
in
giddily,
which
is
how
we
scale
get
inside
of
get
lab,
and
the
first
step
that
we've
been
working
on
is
implementing
a
reverse
proxy,
which
sits
between
Diddley
and
the
application,
and
you
can
read
more
about
Prefect,
which
is
the
name
we've
given
the
reverse
proxy
in
our
documentation.
A
We've
been
working
on
a
minimal
implementation
of
that,
and
recently
we
shipped
the
first
version
of
that
into
our
staging
environment
and
for
the
12.5
development
cycle.
Our
goal
is
to
try
and
get
that
minimal,
prefect,
reverse
proxy
into
production.
It
won't
be
doing
anything
on
get
lab
comm.
Hopefully
it
will
just
sit
there
and
work.
Just
fine
in
the
future.
Iterations
will
be
adding
more
and
more
features
to
it
like
replication
and
failover,
which
are
the
really
the
key
features
in
order
to
actually
ship
a
high
availability
solution.