►
From YouTube: Think BIG 9-25-19
Description
In which we discuss creating visibility and transparency for the package and container registry and supporting additional package managers.
A
All
right,
so
this
is
the
second
version
of
this
meeting.
Thank
you,
everyone
for
filling
out
the
survey
got
some
good
results.
Everyone
responded
so
for
today.
The
idea
is
that
we're
gonna
go
through
the
second
epic.
Let's
create
visibility
and
transparency
for
our
stage,
and
then
we
have
a
few
more
epics
to
go
over
over
the
net
course
of
the
next
several
weeks,
and
then
the
idea
is
that
we'll
start
talking
about
things
that
are
once
we
all
level
set
we'll
start
talking
about
just
bigger
questions
that
we
bring
to
the
to
these
meetings.
A
A
Okay,
everyone
could
see
that
I,
think
and
so
I.
Actually,
all
of
our
epics
and
the
CIC
be
strategy
page
that
Jason
and
I
have
been
updating,
as
well
as
the
rest
of
the
CI
CD
team
was
recently
reviewed
by
the
executive
leadership
team,
so
save
mark
Eric
Johnson,
some
other
people
on
there
as
well.
We
got
some
positive
feedback.
They
really
liked
the
way
that
we
were
stating
our
goals.
We
had
some
constructive
feedback,
a
couple
of
things
they
mentioned.
Were
we
weren't
talking
at
all
about
how
users
can
contribute
like?
When
will
we?
A
Is
it
possible
that
users
will
add
new
package
manager,
clients
in
the
future?
And
if
so,
how
yeah
there?
Then
there
was
just
some
minor
like
rhetoric,
criticism
just
words
that
were
phrased
wrong.
I
was
using
the
word
artifacts
in
in
some
places.
I
shouldn't
be
using
that
artifacts
as
a
specific
term
at
gitlab,
and
there
was
one
other
small
change
that
that
I
had
to
adjust.
But
overall
the
feedback
was
pretty
positive,
so
it
feels
like
we
should
keep
keep
doing
the
things
that
we're
doing
and
I'm
on
this
epic.
A
The
problem
to
solve
here
is
really
that:
okay,
so
one
a
little
goal
that
they
really
liked.
Is
this
goal?
That's
what
made
me
think
of
that,
so
to
build
a
set
of
features
that
within
three
years
will
allow
ninety
percent
of
our
customers
to
store
all
of
their
packages
and
artifacts
and
get
lab
I
like
that
goal
and
yeah
I
said
and
Mark
liked
it
as
well.
So,
but
it's
not
just
a
store
of
that
information.
A
We
also
have
to
present
the
data
and
the
corresponding
metadata
to
provide
a
seamless
experience
for
building
testing
and
deploying
code,
and
for
our
current
integrations
we
do.
We
do
allow
people
to
build
and
test
the
ploy
Co,
but
we're
not
really
presenting
them
the
data
and
metadata
that
they
need
to
really
empower
their
experience.
So
each
registry
should
include
relevant
details,
links
and
evidence
related
to
how
our
users
are
using
software
and
how
they're
using
external
dependencies
so
really
for
this
epoch.
A
A
We've
been
working
on
this
with
a
lot
of
stuff
that
okay,
so
first
we
improve
the
navigation
for
the
over
overall.
Originally
the
container
registry,
the
dependency
proxy
and
packages
were
all
under
separate
navigation
items.
We
clean
that
up
pretty
early
on.
In
12:1
we
created
a
new
API
that
would
allow
you
to
list
the
images
and
tags
of
a
group
much
requested
feature.
We
just
changed
the
improve
the
navigation
for
our
documentation
before
everything
was
spread
out
like
similar
to
how
the
overall
navigation
was.
A
This
is
a
huge
improvement
for
me
and
then
I
mentioned
the
survey.
That's
going
on
right
now
to
identify
the
data,
so
we
think
everyone's
seen
that
survey
and
then
we
have
interviews
planned
starting
in
October,
so
we've
been
lining
up,
weaving
beans
been
putting
together
the
discussion
guide
and
we're
starting
to
line
up
candidates
for
people
that
will
actually
interview
and
get
feedback
based
on
their
responses,
and
then
more
group
level
views
so
API
endpoint
to
list
the
packages
of
a
group.
A
We
have
that
plan
for
12
for
as
a
stretch
goal
we
want
to
allow
users
to
sort
packages
the
packages
list
at
the
group
level.
That's
also
in
motion,
I,
think
Nick's
working
on
that
and
a
group
level
container
registry
browser
another
really
highly
requested
feature,
and
we
want
to
differentiate
between
package
types
in
the
group
level
package
registry.
So
right
now
we
do
have
packages
at
the
group
level,
but
there's
no
way
of
one
long
list
of
maven
and
NPM
and
soon
Conan.
A
A
Something
we're
working
through
now,
and
this
is
something
that
NPM
does
a
great
job
at
and
github
I
think
also
does
a
great
job
with
this
is
showing
contextual
documentation
for
how
to
pull
packages
using
the
command
line.
So
if
you
go
to
github
stool
or
MPN,
for
example,
you
could
see
they
provide
little
text
code
snippets
that
you
could
paste
into
your
CLI
and
actually
download
and
use
those
packages.
A
So
we'd
like
to
do
the
same
thing
for
each
of
our
integrations
and
then
there's
two
design
tasks
here,
which
iam
will
work
on
so
updating
the
design
for
the
package
registry
to
include
the
additional
metadata.
So
this
is
what
everything
that
came
from
the
user
and
the
reason
the
survey
making
threats
incorporated
into
our
design
same
thing
for
the
container
industry,
lots
of
stuff
here
and
a
couple
of
other
so
in
API
to
delete
files
from
a
package.
A
This
is
based
on
a
request
to
be
able
to
delete
files
from
the
UI,
but
first
we're
creating
the
API.
Then
next
we'll
create
allow
users
to
delete
the
items
from
from
the
user
interface
and
then
in
twelve
six
and
twelve
seven.
Hopefully
we
you
know
we'll
be
able
to
start
thinking
about
the
metadata
that
we
could
add
to
the
package
registry
and
to
the
container
registry,
UI
and
I.
Think
there's
a
couple
of
sides
of
that.
A
So
we're
add
NPM
tags
to
the
UI
and
that's
coming
a
little
bit
later
and
then
adding
labels.
These
I'm
sure
might
be
included
as
part
of
this
redesign.
But
I
wanted
to
have
these
up
here
as
examples
of
how
we
could
create
MVC's
of
the
redesign
as
well
and
I.
Think
that's
it
yeah!
That's
it
for
the
Sepik,
any
any
questions
or
comments.
B
So
it
seems
to
me
that
so
this
epic
is
kind
of
almost
like
specifically
set,
as
you
know,
not
necessarily
creating
new
things,
but
I'm,
really
just
sort
of
like
polishing
and
adding
a
lot
of
UI
and
user
friendly
experience,
as
well
as
providing
additional
information
and
any
any
other
sort
of
data
that
the
user
might
find
helpful.
Yeah.
A
I
think
so
I
think
it's
taking
what
we
have
and
squeezing
the
most
that
we
possibly
can
out
of
it,
because
we
have
a
product,
that's
really
useful.
And
if
you
looked
at,
for
example,
the
container
registry
I
said
it's
a
lot,
but
the
UI
looks
very
similar
to
docker
hub
because
we
built
about
using
docker
registry,
but
we're
good
lad,
not
docker
hub
and
there's
a
lot
of
other
information,
whether
that's
source
code
or
pipelines
that
we
can
include
as
part
of
the
experience.
C
Yeah
I
think
I
just
sort
of
been
made
away
today
by
a
tag
on
that
thread.
That
is
fair
number
of
errors
and
stuff
going
on
in
container
registry.
We
might
need
to
sort
of
factor
into
we're
redoing
it
a
bit
I'm
gonna
go,
do
a
bit
of
an
evaluation
of
where
that's
at
first,
but
just
for
a
little
bit
of
information.
There
apparently
there's
a
lot
of
errors
coming
out
of
it
and
we
need
to
be
tracking
those,
so
there
might
be
a
little
bit.
C
A
Yeah
yeah,
all
these
things
these
these
are
the
plans
for
product
features.
So
product
features
aren't
all
of
our
work.
We
still
have
bugs.
We
still
have
technical
debt.
We
still
have
you
know
other
things
like
that
that
need
to
get,
and
these
plans
could
can
totally
change
this.
This
is
me
just
you
know,
laying
out
the
milestones
like
okay,
if
we
did
everything
in
every
milestone
one
at
a
time,
this
would
be
the
planet.
A
I
do
expect
this
to
fully
change
but
I'm
more
looking
for
feedback
on
like
the
steps
that
we're
going
about
and
and
and
here,
I
guess
the
Preferences
that
I'm
saying
in
prioritization
prior
prioritizing.
These
things
is
first
build
an
API
then
will
then
have
the
front-end
consume
that
API
and
build
in
a
user
interface
or
in
that's
one
track,
and
the
other
track
is
research
design,
validation,
build
something
for
something,
that's
like
bigger
feature,
and
so
I
wanted
to
make
sure
that
that
logically
made
sense
to
yeah.
B
I
think
the
way
I
kind
of
view
this
epic
is
so
like,
in
contrast,
see
that
I
think
we
kind
of
covered
last
week
with
the
all
the
different
garbage
collection
and
and
all
those
sorts
of
issues
like
so
those
are
sort
of
the
technically
like
difficult
and
big
complex
issues
and
also
the
other
ethic
where
it's
creating
new
package
managers.
That's
also
kind
of
like,
like
big,
time-consuming,
features
where's
this.
This
is
more
like.
It
just
reminds
me
of
like
a
feature
factory
where
it's
like.
B
Alright,
this
is
just
like
a
list
of
things
where,
as
engineers,
we
should
be
able
to
just
start,
like
you
know,
hammering
out
a
couple
of
these
at
a
time
over
time
and
they
shouldn't
be
complex
or
difficult
overall,
and
it's
just
you
know
finding
like
the
right
spaces
to
put
them
in
at
and
not
sure.
If
the
that's
the
same
feel
from
the
front
end
standpoint,
but
that's
kind
of
you
overall
feel
I
get
from
the
back
end
standpoint.
D
A
comment
on
what
Steve
said
is
from
the
from
the
feeling
that
I
got
while
working
on
the
last
issues
that
I
got
I,
think
maybe
we
need
to
consolidate
a
bit
on
the
API
or
we
are
like
extracting
the
data
from
the
backend.
From
one
side,
we
are
pulling
out
a
JSON
directly
from
the
registry.
From
other
side,
we
are
consuming
an
API,
so
maybe
a
little
bit
of
this
work
should
be
involved
too.
If
you
want
to
expand
it
can't
copy,
it
is
like,
like
reduced
amount
of
code
and
interaction
ATM.
D
A
Is
that
for
the
container
registry,
the
group
level
container
registry
I
think
that
that's
definitely
I
could
have
a
misunderstanding
of
this,
but
I
think
what
has
to
be
true?
Is
we
have
to
start
persisting
that
data?
That's
that
goes
into
the
container
registry
right
now.
We're
I
think
we're
pulling
using
the
docker
API
for
populating
that
data
right
so
we'd
have
to,
and
then
that
to
me,
I
was
just
about
to
ask
what
everyone
thought.
A
A
Movie,
all
over
ok,
so
I
think
this
goal.
The
goals
of
this
one
might
be
a
little
more
straightforward,
so
one
ensure
that
this
list
that
we
maintain
a
prioritized
discoverable
list
of
plan
integrations
I,
get
asked
questions
from
all
kinds
of
people
about.
What's
the
order
what's
the
prior,
like
which
priority?
Where
does
this
one
stand
and
I'm
constantly
getting
new?
A
You
know
the
gate
lab
sensing
mechanisms
is
the
word
they
would
use
for
setting
priority
order
and
it's
it's
a
balance,
because
I
have
customers
that
are
asking
for
net
and
composer
as
our
most
highly
requested
features
but
dogfooding.
You
know
we
really
want
support
for
rubygems
and
Linux
packages,
so
we
have
to
figure
out
the
best
way
to
balance
that
in
terms
of
priority
and
I'm
working
with
the
infrastructure
and
distribution
teams
to
help
that
understand
their
priorities
and
urgency
behind
it
as
well
so
below.
A
There
is
a
prioritized
list
that
I'm
currently
walking
working
off
of
so
we
want
to
support
the
most
common
programming
languages.
I,
don't
you
know
it's
fine
when
we
were
going
through
the
CI
CD
strategy
with
mark
he's
like?
Are
we
gonna
cover
every
language
or
just
the
top
ten,
just
the
top
15?
For
now
it
feels
like
10
is
a
good
number,
but
you
know
maybe
we'll
expand
past
that
but
10
feels
like
that's.
A
We
could
probably
cover
more
than
80%
of
the
market
by
covering
the
top
10
integrations,
and
then
this
is
a
probably
loaded
sentence,
but
standardizing
the
implementation
and
user
experience
for
each
integration.
So
for
me
this
means
that
we
have
a
standard
way
of
authentication
that
so
we're
always
ideally
saying
that
you
could
use
authenticate
with
the
personal
access
token.
We
support
the
same
instance
group
and
project
level
endpoints.
We
have
a
similar.
A
You
know
method
for
like
how
they
can
interact
with
the
user
interface
and
they're
allowed
to
build,
publish
and
delete
images
from
CI
using
the
CI
tokens.
I
think
if
we
get
those
things
right,
there
might
be
other
ones
that
I'm
not
aware
of
and
I'm
sure
there
might
be
some
architecture
changes
that
we
want
to
make
for
how
they
function
overall,
maybe
they
but
I
think
for
now
from
the
at
least
the
user
experience.
A
B
C
I
think
the
big
coil
out
here
for
me,
as
far
as
like
standardizing
across
package
managers,
I
think,
is
that
we
ought
to
be
well
I.
Think
it's
worthwhile
considering
how
how
to
make
this
get
lab'
as
part
of
this
process
like
what
makes
sense
from
a
data
perspective,
at
least
in
my
head.
You
know,
as
Steve
was
mentioning
before
likes,
displaying
everything
in
a
package
from
the
package.json,
a
user
friendly
way,
I
think
when
we
start
talking
about
standardizing
the
view
of
what
we
display
for
each
of
these
different
package
managers.
C
Part
of
that
process
will
be
looking
at
what
was
the
gate
lobby
way
to
actually
approach
this
problem
problem?
You
know
to
actually
implement
this
package
manager
and
how
it
is
this
flow,
as
part
of
and
and
from
in
my
head
at
least-
and
this
is
just
totally
preliminary,
so
I'm
happy
to
go
whatever
research
suggests
by
the
way
in
so
I
would
think
that
reset
of
look
at
will
normally
would
integrate
this
way,
and
then
we
actually
build.
C
We
think
we
build
a
standard
UX
for
it
that
that
works
for
all
of
them
and
just
displays
information
in
terms
of
others.
The
standard
information-
and
this
is
to
get
allowed
the
information
about
your
package,
and
this
is
the
other
sort
of
custom
metadata
and
in
that
sense
standardizing
would
be
sort
of
determining
what
shared
metadata
is
there
or
what
metadata
get
lab
stores
about
those
things
about
each
of
those
individual
packages.
And
at
that
point
you
still
have
a
shared
data
set
for
each
of
the
different
package
of
engines
that
you
can.
C
I
think
I
think
it
turned
from
an
engineering
standpoint
as
we
and
I've
Steve
and
I
have
already
been
talking
about
this,
but
as
we
sort
of
deploy
each
one
is
looking
for
commonalities.
We
don't
want
to
prematurely
optimize
and
start
building.
This
super
generic
thing,
because
that
just
could
be
really
expensive
and
time-consuming,
but
at
the
same
time,
as
we
start
seeing
generalities
across
these
package
manages
it's
worth
so
saying:
hey.
Does
it
make
sense
to
slow
down
a
little
bit
here
and
adjust
something
to
be
more
generic,
so.
A
I'm
really
interested
in
that
last
point.
Not
yet
I
just
want
to
make
sure
that
we're
constantly
asking
that
question,
and
hopefully
you
all
feel
that
I'm
constantly
poking
with
that
question,
because
I
do
want
to
make
sure
that
we're.
You
know
we
have
a
bunch
of
these
to
add,
and
this
is
all
really.
This
is
all
really
valuable.
A
But
I
want
to
make
sure
that
there's
this
thing
in
the
get
lab
handbook
that
we
shouldn't
add
features
if
the
cost
of
maintaining
them
is
more
expensive
than
launching
them,
and
so
I'm
very
cautious
of
that.
Because
I
I
know
how
much
work
it
is
to
add
Conan
and
you
get,
and
you
know,
if
we're
even
getting
down
to
Ruby
that
still
Python,
composer
and
Ruby,
and
so
if
we
need
to
make
sure
that
we're
at
we're
building
in
a
sustainable
way
and
that
the
maintenance
story
is
pretty
easy
and
the.
C
Other
thing
I
wanted
to
mention
Tim
and
not
to
dissuade
or
detract
from
at
that
point
because
I
think
that's
super
important
from
an
engineering
and
execution
standpoint,
but
I
don't
know
whether
you
feel
like
it's
worthwhile,
including
like
community
contributions
in
this
effort.
I
know
we've
been
talking
back
and
forward
about
how
we
execute
how
we
put
time
into
the
community
contributions,
because
it's
really
important
that
we
do
and
I'm
just
sort
of
thinking
about
different
ways.
C
We
can
approach
that
because
some
of
these
things,
as
we
now
have
have
community
efforts
going
on
already,
we
can't
count
on
those
community
contributions.
We
can't
ask
anyone
to
to
give
us
their
work
for
free.
Obviously,
it's
not
really
not
really
fair
and
people.
We
can't
sort
of
demand.
It
happens
at
a
certain
time,
but
that's
something
else
that
I
would
think
of
in
these
terms.
I,
don't
how
you
feel
about
that,
but
yeah.
A
Actually,
Sid
brought
that
up
as
part
of
the
review
of
our
strategy
and
he
he
said
what
is
the
vision
for
user
contributions
for
adding
new
formats
and
he
asked
about
documentation
for
you
know,
do
we
have
documentation
for
how
a
user
can
contribute
in
that?
In
so,
let's
say,
go
support.
We
have
some
documentation
that
Deezy
created
awhile
ago
after
creating
NPM
and
maven.
He
just
sent
me
that
this
morning
and
I
think
it's
a
good
exercise,
and
maybe
it
leads
into
the
previous
point
that
we
were
making
about.
C
Think
as
we
have
more
people
join,
the
team
it'll
be
a
little
bit
easier.
People
won't
be
sort
of
like
so
focused
in
a
specific
area,
because
we
have
pretty
lightweight
right
now
in
the
backend
side,
at
least
so.
For
me,
I
think
I'd
like
to
see
some
of
that
be
expanded
into
some
useful
documentation
for
community
contributions.
Here's
the
good
place
to
start,
like
you
said
I,
can
stop
watching
the
composer
effort.
That's
going
on.
C
You
can
certainly
see
people
struggling
with
not
only
learning
how
to
you
know,
get
lab
and
contribute
to
such
a
large,
active
codebase,
but
also
like
ok
I've
got
to
do
all
of
the
things
and
we've
seen
that
sort
of
consistently
across
well
not
consistently,
but
a
couple
of
those
community
contributions
have
definitely
seen
that
and
I
think
providing
people
with
a
little
bit
of
guidance
on
how
to
do.
That
would
be
really
helpful.
But
then
part
of
the
issue
is
that
we
need
to
then
allocate
resources
to
get
it
going
further.
C
And
what
is
our
MVC
look
like?
What
is
it
it's
the
lead
and
upload
great?
Is
it
a
feed
like
we
were
talking
about
when
you
get
you
know
like?
Is
it
some
other
minimal
thing
that
we
could
just
ask
people
to
do,
but
if
we
say
that
and
that
doesn't
necessarily
satisfy
their
specific
need
with
that
package
manager
right?
So
if
they're
trying
to
contribute
I
would
imagine
often
it's
people
who
go?
C
Oh
well,
I
want
to
use
this
in
for
myself
and
it's
not
here
so
I'm
going
to
add
it
and
if
we
say
just
do
this
bit,
they'll
be
like
yeah,
but
that's
not
useful
to
me.
I'm
gonna
keep
doing
more
of
it.
So
I
think
what
my
sense
is
is
allocating
people
to
assist
on
a
regular
schedule.
Each
week
spend
an
hour
or
two
working
through
whatever
community
contributions
we
have
and
at
the
point
the
person
is
continuing
to
or
decides
they
don't
want
to
continue
contributing.
Then
we
sort
of
say:
okay.
C
We
need
to
assign
it
depending
on
our
priorities,
obviously,
because
you
have
a
well
laid
out
plan
here,
which
I
really
appreciate
by
the
way.
Thank
you.
So
that's
kind
of
my
sense
on
those
community
contributions
is
sort
of
coming
up,
taking
what
Steve's
worked
on,
making
a
little
bit
more
like
public
facing
and
provide
people
some
nice
way
that
they
can
say.
Oh
okay,
that's
what
I
need
to
do
to
get
this
across
the
line
or
get
it
at
least
to
n-b-c
status,
yeah.
A
Yeah,
that's
a
good
idea.
I
like
that,
and
hopefully
we
can
help.
You
know
the
the
users
that
are
taking
on
these
projects
are
motivated
to
get
this
I
know.
The
person
working
on
composure
is
pretty
motivated
to
get
that
through
they've
done
a
lot
of
work,
so
hopefully
we
can.
We
can
help
them.
Yes,.
C
Super
impressive
and
really
awesome
to
see
that
person
like
putting
in
so
much
energy.
So
we
really
it's
really
important
that
we
actually
focus
and
spend
some
really
good
focus
time,
helping
the
community
contributors,
because
if
we
don't
be
risk
actually
burning
those
people
out
without
support
that
they
need,
and
so
for
me,
that's
like
super
important,
so
I
don't
know
if
that
goes
in
the
ethic,
but
I
would
I
think
the
documentation
side
of
it
probably
might
I
defer
to
you
on
that
team,
because.
A
C
A
Well,
there's
Nick
I
thought:
Nick
had
dropped
two
bags,
but
now
I
see
him.
Okay,
cool,
so
I,
actually
and
I
do
have
a
more
serious
question
about
these
integrations
because
we
implemented
as
a
company
and
p.m.
and
Maeve
in,
and
it
seemed
like.
We
just
did
what
we
thought
like
we
build
something
and
we
launched
it
and
we
got
feedback
on
it.
A
But
for
you
know,
reading
through
the
comments
for
nougat
and
composure,
I'm,
seeing
a
lot
of
just
things
that
are
like
maybe
making
my
spidey
sense
tingling
that
we
might
not
be
aiming
in
the
right
direction
or
that
the
people's
use
cases
and
what
they
value
about
these
integrations
might
be
different
than
what
we
suspect
and
is
anybody
else.
Have
that
feeling
like
we're
like
we're
building
something,
but
maybe
it's
not,
but
maybe
we
need
to
validate
why
this
is
valuable
for
users.
I.
B
Mean
I
personally
get
that
a
little
bit
specifically
just
the
idea
that
you
know
I'm
building
Conan
but
I
have
never
used
Conan
in
the
wild.
So
it's
it's
I
think
it's
certainly
something
to
pay
attention
to,
and
and
really
like.
Listen
in
on
those
conversations
that
people
are
having,
because
there
are
most
certainly
little
tidbits,
that
will
come
up
that
we
probably
won't
notice
just
trying
to
introduce
really
basic
functionality
like
I,
I.
Think
of
NPM,
for
example,
the
majority
of
people
using
NPM
really
are
just
you
know,
publishing
and
installing
packages.
B
A
And
so
far,
everything
that
we've
planned
has
been
focused
on
the
user
or
teams
using
it
and
not
so
much
about
the
contributors.
We
haven't
thought
really
at
all
about.
Should
we
host
you
know,
should
we
allow
encourage
people
to
create
their
NPM
packages
and
host
them
on
gitlab?
We
haven't
really
thought
about
that
at
all.
Yet,
with
this,
this
piece
of
the
puzzle,
I'm
thinking
that
maybe
for
nougat
and
composer
I,
could
start
reaching
it.
I've
been
at
least
four
I've
been
for
composer.
A
Did
yesterday,
I
think
I'm
going
to
have
a
more
concerted
effort
for
talking
to
users
about
this
and
figuring
and
I
just
want
to
hear
them
say
why
this
is
valuable
for
them
and
what
they
need.
The
new
get
piece
was
weird
for
me,
because
so
many
people
were
chiming
in
and
saying
I
just
want
to
feed
and
I'm
like
well.
A
What
does
that
mean
because
aren't
we
giving
a
feed
and,
and
how
do
you
create
a
feed
if
you're,
not
you
know,
if
you
don't
have
the
ability
to
authenticate
and
and
publish
things,
but
they
were
so
persistent
and
saying?
Oh,
we
just
want
this
feat
and
then
in
composer
they
had
people
were
so
opinionated
on
it.
You
know
certain
naming
convention
and
really
like
providing
you
know
saying.
A
Be
this
way
or
it
doesn't
make
any
sense
so
I
think
for
me:
I'm
I
moved
new,
get
back
an
iteration
because
we
were
working
on
Makonnen,
but
also
because
I
think
we
need
I'm
I'm.
Having
this
like
little
like
I,
said
this
little
spidey
sense
tingling.
That
I
think
we
need
to
think
about
or
about
verify
why
it's
valuable
for
users
and
maybe
there's
something
that
comes
out
of
that
that
allows
us
to
build
a
smaller
MVC
or
a
product,
that's
more
targeted
for
for
what
their
needs
are
and
yeah.
C
B
B
Like
you
know,
they're
not
gonna
want
to
have
this
huge
file
path
involved
in
the
project
name,
because
it's
not
very
discoverable
from
the
community
standpoint
and
so
I
think
there's
sort
of
two
ends
there,
there's
like
there's
there's
the
side
where
no
one's
gonna
even
see
the
package
name,
and
it's
just
gonna
be
like
automatically
created
and
used
versus.
You
know
how
do
we
also
make
them
discoverable
and
and
useful
for
like
open
source
and
situations
like
that?
It
feels
like.
D
They'll
go
ahead
and
I
just
wanted
to
add
something
about
open
source,
I
think
open
source
open
like
a
discussion
around
where
you
can't
standardize,
because,
for
example,
for
NPM,
ad
or
Yahoo,
well,
whatever
NPM
registry
editing
tools
for
like
they
package
creator
that
want
to
go
up
answers,
I,
don't
think
it's
gonna
bring
the
most
benefit,
at
least
on
the
short
run,
because
it's
difficult
to
shift
registry.
So
you
actually
do
it
only
if
you
know
there
is
a
company
requirements
around
it
or
project
requirements
around
it.
D
But
if
you
want
to
spread
your
package,
you
want
it
on,
like
the
registry
that
easy
and
easy
to
access
and
easy
to
consume
by
the
user,
because
your
aim
is
to
not
deliver
as
much
as
possible.
Well
probably
other,
for
example.
Python
is
the
same
way
if
you
want
package
to
be
open
source
and
reachable
you're
able
to
talk
on
the
default
registry,
because
that's
what's
easy
to
to
spread.
I,
don't
know
about
other
registry,
but
I
think
we'll
need
to
consider
case-by-case
three
on
this.
A
A
They
want
the
ability
to
have
a
private
registry,
that's
not
hosted
on
NPM
or
you
get,
and
they
want
the
ability
to
like
no
one
else
to
see
this,
no
one
else
to
access
it,
except
for
their
teens
and
then
it
seems
like
there's
also
a
subset
of
people
that
are
interested
in
well.
I
want
to
create
my
own
NPM
package
and
I
want
to
host
all
of
the
code
and
everything
on
gitlab,
but
I
want
it
to
end
up
on
NPM
and
I.
Think
thinking
through
each
of
there
might
be
more.
A
It
could
be
missing
like
a
value
but
thinking
through
what
are
the
size
of
each
of
those
markets,
and
is
it
a
step
function
like
that?
Like?
Can
we
look
at
it
and
say:
okay
well,
really,
just
providing
a
feed
of
whatever
you
have
hosted
on
nougat
is
valuable
and
that'll
meet
the
needs
of
sixty
percent
of
our
customers.
Maybe
that's
helpful
in
a
good
way
that
we
could
find
an
MVC,
but
if
it's
anyway,
all
I'm
saying
is
I
think
I
need
to
do
something
user.
A
We
talk
to
users
a
bit
and
think
through
a
little
bit
more
about.
How
can
we
create
an
MVC?
How
can
we
really
drive
in
on
value
for
users
and
how
do
we
make
sure
that
we're
building
things
in
the
right
way,
whether
that's
naming
conventions
or
authentication,
or
you
know
how
we
handle
multiple
registries-
things
like
that,
so
I
think
I
think
I'm
gonna
follow
up
on
that
stuff
and
in
this
milestone
one
one
quick
note
on
these
issues:
all
of
these
are
pretty
straightforward,
except
for
this
helmet
arts.
One.
A
This
helmet
arts
one,
is
a
little
bit
different,
because
really
what
we're
talking
about
is
adding
home
charts
to
the
container
registry.
People
are
already
doing
this.
We
you
could
do
this
now
with
helmet
III
that
basically
they
switch
the
backend
to
use
a
container
registry
as
storage
and
it
kind
of
works
on
the
platform,
but
we're
not
displaying
any
of
the
data,
so
we
don't
show
like
when
it
was
uploaded
or
updated
and
it
shows
us
zero,
bytes.
A
I
think
this
is
something
that
we
could
do
pretty
quickly,
because
we've
added
in
support
for
other
container
types
stan
has
done
it
pretty
quick.
So
this
might
be
one
that's
a
little
bit
more
straightforward,
but
other
than
that
they're
all
so
far.
These
are
all
like
similar
to
how
we've
done
NPM
and
maven,
and
then
this
is
the
current
list.
So
you
know
we
get
through
pi
PI
Ruby
and
then
we
get
to
some
of
the
Linux
stuff
and
go
and
I
have
Swift
on
here.
E
Okay,
just
a
quick
question.
He
says
in
our
goals
for
this
task:
doesn't
it
that
we
were
gonna
pick
perhaps
10
for
the
most
common
programming
languages?
Okay,
I
wondered
how
the
the
most
common
programming
language
were
determined
is
that
is
that
the
most
common
program
in
languages
used
worldwide
or
is
that
the
most
common
programming
languages
used
on
get
out
yeah.
A
It's
a
great
question:
there's
really!
No
I
don't
have
a
solid
answer.
It's
it's
a
combination
of
things
that
customers
have
requested
and
popularity
of
issues
and
then,
like
me,
doing
some
research
on
you
know
googling
what
are
the
top
10
programming
languages
and
but
we
don't.
We
don't
have
a
good
answer
on
which
languages
are
being
used
on
gitlab.
We
actually
don't
have
that
data
right
now,
like
we
can't
say,
looking
at
all
the
repos
on
get
lab,
what
how
many
repos
are
using
Ruby
versus
Python.
We
actually
don't
know
that
answer.
That's
that's!
A
E
No
I
was
gonna
say
that
would
be
the
most.
It
would
be
most
useful,
I
think
to
concentrate
on
what's
used
on
gitlab
itself
as
opposed
to
what's
right
now
you
mention
you
just
mentioned
Swift
and
if
there's
only
like
three
or
four
repos
on
the
entirety
of
gitlab
a
swift,
then
it
doesn't
make
much
sense
to
build
a
package
registry
for
that
language
does
it,
but
if
we
don't
have
that
data,
then
we
can't
make
decisions
based
around
it.
Well,.
A
Well,
it
might
get
approximated
in
the
popularity
of
issues,
although
that's
not
definite,
but
maybe
there's
some
other
way
that
we
can
get
that.
Maybe
we
could
survey
like
send
it
out
with
our
like
the
gitlab
marketing,
email
and
say
like
what's
your
language
of
choice
that
might
help
us
a
little
bit
but
I
think
the
reality
is
like
if
like
Swift
right
now
has
I,
don't
even
know
how
many
votes,
probably
none
and
is
one
of
them
mate.
Okay,
it
has
two
votes
compared
to
like
new,
get
or
composer
I.
A
A
So
much
writing
136
I'm
hearing
a
lot
of
people
ask
me
about
nougat
I
hear
some
people
asked
me
about
composer
I,
hear
it
get
a
lot
of
questions
about
pie,
pie
and
Ruby,
and
then
I
hear
some
requests
for
helm
and
Linux
packages
and
I
haven't
heard
much
about
go
actually,
which
is
surprising
because
to
me
go
is
like
the
trendy
language
right
now.
2019
and
but
we
only
have
six
votes,
so
the
reality
is
I
I,
don't
know
if
this
doesn't
get
uploaded
and
I
don't
hear
from
customers.
A
E
Yes,
that
that
was
another
question
I
had
that
I
kind
of
I've
asked
this
before,
but
is
there?
Is
there
some
kind
of
plan
or
strategy
here
to
encourage
the
dog
fooding
of
the
package
registry?
We
think
it
lab
itself.
So,
for
example,
the
obvious
one
is
get
lap
UI.
So
right
now
that's
served
fire
NPM
when
we're
doing
our
builds
and
stuff
like
that,
when
really
like,
really
it
should
be
served
by
our
packages.
E
A
A
great
idea,
I
in
truthfully
I've,
been
approaching
it
from
the
infrastructure
and
in
distribution
side,
which
is
all
docker
images
and
Ruby
and
Linux
packages
and
I
haven't
really
thought
about
it
from
the
front
end
side,
so
I
think
that's
something
I
could
who
I
guess.
I
would
have
to
follow
up
with
the
front-end
engineering
team
right
and
try
and
find
out
what
their
use
cases
are
and
if
we
can
cover
it.
E
Yeah
yeah
I,
guess
I,
but
would
it
like
to
me
that
makes
it,
but
then
that
would
potentially
increase
the
likeliness
of
a
go
package?
Would
she
be
required
because
I've
seen
we're
gonna
be
potentially
building
the
container
registry
or
yeah
parts
of
the
container
issue,
use
and
go
in
the
future
and
etc,
etc?
So
and
likewise
and
Ruby
would
become
more
of
a
priority
as
well.
I.
Imagine
yeah.
A
Ruby
is
definitely
something
that
I'm
hearing
a
lot
because
we're
the
both
Ian's,
like
all
of
our
internal
customers,
tell
me
that
we
need
that
we
and
that
we
need
caching
or
the
dependency
proxy
set
up
for
it
too,
because
there
there
was
just
an
issue.
I,
don't
know
all
the
details,
but
something
happened
with
Ruby
dependencies
where
cause
they,
they
couldn't
download
them
or
something
like
that
and
it
caused
a
problem.
A
So
they
they
all
our
internal
customers
want
us
want
these
features
and
I
think
NPM
will
be
a
great
place
to
start,
even
if
we
can't
do
the
Ruby
or
go
yet,
but
even
just
getting
feedback
and
then
other
people
to
contribute
and
stuff
I
think
that'd
be
really
valuable.
So
I
could
follow
up
on
that
and
and
see
and
see.
If
we
can
get
that
done,
I
think
RB,
you
do.
You
think
we
would
be
able
to
cover
get
lab
these
cases.
E
Yeah
I
think
so
so
don't
think
we
actually
use
am/pm
for
anything
specific
other
than
hosting
the
package.
You
know,
I,
don't
think
we're
on
there
yeah
using
any
of
the
features
like
not
heavily
using
any
of
the
features
or
anything.
As
far
as
I'm
aware
this
is
that
I,
don't
know
for
sure
so,
yeah
I,
don't
I,
don't
see
it
being
a
huge
problem
at
the
same
time,
I
don't
know
so.
E
D
I
think
it
could
also
open
like
some
door
for
more
like
like
more
like
internal
packages
and
more
internal
utility
being
published.
There's
we
could
use
like
the
get
lab
scope
to
release
all
all
more
internal
stuff
and
I.
Think
like
from
the
process
from
the
point
of
view,
like
of
the
pain
of
switching
a
packager
from
one
register,
the
other
to
the
GDK
I
think
this
can
be
done
like
transparently,
so
you
just
run
an
update
and
it
gets
switched
so
I
see
a
lot
of
benefit
out
of
it.
I
agree
make
yeah.
A
I'm,
a
big
I'm,
a
big
fan
of
that
and
and
and
hopefully
we
get
you
know,
other
people
will
contribute
and
get
frustrated
by
something,
and
then
say:
oh,
we
really
need
this
and
we'll
find
out.
You
know,
get
more
feedback,
so
that'd
be
great.
I'll
follow
up
with
the
front-end
engineering
team.
Who
do
you
think
is
the
best
person
I
should
reach
out
to
about
that.
E
Looking
okay,
cool
I
kind
of
wonder
actually
like
saying
so:
we've
get
lab
UI.
If,
if
the
package
version
is
increased,
that's
a
manual
action,
somebody
actually
has
to
manually,
go
and
update
package
JSON
and
then
pray
and
whole,
mr
for
that,
just
bump
up
the
version
of
google
app
UI
and
the
product
so
like.
Potentially
one
of
the
the
features
that
we
can
look
at
here
or
consider.
Dogfooding
is
a
weighty,
the
gitlab
project
that
a
new
version
of
the
package
has
been
published
and
that
it's
available
to
upgrade
assumed
that.
A
B
A
Think
if
we
cover
these
and
there's
probably
one
other
or
two
that
we're
not
seeing
it
just
because
we
haven't
gotten
far
enough
yet
but
I
think
that
would
get
us
a
good
percentage
of
the
way,
because
we
will
have
covered
all
these
management
features.
We
will
have
covered
a
lot
of
the
UI
will
have
covered
the
like.
Adding
in
new
integrations
will
have
covered,
improving
like
performance
or
rolling
out
the
dependency
proxy
I
think
it
gets
us
a
good
percentage
of
the
way
there.
A
Although
there's
probably
other
things
like
thinking
about
how
do
you
get
such
a
large
percentage
of
users
to
use
the
future?
There's
that
they're,
probably
like
marketing
that
we
need
to
do
and
outreach
and
probably
like
getting
ahead
of
it
in
terms
of
like
how
do
you
migrate
from
J
frog
to
get
lab?
We
don't
really
have
a
story
for
that.
Yet,
like
we're
just
saying:
okay,
you,
users
or
customers.
C
A
That
could
be
a
whole
nother
Avenue
that
if
we
really
want
to
reach
that
high
percentage,
we're
gonna
have
to
have
a
good
migration
strategy
from
Nexus
and
j.j
frog
to
to
get
one
so
I
think
that'll
be
another
really
key
area,
I'm,
not
sure
when
we
would
tackle
that
that,
but
would
probably
come
after
some
of
the
some
of
these
epics
or
as
we
get
customers
that
are
saying
I'm
cancelling
J
frog.
You
have
enough
features
like
now.
A
All
right,
I
think
that
is
actually
what's
that
question
we're
out
of
time
anything
else
that
we
wanted
to
mention
quick
questions,
comments,
okay,
so
I
think
next
week,
we'll
finish
going
through
the
final
two
epochs
these
should
those
should
be
much
quicker.
Let's
shouldn't
be
a
problem
to
cover
those
and
then
I
think
what
I
would
like
now
is.
If
you
know
Nick
I
know
you
mentioned
a
couple
of
weeks
ago.
Before
we
had
this
meeting,
you
brought
up
the
NPM.
A
Can
we
you
know
dog
food
that
internally
just
start
adding
questions
like
that
to
this
doc,
for
for
conversations
that
we
could,
you
know
have
in
this
meeting
like?
Should
we
dog
food,
our
own
product
or
is
there
a
faster
way
to
MVC
new
package
manager
integrations
or
what
will
we
do
for
dependency
scanning
or
something
like
that?
This
way
we
could
start
to
have
these?
A
You
know
the
topics
that
are
in
your
heads
and
in
our
in
in
our
heads
and-
and
we
can
start
talking
about
those
versus
like
just
me,
presenting
here's,
what
the
plan
is
and
level
setting
and
getting
feedback
and
adapting
on
it.
Then
we
could
start
to
like
as
a
team
synthesize
that
information
and
ask
to
ask
these
bigger
questions.