►
From YouTube: GitLab 13.9 Kickoff - Create:Source Code
Description
Source Code PM (Daniel Gruesso) walks through the work planned for the 13.9 release scheduled to be shipped on 2021-02-22.
More information on the planning issue: https://gitlab.com/gitlab-org/create-stage/-/issues/12773.
A
Hi
this
is
daniel
grusso,
I'm
the
product
manager
for
the
create
source
code
group
here
at
gitlab,
and
today,
I'd
like
to
share
with
you
the
kickoff
for
the
gitlab
release,
13.9,
which
we'll
be
shipping
out
on
february
22nd.
So,
let's
get
right
to
it.
The
first
thing
that
we're
going
to
work
on
is
related
to
code
owners
as
part
of
gitlab
13.9.
A
You
are
now
able
to
define
optional
code
owner
sections
so
code
owner
sections
are
pretty
great
because
they
allow
multiple
people
or
multiple
groups
to
look
after
common
parts
of
the
code.
So
now
with
13
8
we're
going
to
be
able
to
mark
those
sections
as
optional.
If
you
want
to,
let's
say
indicate
who
the
code
owner
is
for
a
particular
part
of
the
code,
but
you
don't
necessarily
want
to
enforce
approvals
for
that
section
of
the
code.
A
So
that's
a
great
improvement
in
13.8
in
13.9,
we're
going
to
build
on
top
of
that
and
basically
we're
going
to
allow
direct
changes
to
those
files
that
have
to
do
with
optional
code
owner
sections.
So,
for
example,
let's
say
that
you
define
a
section
here
named:
go
and
you've
defined
it
as
an
optional
section
here,
with
the
carrot
character.
A
The
second
thing
that
we're
going
to
work
on
also
builds
on
code
owners.
So,
right
now,
when
you
create
an
approval
rule,
let's
say
you
don't
have
a
requirement
to
approve
by
code
owners,
but
you
have
defined
code
owner
sections
on
your
file
today.
When
you
create
merge
request
approvals,
you
can
define
either
users
or
groups
that
are
able
to
approve
changes
for
that
market
request
so
well
now.
A
What
we
were
going
to
do
as
part
of
13.9
is
that
you
will
be
able
to
also
define
sections
of
your
code
owner
files
to
be
the
approver
for
a
particular
merge
request
or
as
a
permanent
setting
on
your
project.
So
that's
going
to
be
pretty
great,
as
I
said,
for
allowing
multiple
groups
to
look
after
parts
of
the
code,
but
then
for
changes
that
you
deem
that
are
sensitive
and
you
want
them
to
be
looked
at
by
a
particular
section.
You're
going
to
be
able
to
do
that.
So
we're
excited
about
that
change.
A
So
you
know
people
are
allowed
to
push
directly
to
the
master
branch
or
to
the
main
image
and
then
push
the
change
and
then
revert
the
setting.
So
you
know
it's
kind
of
time
that
could
be
better
spent
in
getting
your
application
back
into
a
working
state.
So
what
we're
going
to
do
as
part
of
39
is
you're
going
to
be
able
to
define
as
part
of
your
protected
branch
settings
who,
which
user
or
which
groups
are
allowed
to
force,
push
to
the
to
the
protected
branch.
A
So,
let's
say
in
the
example
that
I
mentioned
earlier.
If
I
have
a
group
of
sres
or
a
particular
user
that
I
know
it's
it's
on
paul
or
things
like
that,
I'm
going
to
be
able
to
give
that
person
the
power
to
force
push.
So
those
firefighting
scenarios
become
kind
of
easier
to
manage
and
handle.
It's
very
excited
about
that
change,
something
that
has
been
here
for
for
a
while.
A
I
see
that
it
has
now
166
upvotes,
so
very
excited
about
that,
and
then
the
final
thing
that
we're
going
to
focus
on
has
to
do
with
forking.
So
today,
when
you
fork
a
project-
and
let's
say
you
want
to
compare
your
changes
against
the
parent
fork-
well,
you're,
not
a
I'm
able
to
do
that
within
the
project.
You
can
only
compare
branches
with
that
that
are
basically
part
of
your
torque
network.
A
But
if
you
want
to
compare
your
changes
against
the
parent,
well
you're
not
able
to
do
that
today,
but
it's
a
great
capability
to
contribute
to
projects
that
are
not
owned
by
you,
and
we
see
this
happening
a
bunch
in
open
source
projects,
but
also
large
orgs
that
contribute
back
to
projects
outside
of
their
org
or
to
a
sister
org.
So
this
is
going
to
make
that
easier
and
allow
you
to
compare
those
changes
in
an
easier
manner.
So
we're
very
excited
about
these
changes
and,
as
always,
your
feedback
is
very
welcome.