►
From YouTube: Package: Think BIG 01-15-20
Description
In which we discuss improvements to the Container Registry UI, replacing vendors and epic puns
A
Hello,
everyone
welcome
to
think
big
that
it
is
now
being
recorded,
which
is
very
important.
I.
Have
the
first
agenda
item.
Is
the
housekeeping
item
we're
shifting
the
cadence
of
our
think
big
sessions?
We
want
to
make
sure
that
we're
using
our
time
really
wisely,
especially
the
synchronous
time,
so
we're
dropping
it
down
to
once
a
month.
I'm
sure
have
seen
an
update
on
the
calendar
a
few
days
ago.
So,
let's
think
number
one
thing
number
two:
is
we
successfully
validated
the
new
designs,
including
the
additional
get
lab
metadata?
We
tested
it
with
users.
A
We
asked
them
to
try
to
complete
a
task
with
the
current
UI
and
then
the
design
of
the
new
UI
and
then
asked
follow-up
questions
to
see
if
they
were
better
able
to
troubleshoot
problems
or
understand
the
history
of
a
package.
So
we
had
a
lot
of
successes
there.
Next
steps
is
going
to
be
partnering
with
the
team
member
to
kind
of
break
apart
the
design
into
what
the
next
steps
are
going
to
be
so
we'll
see
the
new
designs
hitting
the
package
stage
pretty
quickly
and
with
that
I
give
it
to
NIC
and
Nico.
B
B
So
this
is
how
the
new
container
register
look
like
before
this
will
be
an
expandable
section
section.
It's
now
a
paginate
list
that
you
can
navigate
today.
They
stretched
from
the
back
end,
and
now
the
biggest
difference
is
that,
whenever
I
click
here
instead
of
opening,
the
section
is
navigating
to
a
new
page
with
a
unique
URL
and
it's
pulling
down
all
the
tags
on
the
system.
So
this
became
like
a
list
and
details
page
well,
even
though
the
detailed
page
now
contains
another
list,
it
can
actually
be
enriched
with
the
image
name
image
info.
B
Whatever
info
we
can.
We
want
to
put
here
so
why
this
is
very
different
compared
to
the
previous
approach.
Well,
beside
that
there
is
an
animation
I,
don't
know
if
you
can
appreciate
it
in
the
screen
share.
Is
that
actually,
this
is
a
front-end
navigation.
It
means
that
every
time
I'm
going
back,
this
is
cached
I'm,
not
refreshing
the
info
year.
This
is
like
the
slowest
call
that
we
have
in
the
system,
along
with
the
tag.
B
So
this
is
a
huge
performance
boost,
so
I
can
jump
in
and
forth
between
the
tags,
and
this
generates
zero
problems,
and
I
said
before
that.
This
will
work
on
the
group,
so
this
is
like
a
project
that
is
on
its
own.
This
is
a
project
which
is
part
of
gitlab,
at
least
an
administrative
group
when
it
has
his
own
tags.
Let's
pick
something,
it
should
have
a
lot,
no
okay,
and
if
we
go
in
the
group
level,
this
is
now
loading
together.
All
the
group,
the
size
of
the
pagination,
is
defined
by
a
constant.
B
This
is
something
that
you
can
adjust
and
once
again,
I
can
jump
in
out
in
and
out
of
the
target
like
rather
Christian
and
rather
fast.
Okay.
The
bonus
here
is
that
this
is
like
on
localhost.
So
there
is
like
the
network
code
is.
There
is
like
zero
basically,
but
the
the
code
was
low
because
it's
actually
the
API
of
the
container
register
is
not
the
fastest
one,
but
like
this
due
to
the
fact
that
is
separate-
and
this
is
cached-
it
feels
much
faster.
B
As
I
said,
this
is
a
unique
page
in
URL.
The
only
little
bump
that
you
see
here
is
that
the
breadcrumb
is
going
to
you
quickly,
flash
because
in
rails
doesn't
know
about
the
last
part
here
basically,
and
we
in
the
JavaScript
is
taking
over
to
actually
update
the
breadcrumb,
but
it
also
means
that
the
breadcrumb
is
also
front-end
navigation,
and
so
we
can
keep
the
animation.
B
We
can
keep
the
caching
of
that
of
the
request,
so
the
work
that
we
did
behind
this
is
mostly
front-end
and,
of
course,
there
is
a
little
bit
of
back-end
what
we
need
to
basically
enabled
pagination
on
the
images
endpoint
or
repost
endpoint.
However,
we
want
to
call
them,
and
then
you
can
see
that
here
in
the
code.
B
This
is
your
own
time,
so
the
steriliser
here
is
this
stuff
that
we
brutally
copy
pass
it
from
tag
sterilizer
and
project
and
group
now
to
just
have
with
pagination
plus
the
show
page,
because
we
need
to
render
the
navigation
back
to
the
index
so
that
the
JavaScript
can
become,
and
this
is
basically
the
extent
of
that
I
can
worked.
What
is
working
and
the
rest
is
just
a
mole
and
features
like
to
load
and
unload
stuff.
D
E
E
B
E
B
B
Normally,
it
should
be
like
image
/
anyone
that
is
actually
the
your
base64
encode
full
path
to
reach
the
API.
But
this
is
something
that
we
can
flush
out
outside
of
approach
of
perfect
content.
Ideally,
this
work
needs
to
be
split
problem
for
Amar's
to
be
able
to
be
manageable,
yeah
any
other
questions
so.
F
B
G
B
F
I'm
curious
is
the
way
that
you
have
these,
like
you
know,
like
the
hall
I
know
it's
just
the
animation
of
switching
from
one
page
to
another,
but
it
makes
me
think
about
if
we
can
compartmentalize
that
into
like
a
component
when
dealing
with
packages,
like
maybe
there's
a
view
where,
depending
on
certain
package,
managers
have
like
a
more
invested
kind
of
like
file.
Setups,
so
it'd
be
kind
of
cool
to
have
like
something
where
it's
like.
F
B
C
C
So
I
guess
I,
don't
know
if
this
is
like
something
that
we
want
to
introduce
as
a
company-wide
animation,
because
I'm
see
if
you're
gonna
have
certain
bits
of
gitlab
working
like
this
and
then
other
bits
of
get
lab.
Not
working
like
this.
It's
gonna
be
possibly
become
a
very
like
jarring
experience
over
time,
especially
if
the
animations
between
different
areas
on
same
or
they
change
or
another
group,
wants
a
different
style
of
animation
or
whatever
it
might
be,
and
I
don't
know.
C
F
A
One
of
the
things
I'll
do
Nicky
Nicko
is
I'll
reach
out
to
the
rest
of
the
UX
team
and
see
because
we
don't
use
this
animation
or
transition
anywhere
else
to
see
if
there
is
a
reason
for
it
as
well
as
have
a
conversation
around
like
how
to
introduce
that
properly.
It
could
be
something
that,
if
you
are
looking
at
a
detail
of
a
detail
of
the
detail,
we
kind
of
offer
up
a
animation
solution.
A
B
As
a
sidenote
I
mean,
the
animation
is
the
least
amount
of
technical
stuff,
you
can
just
remove
it
with
one
removing
one
characters
from
the
components
and
the
resting
state
yeah.
Thank
you
for
taking
a
look
into
this.
What
what
is
your
opinion
about
the
usability
of
this
compared
to
the
expandable.
A
List
for
sure
I
think
just
if,
if
it
was
just
what
it
is
now
where's
the
same
information
as
the
expandable
list,
just
in
a
new
view,
maybe
not
as
valuable
but
I
could
see
it
very
quickly
coming
out
into
like
this
is
the
full
detailed
view
of
that
and
that
experience
working
out
really
well
I
would
want
to
put
it
in
front
of
the
user
and
just
get
their
reaction
right.
That's
always
my
answer
to
that
question.
So,
I'm.
B
So
we
could
implement
this
in
parallel
with
the
existing
solution
and
just
turning
it
on
and
off
with
the
feature
flag.
This
is
actually
what
is
running
on
my
machine
right
now.
I
can
just
turn
off
the
feature
flag
and
you
get
the
old
view
any
at
least
without
problems
so
that
that
could
be
used
to
like
do
some
testing
with
the
user
as
well.
That's
really
good
to
know
and.
E
And
we
have
some
internal
projects
that
have
one
at
the
group
view
that
they
would.
That
would
be
useful
and
then
have
many
many
images,
so
we
could
test
internally
pretty
easily
I
know
we
have
this
CNG
project
that
hosts
all
of
the
get
may
have
required
images,
so
that
would
that
would
be
a
good
user
test.
We
could
run
and
well
dan
has
a
question
I.
Don't
yet
you
want
to
vocalize
it.
D
Yeah
I
was
just
going
to
say
the
initial
pages.
That
is
the
the
capability
add
metadata
here
like
I
know.
This
is
just
a
serious
example,
but
if
we
have
these
sort
of
foo
bar
Baz
developer
names,
it
gets
pretty
I,
don't
know
which
one
is
which
right,
if
I'm
sort
of
paging
through
here
I'm,
just
wondering
what
the
end
point
brings
back
from
that
specific
call.
Are
you
getting
a
list
of
tags.
F
E
I
think
the
we
were
blocked
from
doing,
search
and
filtering
because
of
the
API
and
so
yeah
and
sorting
because
of
the
time
of
the
API
requests.
That
would
be
really
valuable
if
we
could,
if
we
could
sort
but
I,
think
we're
we're
dependent
on
getting
storing
everything
in
a
database
or
locally.
So
we
could
do
that.
E
E
B
I
think
that
from
that
code
is
final,
probably
90%
final,
because
we
reuse
most
of
the
production
code
that
we
have
and
whatever
we
didn't
reuse.
We
use
the
same
pattern
of
the
design
tab,
which
is
uses
the
same
technology
and
same
technique
that
we
are
using
here,
so
be
your
router
and
this
kind
of
stuff.
So
we
are
following
already
established
pattern.
The
back
end.
We
hope
we
pass
that
code.
So
probably
back
an
engineer
can
take
a
look
and
decide
if
it's
okay
or
it
needs
to
be
redone,
and
then
we
will.
B
E
B
Yeah
I
I
personally
wish
that
we
could
actually
display
the
image
in
full
here,
because
this
is
a
unique
URL.
So
I
can
copy
this,
send
it
to
you
and
you
can
open
in
your
browser
right
and
if
you
don't
have
the
image
in,
for
at
least
just
the
name
of
the
part
or
something
it
just
be
like.
Where
am
I
what
I'm
doing
with
this?
B
Because
you
just
get
a
touch
info
and
to
do
so,
there
was
more
back-end
work
needed
because
we
actually
need
to
pass
the
information
here
up
here
in
the
URL
and
if
I
start
adding
details.
This
URL
like
grows
enormously
long
and
not
okay,
and
so
we
will
need
to
modify
the
API
to
work
by
tag
ID,
probably
instead
of
like
now
we
have
a
path
that
we
can
eat
to
get
this.
B
So
there
is
a
little
bit
more
work
on
the
backhand
side,
but
I
think
it
will
be
available,
but
it
can
also
be
an
interactive
step
where
here
you
are
perfectly
in
context.
While
you
are
navigating
from
the
list
to
the
tags
and
then
if
you're
refreshing
the
page,
you
have
a
little
bit
less
information.
That's
something
that
you
can
leave
on,
probably
in
the
beginning,
but
maybe
he
and
he
had
better
opinion
and
me.
A
That
was
actually
excuse
me
where
my
head
was.
That
is
how
to
like
make
this
detailed
view
a
little
bit
more
robust
and
fill
it
with
the
information
or
users
are
looking
for
about
the
image
that
isn't
specific
to
the
tag.
If
we
could
get
that,
that
would
be
a
huge
win
for
sure.
I
agree
with
you,
Nica.
A
Also
I
think
I
forgot
to
say
this.
It
was
a
really
cool
proof
of
concept.
It
was
worth
the
hype.
Mr.
Nico,
it's
really
great
to
see
the
the
different
views
and
that's
starting
to
separate
the
navigation
and
the
experience
of
it
instead
of
just
kind
of
listing
it
out
full
face
for
the
user,
I'm
really
excited
by
it.
F
F
B
D
And
so
the
other
thing
I
was
going
to
say
is
that
we
we
now
have
the
capability
to
actually
start
prioritizing
work
in
the
container
registry.
So
if
there,
if
there
is
like
really
valuable
features
and
work
that
we
can
be
looking
at,
we
can
start
working
on
those
things
and
prioritizing
them
accordingly
with
the
Haleigh
and
ROM.
So
it
might
have
blocked
us
before,
but
we're
not
necessarily
blocked
on
that
stuff.
Any
more
of
this,
this
should
be
useful
stuff
to
work
on.
B
B
Somebody
mentioned
that
we
don't
have
a
pagination
on
the
list
and
pointless
a
little
bit,
not
okay,
for
the
images
we
have
for
the
tags,
but
we
don't
have
for
the
images
and
that's
why
the
current
implementation
of
the
group
level
container
registry
is
sitting
behind
the
feature
disabled
by
default.
Feature
like
because
there
it
libros
even
more
like
because
you
are
listing
thanks
from
different
rebels,
and
so
we
will
solve
that
concern
as
well,
and
it
will
open
the
path
for
searching
for
sorting
and.
H
B
A
So
one
of
the
things
we
need
to
avoid
is
the
pagination
sided
pagination,
just
because
the
mental
model
for
a
user
is
gonna
be
really
confusing
really
quickly,
especially
if
they
leave
the
experience
and
come
back
it'll
be
really
difficult
for
them
to
know
where
they're
at
that's.
Why
we've
been
avoiding
it.
E
C
So
I
don't
know
if
the
same
can
be
applied
to
containers
or
containers
deployed
via
CI
CD.
So
I
don't
know,
maybe
it's
worth
having
a
word
with
Gigi,
because
the
actual
displaying
of
that
information
is
really
easy.
It's
the
linking
that's
the
hard
bit
so
if
he
can
do
the
same
kind
of
thing
with
packages
working
back
from
that
token,
then
yeah.
It
should
be
relatively
easy
to
add
on
the
front
end
I
think.
E
The
same
is
true
now
for
the
packages
like
goodbye,
npm
publish
it
won't.
We
won't
show
that
data
in
the
details
screen,
but
if
I,
if
I
publish
from
using
CI
or
at
least
using
the
job
token,
it
will
show
up
I
think
is
the
idea
I
wonder
if
that,
if
the
same
is
true
for
an
image,
because
the
probably
the
majority
of
images
are
built
using
CI
and
I
suspect,
that's
true,
although
we
don't
have
that
exact
data,
but
I,
think
many
more
images
are
built
using
CI.
E
So
if
we
could
show
that
that
would
be,
that
would
be
really
valuable
because
we
know
from
the
research
that
Ian
did
that.
A
big
reason
people
go
to
the
UI
at
all
is
to
either
verify
that
they're
using
the
right
image
or
to
troubleshoot
something
it's
so
being
able
to
tie
it
to
a
specific
pipeline
or
job
ID
would
be
really
valuable.
C
If,
if
that
is
the
case,
and
we
can
work
back
from
a
job
token
to
verify
what
pipeline
has
produced
an
image,
then
potentially
we
could
also
display,
like
the
last
pushed
container
containers.
Couldn't
we,
which
is
something
that
users
have
asked
for
in
the
past,
is
that
they'll
push
something
to
the
Container
HD
and
it
won't
show
on
the
first
page,
because,
due
to
whatever
the
order
and
mechanism
is
it's
way
way
way
down
on
page
50
and
whatever
it
might
be.
C
But
if
we're
the
ones
tracking
the
pipeline's-
and
we
know
when
the
pipeline's
are
finishing
or
when
they
succeed,
then
we
could
have
a
section
at
the
top
that
would
display
latest
latest
pipeline
builds
or
something
like
that
and
that
might
not.
You
might
have
to
do
a
further
API
request
to
go
and
get
the
details
for
that
particular
image
or
container,
but
we
could
use
out.
C
We
could
leverage
our
database
there
to
then
display
those
latest
latest
potential
images
and
help
help
our
users
a
little
bit
of
see
that
the
scenario
exists
where
they
could
just
push
via
docker
or
whatever,
and
it
we
would
have.
No
information
whatsoever
and
therefore
we
can't
display
it
for
those,
but
anything
done
see
ICD.
Potentially,
we
might
be
able
to
do
something
there.
I.
A
Think
we
should
definitely
investigate
that
idea,
every
user
that
I've
talked
to
as
soon
as
your
team
kind
of
passes,
the
ten
to
twelve
people
mark
consistently.
Like
all
of
our
images,
all
of
our
containers
are
all
built
by
CI.
We
don't
even
touch
docker
anymore,
it's
just
like
Auto
happens,
and
those
are
the
people
that
are
also
producing
enough
images
to
struggle
to
find
the
latest
one.
So
there's
definitely
the
possibility
that
we
can.
A
A
large
group
of
our
users
will
be
aided
using
that
kind
of
pipeline
roundabout,
especially
considering
how
many
of
them
use
it
I'm
just
wondering
Tim.
Do
we
have
a
way
to
find
out
or
the
way
to
look
at
the
data
itself
to
be
like
this
image
came
from
CI,
and
this
one
did
not,
so
we
can
actually
get
a
number
to
make
decisions
like
that.
E
He
was
mentioning
but
I
think
no,
but
just
based
on
the
like
the
user
interviews
that
I've
done
I
think
it's
like
an
exponential
difference,
because
if,
if
you
are
building
something
from
the
command
line
or
using
the
doctor
client,
it's
maybe
like
you're
doing
one
image,
but
if
you're
building
something
from
CI
you're
building
on
every
merge
on
every
deploy,
you're
building,
many
images
so
I
think
it's
logically
it
shouldn't
even
be
close.
I,
don't
think.
E
Sounds
like
the
big
question
we
have
is:
can
we
know
that
an
image
was
built
with
CI
job
token
or
a
deployed
maybe
or
or
a
deploy
token,
and
if
so,
can
we
display
that
information
in
the
front
end
and
then,
if
that's
true,
then
the
next
item
on
the
decision
tree
would
be.
Can
we
have
some
kind
of
like
recent
activity,
feed
added
to
the
user
interface?
E
F
E
B
D
B
D
That
is
this,
the
UI
functionality
of
that
animation.
But
you
said
you
can
disable
that
behind
a
feature
flag,
but
otherwise
that's
not.
There's
not
subtracting
too
much
from
the
value
that
you've
added
here
with
this
group
of
concept,
so
I
would
say
this
is
kind
of
like
a
mass
situation.
You've
already
got
basically
the
work
here
and
you
want
to
get
an
issue
for
a
back-end
engineer
to
be
able
to
go.
D
Do
that
work
that
you
identified
earlier
so
you'd
want
to
build
that
issue,
so
I
would
say
Emma
and
an
issue
tagged
with
packaged
triage
to
get
someone
to
do
it
when
you
actually
create
that.
Are
you
going
to
want
to
request
Tim
and
Ian?
Look
at
it
with
a
little
more
detail
that
sounds
like
both
of
Timoney
and
they're,
pretty
happy
with
it
so
like
we
all
are
because
I
think
it's
pretty
great,
but
you
you
really
want
to
look
at
it.
D
There's
like
how
can
we
get
there
this
this
conversation
we're
having
around
tracking
whether
something
was
created
with
this
di
I'm
through
CI
or
not
instead
of
separate
functionality,
so
I
would
just
a
bad
that
is
a
value-add
after
the
back,
but
I
would
want
to
get
this
in
an
M
our
state
ready
to
merge
as
soon
as
possible,
with
this
minimal
effort
as
possible,
because
you've
already
done
all
of
the
work
but
I
look
of
it
so
yeah
and
just
well
I'm
blabbing
on
about
it.
This
is
really
cool.
D
D
D
This
is
an
area
where
hey,
let's
create
an
issue,
have
a
discussion
around
a
technical
feasibility
of
this
involving
you
know
in
the
case
of
the
town
registry
work
you
know,
Rowland
and
Haley
would
be
necessary,
but
you
know
include
everyone
anyway
and
try
to
work
through
how
to
actually
achieve
that,
because
this
seems
like
pretty
valuable
and
it
may
not
be
a
people
work
it
could
be,
but
we
have
to
investigate
so
I
would
say
out
of
this.
We
want
to
go
mi
issue
for
the
backend
work.
D
B
D
Always
go
to
the
director
MRF,
you
can
I
mean
I,
don't
you
want
to
bypass
that?
But
we
do
want
to
describe
what
we're
trying
to
do.
I
think
it's
worthwhile
doing
that,
and
then
we
sort
of
want
to
do
a
research
issue
around
adding
this
functionality
for
container
registry
or
anything
that
is
required
and
I
think
the
other
thing
we
talked
about
was
searching
and
all
that
sort
of
stuff
and
Azrael
mentioned.
D
We
could
end
up
not
being
able
to
do
that
effectively
until
we
have
to
look
to
the
backend
for
a
manifest
storage
so
that
we
can
actually
practically
go
search
and
do
that
sort
of
thing.
So
that
might
be
a
not
quite
yet
sort
of
scenario,
but
it's
worth
sort
of
generating
that
issue
slash
whatever
you
want
to
do
to
sort
of
record
that.
D
E
E
One
quick
thing
that
is
not
on
the
agenda:
if
I
could
breach
protocol
for
five
minutes,
I
will
just
share
my
screen,
quick
because
I'm
we're.
Basically,
we
have
the
group
presentation
for
C
ICD
next
Tuesday
I
think
it's
next
week.
I
can't
remember
exactly
which
day
and
I
put
together
a
topic
slide
that
I
just
wanted
to
share
one
question:
I
hear
very
often
from
prospects
and
from
sales
is:
when
can
they
replace
my
existing
universal
package?
Manager'
vendor
not
to
name
names
with
get
labs
package
offering
and
so
I?
E
This
is
not
a
comprehensive
list,
but
I
did
try
to
come
up
with
sort
of
the
top
seven
items
that
we
can
add,
and
so
I
just
wanted
to
review
this
list
and
get
feedback
from
people
and
see
is
anything
seem
odd.
Here.
Is
anything
missing
or
is
anything
concerning
so
I
think
based
on
feedback
from
CID?
One
of
the
things
that
we
heard
is
one
of
the
most
high
leverage
things
we
could
do
is
use
our
community
to
drive
additional
contributions
for
package
managers
and
enabling
them
to
do
that.
E
So
we've
taken
steps
to
move
in
that
direction.
We
created
documentation,
scheduling,
office
hours,
I'm,
trying
to
reach
out
on
some
of
the
not
on
issues
like
cargo,
which
are
not
as
I
don't
hear
as
often
from
our
enterprise
customers,
but
are
popular
in
the
community,
so
I'm
trying
to
see
if
we
could
drive
more
contributions
and,
of
course
we
have
our
pH,
the
pH
key
contribution,
that's
moving
and
one
for
terraform.
E
So
this
is
something
that's
high
leverage
that
we
can
do
in
terms
of
the
private
registry
support
for
the
most
commonly
used
package
manager
formats.
This
is
the
list
that
I
hear
from
almost
every
enterprise
customer.
Whenever
they
ask
me,
when
are
you
going
to
support
X
it's
in
this?
It's
in
this
list
and
obviously
we
have
net
and
PHP
and
progress.
E
Python
is
scheduled
for
coming
up
next
and
then
the
three
that
we'd
like
to
get
to,
hopefully
in
may
be
in
2020,
is
Ruby
and
then
rpm
and
Debian
or
DB
another
value
how
you
pronounce
it,
and
the
next
item
on
here
is
providing
local,
remote
and
virtual
repositories.
So
this
is
basically
the
ability
to
pull
right.
Now
we
only
allow
users
to
pull
from
their
get
lab
private
registry
registry.
E
E
This
next
item
is
simplifying
the
naming
conventions.
We've
talked
a
lot
we're
actually
we've
talked
about
this
in
our
early
think
big
sessions.
I
think
this
will
be
and
I
call
out
self
management
senses
here,
because
it's
not
probably
like
we
talked
about
it's
not
so
simple,
forget
lab
comm,
just
due
to
naming
collisions
but
for
self
manage
instances.
This
is
something
that
we
could
do
and
I
think
would
be
really
valuable.
E
A
seamless
experience,
the
CIA,
CD
I
think
this
needs
more
definition.
And
actually
you
know
if
you
haven't
seen,
there's
a
new
role.
That's
opening
up
whether
there's
going
to
be
a
team
that
works
on
templates
and
cross
CITV
workflows.
That's
one
option,
but
I'm
also
thinking
things
here
about
things
here,
like
the
ability
to
delete
images
easily
via
CI
CD.
There's
some
issues
I've
seen
where
people
are
saying
why
do
I
have
to
in
every
time
log
into
docker
from
CI
CD?
E
If
I've
already
logged
in
to
get
lab-
or
you
know-
maybe
there's
other
things
that
we
could
do
to
streamline
people's
workflows.
One
one
option
is
expiring
images.
The
way
that
we
do
artifacts
things
like
that,
just
making
it
as
easy
as
possible
for
people
that
are
using
get
lab
pipelines,
the
proxying
and
caching
of
packages
for
faster,
more
reliable
builds.
E
That
could
probably
add
more
secure
here
as
well
and
then
having
policy-driven
management
features
like
we're
working
on
the
expiration
and
retention
policies
and
then
also
things
like
quotas
and
limits
is
something
I
hear
consistently
forget
lab
and
for
our
large
customers.
They
want
the
ability
to
set
limits
to
things
like
what
size
packages
or
images
can
be
uploaded,
total
size
limits
for
given
given
projects
and
groups
and
then
ways
of
enforcing
that
so,
like
I,
said,
there's
more
things
here.
E
That
need
to
be
done,
and
this
is
the
Devils
in
the
details
as
they
say,
but
if
I
had
to
say,
like
seven
steps
for
us
to
replace
other
vendors.
These
are
the
things
that
I'm
thinking
of
so
I
just
wanted
to
before
I
present
that
or
put
this
in
the
presentation
for
next
week.
I
just
wanted
to
share
it
with
everybody.
Here.
B
E
Yeah
I
think
that
that
might
be
a
requirement.
That's
definitely
a
bigger
project,
so
they
started
when
I
first
started
Marren
scheme
and
the
delivery
team
were
working
on
the
dashboard,
which
shows
how
much
size
you're
using
for
packages.
They
tried
to
do
it
for
the
container
registry
and
it
was
an
impossible
problem
to
solve
just
because
of
the
size
and
the
way
that
we're
storing
data.
E
But
I
think
my
stated
goal
in
their
direction.
Page
is
that
in
within
three
years,
so
I
guess
by
2023
that
we
are
so
that
we
can
have
90%
of
our
customer
base
off
of
those
other
package
manager.
Vendors,
so
I
think
it's
it
it'll
horizon,
but
it
is
something
that
I
do
want
to
aim
for
so
that
list
as.
E
And
assuming
that
you
inserted
all
the
sub
parts
that
are
included
all
the
sub
bullets,
but
yeah
I
think
that's
I,
think
that
would
get
us
there,
with
the
exception
of
we
probably
want
a
migration
strategy,
would
be
another
key
step.
That's
not
in
there
so
giving
people
an
easy
way
to
migrate
from
their
existing
vendor
to
get
love
and
I.
Think
having
something
like
that
will
just
make
developers
lives
a
lot
easier
and
make
people
a
lot
happier
and
and
make
that
that
would
be
another
step.
E
E
But
yeah
I
see
that
this,
this
being
really
like,
are
what
we're
working
on
over
the
next
several
years
and
and
and
I
think
that
will
get
us
to
the
goal.
Assuming
that
there
might
be
new
requirements
that
come
in,
there
might
be
new
things
that
come
up,
but
looking
at
it
now
that's
sort
of
like
the
what
I'm
hearing
from
users
what
we
need
to
cover
and
what
the
market
and
the
competition
is
doing.
At
least
nine.
D
So
my
suggestion,
based
on
saying
a
lot
of
seed
feedback,
is
to
not
have
this
stuff
in
a
Google
Doc
when
it
should
be
somewhere
else
and
then
just
well
I
thought
Sid
saved
multiple
times.
You
could
screengrab,
what's
in
our
handbook
or
what's
in
somewhere
else
and
put
it
in
a
spreadsheet,
and
but
just
like
this
planning
stuff,
we
should
be
somewhere
available
to
people
that
don't
necessarily
know
the
document
exists.
Yeah.
E
D
Start
with
the
direction
page,
but
I
would
love
to
have
like
an
epoch,
I'd
like
to
have
an
epoch
of
epochs,
or
something
like
that,
because
this
is
a
pretty
long
term
goal
because
then
you
know
you
start
talking
about
limits
and
that's
an
initiative
that
the
engineering
department
has
ongoing,
that
we
haven't
done
enough
work
on
yet,
and
so,
when
you
start
mentioning
limits
and
those
sorts
of
things,
Steve's
done
a
little
bit
of
an
investigation
in
that.
But
that's
work,
I
know
I
need
to
promote
into
our
work
flow
pretty
soon.