►
From YouTube: GitLab 12.7 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,
my
name
is
James
Ramsey
and
I'm
senior
product
manager
for
the
source
code
and
get
early
groups
of
the
create
stage
of
the
develops
lifecycle
here
at
gate.
Lab
I've
got
two
features
that
I'd
like
to
highlight
to
you
that
we're
going
to
be
working
on
in
the
12.7
release
of
get
lab
which
will
be
released
on
January
22nd.
The
first
is
to
add
a
new
mode
to
the
merge
request.
Diff,
so
I'll
quickly
open
the
issue
for
this
improvement.
A
The
merge
request
allows
you
to
see
the
changes
that
are
being
made
and
proposed
to
be
merged
into
another
branch,
and
the
comparison
view
shows
a
diff
summarizing.
The
changes
it
by
default
shows
a
comparison
between
your
branch
and
the
target
branch,
often
master
or
develop,
but
there
are
some
situations
where
the
way
the
diff
is
calculated
can
result
in
a
confusing
result
to
be
shown
that
tap
to
provide
a
bit
of
context
and
backstory.
There
are
a
number
of
different
ways
that
get
supports,
showing
a
diff.
A
The
way
we
do
it
is
using
the
git
diff
command
target
three
dots
source,
so
target
being
the
target
branch
source.
Being
the
source
branch
or
the
feature
branch
and
what
the
three
dots
symbolizes
is
calculating.
The
diff
based
on
the
most
recent
commit
in
the
feature,
branch
and
the
common
ancestor,
commit
between
the
source
and
target
branch,
and
so
that
could
be
quite
a
while
ago,
potentially
a
a
week
or
two
ago
when
the
feature
branch
was
created
and
sometimes
what
happens
is
over
a
period
of
time.
Master
branch
progresses
quite
significantly.
A
And
what
might
happen
is
the
developer
merges
the
master
branch
or
the
target
branch
back
into
the
source
branch
to
bring
those
changes
into
their
feature
branch
before
then
merging
back
into
that
same
branch?
When
that
happens,
if
you're
doing
comparison
using
the
three
dots
using
the
merge
base,
that
will
show
not
only
the
changes,
you've
authored
in
your
feature
branch,
but
also
the
content
of
that
merge,
commit
from
master
into
the
source
branch
or
your
feature
branch
and
that
can
result
in
a
pretty
confusing
diff.
A
And
so
what
we've
been
working
on
over
the
past
couple
of
releases
is
this
feature
called
a
merge
ref,
so
we
create
murderer
already
one
for
the
head
and
one
for
the
merge
result
and
the
merge
result.
One
allows
us
to
show
a
much
more
useful
diff
in
this
situation
and
so
in
12.7
we'll
be
adding
a
very
first
minimal
version
of
this
diff
mode
to
the
merge
request.
Interface
it'll
be
available
in
the
drop
down
here.
Currently
you
select
the
latest
version.
A
This
new
version
will
not
be
shown
by
default,
you'll
have
to
select
it
and
it
will
also
not
support
commenting
in
12.7,
and
this
is
because
there's
a
quite
a
lot
of
work
involved
in
this,
and
so
we're
trying
to
take
small
steps.
Small
iterations
towards
this
feature.
But
this
is
a
really
big
improvement
and
will
be.
You
can
follow
the
epic
to
see
future
iterations
and
see
will
be
going
over
coming
releases,
so
this
is
really
exciting
handling
an
important
situation,
making
sure
the
diff
is
really
accurate
to
make
sure
that
reviews
are
efficient.
A
The
second
feature
I'd
like
to
highlight
is
scoping:
merge,
request
approvals
to
protected
branches.
Over
the
past
year,
we've
been
working
to
improve
the
configuration
of
merge,
request,
approval
rules
as
well
as
other
merge
requests
related
settings
so
that
different
types
of
organizations
and
teams
can
accurately
make
sure
the
right
people
are
reviewing.
Merge
requests
make
sure
that
that
a
minimum
number
is
reached
from
the
right
number
of
groups.
A
So
someone
from
back-end
some
in
front-end,
some
from
security,
we
are
have
we've
had
code
owners
support
over
the
last
12
months,
so
that
you
can
specify
dynamically
who
should
review
it
based
on
the
file
paths
changed
in
the
merge
request,
but
one
thing
we've
noticed
and
heard
from
a
lot
of
our
customers
is
that
as
they
adopt
these
new
features
and
make
their
merge
request
rules
more
strict
and
substantial.
Like
the
number
of
approvals
required.
A
There
are
a
bunch
of
situations
where
most
requests
for
approvals
aren't
needed.
Merging
from
feature
branch
to
feature
branch
is
one
example.
Probably
no
approvals
are
required
in
that
situation,
but
also
release
branches,
for
example,
require
different
source
of
approvals
to
the
default
branch.
So,
if
you're
merging
from
master
into
a
release
branch
or
from
release
branch
to
release
branch,
that
code
should
already
be
trusted
because
it's
in
a
protected
branch.
A
So
if
it's
entering
via
master,
has
already
met
the
quality
controls
that
you've
set
and
so
different
kinds
of
approval
rules
are
required
in
order
to
solve
this
problem,
reducing
the
amount
of
approvals
required
when
they're
not
needed
and
allowing
stricter
rules
when
they
are
needed.
We're
allowing
merge,
request
approval
rules
to
be
scoped
to
protected
branches.
A
In
a
recent
release,
we
allowed
code
owner
require
approval
requirements
to
be
scoped
to
protect
branches,
and
so
this
will
be
consistent
with
that
and
allow
us
in
the
future
to
streamline
the
settings
into
a
new
unified
interface
that
we're
beginning
to
think
about
building,
and
so
this
is
a
mock-up
that
we've
built
where
you
can
see.
It's
very
similar
to
the
current
approval
rules,
interface,
but
there'll
be
a
new
section
where
you
can
select
drop
from
the
drop
down
which
protected
branches
a
rule
will
apply
to.
A
So
this
means
that
you
can
just
put
all
your
protections
on
the
master
branch,
if
that's
the
branch
you're
using
for
continuous
deployment
in
your
releases
and
any
other
mode
requests
that
developers
create,
can
just
exist
without
any
approval
requirements.
So
you
can
add
the
strict
enforcement
of
your
policies
and
controls
where
you
need
them,
but
then
provide
flexibility
and
freedom
to
your
engineers
and
all
the
other
important
workflows
that
happen
on
a
day
to
day
basis.
So
these
are
really
two
very
meaningful
improvements.
A
Scoping
merger
to
approval
rules
to
protect
branches
should
provide
really
immediate
benefit
to
lots
and
lots
of
customers
in
12.7,
while
adding
the
minimal,
merge.
Ref
diff
mode
is
really
the
first
iteration
in
a
number
of
iterations,
where
we're
going
to
be
making
this
new
improved
diff
available
to
everyone.
So
stay
tuned
for
further
updates
in
upcoming
releases,
as
we
continue
to
improve
this
feature
and
also
a
brief
update
on
the
state
of
get
early
AJ,
which
is
one
of
the
big
in
big
projects
that
were
working
on
in
the
get
early
team.
A
We're
continuing
to
work
on
replication
and
tracking
replication
State
in
the
database
and
we'll
be
doing
regular
demos
of
the
failover
in
our
demo
environment
to
test
that,
and
we've
also
started
rolling
out
some
small
iterations
of
giddily
H,
a
particularly
the
prefect
proxy
into
our
production
environment,
to
begin
testing
that
at
scale
and
so
we're
continuing
to
work
towards
a
march
22
minimal
version
that
we'll
be
hoping
to
make
GA
in
in
late
March.
So
that's
the
progress
from
the
get
early
team
which
is
moving
forward.