►
From YouTube: May'2020 GitLab Package office hour
Description
Recording from the Package office hour during the Q2 Hackathon
A
There
we
go
hello
and
welcome
to
this
month's
community
office
hours
for
the
package
team.
The
goal
of
these
meetings
are
to
kind
of
have
an
informal
chat
with
members
of
the
community
for
any
ideas
that
they
would
like
to
contribute
to
get
lab
or
any
questions
they
have
in
terms
of
how
to
implement
them
as
well
as
just
give
a
general
chance
to
ask
any
questions
that
may
come
up.
So
this
we
try
to
do
these
about
once
a
month,
and
this
month
we
have
a
few
people
attending
I.
A
B
So
currently,
with
the
go,
MVC
I
think
it's
pretty
much
just
waiting
for
a
security
review,
so
Steve
all
the
answers.
Questions
that
been
answered
documentation
has
been
taken
care
of
so
I
think
it's
just
waiting
for
the
somebody
from
the
security
team
to
see,
or
they
requested
a
path.
Traversal
tests
and
I
wrote
a
couple
of
tests
so
waiting
for
them
to
say
whether
or
not
that's
what
they
want.
A
B
A
B
A
B
A
Like
okay,
so
just
so
I
understand,
we
had
there's
the
first
step
beyond
what
we
did
for
a
for
when
it's
built
using
the
job
token
is
having
some
manually
way
to
enter
in
a
project
name.
Yes,
that
probably
takes
us
a
pretty
decent
amount
of
the
way
to
write
like
if
people
want
to
enter
that
in
it'll.
Be.
Do
you
think
the
on
that
note?
We
don't
really
have
a
way
for
having
a
readme
for
packages
either.
B
Think
that
could
be
useful.
I
haven't
thought
a
lot
about
that
so
I'm
hesitant
to
say
much
about
it.
I
think
that
explicit
I
think
creating
an
explicit
schematic
link
between
a
package
and
the
source
project
would
allow
for
a
lot
of
things
like
that,
but
yeah
I
haven't
really
thought
about
it.
Okay,.
A
B
Mean
my
suggestion,
yeah
adding
a
so
main
thing
is
adding
a
something
like
package
source.
You
know
adding
a
database
type
and
I
haven't
looked
through
this
and
eat,
or
you
know,
read
through
my
whole
blog
post
and
the
issue
here,
but
mostly
just
creating
that
schematic
element
having
a
way
to
create
you
know,
create
that
link
and
then
displaying
it
for
now.
B
There's
something
you
know,
there's
some
things
like,
though,
that
when
the
package
is
created,
that
link
could
be
automatic
because
it's
implicit
in
the
structure
of
language
itself,
and
there
are
some
things
like
NDM,
where
I
think
it'd
be
a
good
idea
to
automatically
create
the
link
based
on
metadata
if
there
is
sufficient
metadata
and
then
there's
other
questions
like
if
I
have
already
linked
one
version
of
a
package
to
a
project.
If
another
version
of
that
package
is
uploaded,
should
I
automatically
recreate
that
link
but
I
think
that's
beyond
the
first
steps.
B
C
It's
just
gonna
say
that
that
sounds
pretty
reasonable.
Pretty
pretty
approachable
to
me,
I
think
a
tin,
an
API
endpoint
to
to
link
these
two
and
Steve
can
correct
me
if
I'm
wrong
here,
probably
isn't
too
difficult
and
then
wiring
it
up
in
the
UI
is,
is
very
straightforward.
The
current
UI
that
I've
built
that
displays
the
project
link
right
now
is
basically
only
pipeline
project.
C
So
if
a
package
is
built
via
pipeline
that
will
link
to
the
project
that
when
that
pipeline
lives,
so
we
would
potentially
have
to
add
your
additional
logic
to
display
this.
This
new
link
or
some
I
guess
it's
possible,
although
extremely
unlikely
that
you
could
link
a
package
to
a
different
project
and
have
it
built
by
a
pipeline
that
belonged
to
and
even
like
a
third
project.
C
B
I
was
thinking
when
I
was
writing
this
up.
I,
remember
thinking,
if
you
have
you
know
a
B
and
C
and
a
is
the
package
and
B
is
publishing
it
via
building
and
C.
Is
where
you're
publishing
it
too?
Then
it
makes
sense
to
show.
So
if
the
user
has
manually
said
this
package
that
we've
uploaded
is
linked
to
this,
the
source,
as
this
project
over
here
I
think
it
makes
sense
to
override
the
pipeline
information
saying
you
know
it
comes
from
this
project.
C
It
links
to
the
commits
that
generated
the
pipeline,
so
that
would
potentially
go
to
project
C
in
this
case
instead
of
project
B,
which
I
yeah
I,
don't
know,
if
that's
so
bad
I
I,
definitely
think
that
you
would
want
to
only
display
one
project
and
in
most
cases,
I
think
you'd
probably
want
to
display
the
source.
You
know
so.
Somebody's
actually
like
going
out
of
their
way
to
say
this
project
is
the
source
of
this
package.
D
C
A
We
would
if,
if
the,
if,
in
the
case,
that
you've
linked
a
project
URL
and
that
it
would
still
build
be
a
pipeline,
I
would
still
think
you
would
want
to
know
that
it
was
build
via
this
pipeline.
You'd
want
to
link
to
that
code.
You
probably
I
think
to
Ethan's
point.
You
still
want
to
see
that
activity
right,
but
probably
I,
was
thinking
of
that.
A
A
B
A
A
E
A
A
C
A
B
Okay,
so
Steve
was
talking
on
that
issue.
Steve
was
talking
about
a
project
entity
kind
of
thing
that
our
package
entity
to
describe
all
you
know
that
grouping
of
all
of
the
versions
of
a
given
package
name,
and
so
essentially
my
strategy-
is
leave
that
grouping
as
a
logical
thing,
as
opposed
to
actually
creating
a
database
element
for
it.
B
E
A
B
C
So
one
thing
I'm
a
little
bit
unsure
about.
If
we're
gonna
do
this
manual
linking
and
we're
gonna
build
some
kind
of
UI
to
to
link
a
package
to
a
project
is
what
kind
of
permissions
are
going
to
be
required
for
the
user
to
be
able
to
do
this?
So
do
they
have
to
be
a
maintainer
of
both
that
the
project
that
you're
linking
to
and
that
the
project
that
the
package
resides
in
or
do
they
do?
They
have
to
have
some
other
kind
of
permission
modes
like?
Is
there
a
way
to
unlink,
for
example?
C
Obviously,
these
are
visual.
Just
general
questions,
I'm
not
expecting
like
an
answer
from
anyone,
but
it's
it's
probably
worth
thinking
about,
because
I
guess
it's
gonna
be
very
easy
to
like
if
you're,
if
you're,
given
a
UI
or
even
API,
driven
after
doing
this,
then
mistakes
can
be
made
and
all
that
all
of
that
kind
of
stuff.
So
we
need
to
possibly
make
these
reversible
or
blockable
or
any
other
kind
of
not
allowed
to
do
this
kind
of
action
for
them.
I
think.
B
Definitely
they
should
be
removable
as
far
as
permissions
I
can
see.
An
argument
for
requiring
maintainer
on
both
I
can
also
see
arguments
for
not
I.
Think
some
of
it
comes
down
to
is
this
going
to
have
an
effect
on
the
source
project,
because
if
the
link
you
know
if
we
list
packages
or
something
like
that,
then
if
I
was
maintaining
some
packaged
source
I
wouldn't
want
random
things
showing
up
that
I
didn't
create.
But
if
there
is
no
impact
on
the
source
project,
then
maybe
maybe
not
I,
don't
know.
A
My
first,
without
thinking
about
it
more
and
more,
my
first
instinct
was
developer
and
above
because
they're,
the
ones
who
can
publish
the
packages.
So
if
you
can
add
a
package,
you
should
be
able
to
add
some
metadata
about
it
as
well,
and
then
I
was
thinking.
Would
we
want
to
do
any
kind
of
validation
of
the
URL
like
I
confirm
that
it's
not
malicious
or
something,
and
that
don't
you
know
that
it's
actually
goes
somewhere.
That's
a
valid
URL.
C
B
C
Another
interesting
idea
that,
for
maybe
this
is
this,
is
potentially
be
seen
as
a
drawback,
although
I'm
not
entirely
sure
how
much
of
scenario
would
come
into
play,
but
imagine
it
so.
I've
created
nick's
package
and
and
ethan
is
using
my
package
in
his
project
and
steve
is
using
my
package
in
his
projects.
C
There's
two
packages
now:
if,
if,
if
a
geyser
links
his
version
of
nick's
package
to
my
projects,
that
won't
necessarily
touch
steve's
version
of
steep
lake
of
my
package
in
steve's
projects,
so
steve
will
have
my
my
package,
but
not
linked
to
the
project,
whereas
Ethan
would
have
my
package
but
link
to
the
budget
so,
but
that
kind
of
flips
things
around
in
the
sense
that
this
feature
really
is
only
gonna
be
used.
If
the
developer
of
a
particular
project
really
cares
about
where
the
package
is
coming
from.
C
E
E
Was
gonna
check
something
first,
so
in
NPM,
if
I
recall
correctly
inside
of
the
package.json
file,
others
there's
an
optional
field
for
the
registry,
our
staff
for
the
repository
at
the
git
repository
I'm,
wondering
if
most
package
managers
have
something
like
that
that
we
could
extract
when
the
package
is
uploaded
and
then
linked
from
there.
There's.
E
B
Know
I
go
it's
implicit
in
the
package
name
though
there's
some,
you
know,
there's
the
whole
vanity
URL
thing
so
go
supports.
You
know.
I
can
have
a
package
on
git
lab
and
have
a
custom
domain
and
use
the
custom
domain
as
the
package
name
and
have
it
set
up
correctly
so
that
that
responds
to
particular
requests
that
point
to
get
lab.
So
it
is
implicit
in
the
linkage
is
implicit
and
go,
but
it
would
require
some
extra
steps,
though
it
can
be
explicitly
verified.
Oh.
E
E
B
E
That
would
be
awesome
and
I.
Think
part
of
it
is
also
my
I've,
never
really
dealt
with
port
forwarding
and
all
of
that
kind
of
stuff
and
setting
that
up
locally,
so
I
might
just
be
having
some
trouble
with
that
as
well.
But
I'll
see
if
I
can
figure
that
out
and
ask
you
if
I
have
some
questions
getting
that
set
up.
D
D
D
A
Have
an
EM
are
open
that
just
kind
of
simply
changes
the
license
files,
so
anybody
who
has
a
self
managed
e
instance
will
be
able
to
use
it
in
the
core
or
starter
and
then
over
the
next.
Several
milestones
will
actually
plan
the
migration
of
all
the
files
to
move
it
properly,
so
I
think
right
now.
It's
probably
the
majority
of
the
contributions
we're
seeing
our
Enterprise
Edition,
but
I
expect
that
in
the
cup
like
in
a
month
or
two
months
that
it'll
be
much
less
okay.
D
Cool
I
mean
if
in
case
you
haven't
seen
it
I'll,
try
to
find
it.
In
my
handbook,
I
mean
people
that
are
contributing
to
e.
If
you
need
a
license,
I
mean
here's
a
like
a
handbook
page.
Blank
word
you
can
I
mean.
Obviously
anyone
can
start
out
with
a
free
30-day
trial
license
and
then,
if
you
need
licenses
beyond
that,
feel
free
to
ping
me
to
help
with
a
license
and
the
other
thing
I
talked
to
contributors
about
it.
D
Is
that
actually,
in
terms
of
like
submitting
an
MRI
like
you,
don't
typically
need
an
enterprise
edition.
You
typically
eat
it
when
you
need
to
do
testing
locally
and
and
so
forth,
so
it
shouldn't
be
a
blocker
in
terms
of
getting
you
getting.
People
started,
but
I'm
just
led
me
or
Tim
now
that
if
you
get
stuck
with
the
license
issue,
so
you
don't
have
to
deal
with
that.
D
D
D
That
one's
internal
I
mean
that's
something
that
I'll
deal
with,
so
you
don't
have
to
worry
about
that.
But
I
just
want
people
to
know
that
you
can
always
like
reach
out
to
me
or
ping
me
and
then
I'll
do
the
internal
work
or
actually
getting
the
license,
but
that
it's
the
center
yeah.
That's
it's
pretty
simple.
It
usually
takes
me
like
five
minutes
to
get
people
license
out
email
so.
D
A
Especially
for
folks
watching
the
hackathon,
so
I'll
just
share
my
screen
briefly
so,
every
month,
when
we
have
these
office
hours,
we
create
an
issue
and
in
the
issue
we
link
to
some
suggested
contributions
and
we
have
identified
as
some
low-hanging
fruit
as
well
as
some
bigger
projects
as
well.
So
in
terms
of
a
low-hanging
fruit,
we
have
don't.
We
have
this
already.
Okay,
let's
just
get
to
this
one
so
enabling
support
for
for
publishing
and
installing
packaged
it
and
you
get
packages
using
the
job
token.
A
So
this
is
a
good
opportunity
to
get
familiar
with
where
the
package
registry
code
lives
and
also
some
of
the
authentication
code
for
good
labs.
So,
if
you're
interested
in
those
things,
that's
a
good
place
to
start,
we
have-
and
we
have
a
few
examples
of
some
issues
with
Jupiter
notebooks.
These
are
more
front-end
focused
issues
with
you
know,
issues
where
images
aren't
being
displayed
properly
or
things
like
that
and
then
for
the
bigger
projects
we
have.
A
You
know
you
could
always
do
anything's
doing,
which
is
adding
in
a
new
package
manager,
format
and
there's
a
few
dependency
proxy
issues
here.
Adding
authentication
support
so
the
dependency
proxy
will
work
with
private
projects
and
then
you
know
extending
the
maven
repository
to
work
with
group
at
the
group
level.
We
just
talked
about
identifying
that
a
package
is
linked
to
get
that
project
today
and
then
there's
a
backstage
issue
there
yeah.
Then
this
is
a
good
place
to
go
another.