►
From YouTube: Package Think Big
Description
We discuss focusing the team on the dependency proxy, pipelines for packages, and metadata.
A
A
It
also
came
up
a
bunch
during
the
issue
about
how
to
grow
the
team
about.
Where
does
the
dependency
proxy
live?
Does?
Does
it
make
sense
to
split
the
product
into
a
container
image
proxy
and
package
pro
proxy,
so
it
make?
Maybe
it
makes
sense
to
to
de-risk
some
of
that
work
in
general
and
focus
on
that
for
a
given
milestone
or
beyond.
So
I
thought
it
would
be
helpful
to
so.
A
A
Okay,
so
for
the
container
for
the
well.
I
I
didn't
think
that
there's
any
way
we're
gonna
get
around
the
registry
development
and
deployment
work.
I
know
haley
and
juan
that's
going
to
be
taking
up
our
time
through
the
end
of
next
year,
but
I
thought
we
might
be
able
to
make
time
for
the
moving
the
dependency
proxy
to
workhorse
or
which
requires
some
more
coursework
and
also
some
rails
work.
A
We
also
during
our
most
recent,
actually
steve
uncovered
that
the
dependency
proxy
is
throwing
some
controller
errors
which
is
contributing
to
our
error
budget.
So
this
might
be
another
good
one
to
tackle,
because
it's
currently
like
nine,
almost
90
percent
of
our
error
budget
is
the
dependency
proxy,
also
be
very
helpful
if
we
had
user
level
data-
and
we
were
counting
this
towards
our
monthly
active
users,
the
the
dependency
proxy's
pulling
over
a
million
images
per
week
and
we're
not
getting
any
credit
for
that
for
our
user
data
for
at
gitlab.
A
A
As
with
the
container
registry,
where
we
have
petabytes
of
data
and
then
something
you
know
that
we've
kind
of
punted
on
for
a
while,
but
I
think
it
would
be
great
to
start
considering
the
user
interface
for
this.
So
creating
a
graphql
for
query
for
the
dependency
proxy.
That
could
return
a
list
of
images
and
manifest
information
would
be
really
helpful
and
we
could
start
to
present
that
information
to
users
in
in
the
user
interface.
A
But
I
suppose
we
could
do
the
same
thing
with
images
pulled
from
docker
hub
and
we
could
add
a
simple
rule
that
says:
don't
don't
ever
pull
images
that
have
a
red
hat
in
the
name
for
instance,
or
that
where
the
author
name
has
changed
in
a
given
time.
So
this
issue
was
actually
opened
by
a
customer
recently
and
it
suggests
that
we
basically
just
have
a
list
of
allow
and
deny
patterns,
and
I
thought
that
this
would
also
be
a
good
idea.
A
A
C
Yeah.
My
question
was
seeing
the
milestone
review
issue.
They
were
all
about
the
dependency
proxy
for
container
images.
Should
we
extend
the
scope
of
this
to
the
dependency
process
for
packages,
and
I
think
we
already
have
some
ideas
like
changing
the
current
implementation
into
a
real
proxy
so
that
we
can
easily
add
caching.
A
A
D
I
would
want
to
maybe
consider,
though,
with
the
migration
to
workhorse
I'd
be
curious,
like
like,
in
my
view,
I
feel
like.
Maybe
that
should
happen
before
we
start
to
add
more
and
more
because
it's
sound,
or
at
least
I
like
thinking
about
it.
It
seems
like
the
kind
of
thing
where,
if
we
add
more
now
like
with
different
packages
and
start
refactoring,
whenever
we
do
change
the
workhorse,
that
might
end
up
being
more
work
on
top
of
what
we
already
have.
D
A
D
D
A
E
E
C
C
D
Yeah,
I
think
it
depends
on
you
know
like
how
big
of
a
factor
time
is
on
this.
We
can,
probably
you
know,
become
more
familiar
and
and
take
the
time
to
figure
out
how
to
implement
that,
but
it
might
take
longer
than
if
we
got
one
of
the
workhorse
maintainers
to
jump
on
it
for
us.
So
it
kind
of
depends
on
that
time
factor
or
if
we
wanna.
If
we
want
to
gain
the
experience
of
becoming
more
familiar
with
workhorse
and
doing
it
ourselves.
E
C
C
Yeah,
it's
basically,
we
need
to
apply
a
what
will
cause
those
for
uploads.
We
need
to
apply
that
in
a
get
request,
and
on
top
of
that
we
need
to
have
a
custom
logic
that
will
tell
workers
hey.
You
need
to
download
data
from
this
source
and
upload
it
there,
and
this
is,
I
don't
think
it
exists
in
workforce.
B
B
B
A
F
A
A
E
I
would
just
like
to
see
some
cash
eviction
and
inspiration
policies
done
before
adding
any
more
features,
because
with
any
any
additional
features,
comes
additional
data
and
we
might
soon
found
ourselves
in
the
same
situation
that
we
are
right
now
with
the
container
registry
and
we're
still
a
long
time
to
avoid
that.
So
the
sooner
we
do
that
the
best.
A
Yeah,
so
we
can
still
I'll
just
pull
up
the
screen
again,
so
we
we
could
still
prioritize.
We
can't
do
the
well.
Maybe
we
could
do
the
workhorse
portion
I'll
follow
up
on
that
the
rails
portion
will
need
to
move
back
a
milestone
even
from
wherever
this
work
is
done,
but
we
can
investigate
the
controller
errors.
We
can
add
the
user
level
data.
We
can
prioritize
removing
artifacts
that
are
older
than
90
days
and
we
can
also
potentially
add
a
graphql
query,
or
would
that
be?
A
E
G
G
A
B
Okay,
yeah
one
of
the
one
of
the
things
there
that
I
chatted
with
sam
about
it
and
sam
was
mentioning
that
he's
worked
in
other
places
where,
like
that,
swarming
thing
is,
can
be
really
good
for
the
whole
team
to
be
working
together
on
one
thing
and
that's
kind
of
what
was
in
my
head
as
well
of
like,
let's
all
focus
on
the
same
thing
together
if
possible.
I
I
not
you
know,
I'm
not
dismissing
your
points
you
are
on
on.
B
You
know
the
work
you
have
going
on
that
you
and
haley
have
going
on
with
the
container
registry,
which
is
super
high
priority
as
well,
but
being
able
to
all
work
together
is
kind
of
a
cool
thing.
So
if
we
can
make
that
happen
in
a
way
that
makes
sense,
that's
kind
of
my
main
motivation
just
to
break
up
the
way
we're
working
and
get
everyone
together
on
the
same
goal
is
kind
of
the
intent
there.
B
E
D
A
A
Originally,
we
were
thinking
that
problem
validation
would
make
sense
where
we
would
go
and
talk
to
customers
and
say.
Is
this
a
problem
we've
kind
of
heard
from
customers
that
this
is
needed
and
seeing
the
competitive
research?
It's
maybe
a
little
more
clear,
so
I
was
wondering
maybe
it
makes
I
was
thinking
that
it
makes
sense
to
move
more
to
like
solution
validation,
to
be
able
to
show
customers
a
specific
idea
and
say
like
this
is
what
we
have.
A
H
A
I've
been
doing
my
customer
conversations,
just
kind
of
gently
probing
about
it
and
it
seems
like
people
are
instantly
just
kind
of
yes
and
I
had
a
twitter
poll
and
my
huge
twitter
audience
of
you
know
100
users,
we
we
had
100
were
saying
that
this
this
functionality
would
be
useful.
So
I
think
we're
zooming
in
on
something
and
really
having
an
mvc
proposal
would
be
really
valuable
for
taking
the
next
step.
C
Yeah,
I'm
thinking
into
something
super
basic
where,
when
you
push
a
package,
you
have
a
pipeline
and
the
jobs
on
this
pipeline
will
simply
pull
the
package
archive
and
then
it's
the
job
configuration
you
do
whatever
you
want
with
that
file,
although
we
might
want
to
start
with
specific
package
types
first,
because
not
all
the
package
types
are
archives
or
files.
For
example,
composer
is
a
git
tag,
it's
not
an
archive.
A
I
would
vote
for
starting
with
npm
or
maven,
whichever
one
is
easier
from
a
technical
perspective
from
a
data
point
of
view
like
npm,
is
the
most
popular
in
terms
of
polls,
but
maven
does
see
the
most
pushes.
So
if
we
were
going
to
focus
on
one
event,
when
a
package
was
published,
we'd
probably
see
the
most
events
for
for
maven,
even
though
npm
is,
and.
B
I
mean,
I
think
the
other
thing
to
consider
consider
there
is.
We
have
some
pretty
large
customers
who
use
both
npm
and
maven,
who
we
could
consider
reaching
out
to
to
discuss
how
they
might
want
to
use
it,
whether
it's
valuable
for
them.
I
know
some
of
those
customers
not
mentioning
any
names,
because
online
I'm
like
so
most
customers
have
been
really
keen
to
work
with
us
and
some
future
sort
of
development
efforts,
so
might
be
a
might
be
a
cool
opportunity
to
partner
with
a
large
customer.
A
I
How
the
user
needs
to
define
it
or
configure
the
pipeline
to
be
triggered,
I
mean.
Is
it
the
same
user
that
defined
the
pipeline?
Is
the
one
that
you
need?
You
need
that
user
to
define
the
pipeline
if
it
will
be
triggered
because
of
a
packet
change
or
those
are
different
users,
because
there's
a
two
questions,
so
how
how
users
define
it
if
those
are
like
the
same
users
that
are
defining
pipelines.
C
A
I
could
answer
that.
I
think
that
most
it
depends
on
the
organization
at
a
small
midsize
customer.
It's
probably
the
same
person
setting
it
up.
It's
probably
a
developer
or
devops
engineer,
but
at
a
large
enterprise,
it's
much
more
likely
to
be
sort
of
the
center
of
excellence
team,
that's
maintaining
this
list
of
packages
and
and
the
package
registry
for
a
set
of
groups
underneath
them.
But
it's
still
going
to
be
a
devops
engineer.
It's
still
going
to
be
so
yeah.
It's
still
going
to
be
whoever's
used
to
writing
pipelines.
C
Yeah,
so
the
the
jobs
are
used
to
demonstrate
this
feature.
They
were
totally
different
from
the
usual
jobs
we
have
currently,
and
the
thing
is
that
even
for
the
runner,
I
had
to
make
some
modifications,
because
when
the
runner
picks
up
the
job
for
the
package
pipeline,
it
doesn't
have
to
pull
a
git
repository.
It
has
to
pull
a
package
file,
so
it's
really
different
and
the
it's
like
the
starting
conditions
for
the
job
is
different
in
the
pipeline
for
packages.
C
A
Functionality
that
people
would
want
like
they
want
to
know
when
a
package
is
updated,
they
want
to
scan.
They
want
to
scan
their
basically
their
entire
package
registry
or
or
container
entry
when,
when
there's
an
update
or
they
want
to
when
a
new
up
version
is
updated,
they
want
to
delete
any
old
versions,
for
example,
so
there's
a
lot
of
stuff
where
they
may
not
want
to
run
their
entire
development
pipeline
or
pull
a
repository.
They
may
just
want
to
run
something
against
their
package
registry,
for
instance,.
A
C
Yeah,
exactly
the
the
main
event
is
a
package
that
is
pushed
in
the
package
registry
in
the
gitlab
package
registry,
but
it's
not
necessary
that
we
have
the
source
code
for
that
or
the
or
the
build
info
for
that
package,
because
the
package
could
come
from
a
project
within
git
lab
or
it
could
come
from
an
external
tool
or
even
manually.
You
can
just
pull
up
a
terminal
or
console
and
just
build
your
package
and
push
it
to
the
gitlab
package
registry
and
that's
the
start
for
the
pipeline.
A
A
Once
we
have
that
mdc,
we'll,
try
and
that'll
be
something
that
we
can
validate
with
customers.
So
going
to
the
I
mentioned,
we
have
several
customers
that
have
expressed
interest
in
this,
so
going
to
them
and
kind
of
reviewing
the
proposal
and
and
seeing
if
it
makes
sense
and
and
fits
their
needs,
and
then
from
there
scheduling
an
issue
and
seeing
if
we
could
build
something.
B
A
So
one
thing
that
we've
seen
a
lot
of
issues
for
is
basically
you
know:
we've
had
one
model
data
model
for
the
package
registry
for
a
while.
Let's
just
share
my
screen
again
and
I've
collected
a
bunch
of
issues
in
in
one
epic
that
are
all
related
to.
We
can't
the
users
don't
have
the
data
that
they
want.
A
A
So
I
just
wanted
to
bring
this
up
and
say
that
this
will
probably
be
a
major
focus
for
us
in
the
coming
months
and
we
have
an
issue
scheduled
for
14.2,
for
example,
to
bring
in
more
npm
metadata,
we'll
need
to
do
the
same
thing
for
each
of
the
package
manager
formats.
So
a
lot
of
the
work
and
then
making
sure
that
that
shows
up
in
in
the
api
and
just
making
you
know,
there's
a
bunch
of
other
things
like
that,
not
really
the
best
discussion
item,
I
realized
as
I'm
talking
through
it.
G
C
C
Currently,
we
do
have
a
number
of
models
in
the
rails
back
end
and
those
models
gets
updated
and
we
throw
more
code
inside
of
them
for
each
package
type.
We
add
for
each
support
which,
for
each
additional
package,
type
support,
we
add-
and
this
is
slowly
becoming
like
what
I
call
giant
bags
of
everything-
and
this
is
not
great.
So
we
have
this
idea
of
splitting
this
and
organize
the
code
more
cleanly
and
yeah.
I
think
it's
really
two
different
things
between
splitting
the
models
and
having
a
proper
backup
for
the
package
features.
A
That's
something
I
hear
probably
two
to
three
times
a
month.
I
would
say
from
customers,
they
always
say
you
know
talking
to
large
enterprise
customers
and
they
ask
about
well
what
about
backing
up
the
registry.
We
can't
do
that
now,
so
not
not
every
day,
not
every
week,
but
it
does
come
up
often,
and
we
haven't
really
scheduled
anything
like
that.
C
C
A
Yeah,
I'm
gonna.
I
I
have
that
to
follow
up
on
probably
schedule
it
a
bit
further
out
but
yeah
something
to
to
follow
up
on
and
and
with
regards
to
the
metadata
just
for
that
comes
along
with
the
packages
we'll
try
and
schedule
that
bit
by
bit
as
we
move
forward,
starting
starting
with
npm,
and
then
we
also
have
issues
for
helm,
that's
scheduled
extracting
the
metadata
and
presenting
it
so
we'll
work
through
each
format.
At
a
time.