►
From YouTube: September2020 Package office hour
Description
Package office hour to highlight issues for wider community members and review MRs in progress.
A
Hello
welcome
everyone
to
our
monthly
community
office
hours
for
the
package
stage.
This
is
a
special
month
because
we're
also
having
a
get
lab
hackathon
today
and
tomorrow,
where
you
can
contribute
for
prizes
as
well
as
work
with
other
people
so
yeah
today.
We
just
wanted
to
open
it
up.
I
we
shared
an
issue.
A
I'm
trying
to
talk
less
in
these
and
trying
to
make
it
more
about
the
community
and
the
developers
speaking,
but
I'm
happy
to
ramble
on
if
about
random
things,
people
want.
B
Yeah
it
looked
like
there
were
also
like
three
or
four
issues
that
steve
that
you
could
probably
address
like
if
you
want
to
give
it
like
a
high
level
overview
of
what
some
of
these
issues
are.
I
think
that
would
be
that'll
be
good
as
well,
but.
A
Yeah,
I
could
start
there
and
yeah
I'll
just
I'll
share
my
screen.
I
think
that'll
be
easier,
oops,
okay,
so
I
put
in
about
15
issues
here
and
there
they're
all
are
they
have.
There
are
some
consistent
themes,
so
one
thing
that
we're
looking
to
do
is
a
limitation
that
we
have
is
some
of
the
different
package
manager
formats.
Only
work
at
you
have
to
scope
the
packages
to
a
specific
level,
for
instance
at
for
nougat.
A
You
have
to
use
the
project
level,
so
you
have
to
scope
all
of
your
project
names
to
the
project
level.
We
were
recently
working
on
expanding
this
for
our
conan
repository,
so
I
thought
that
it
might
be
helpful
if
people
had
questions
about
how
to
do
this,
they
could
ask
steve,
who
recently
did
that
work
and
there's
a
bunch
of
issues
here
like
pulled
nuget
packages
at
the
instance
level
npm
at
the
project
level,
group
and
subgroup,
support
for
nuget
and
then
there's
another
one
down
here
too,
I
think.
A
There's
another
one
for
allowing
users
to
publish,
install
images
using
their
name
space.
This
is
something
that
github's
container
registry
does.
That,
I
think,
is
really
interesting.
You
could
you
don't
have
to
publish
to
a
project
or
a
group.
You
could
actually
publish
to
your
for
me.
It
would
be
t
rizzy
or
you
could
also
publish
it
to
your
namespace.
So
if
you
were
at
company
acme,
you
could
do
that
as
well.
A
Then
there's
a
couple
of
other
issues
here,
and
this
is
a
bug
where
images
are
not
being
properly
deleted
from
the
container
registry
eye.
This
is
a
pretty
popular
issue
where
and
I
believe
that
we
have
a
cause
identified
in
it.
So
it's
a
good
option
for
working
through
some
some
some
issues,
this
one
actually
steve.
I
think
we
should
remove
this
package
versions,
rendering
results
and
then
two
queries.
I
think
you
are
almost
you're.
C
A
On
this
now,
actually
so,
let's
remove
that
one,
and
then
we
have
some
other
package
manager
stuff,
like
the
pi
pi,
supporting
searching
by
name
ensuring
that
when
you
publish
a
new
package
version
that
we
add
that
to
the
activity,
feed
and
project
notifications,
it's
a
nice
ui
improvement
or
ux
improvement.
A
We
have
some
of
the
package,
name,
validation,
improvements
for
each
format.
So
how
do
we
validate
that?
The
name
is
correct
and
doesn't
cause
any
issues.
There's
if
you're
interested
in
c
and
are
in
conan.
You
could
there's
an
issue
with
the
user
interface,
where
we
aren't
showing
that
it
was
built
with
a
pipeline,
even
if
it
was
so.
If
you're
interested
in
cnc,
plus
plus
that'd
be
a
good
project
and.
A
Then
there's
an
issue
here
where,
with
nuget
packages
that
fail
to
upload
when
they
have
an
extended
version,
so
right
now
you
could
publish
a
new
get
package
that
has
a
version
1.0.0.
But
if
you
had
1.0.0.1
it
would
fail.
So
that's
another.
It's
an
opportunity
to
work
with
regex
and
naming
restrictions
that
we
have.
So
that
could
be
another
fun
opportunity.
A
D
D
A
A
B
B
D
I
said
that
storage
driver
parsing
could
be
simplified,
centralized
I
think
that's
the
most
meaty
one,
it's
just
a
bit
of
cleanup
and
it's
not
that
difficult
to
prove
that
it's
correct
and
you
don't
really
need
to
know
all
of
the
ins
and
outs
of
the
way
that
the
docker
container
shoe
works.
So
I
think
it's
a
good
good
entry
point.
D
We
have
a
rounding
issue
which
would
be
relatively
easy
to
fix,
and
it
would
be
a
good,
a
good
introduction
to
the
garbage
collector
with
the
file
system.
Working
with
that
and
seeing
what
kind
of
what
kind
of
things
are
going
on
there.
F
A
F
All
right
so,
and
what
we're
talking
about
here
is
if,
if
you
look,
we've
got
a
development
page
for
working
on
package
managers
in
the
contributor
docs
and
what
we're
talking
about
is
the
section
that's
labeled,
remote
hierarchy,
which
is
a
very
complicated
name
but
pretty
much.
What
it's
saying.
That
is
that
when
we
make
when
you
set
your
remote
for
a
given
package,
type
like
npm,
sometimes
you're
setting
it
with
a
project
id
directly
in
the
remote.
F
F
You
know
who
owns
this
package,
what
project
does
it
belong
to,
and
so
that's
kind
of
where
we
run
into
all
these
naming
restrictions
that
we
have
on
many
of
our
package
types.
But
if
you're
scoped
down
to
the
project
level-
and
you
have
the
project
id
within
the
path,
then
we
can
just
verify.
I
mean
we
already
know
what
project
it
belongs
to.
We
can
verify
you.
D
F
Permissions
and
all
that
sort
of
stuff,
just
by
looking
at
it,
so
it's
really
beneficial
to
fill
in
this
table
and
add
project
level
scoping
to
anything.
That's
missing
it.
So
I'm
finishing
up
the
common
scope
right
now
and
really
the
only
other
one
that
needs
project
level.
Scoping
is
npm,
but,
as
you
can
see,
there's
a
lot
that
don't
have
group
level
access,
or
instance,
level
access
which
can
be
really
helpful
when
you're
working,
you
know
within
a
given
group,
and
you
need
to
access
a
whole
bunch
of
different
packages
across
different
projects.
F
F
So
what
I
did
was
I
took
a
look
at
sort
of
how
or
you
know
how
conan
is
set
up
and
let
me
actually
pull
my
code
over.
F
And
so,
if
we
look
at
the
conan
api
here,
we
have
all
these
different
routes
that
are,
you
know,
packages
cone
in
the
ping
route.
We've
got
the
search
route,
we
have
the
authentication
route
and
so
they're
all
within
this
same
namespace
of
just
packages,
cone
in
v1
there's
nothing
about
projects
or
anything.
F
So
what
I
wanted
to
do
was
take
all
of
these
endpoints
and,
in
addition
to
having
them
in
this,
namespace
also
have
them
in
a
different
name:
space,
that's
scoped
to
projects,
and
really
my
initial
thought
was
the
the
actual
endpoints
there's
nothing
in
them.
That
should
really
have
to
change
other
than
the
sort
of
prefix
to
the
url
and
sort
of
checking.
You
know
how
the
authentication
works,
so
what
I
was
able
to
do
was
identify
a
way
to
extract
those
routes
into
a
shared
section.
F
So
what
I
did
was
I
was
able
to
expand,
extend
active
support,
concern
and
turn
everything
into
a
single
concern
rather
than
having
it
as
its
own
api
instance,
and
then
this
code
and
package
endpoints.
I
could
then
share
with
different
name
spaces.
So
I've
got
the
existing
namespace,
which
was
packages
cone
in
p1,
and
I
just
include
the
package
endpoints
and
then
I
go
over
to
the
project
level,
and
so
here
I
have
my
project
resources
with
the
project
id
and
then
right
inside.
F
I
can
include
the
package
endpoints
and
now
I've
got
two
entire
sets
of
endpoints
that
really
have
the
same
functionality
but
different
scoping
and
then
from
there.
It's
just
a
matter
of
you
know,
refactoring
tests
and
and
some
other
things
that
can
add
up
quickly,
but
in
terms
of
opening
up
those
different
levels.
There
is
a
nice
easy
way
to
do
it
using
these
concerns,
trying
to
think
if
there
was
anything
else
I
had
to
talk
about
with
that.
F
There
is
one
aspect
to
pay
attention
to
some
of
these
deal
with
workhorse
routes.
I
don't
think
you'd
run
into
this
unless
you're
working
at
the
project
level
with
uploads,
but
if
anything's
doing
uploading
through
workhorse,
which
you
would
see
by
if
you're
looking
at
the
endpoints
you'll,
see
things
like
workhorse
named
within
the
actual
endpoints,
then
you
would
need
a
secondary
merge
request
in
the
workhorse
project.
To
add
a
special
route,
saying:
hey
it's:
okay
to
upload
packages
or
package
files
through
this
route.
F
G
So
I
noticed
that
I
think
maven
has
just
a
single
file
that
has
all
of
the
and
or
has
a
single
endpoint
class
that
has
all
of
the
different
name
spaces
in
it.
Whereas
for
your
changes
with
conan,
you've
created
two
separate
classes
for
the
project
and
instance
level
endpoints.
Is
there
a
particular
motivation
for
that
or
guidelines
on
when
to
do
that?.
F
F
So
when
you
set
your
remote
on
conan,
it
will
prefix
every
single
call
it
makes
with
that
remote
url,
whereas
with
maven
maven.
In
order
to
upload
a
package,
you
need
the
project
id,
but
for
downloading
packages
you
the
way
that
the
maven
I
forget,
what
the
name
of
the
file
is,
the
pom
xml,
I
think,
is
set
up.
F
You
can
set
the
different
repositories
for
different
dependencies,
and
so
not
every
single
request
that
maven
makes
is
going
to
use
the
same
remote,
no
matter
what
it
just
depends
on
your
configuration,
and
so
that's
where
we
didn't
need
to
set
up
every
single
endpoint
with
the
project
id
and
we
didn't
so.
We
didn't
need
to
duplicate
everything
and
that's
kind
of
why
that's
all
in
one
file
versus
cone
and
we
had
to
duplicate
everything.
So
we
it
was.
F
It
made
more
sense
to
split
it,
and
that's
definitely
something
to
pay
attention
to
in
working
is
whether
or
not
we
need
to
have
every
single
endpoint
be
accessible
from
every
single
prefix.
F
And
I
wasn't
going
to
point
out
for
anyone.
That's
looking
for,
because
those
are
like
sort
of
big,
like
you
know,
like
they'd,
be
a
really
challenging
but
fun
problem
to
work
on
during
a
hackathon.
But
if
you're
looking
for
just
some,
like
you
know,
first-time
contributions
or
you
just
really
want
to
kind
of
like
get
your
fingers
into
the
code
base
a
little
bit.
I
think
one
of
the
ones
that
tim
pointed
out
talking
about
how
the
conan
packages
that
are
built
with
ci
built
within
a
pipeline
they're.
F
They
never
actually
show
up.
As
being
said
that
they're
built
in
a
pipeline,
that's
actually
true
for
a
few
other
package
types
too.
I
think
maven
and
npm
are
the
only
ones
that
show
pipeline
info.
I
might
be
wrong
on
that,
but
if
you
look
at
this
conan
issue,
I
left
a
few
notes
in
here
about
where
this
kind
of
lives
in
in
the
in
maven
and
if
we
look
at
maven,
it's
really
kind
of
straightforward.
F
All
we
really
have
to
do
is
find
where
the
package
is
being
created.
So
here
we
have
a
specific
create
service
for
for
maven
packages
and
it's
just
a
matter
of
adding
one
line.
So
we
just
need
to
create
the
build
info
for
this
package.
F
If
there
is
a
build,
that's
you
know
currently
being
used,
and
so
something
like
this
line
is
probably
all
that
really
needs
to
be
added
to
each
of
these
different
services.
So,
like
somewhere,
there's
a
conan
create
package
service
and
it
would
just
be
a
matter
of
adding
this
line,
possibly
having
to
update
the
api
endpoint.
That
calls
the
create
service
to
add
the
build
parameter,
but
that's
really
about
all
that
needs
to
be
done
and
then,
of
course,
writing
a
few
tests
to
prove
that
that
it
works
as
expected.
F
G
F
F
I
think
that
might
have
come
up
when
it
was
originally
implemented,
but
the
information
is
not
there
historically,
so
unless,
unless
it
was
linked
at
the
time
of
the
package
creation,
there's
no
way
to
look
back
historically
and
find
pipelines
that
that
created
a
specific
package.
I
might
not
be
completely
correct
there,
but
I'm
pretty
sure
that
was
one
of
the
problems
we
ran
into
was
that
there
was
no
way
to
sort
of
backfill
that
historic
content.
D
B
No,
I
was
about
to
ask,
like
I
mean
ethan
and
jochen,
I
mean
I
think
both
of
you
have,
mrs
in
flight
or
in
progress.
Just
wait
to
see
if
you
guys
have
any
comments
or
questions,
but
do
you
wanna
like
I'm,
not
quite
sure.
If
I
do
you
want
to
verbalize
your
comment
there,
like
hey
there.
E
E
E
F
Yes,
I
think
that
that
hits
on
another
really
valuable
contribution
that
we
can
always
use
is
like
examples
of
ci
templates,
because
I
mean
we're
building
these
package
managers,
but
you
know
we're,
as
you
see
we're
ruby
developers
and
as
much
as
I
want
to
be
an
expert
in
c
plus,
plus
or
go
or
php.
B
G
G
Generally,
yes,
some
of
them
have
some
build
issues
that,
though
some
some
of
that
is
due
to
in
one
case,
I'm
waiting
for
giddily
changes
to
percolate
through
the
system.
G
I
think,
okay
and
there's
you
know
I
could
rebase
some
of
them,
but
I
haven't.
There
haven't
been
any
comments
from
the
team
in
a.
A
So
this
is
the
link
that
ethan
just
shared,
and
it
sounded
like
this
was
the
conversation
that
was
going
on
this
morning
with
steve
and
david.
So
is
where.
G
G
A
G
So
gg
not
sure
how
to
pronounce
his
name
made
some
comments
a
while
ago
that
I've
responded
to
and
then
occasionally
I've
had
to
rebase
that
to
get
it
to
be
mergeable
but
waiting
for
a.
G
G
So
that
one
won't
build
right
now,
or
at
least
the
last
time
I
poked
at
it,
because
I
made
some
that's
actually
something.
That's
I'm
curious
about.
I
mean
I
do
need
response.
You
know,
there's
things
to
be
reviewed,
but
also
I
merge
some
changes
into
gitaly
a
lot,
I'm
seeing
a
bunch
of
ci
failures,
because
now
the
updated
code
is
using
parameters
for
the
italy
grpc
that
are
new
and
the
definitions
haven't
registered.
G
I
tried
updating
the
gem
file
and
I
updated
the
giddily
server
version.
At
least
I
thought
I
did.
Apparently
I
didn't
and
the
gem
file
lock,
so
I'm
not
sure
how
to
get
the
ci
to
pass
on
that
it
does
pass
locally
because
locally,
I'm
using
the
a
more
a
recent
version
of
the
italy
gem,
but
I'm
not
sure
how
to
get
ci
to
pass
on
that.
B
A
A
A
F
Probably
yeah-
I
I
I'm
not
as
familiar
with
that
one.
So
I'm
not
I'm
not
quite
sure
about
the
changes
with
italy
but
yeah.
That's
probably
the
best
avenue.
G
So,
a
few
weeks
ago,
stan
pinged
them
ping,
the
giddily
team
and
they
released
a
new
pre-release
version
of
the
gem
that
has
the
definitions
in
it.
So
there
is
a
gem
published
that
has
the
new
definitions
from
my
merge
changes,
but
it's
that
those
updates
have
not
made
it
into
the
main
application
or
something.
A
Okay,
okay,
I
could
I
could
check
with
stan
too.
That
would
be.
I
could
follow
up
on
that
I'll.
Take
a.
A
F
Available,
I
can
ping
him
this
afternoon
and.
B
F
He's
just
because,
if
that's
the
case,
he
might
have
gotten
a
little
overloaded.
So
I
can
see
if
we
need
to
just
re-delegate
a
few
of
these
to
myself
and
david
too.
G
So
this
is
one
that
originally
there
was
a
different,
mr.
That
is,
I
marked
draft
because
it's
it
got
messy
and
david
was
working
on
that
one
and
then
I
separated
out
part
of
it
to
be
a
smaller
change
set
and
then
it
got
that
was
while
david
was
on
vacation.
So
it
got
picked
up
by
gigi
and
yeah
that
just
needs
review.
A
A
A
C
No,
actually,
actually,
that
I
just
posted-
I
just
just
I'm
just
following
the
trading
and
gitlab
about
the
the
proxy
for
nougat,
because
in
the
company
that
I've
been
working,
I'm
gonna,
I'm
gonna,
try
to
put
gitlab
instead
of
github
there
and
package
manager
is
the
great
feature
that
we
need
working
well
to
change
from
github
to
google
web.
So
so
that's
why
I'm
here
and
just
following
you
guys.
A
Cool
yeah,
I
think
our
our
package
registry,
offering
for
nougat,
compares
pretty
closely
to
what
github
has,
except
we
have
a
few
more
options
for
authentication
and,
for
I
know,
github
doesn't
support
packages
for
nuget,
for,
like
certain
types
of
accounts
like
enterprise
accounts,
so
be
curious
to
get
your
thoughts
as
you
start
to
adopt
it.
C
Yeah
and
the
important
thing
for
us
is
to
have
a
centralized
repository
instead
of
like
publishing
nugget
patches
in
every
single,
every
single
repository.
You
know
I
mean
so
I
I
just
wanna,
I
just
wanna
ping
one
address
and
then
retrieve
all
the
packages
instead
of
like
registering
or
saving
all
the
the
urls
in
my
visual
studio,
you
know
so
having
a
proxy
is
a
great
feature
for
us.
A
Well,
yeah:
that's
that's
something
that
we're
planning
on
rolling
out,
starting
we'll,
probably
start
with
maven
and
mpn.
Those
are
our
most
commonly
used
formats
and
that
what
we'll
do
is
we'll
add
remote
and
virtual
I'll
link
this
issue
in
a
second
we'll
remote
and
virtual
registries.
So
you
can
add
an
arbitrary
amount
of
remotes
and
then
link
them
all
in
a
virtual
registry
with
just
a
single
url
and
then
we'll
add
caching
and
compliance
to
that
in
the
future.
I'll
forward,
the
epic
for
nougat.
A
B
E
Just
for
your
information,
I
recently
added
or
introduced
composer
packages
at
our
company,
which
worked
quite
well.
I
just
wrote
a
little
script,
which
was
adding
like
or
transforming
actual
composer
tags
to
versions,
and
that
worked
great,
I
mean
my
workmate
is
really
happy
now,
so
we
can
dump
the
other
proposal
repository
and
using
gitlab
now,
and
we
slowly
keep
on
migrating
the
projects
to
gitlab
only
so
yeah
that
worked
great
so
far,
yes,.
A
Do
you
think
there's
a
way
that
we
can
create
more
awareness
amongst
php
developers
that
this
feature
exists
on
gitlab,
because
I'm
noticing
that
we
launched
it?
But
I
don't
know
that
we,
like
really
did
it
reached
out
to
the
php
community
I
was.
I
was
just
wondering
if
you
had
any
thoughts
on
that.
E
Well,
I
tried
to
spread
the
word
like
in
the
type
of
three
type
of
three
cms
community
and
I
got
good
feedback
from
a
bunch
of
people,
but
still
a
lot
of
people
just
telling
me
well.
That
feature
is
available
on
gitlab.
Now
I
wasn't
aware
of
that,
and
so
just
trying
to
like
on
twitter,
like
let
the
people
know
when
I
finish
another
feature
for
a
composer
and
just
try
yeah
to
get
awareness
somehow.
A
B
I
mean
I
mean
johan,
I'm
not
sure
if
you're
open
to
doing
this,
but
like
a
blog
post
makes
sense,
like
your
experience
of
you,
know,
deploying
this
at
that
work,
and
I
mean
it
doesn't
have
to
be
like
a
really
long
or
or
lengthy
dissertation,
but
like
we
have
unfiltered
blog
posts
that
you
know.
If
you
want
to
start
writing
up
and
tim,
your
I
could
like
help
with
the
edits
and
we
can
make
it
pretty
simple,
but.
B
Maybe
yeah,
let
us
know
yeah,
so
I
think
that
would
be.
I
mean
I
think,
that'll
be
a
good
asset
to
have
with
like
tweets
and
other
like
a
social
promotion
promotions
that
we
want
to
do.
That's
not
just
that
it's
available,
but
this
is
how
it
was
used
and,
like
your
experience,
I
think
would
be
interesting.
B
No,
no,
this
a
good
session
would
have
some
new
contributors
and
like
experienced
contributors,
so
nice
mix.