►
From YouTube: Package Roadmap Review
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
One
of
the
challenges
that
I've
had
typically
when
walking
through
customers
in
a
pitch
deck
is
how
do
you
represent
not
just
the
categories
that
we're
working
on,
but
the
different
themes
that
we're
approaching
as
a
stage,
and
so
what
we
created
here
is
something
similar
to
a
metro
map
and
look
just
looking
quickly
through
the
legend
here
we
could
see
where
we
clearly
state
the
vision
that
the
goal
of
the
package
group
is
within
three
years
to
be
the
single
source
of
truth
for
storing
and
distributing
of
packages
and
images
for
all
gitlab
customers.
A
We
also
have
a
metric
key
here,
so
each
subway
line
or
or
a
theme
focuses
on
a
specific
metric.
Now
each
feature
that's
listed
may
have
a
sub
metric,
but
generally
speaking,
when
we
talk
about
making
the
product
more
useful,
we're
thinking
about
gmail
or
monthly
active
users
when
we're
thinking
about
efficiency,
generally
we're
thinking
about
improving
our
margins.
A
So
I'd
like
to
start
with
that
summary,
starting
on
the
usefulness
track
generally.
How
I
would
like
to
walk
through
this
is
to
say
the
first
stop
is
performance
and
reliability.
One
thing
we've
heard
over
and
over
from
our
customers
is
that
the
platform
that
the
product
being
stable
and
reliable
is
the
most
important
thing.
People
are
using
gitlab
package
as
part
of
their
production
workflows.
So
when
something
breaks,
it's
a
break
in
their
production
pipelines
and
it
could
be
cause
major
problems
throughout
their
development
life
cycle
on
this
metric.
A
The
next
stop
there
is
adding
support
for
net
new
formats.
So
right
now
we
have
about
10
plus
formats
that
are
supported
in
the
with
the
package
registry,
but
adding
new
formats
allows
us
to
drive
top
of
funnel
usage.
A
So,
let's
say
we
add
support
for
rpm,
which
is
frequently
requested
by
customers
that
allows
us
to
introduce
a
whole
segment
of
users
that
are
not
currently
using
the
package
product
to
start
using
it
and
then
through
contributions
and
improvements
will
drive
them
further
and
further
down
the
funnel
speaking
of
driving
users
further
down
the
funnel.
We
have
some
formats
that
are
in
alpha
or
beta
mode
beta
support.
So
basically,
these
are
formats
that
you
can
use,
but
they're
not
considered
generally
available.
A
Another
aspect
that
we
see
on
the
line
is
having
more
metadata
available
for
dependencies,
so
typically
people
are
using
the
user
interface
or
their.
When
they're
looking
at
a
package,
they
use
package
metadata
to
validate
that
the
package
was
built
properly
and
if
it
wasn't,
they
will
use
that
same
exact
metadata
to
troubleshoot.
What
went
wrong
so
having
all
that
available,
discoverable
and
searchable,
is
something
that's
really
important
for
our
user
base.
A
I
mentioned
discoverability
so,
as
we
start
to
think
about
just
in
general,
the
usability
and
discoverability
of
the
product
is
something
that's
really
important
for
our
users.
It's
complicated,
they're
publishing
a
lot
of
images
and
packages
every
day,
so
making
sure
that
it's
easy
to
find
what
they're
looking
for
when
they're
looking
for.
It
is
a
way
that
we
can
improve,
developer
experience
and
going
back
to
our
three-year
vision.
A
A
It's
a
little
bit
more
challenge
when
we
get
challenging
when
we
get
to
large
complex
organizations
with
thousands,
five,
ten
thousand
plus
developers-
and
one
key
missing
feature-
is
this
idea
of
a
virtual
registry
which
allows
you
to
say
proxy
and
cash,
all
of
proxying
cash
from
many
external
remote
repositories.
A
So,
for
instance,
if
we're
talking
about
maven,
you
could
set
up
a
one
virtual
registry
that
will
have
be
behind
one
url
that
will
pull
dependencies
from
maven
central
from
artifactory
from
sonotype
and
from
any
other
arbitrary
number
of
sources.
This
allows
admin
to
not
have
to
maintain
multiple
config
files
on
each
developer's
machine.
This
feature
is
brought
up
every
week
by
several
customers
as
a
key
missing
feature.
It's
something
that
we
are
striving
to
work
towards.
A
Next,
I'd
like
to
touch
on
efficiency,
this
is
something
that
we're
really
focusing
on
now,
so
making
sure
that
we're
driving
down
the
overall
cost
per
user
and
really
there's
two
ways
that
we
could
do
that.
One
is
by
doing
things
like
adding
limits
which
encourages
user
behavior
by
limiting
the
amount
of
storage
that
they
could
use,
or
the
amount
of
data
transfer
capacity
that
they
have.
The
other
is
by
launching
features
that
will
help
them
help
encourage
them
to
run
to
remove
storage
or
to
reduce
their
data
transfer.
A
A
They
want
to
know
not
only
how
much
storage
are
they
using,
but
how?
How,
by
how
and
by
whom
are
given
packages
being
used
by
so
being
able
to
have
that
data
and
then
also
clean
up
old
packages
based
on
that
data
would
not
be
very
useful
and
then
we
start
to
get
into
storage
and
data
transfer
limits,
which
are
things
that
will
help
get
lab
to
control
margins
from
the
top
down.
A
Finally,
just
touching
on
the
the
security
line
here,
so
the
first
thing
that's
worth
mentioning
is
our
goal
for
the
package
group
and
beyond
that,
as
git
lab
as
a
whole
is
to
have
zero
beyond
slo
security
issues,
that's
critical
to
our
long-term
success
and
it's
something
that
we
track
and
discuss
regularly.
A
We
need
to
make
sure
that
it's
easy
for
administrators
to
manage,
who
has
permission
to
which
projects
and
to
which,
which
dependencies
something
else
that
we're
working
on,
and
I
think
the
same
thing
could
be
true
said
to
be
true
about
other
stages,
but
it's
worth
calling
out
here,
because
this
will
be
a
way
for
us
to
have
tears
in
the
ultimate
level
a
tighter
connection
with
gitlab,
secure
and
defend.
A
We
have
a
lot
of
crossover
between
our
two
stages,
so
making
sure
that
the
products
really
do
work
well
together
and
seamlessly
together
is
something
that
will
be
really
important
as
we
move
forward
beyond
that,
we
have
the
dependency
firewall,
which
will
allow
you
to
filter
upstream
dependencies
before
they're
ever
downloaded.
So
if,
for
instance,
you
could
say
never
download
a
dependency
in
which
the
author
or
email
name
has
changed
within
the
past
30
days
or
from
a
compliance
perspective,
you
could
say
never
download
a
dependency
that
has
this
license
or
this
this
creator.
A
In
addition,
there
are
other
features
that
we're
hoping
to
add
here,
such
as
image
and
binary
signing
with
cosign,
so
you'd
be
able
to
verify
you'd
be
able
to
when
the
image
or
package
is
built.
You
can
sign
it
using
cosign
so
that
you
can
verify
to
your
customers
downstream
of
you
that
this
is
the
exact
image
or
package
that
was
built.
Here's
who,
by
it
was
built
by-
and
you
could
have,
that
extra
attestation
of
dependencies.
A
So
this
is
still
we're
still
working
on
it.
This
is
going
to
be
a
living
document,
we're
maintaining
it
right
now
in
figma.
Probably
these
deserve
monthly
or
bi-monthly
updates.
The
idea
was
to
not
put
timelines
on
here,
but
to
just
just
show
thematically
what
we're
working
on
and
why
so
we
can
kind
of
show
the
different
tracks
of
the
package
group
and
how
we
can
measure
success
of
each
of
these
different
tracks.