►
From YouTube: GitLab 13.3 Kickoff - Package:Package
Description
Kickoff video for milestone 13.3, which will be released on August 22, 2020.
A
Hello
and
welcome
to
the
kickoff
video
for
milestone
13.3,
which
is
scheduled
for
release
on
august
22nd
2020..
Today,
I'm
here
with
ian
and
we're
going
to
talk
about
what
we're
working
on
in
the
package
group
and
what
some
things
that
we're
excited
about
ian.
Do
you
want
to
talk
a
little
bit
about
what
we're
working
on
on
the
validation
track?.
B
For
sure
we
are
going
to
be
doing
solution,
validation
for
remote
and
virtual
repositories.
We
have
spoken
to
some
of
our
customers
and
users
and
discovered
that
they
tend
to
have
packages
in
many
different
locations,
not
all
nice
and
refined
inside
of
gitlab,
and
so
we've
designed
a
solution
that
will
help
them
by
connecting
remote
repositories
and
registries
into
the
gitlab
infrastructure
and
put
together
several
different
repositories
and
registries
into
one
endpoint,
so
that
they
can
have
a
one
nice
streamlined
connection
api
to
be
able
to
get
all
their
packages.
B
B
Definitely
I
would
love
to
get
everyone's
experience,
because
we
want
to
make
sure
our
products
and
our
features
are
designed
for
everybody.
Specifically,
though,
we're
kind
of
focusing
on
the
larger
organizations,
the
ones
that
tend
to
have
packages
in
many
places,
so
they'll
have
some
in
an
archive
from
five
years
ago.
Some
they've
recently
connected
and
some
that
are
out
on
public
registries,
will
really
benefit
most
from
this
kind
of
feature.
A
Cool
yeah-
I'm
really
excited
about
this
one.
Do
you
want
to
jump
over
to
what
you're
designing
this
milestone.
B
Yes,
I'm
really
excited,
because
the
things
we're
focusing
on
in
the
design
end
will
help
our
customers
manage
their
storage
costs
when
it
comes
to
the
package
registries
themselves.
So
the
first
one
is
focusing
on
creating
cleanup
policies
for
packages.
We
have
these
already
for
tags
and
we've
gotten
a
lot
of
great
feedback.
We'd
like
to
do
something
very
similar
where
you
can
set
up
automatic
rules
to
indicate
when
packages
may
not
be
useful
anymore
and
to
automatically
remove
them
from
storage.
B
The
next
one
is
to
help
users
that
have
many
different
versions
of
the
same
package:
speed
up
the
way
that
they
can
just
delete
those
extra
versions
and
older
versions
of
packages
by
displaying
them
right
in
that
other
versions
tab.
So
you
would
get
a
nice
way
to
see
a
whole
list
of
all
those
versions
and
just
click
through
and
delete
them
as
easily
as
possible.
A
Cool,
it
sounds
like
there's
a
theme
here
that
we're
helping
people
lower
the
cost
of
storage
for
using
git
lab
exactly
okay,
and
I
guess
I
could
jump
in
onto
what
we're
working
on
on
the
build
track.
So
we
have
a
few
different
items.
Let
me
just
move
my
myself
and
e
in
here,
so
the
first
one
is
adding
a
setting
to
prevent
or
to
disable
duplicate
package
uploads
to
the
package
registry.
A
This
is
a
common
request.
We
hear
about
the
maven
repository
and
pi
pi
that
you
can
upload
a
duplicate
package
and
then
it's
confusing
which
one
you're
actually
supposed
to
use.
We
don't
want
to
completely
just
block
people
from
uploading
duplicates
because
we've
talked
to
some
customers.
That
say
we
want
duplicates,
that's
actually
acceptable.
A
So
what
we'll
do
is
add
a
setting
at
the
group
level,
which
will
say
to
say
it'll,
be
automatically
set
to
disable,
but
you
could
always
enable
it
if
you're
interested
the
next
one.
Keeping
in
this
theme
of
helping
reduce
the
cost
of
storage
right
now,
you
can't
delete
packages
from
the
group
level
package
registry
view.
So
what
we'll
do
in
this?
Next,
milestone
is
we'll
add
in
that
ability.
A
And
then
one
more
or
two
more
actually,
we
have
in
13-2
the
last
milestone.
We
launched
support
for
composer
dependencies
in
the
package
registry,
but
there
was
a
problem.
We
didn't
actually
update
the
user
interface
to
reflect
the
most
up-to-date
metadata
and
to
have
its
own
special
tab
in
the
user
interface,
so
we'll
be
adding
support
for
that
in
13.3.
A
And
finally,
we
will
be
overall
updating
the
user
interface
with
for
the
package
registry.
So
here
you
could
see
an
example
of
the
package
details
as
it
is
now.
You
could
see
this.
We
have
this
sort
of
a
table
here
with
some
metadata
and
then
the
setup
commands
well
we're
kind
of
changing
the
whole
thing.
A
This
is
an
inspiration
for
me
and
I
feel
like
I'm
stealing
his
thunder
somehow,
but
this
is
we're
changing
it
around
that
you'll
be
able
to
see
a
history
or
an
activity
feed
for
what's
been
happening
with
your
package,
you
could
see
here
when
it
was
published
which
commit
was
responsible
for
it
which
pipeline,
for
example,
you
still
have
access
to
the
install
and
setup
command.
So
if
you
want
to
set
up
set
gitlab
as
a
remote
repository,
you
could
quickly
do
this
or
you
can
easily
find
out.
How
do
I
install
this?
A
A
B
B
Not
only
are
we
helping
users
focus
on
what
matters,
so
how
did
this
package
come
to
be
and
where
did
it
come
from
separating
out
the
duplicative
data
and
additional
data,
but
also
the
ui
just
looks
more
polished
now
and
it
helps
refine
the
idea
that
it
is
up
to
par
with
the
rest
of
git
lab
and
feels
in
harmony
with
the
rest
of
the
user.
Experience.
A
Well
well
said
I
wanted
to
vote
for
this
one
too,
because
I'm
also
really
excited
about
this,
but
I'm
more
excited
for
the
vision
of
the
dependency
proxy
and
where
it's
going,
I
think
it's
going
to
really
help
our
larger
customers
start
to
rely
solely
on
gitlab
for
artifact
management.
So
I
think
where
this
is
going
in,
the
future
has
got
me
really
excited
and
I'm
just
hoping.