►
From YouTube: GitLab 13.0 Kickoff - Create:Source Code
Description
PM for Source Code group (Daniel Gruesso) does an overview of the items planned for 13.0 release of GitLab, shipping on May 22nd, 2020.
A
Hi
I
am
Daniel
Caruso
I
am
the
product
manager
for
the
create
source
code
group
and
today,
I'll
be
walking
you
through
the
kickoff
for
the
$13
release
for
the
source
code.
So
this
is
the
release
that
will
be
shipped
on
May
22nd
2020
and
our
team
is
working
on
some
exciting
changes
that
I'll
discuss
with
you
today.
So
the
first
one
is
the
ability
to
comment
on
multiple
lines:
an
emergency
diff.
A
So
currently
we
have
the
ability
to
comment
on
a
single
line
when
reviewing
an
mr-
and
that
is
great
when
the
reviewer
wants
to
provide
kind
of
a
simple
feedback
or
a
single
line.
But
oftentimes
a
comment
will
encompass
a
chunk
or
a
section
of
the
code
in
the
mr.
So
with
this
we're
looking
to
give
users
the
ability
to
select
a
range
of
code
in
the
mr
and
leave
a
comment
for
the
entire
range,
so
we
think
this
is
going
to
be
very
powerful
for
the
specificity
of
the
feedback.
A
That's
coming
back
on,
mrs
we're
really
excited
about
it.
The
next
thing
that
we're
going
to
work
on
is
making
merge,
ref
dips,
that
he
falls
comparison
mode.
So,
as
you
know,
in
12-8
we
introduced
a
new
view
for
merge
requests.
That
shows
you
kind
of
a
clear
comparison
when
you
have
merged
the
target
branch
into
your
branch,
and
we
find
this
view
so
valuable
that
we
want
to
make
it
the
default
of
view.
For
mrs
and
this
will
basically
add
more
clarity,
for
whoever
is
reviewing
the
mr.
A
The
next
thing
that
we're
going
to
work
on
is
supporting
multiple
code
owner
sections,
so
I'm
really
excited
about
this
one.
Currently
code
owners
only
allows
for
one
rule
to
match
each
path.
So
if
you
have
multiple
teams
that
want
to
use
the
feature,
they
can't
really
do
it
in
a
in
a
feasible
way.
So
what
we're
looking
to
do
here
is
that
will
allow
multiple
sections
in
the
coroner's
file
and
will
allow
for
more
specificity
with
rules.
A
So
you
can
have
multiple
rules
than
the
rule
that
has
the
most
specificity
is
the
one
that
will
be
used
and,
and
that
way
multiple
groups
can
have
their
own
file
and
not
kind
of
step
in
each
other's
toes
when
they're
making
change
to
code
owners.
So
we're
really
excited
about
this
change
and
we
think
that
it's
going
to
make
the
code
owners
feature
much
more
powerful.
The
next
thing
that
we're
going
to
work
on
is
around
code
intelligence
and
simplifying
the
setup
for
code
intelligence.
A
So,
as
you
know,
the
native
code
intelligence
feature
that
was
recently
shipped
with
kit
lab
requires
a
CI
pipeline
that
generates
an
l-sit
file
and
then
it
needs
to
be
converted
into
a
custom
good
lab
format.
So
we
want
to
simplify
that
process,
so
code
intelligence
can
reach
more
users
and
make
it
more
usable.
So
basically,
all
it's
going
to
do
is
require
users
to
use
a
standard
elsif
and
that
can
be
validated
either
by
gitlab
or
any
other
tool,
and
then
a
CI
will
take
care
of
the
rest.
A
As
long
as
the
CI
job
passes,
that
good
lab
will
do
the
rest
and
set
it
up
for
you
and
that
will
enable
features
like
just
hovering
over
your
code
and
being
able
to
see
the
links
like
the
references
or
the
definition
for
a
particular
term.
So
this
is
really
powerful
and
we're
really
excited
about
this
one.
And,
lastly,
we
want
to
enable
the
this
feature
of
native
code
navigation
for
everyone
right
now.
The
feature
is
behind
a
feature
flag.
As
I
said,
it's
not
the
setup,
it's
not
as
simple
as
we
would
like.