►
From YouTube: UX Showcase - Registry Customization
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
A
The
first
thing
that
I
wanted
to
share
with
you
was
expanding.
The
cleanup
policies
to
include
packages
and
other
dependencies
this
will
enable
our
customers
to
manage
their
package
registry
storage
costs
by
automatically
removing
unneeded
assets
from
a
user
goal.
We
wanted
to
create
a
tool
that
allowed
admins
and
maintainers
to
identify
and
automatically
remove
packages
and
other
stored
dependencies
from
the
registry,
all
with
the
focus
of
helping
them
manage
their
storage
costs.
A
I've
shared
what
we
worked
on
before
with
the
cleanup
policy
for
image
tags
before
here
at
the
showcase,
and
I'm
really
excited,
because
we
can
take
all
of
the
learnings
that
we
got
from
doing
that
work.
The
research,
the
actual
building
of
it
we've
gone
through
two
iterations,
take
all
of
that
information
and
port
it
over
to
different
packages
and
other
dependencies
with
a
lot
of
confidence.
A
The
goal
is
to
create
an
automatic
tool
that
will
regularly
remove
unwanted
dependencies
based
on
a
variety
of
factors.
This
could
include
the
package
name
and
version
the
amount
of
time
that
package
has
been
in
the
registry
and
historical
data
of
how
the
package
was
built,
like
the
branch
commit,
mr
et
cetera,
the
next
steps
is
going
to
include
a
technical
evaluation
of
the
cleanup
policy
for
image
tags
and
see
what
can
be
ported
over
to
the
package
side
and
what
needs
to
be
customized.
A
One
of
the
other
things
that
we're
working
on
right
now,
which
kind
of
flows
into
the
post
mvc
idea,
is
going
to
change
the
focus
of
the
cleanup
policy
from
being
associated
with
the
packages
metadata
to
move
more
of
its
usage
data.
When
we
talk
to
our
users,
one
of
the
things
that
they
really
wanted
to
see
in
the
next
version
was
to
determine
if
a
package
or
dependency
should
be
removed.
Based
on
the
amount
of
time
it's
been
since
it
was
last
pulled.
A
For
example,
they
would
like
to
be
able
to
say
this
package
can
be
deleted
because
it
wasn't
built
from
the
main
branch
and
nobody
has
pulled
it
for
the
last
30
days.
That
usage
data
aspect
ensures
that
they're
not
accidentally
deleting
assets
that
they
need
or
being
used
regularly
so
it'll
be
really
exciting
and
really
make
that
kind
of
feature
lovable
for
our
users.
A
A
We've
talked
to
a
large
number
of
organizations
and
gotten
some
varied
responses,
and
we've
discovered
that
these
variances
come
both
from
the
package
format
itself.
So
if
it's
npm
or
maven,
et
cetera
or
from
the
type
of
organization
or
devops
setup
that
they
have
can
alter
how
they
feel
about
duplicate
packages
as
an
mvc
solution,
we
wanted
to
create
a
setting
that
would
allow
the
organization
to
determine
if
the
package
registry
at
a
project
level
would
allow
for
duplicate
packages
or
not
allow.
A
One
thing
we
did
add
based
on
the
research
was
also
the
ability,
if
a
if
an
organization
is
determined
not
to
allow
duplicate
packages,
to
add
exceptions.
The
story
that
we
heard
over
and
over
again
when
we
had
these
conversations,
was
that
we
don't
want
to
allow
duplicate
packages
except,
for
example,
maven.
You
build
several
snapshots
that
get
added
and
it's
used
as
part
of
testing.
So
we
want
to
allow
snapshots
without
having
to
create
new
versions
of
them,
but
not
allow
duplicates
in
any
other
form.
A
We
want,
from
a
business
perspective,
for
customers
to
be
able
to
create
immutable
registries
that
can
be
pulled
from
that
cannot
be
updated
or
added
to
and
from
the
user
goal.
We
wanted
a
really
easy
way
to
turn
that
read
only
mode
on
and
off
and
make
sure
that
it
was
really
clear
what
they
were
doing.
A
A
No
current
package
can
be
updated
inside
of
that
registry
and
that
users
and
their
subsequent
customers
can
still
pull
packages.
The
example
that
we
heard
around
this
was
that
we
have
a
team
that
is
doing
research
around
certain
types
of
technology
and
at
the
conclusion
of
their
research.
They
want
to
be
able
to
upload
and
publish
those
packages
so
that
other
teams
and
other
research
teams
even
can
use
those
packages
and
everything
can
be
built
upon.
A
A
The
last
thing
I
wanted
to
talk
about
was
file
size
limits,
as
storage
and
consumption
has
been
a
big
priority
for
us
here
at
gitlab
and
for
our
customers
file
size
limits
really
help
organizations
determine
some
restrictions
on
their
file
sizes
in
order
to
help
them
with
their
storage
costs.
In
general,
we
wanted
to
give
instance
level
admins
a
way
to
set
package
file
size
limits
to
help
their
organizations
manage
their
storage
costs
and
from
a
user
goal.
A
I
like
this
story
because
this
actually
didn't
start
with
design.
This
was
back
in
engineering.
We
needed
to
implement
the
feature
for
file
size
limits.
It
came
up
that
at
the
get
lab
admin
level,
we
should
be
able
to
set
those
limits
for
the
different
tiers
of
our
product,
as
well,
as
instance,
and
self-hosted
should
be
able
to
set
those
restrictions
themselves.
So
the
ui
and
the
idea
came
from
back
end
and
then
I
came
in
and
we
worked
together
on
it
and
that's
always
a
really
fun
story
and
a
really
fun
experience
for
me.
A
So,
like
I
mentioned
gitlab
needed
to
introduce
file
size
limits
to
help
customers
better,
manage
their
package-related
storage
costs.
The
investigation
concluded
that
customers
had
wildly
different
needs
and
expectations,
and
the
different
package
formats
also
had
wildly
different
requirements
and
needs
working
with
the
back
end.
We
were
able
to
first
create
an
mvc
that
is
a
very
light
ui
that
enable
git
lab
admins
and
instance
level
admins
to
adjust
the
file
size
limits
for
their
organizations,
and
we
added
the
tab
effect
to
be
able
to
determine
the
different
tiers
and
set
those
limits
as
well.
A
A
Thank
you
so
much.
That's
what
I
wanted
to
share
with
you
today.
I
also
want
to
send
a
special
thanks
to
tim
and
steve
and
nico
and
the
rest
of
the
package
team
for
all
of
your
help.
Making
these
really
small
changes
that
really
help
customize
the
experience
of
our
registries
to
match
our
organization's
needs.