►
From YouTube: Package: February 2021 ThinkBIG
Description
In this video we discuss the Package roadmap and maturity targets, the upcoming registry metadata database and the package registry's data model
A
Okay,
so
the
first
thing
that
I
think
is
is
worth
mentioning
is
something
that
I've
been
working
on
over
the
past
few
weeks
is
updating
our
maturity
targets
for
the
stage,
so
maturity
targets
are
used,
something
I
learned
while
I
was
being
well.
I
was
the
ceo
of
shadow
is
that
the
majority
of
targets
get
pulled
up
regularly
during
investor
calls
during
customer
conversations
and
during
prospect
conversations
so
having
these
targets
displayed
and
accurate
is
something
that's
really
useful
for
the
sales
team
and
for
our
customer
success
team.
A
I
will
share
my
screen
because
I
think
it's
easier
and
if
dan
doesn't
like
it,
he
could
tell
me
so.
Basically,
I
created
this
epic
of
epics
that
houses
all
of
our
maturity
targets
for
each
of
our
product
categories,
and
I
tried
to
put
them
in
at
least
some
semblance
of
priority
order,
and
so
we
basically
right
now
the
main
three
epics
that
we're
working
on
is
the
package
registry
making
that
complete
the
dependency
proxy
and
the
container
industry.
A
And
then
generally,
we
see
helm,
chart
repository
on
there,
making
the
registry
level
making
the
package
registry
level
and
then
further
down.
We
see
making
release
evidence
viable
and
making
the
dependency
firewall
minimal,
which
doesn't
exist
today,
so
that's
kind
of
like
the
first
high-level
priority
and
then
we
could
dive
into
each
of
these
epics
one
nice
thing:
well,
it's
not
that
nice,
but
you
can
look
at
the
road
map
view
and
this
these
high-level
epics
just
match
our
dates.
A
That
are
that
our
maturity
targets
are
set
to
so
that
the
individual
issues
underneath
them
are
not
mapped
to
dates.
Yet
we
haven't
done
that,
but
at
least
you
could
see
like
okay.
Well,
we
intend
for
the
registry
to
be
complete
in
may
and
maybe
that
needs
to
be
adjusted
as
we
get
closer,
but
you
could
generally
see
where
we're
going
with
sort
of
the
making
the
features
lovable
going
out
pretty
far
into
2023.
A
I
have
basically
I'm
thinking
about
making
the
feature
complete
as
the
breadth
of
the
category,
so
we've
we've
in
the
past
year
and
a
half
now
being
together,
we've
added
in
a
lot
support
for
a
lot
of
different
formats.
You
can
see
we
moved
the
feature
to
core
we
added
in
support
for
python
nuget
composer.
A
We
updated
the
user
interface
and
nuget.
So
what
I
have
on
here
is
finishing
some
of
the
work
around
the
generic
package
repository,
which
is
really
just
adding
tagging
at
this
point.
So
that
feature
is
pretty
close,
we're
adding
rubygems.
I
think
this
will
be
really
valuable
both
for
for
our
users,
but
also
for
dog
fooding.
C
A
Being
more
specific,
I
think
that's
probably
your
job
token
and
your
deploy
token
and
then
you're
able
to
push
and
pull
packages
and
delete
them
not
actually
not
included
in
the
mvc
right
now
or
some
of
the
is
the
basic
user
interface
for
the
package
managers,
but
that
would
be
fast
follow.
So,
even
though
it's
not
mentioned
in
the
majority
targets,
you'll
see
that
we
did
have
the
overall
polish
for
the
package
registry
included
there.
So
that's
like
kind
of
included
the
redesign.
A
B
Because
I
like
that,
idea
that
mikko's
brought
up
it
would
be
useful,
maybe
in
like
either
an
issue
or
on
that
like
like
how
to
create
a
package
manager
doc
page
that
we
have
if
there
was
like
a
list
of
you
know,
these
are
the
five
things
to
make
it
complete.
These
are
the
five
things
to
make
it
lovable.
These
are
the
ten
things
to
make
it
whatever
the
different
sort
of
levels.
B
A
No
okay!
Well,
yes,
here
it
is
it's
in
the
make
the
package
registry
lovable.
So
it's
this
one
make
it
easier
to
find
and
delete
packages,
and
then
here
we
see
the
problem,
validation
and
then
the
issues
that
we
have
so
far
for,
like
things
like
remove
branch
related
packages
on
merge,
an
api
to
delete
files
from
a
package,
and
then
we
have
the
design
issue
which
will
turn
into
an
implementation
issue.
A
So
I
didn't
want
to
hold
off
on
moving
us
to
complete
for
the
cleanup
policies,
even
though
I
see
an
argument
for
that,
I
just
thought
it
would
be
better
to
kind
of
limit
the
scope
of
the
next
maturity
target
to
just
just
brett.
Can
you
can
you
use
this
feature?
Can
we
get
people
in
the
door
and
then
the
next
thing
making
it
lovable
would
be
kind
of?
A
We
could
just
skip
to
that,
setting
your
registry
to
private
or
public,
making
it
easy
so
search
and
cleanup
and
then
identifying
image
packages
as
protected
so
similar
to
protected
branches,
and
there
might
be
more
things
that
we
add
here
once
we
clear
this
hurdle,
but
for
now
that's
at
least
what
I'm.
What
we're
putting
there.
A
B
A
We
have
the
cleanup
policies
for
tags,
and
this
epic,
I
think,
is
what
needs
cleaning.
It
has
some
issues
in
here
that
probably
aren't
required
for
us
to
reach
the
next
maturity
target,
but
some
things
that
are
important
rolling.
You
know
the
making
sure
that
it
scales
making
sure
that
we
roll
it
out
for
gitlab.com
and
then
having
try
dry,
run
and
force
run
added
to
the
feature.
Those
could
all
be
included,
but
there
might
be
some
I
need
to
go
through
here.
A
A
And
then
this
bug
has
just
been:
it
drives
people
crazy
right
now,
there's
there's
a
workaround
for
this,
but
if,
basically,
if
you,
if
you
delete
your
project
or
group,
it
breaks
the
container
registry
and
then
you
have
to
run
some
manual
script
to
delete
them.
So
that's
something
that
we
would
like
to
include
in
this
maturity
target
and
then
something
that
I
know
nico
and
ian
and
I
are
passionate
about-
is
get
reworking
the
user
interface
for
the
container
registry.
A
A
A
That's
rolling
out
this
year
later
this
year
and
so
being
able
to
show
some
storage
to
statistics
will
be
important,
and
then
this
is
one
of
our
most
popular
issues,
I'm
not
sure
if
we'll
ever
be
able
to
do
this
or
or
if
we
will,
when
we
get
once,
we
have
the
manifest
database,
but
remove
branch-related
images
on
merge
so
similar
to
the
way
that
you
could
squash
previous
commits.
Basically,
any
image
or
package
for
that
matter
that
was
created
as
part
of
the
dev
branch
could
be
deleted
upon
merge.
E
A
I
think
that's
that's
part,
one,
probably
right
now,
no
there's!
No!
I
don't
there's
no
association
association
with
an
image
to
a
branch
or
even
a
project
for
that
matter.
Really,
although,
if
it
was
using
like
a
an
automatic
if
they
were
doing
it
they're
on
their
own,
but
we
don't
have
any
way
of
knowing
that
programmatically.
F
So
people
can
expect
that
to
happen
if
they
follow
a
given
naming
convention.
Otherwise,
I
think
this
needs
some
work
from
runner,
because
that's
the
only
way
to
find
out
which
images
were
built
from
a
given
pipeline
and
from
which
branch
a
pipeline
was
created
and
then,
if
that
branch
has
been
merged
or
not
so.
E
A
No
problem
so
yeah
these
are,
I'm
I'm
open
to
feedback
on
this
epic.
I
I
feel
like
we
for
a
while
we
were
dumping,
not
dumping,
but
putting
a
lot
of
things
in
here
and
I
feel
like.
Maybe
some
of
these
can
come
out,
but
I'm
open
to
feedback.
So
please
review
and
of
course,
let
me
know
if
you
have
any
questions.
A
I
was
really
tempted
steve
to
make
to
move
this
to
complete
after
the
recent
work
that
we've
done,
but
I
was
thinking
that,
if
we
are
comparing
ourselves
to
artifactory
or
nexus
that
we
should
really
look
at
make
this
feature
being
complete,
as
we
support
virtual
registries
for
each
of
the
package
manager
formats,
I'm
not
sure
that
we'll
need
to
cover
it
for
everything.
I
don't
know
that
we'll
ever
need
to
create
a
virtual
conan
repository
or
even
rpms
or
debian.
For
that
matter.
A
What
I
hear
most
from
customers
today
are
these
three
npm,
maven
and
nougat
most
frequently
and
then
for
git
lab
for
us
to
replace
our
current
vendor
that
we're
using
for
for
ruby
packages.
We
would
have
to
also
support
this
proxy
and
caching
feature,
so
the
these
four
are
kind
of
the
minimum
it'd
be
also
nice
to
extend
it
to
work
the
container
registry
instead
of
pulling
from
just
docker
hub
proxying
and
caching.
You
could
also
proxy
and
cache
images
from
ecr
or
something
like
that
or
google
google's
container
registry
python.
A
C
May
I
ask
a
question
on
the
dependency
proxy
work
overall,
I
realized
that
it's
been
going
on
a
little
bit
on
the
side
in
the
meaning
that
on
the
front
and
probably
ux
wise,
we
have
a
little
bit
more
blurry
view
of
the
status
of
what
is
ready.
What
is
going
to
be
ready?
Will
it,
since
this
is
one
of
our
important
goals?
Will
it
make
sense
to
think
about
it,
or
I
have
a
demo
session
or
something
like
that
just
to
to
get
the
point.
A
So
we
have
work
lined
up
for
future
iterations
ian,
I
know
put
together
some
designs
for
how
we
display
images
pulled
from
doctor
hub
right
now,
the
we
have
a
feature
that
forwards
requests
for
npm
packages
that
aren't
found
in
your
registry
to
the
npm
public
registry
in
the
future,
that'll
be
a
proxy
and
cash,
and
we
could
display
packages
in
metadata
that
are
pulled
from
the
public
npm
registry
there
as
well.
So
I
think,
having
that
discussion
now
is
well
timed,
so
yeah,
I
think
that's
a
good
idea.
A
Niko
there
are.
I
wasn't.
I
I'm
happy
to
go
through
the
make
the
registry
lovable
feature.
Maybe
that's
one
one
more
that
we
could
do,
because
that
has
some
cool
features
on
there.
I
think
so
a
couple
of
things
that-
and
this
again
now
we're
getting
much
further
out
so
open
to
feedback.
If
you
think
these
things
are
not
interesting
or
not
valuable
but
extend
you
know
right
now.
The
registry
only
works
with
the
project
level
endpoint,
although
you
could
go
to
the
group
level
ui
and
see
them.
A
A
Let's
see
setting
your
registry
to
public
or
private
is
independent
of
your
project.
Repository
is
a
very
frequently
requested
feature.
A
lot
of
companies
out
there
share
either
their
code,
it's
with
with
other
teams
within
their
organization,
or
they
would
like
to
share
their
registry
and
not
share
their
code,
so
they
just
want
to
be
able
to
control
the
visibility
of
the
registry
and
repositories
separately.
A
A
So
those
are
things
that
frequently
come
up
during
customer
calls
and
then
now
we're
getting
a
little
bit
lower
so
into
some
of
the
problem
validation.
So
we
had
a
call
with
a
an
important
customer
a
few
months
ago
and
we
were
talking
about
potentially
creating
a
multi-cloud
push-pull
mirror.
So
we
have
some
scheduled
validation
for,
if
we'll
do
that
in
the
future,
although
based
on
our
research
so
far
doesn't
look
like
we'll
do.
G
A
A
Basically,
I'm
for
me,
I'm
using
them
during
planning
to
make
sure
I
didn't
miss
anything
and
then
I'm
pulling
it
that
we're
moving
our
maturity,
targets
forward
each
milestone
and
then
also
just
they
get
reviewed
every
month
as
part
of
our
direction
update
so
like
each
month
on
the
last
week
of
the
month,
we
have
to
update
our
direction
page,
and
that
includes
updating
the
maturity
targets.
So
usually
they
get
looked
at
then.
E
A
Any
shift
on
dates,
I
I'm
sorry
any
shift
on
dates
has
to
be
approved
as
well.
So
if
I
wanted
to
just
move,
let's
say
the
dependency
proxy
back,
not
that
it's
a
problem
but
kenny
would
have
you
know,
look
at
it
and
say
well,
why
are
we
doing
that?
Does
that
make
sense?
And-
and
so
there
is
like
another
check
in
there.
E
A
Yeah
well
they're
they're
accurate
in
the
sense
that
I'm
not
incredibly
happy
with
this
feature.
So
really
what's
what's
here
now
is,
for
instance,
we
have
our
make
the
container
registry
complete
that
target
date
right
now
is
set.
You
can't
see
that
for
may
2021,
and
so
the
percent
complete
is
the
number
of
issues
that
are
in
this
epic.
A
How
many
of
them
are
complete,
so
it's
not
it's
pretty
dumb
number
in
that
sense,
so
it
doesn't
really
represent,
like
total
amount
of
work,
because
you
can't
do
things
like
it
doesn't
take
into
account
weights
or
and-
and
we
don't
have-
the
other
dates
set
yet,
but
I
think
one
goal
would
be.
It
would
be
nice
to
have
that
information
in
here
and
make
this
something
that
we
can
review
with
customers,
but
that
that
could
be
something
that
we
work
on.
Moving.
B
Yeah,
I
was
just
curious
when
it
comes
to
like
deciding
what's
prioritized
between,
like
you
know
like,
should
we
drive
through
and
try
to
get
the
completion
category
done
on
package
registry
versus?
Oh,
we
should
do
a
little
work
on
one
of
the
lovable
features,
just
because
you
know
it's
very
highly
upvoted
and
whatnot.
How
do
you
weigh
prioritization
or
what's
your
thought
process
when
I'm
trying
to
schedule
and
work
on
those-
and
I
guess
a
follow-up
would
be?
B
A
A
So
for
me,
a
lot
of
what
I
think
about
is:
are
we
supporting
our
existing
functionality
and
there
are
there
improvements
that
we
need
to
make
that
will
help
people
with
what's
out
there
today,
then,
after
that,
I
could
say:
okay
well,
what
new
features
can
we
bring
in?
That
will
add
new
functionality
and
that's
when
I'm
considering
some
combination
of
customer
feedback
and
the
maturity
targets.
So
if
it's
something
I
promise
to
a
customer
I'll
and
several
customers
that
and
it's
not
a
maturity
target,
we
may
still
prioritize
it.
A
So
I
kind
of
look
at
it
that
way.
It's
like
secure,
something
anything
that's
wrong
or
that
is
gonna
like
bite
us
in
the
future.
If
it's
not
supported
anything,
that's
promised
to
customers,
which
frequently
is
if
it's
promised
to
multiple
customers.
It
ends
up
in
a
maturity
target
and
then,
finally,
if
something
that's,
you
know
not
in
our
maturity
target
not
promised
by
customers,
but
we
think
it
would
be
helpful
because
of
some
other
sensing
mechanism
like
how
many
upvotes
it
has
or
if
it's
a
backstage
or
we
don't
have
backstage
issues.
B
H
A
Okay,
so
this
I
thought
we
could
just
go
through
two
rounds.
So
one
thing
that
came
up
came
up.
You
know
what,
as
I
think
everyone
knows,
we're
working
on
this
new
manifest
database
for
the
container
industry
and
that
will
unblock
a
lot
of
features
for
us
in
future
development
and
hayley
and
juan,
and
I
have
been
attending
the
cncf
meetings
and
we're
talking
about
how
the
api
can
be
reworked
in
the
future
to
provide
more
functionality.
A
And
so
I
thought
it
would
be
worth
just
taking.
Maybe
two
minutes
and
if
you're
interested
give,
maybe
just
one
feature
that
you're
most
excited
about
adding
when
we
have
the
new
manifest
database
and
then
the
first
thing
that
you'd
like
to
fix
in
the
second
round.
So
we
could
start,
maybe
with
steve
since
you're
on
my
top
left.
C
E
Yeah,
I'm
I'm
yeah,
I
think
I'm
the
only
dan
anyway
yeah
I
said
I
think,
for
me.
I'm
really
excited
about
reducing
the
overall
storage
cost,
which
is
pretty
significant
and
that's
really
cool
generally
improved
performance,
I'm
hoping
for
I
mean
hoping
for
I'm
just
it's
always
the
option
to
not
that's
really
cool
and
then
deeper
integration
as
well.
E
I
think
having
the
a
manifest
database
having
it
in
a
data
storage,
a
database
environment
gives
us
a
lot
more
ability
to
to
do
different
things
with
the
actual
data
and
sort
of
modernizing
a
lot
of
the
apis
and
interactions
will
be
fun
too.
I
mean
just
in
general.
The
last
thing
I'm
really
excited
about
is
the
teams
had
a
really
a
good
chance
to
update
a
lot
of
that
area
of
the
code
base
that
we're
working
with.
E
G
H
H
But
you
know
what
percent
of
the
actual
storage
is
being
used
by
this
one
group
are
how
what's
the
average
number
of
repositories
under
a
group,
or
things
like
that,
you
could
actually
do
a
sql
and
ask
some
questions
kind
of
get
a
feel
for
what
the
data
is
actually
there
and
what
it's
like.
Because
of
the
the
current
metadata.
It's
really
hard
to
to
get
those
kind
of
answers,
and
that
ties
into
storage
reporting
too.
F
Yeah,
the
first
thing
will
certainly
be
fixing
tech
pagination.
So
that's
not
a
feature.
It
was
supposed
to
work,
but
it
doesn't
so
yeah
that
should
be
helpful
for
the
front
end
and
even
the
backhands
and
then
make
the
tag
list
requests
take
less
than
a
second
to
complete,
because
we
are
now
seeing
a
few
taking
over
30
minutes
yeah.
F
D
A
Okay,
so
I
think
we
can
move
on
to
the
next
one.
I'm
I
think,
since
we
mentioned
that
we
do
have
this
issue
for
the
dependency
proxy
and
ian's.
Not
here,
I
think
it'll
be
helpful
if
he
was
here
for
this
discussion.
So
if
it's
okay,
steve
can
move
down
this
topic
for
next
iteration
and
then
we
could
talk
through
your
next.
B
G
C
Yeah,
so
if
we're
in
the
process
of
rethinking
of
the
the
model
structure,
I
think
maybe
we
should
save
to
rethink
the
the
root
models
or
so
not
having
one
table
for
all
the
package
manager
for
all
the
package
types,
but
several
tables
could
some
could
be
something
that
we
can
do
I
I
know
I
had
several
conversation
with
david
around
this,
so
the
topic
is
there.
Maybe
it's
a
good
time.
D
D
B
E
E
B
E
Yeah,
I
think,
in
that
that
blueprint
the
architecture
blueprint
process
is
that
it's
sort
of,
I
think,
intended
to
sort
of
look
at
these
types
of
issues
and
and
try
to
address
them
in
a
way
that
is,
gives
people
the
space
to
really
think
about
the
big
picture
of
it
and
come
up
with
stepwise
approach
to
achieving
that
goal.
And
so
I
feel
like
this
might
be
a
good
opportunity
for
you
to
work
and
look
at
that
process
and
cool
cool
team.
B
B
That
actually
reminds
me
of
we
have
this
dual
api
authentication
we're
working
through
right
now,
and
we
have
seen
some
community
contributions
come
through
that
are
trying
to
change
the
intent
of
the
new
authentication
already.
So
it's
hard
to
to
kind
of
juggle
things
as
it's
in
process
still,
but
that
would
definitely
have
to
come
into
play
during
that
sort
of
blue
print
planning.
A
A
Please
had
someone
reach
out
and
slack
today,
and
I
know
we
have
this
investigation
issue,
but
I
thought
it
would
be
worth
just
bringing
up
here
and
maybe
having
a
short
brainstorming
session
on
how
we
could
help
customers
with
this,
so
getting
their
packages
from
another
vendor
into
gitlab,
and
then
also
you
know
recognizing
that
it's
not
just
those
files
that
need
to
move.
They
need
to
update
their
pipelines,
they
need
to
update
their
run
books
and
there
might
be
other.
E
Just
to
verbalize
for
ian
who
isn't
present
it's
possible
if
an
organization
is
using
the
dependency
proxy,
we
can
capture
when
the
ci
build,
builds
attempt
to
pull
directly
from
artifactory
and
create
an
alert
toward
to
do
to
fix
it.
Question
mark
try
to
aid
users
in
identifying
all
those
many
many
locations.
Question
mark.
C
A
C
I
think
the
question
here-
and
I
don't
know
how
to
answer
this,
but
maybe
tim
ken
is-
is
this.
That
is
something
that
is
going
to
be
something
that's
gonna,
be
upfront,
and
then
the
user
won't
meet
this
anymore,
because
there
is
a
mass
migration
and
there's
a
bunch
of
user
migrating
or
is
something
that
they
are
going
to
need
consistently
across
the
years.
A
I
think,
for
probably
for
the
most
part,
it'd
be
something
that's
done
a
handful
of
times
not
consistently.
So
what
I've
seen
from
the
larger
customers
is.
They
probably
have
many
different
formats
that
they
support
and
they
would
probably
look
to
migrate
like
given
pods
off
of
artifactory
rather
than
wholesale.
A
Let's
one
shot
get
everybody
everything
off
artifactory
and
into
gitlab.
So
they
probably
say:
okay,
we're
going
to
do
all
of
our
node
packages
this
quarter
and
then
they
would
work
on
that.
The
next
quarter.
They
would
add
their
python
packages
for
smaller
customers
with
people
that
have
you
know,
let's
say
less
than
30
or
less
than
40
developers.
They
might
do
it
all
at
once.
A
A
We
don't
have
to.
I
know
we
have
an
investigation
and
research
issue.
Is
there
anything
that
I
can
help
answer
before
we
start
that
investigation?
Are
there
any
things
that
you're
like
well?
This
would
be
really
if
we
knew
these
things
that
would
make
the
investigation
go
much
smoother,
because
then
I
can
make
sure
I
bake
that
into
the
research
that
I'm
trying
to.
A
A
Yeah,
it's
pretty
nebulous
so
we'll
we'll
we'll
we'll
schedule
that
in
right
now
that
investigation
scheduled
for
1311
and
the
research
issue
it
might
be
mistimed.
I
might
try
to
start
talking
to
some
of
some
smaller
customers
sooner
about
their
needs
and
we
can
see
what
happens
in
the
investigation
issue
in
1311.
A
Well,
thank
you,
everyone
for,
for
your
time
and
patience
and
going
over
the
road
map
and
maturity
targets
and
everything
I
please
feel
free
to
comment
in
that
issue
or
any
of
the
issues.
If
you
have
any
questions
that
come
up
after
this
or
thoughts,
and
if
not
I'll
talk
to
you
all
soon,
I'm
going
to
stop
the
recording.