►
From YouTube: August'2020 Package office hour
Description
Discussion on community MRs in progress plus highlighting issues for community contribution.
A
Okay,
well
welcome
to
the
august
package
office
hour
and
I
thank
you
ethan
and
tim.
I
think
you
just
made
comments
on
the
issue
for
the
office
hour
yeah.
So
a
few
mrs
from
ethan,
particularly
that
we
can
look
at
and
then
tim,
I
guess,
do
you
want
to
start
with
the
other
topics
that
you
listed
there
or
how
do
you
want
to
or.
B
A
B
B
Just
to
give
you
an
idea
of
what's
changed
and
why
you'll
be
able
to
dig
into
any
specific
commits
or
pipelines
and
link
to
them
if
it
was
built
using
ci
cd,
we
move
the
install
commands
down,
but
they're
still
super
visible
and
I
think
that's
okay,
and
then
we
have
this
additional
metadata
here.
Like
where's,
the
source
project
located.
C
B
Well,
as
any
license
information,
if
it's
included,
there's
a
bunch
of
other
changes
here
as
well,
but
that's
kind
of
the
one
that
I'm
most
excited
for.
So
if
you're
interested
in
the
front
end
aspect
of
the
package
stage,
this
is
a
great
epic
to
jump
into
and
give
feedback
or
potentially
contribute.
B
The
other
thing
is
I'm
not.
This
might
be
worth
mentioning.
This
is
another
community
contribution,
that's
in
progress
and
basically
what
we're
doing
here
is
validating
that
package
versions.
So
each
package
manager
has
a
different
sort
of
enforcement
of
how
they
handle
versioning.
So
right
now
we
have
added
in
validation
for
maven
npm,
nougat
conan,
and
I
know
we're
working
on
pi
p.
I
now
so
potential
option
for
contribution
is
maybe
working
on
composer,
adding
in
some
validation.
B
So
this
that's
another
one,
that's
a
potential
option
and
then
for
people
that
use
the
package
stage
regularly
we're
actually
looking
to
do
some
user
research
or
solution
validation.
We
would
call
it
this
would
be
a
meeting
with
our
product
designer
ian
and
basically
you
are
given
a
task
and
you
have
to
go
through
an
example,
user
interface
and
try
to
accomplish
those
tasks.
It's
a
really
good
way
of
giving
us
feedback
on
our
designs
and
also
another
way
of
contributing.
B
So
if
you
are
interested
in
this,
you
can
reach
out
to
me
at
t-rizzy,
gitlab.com
and
we'd
be
happy
to
schedule
something
and
then
finally,
I'm
breezing
through
these
quickly.
We
have
an
issue
scheduled
for
this
milestone
to
prevent
duplicate
packages
from
being
uploaded,
specifically
focusing
on
maven,
pipi
and
nuget.
B
If
you
have
any
concerns
about
that,
if
you
have,
if
people
are
worried
about,
I
wanna
up
for
some
reason:
upload
duplicates
the
exception
is
maven
snapshots.
We
we
will
would
like
to
allow
duplicates
of
those,
but
this
is
another
opportunity
if,
if
you
have
an
opinion
on
that
to
chime
in
okay,
that
was
my
five-minute
version
of
just
some
ideas,
any
questions,
or
should
we
move
on
to
some
of
the
openmrs.
A
Just
a
quick
comment:
I'm
going
to
write
it
down,
write
a
comment
on
the
issue
too.
So
if
there
are
any
issues
that
are
still
left
open,
like
it's
probably
worth
highlighting
for
the
hackathon
in
about
a
month,
so
I'll
reach
out
to
you
tim,
we
might
want
to
yeah.
I
want
we'll
just
we'll
see
what
the
where
the
issues
are
and
then
there
any
worth
that's
with
highlighting
I'll
open
an
issue
for
a
hackathon
we'll
make
sure
that
these
get
highlighted
too.
B
Cool,
I
think
we
can
have
a
nice
mixture
of
front
end
and
rails
issues
as
well.
For
that,
so
we
can.
We
could
start
promoting
that.
Basically,
in
the
middle
of
august,
I
think
yeah,
awesome,
okay,
I
guess
I
should
let
ethan
and
the
developers
talk.
That's
enough
of
me.
So
what
should
we
should
we
jump
into
the
openmrs.
D
So
the
mrs
I
listed
there's
not
a
whole
lot
to
necessarily
talk
about.
I
think
those
are
just
ones
that
you
know
those
are
the
main
go.
Mrs
I've
been
working
on
getting
mrs
and
I
think
the
last
one
should
be
merged
soon.
Once
I
make
a
couple
of
changes
so
that
will
allow
this
isn't
one
of
necessarily
one
of
the
ones
that's
listed
on
there,
but
with
the
giddily
changes
that
will
allow
me
to
move
all
of
the
archive
generation
out
of
get
lab
proper
out
of
the
ruby
application.
C
B
D
The
yeah,
so
it's
re,
reworking
the
authentication
for
packages
in
general
conan
is
just
the
one
that
I
started
working
on
first,
that
might
not
be
a
good
choice,
but
that's
so
it's
the
ascent.
It's
the
first
step
of
creating
a
unified
system
for
managing
off
custom
authentication
for
the
package
managers.
D
C
So
you
can
imagine
that
as
a
table
where
you
have
how?
How
do
you
send
the
tokens?
Are
you
using
basic
alls,
oros
or
a
custom,
http
header,
and
what
kind
of
tokens
you
are
using
like
personal
access
tokens
deploy,
job
tokens,
ci
tokens
and
all
the
intersections
are
the
support
we
need
to
implement
for
package
managers
api,
and
the
issue
is
that,
right
now
the
authentication
part
for
the
api
is
kind
of
a
small
mess.
I
guess
it's
a
giant
file
with
functions.
That's
it
it's
not
properly
organized.
C
I
think
we
are
clear
that
we
can
solve
that
in
a
single
line,
which
is
which
means
that
people
that
will
add
a
new
api
will
be
able
to
describe
the
authentication
needs
in
one
line
and
they
will
be
supported
and
well
then
you
have
to
code
what
this
line
is
doing.
So
that's
the
whole
point
of
the
dsmr,
so.
C
C
What
is
it
you
have
to
locate
it
and
read
it,
that's
it.
The
second
step
is
the
value
that
you
just
read.
You
need
to
find
the
proper
token
if
it
is
a
job
token,
you
need
to
load
it.
If
it
is
a
personal
access
token,
you
need
to
load
it,
and
those
two
parts
can
be
just
two
sets
of
functions
that
you
chain
and
that's
it,
and
this
these
two
parts
could
be
living
in
a
common
place.
C
C
I
don't
know,
let
me
think
about
a
new
way
to
authenticate
a
new
header,
no
a
new
parameter.
Perhaps
that
could
be
possible
and
on
in
the
other
side
of
the
the
problem.
It's
the
token
types
perhaps
one
day
we
need
to
support
group
token
type
or
something
like
that,
and
this
would
be
just
the
second
column,
and
here
the
dsmr
it's
using
well,
it's
based
on
the
the
api
developers
will
implement
their
own
set
of
functions
and
I
don't
think
that's
a
good
way
to
achieve
that.
C
D
I
mean
I,
I
definitely
followed
that,
and
I
did
respond
to
some
of
your
comments,
but
again,
I
you
know
forgot
to
ping
you
I
just
wanted
to
say
to
everyone.
I
posted
a
link
to
the
epic
that
has
a
lot
of
the
discussion
on
it
that,
where
some
of
where
we've
been
talking
about
this
and
david
one
of
the
things,
one
of
the
questions
I
had
was
so
you
were
describing
you
know,
possibly
as
the
future,
and
you
know
not
necessarily
in
this,
mr
having
a
adapter
pattern
with
low.
D
You
know
credential,
locator
and
user
finders.
How
would
you
envision
those
so?
Presumably
there
would
need
to
be
a
hash
somewhere
that
associates
the
different
different
symbols
with
a
concrete
implementation
to
you
know,
do
the
task
for
that
symbol.
How
are
you
envisioning
that
hash
getting
built
so
something
like
the
mount
command?
You
know
there's
the
api
file
that
has
all
the
mount
dismount
that.
C
C
So
that's
another
thing
we
will
need
to
support,
and
once
we
have
everyone
supported
and
the
code
is
stable
kind
of.
We
can
think
about
how
we
can
improve
things
because
the
these
two
sets
of
functions,
I
guess
we
will,
they
will
grow
quite
large,
so
that's
expected.
So
how
do
you
split
them
or
organize
them
in
a
clean
way
so
that
you
don't
repeat
the
same
mess
as
oath
dot
rb,
which
is
the
file
for
authentication
in
apis?
And
it's
just
a
giant
bag
of
functions?
C
To
that,
you
can
just
take
each
function
and
embed
embed
it
in
in
its
own
class,
and
then
the
authentication
code
will
just
load
all
the
classes
and
given
the
parameters
or
the
config
that
the
user
will
pass,
you
you
just
load
the
class
and
instantiate
it
and
just
called
the
execute
or
whatever
function
you
need
and
each
class
will
do
its
own
job.
Look
like
let's
say
that
we
need
that.
We
need
to
read
authentication
tokens
from
basic
oauth.
C
C
But
before
that,
I
would
just
work
with
two
sets
of
functions
and
and
implement
all
the
package
managers
that
we
have
and
then
we
revisit
the
authentic
this
authentication
refactoring
and
think
about
simplifying
it
or
reorganizing
it.
But
I
don't
think
it's
a
good
idea
to
try
to
tackle
all
the
objectives
at
once.
You
just
start
really
really
simple
and
you
just
iterate
on
it
iterate
iterate
and
when
the
the
thing
is
going
out
of
the
reasonable
bounds.
I
guess
you
just
think
about
how
do
you
can
you
refactor
it?
D
C
Don't
attach
too
much
important,
don't
don't
attach
too
much
interest
or
priority
on
that,
because
that's
the
word
of
refactoring.
If,
if
you
have
a
function
and
you
need
it
to
split
it
in
three
classes
and
four
functions,
you
can
do
it
and
and
it's
better
to
start
simple.
Since
we
don't
know
what
kind
of
things
we
will
need
to
support
and
actually
conan
is
one
that
have
an
exotic,
not
exotic
but
custom
thing,
because
it's
using
a
personal
access
token
that
is
encoded
in
jwt.
C
C
C
D
So
I
was
thinking
of
starting
a
separate,
mr
and
copying
over
some
of
the
stuff
to
sorry
this
cat
chewing
on
things.
So
I
was
thinking
of
copying
over
some
of
the
implementation
and
starting
with
one
of
the
simpler
ones
and
then
marking
the
current,
mr
well
renaming
it
to
something
conan
and
marking
it
work
in
progress.
So
you
know
doing
the
initial
work,
the
initial
mr
for
one
of
the
ones
that
just
uses
basic
auth.
C
C
C
I
think
I
did
a
small
analysis
for
this
on
the
issue
and
yeah,
I
think
you're
better
off,
starting
with
one
that
has
only
talk,
not
a
token
location,
a
request,
location
for
the
tokens
and
a
token
type.
So
you
would
have
these
two
sets
with
just
one
function
and
that's
it.
But
this
way
you
can
take
time
to
to
build
the
skeleton
or
all
the
files
you
need
by
the
way.
C
That's
a
good
find
the
namespace
thing
so
that
we
can
have
different
ways
to
authenticate
in
different
namespaces
with
well
grape
api
namespaces,
that's
really
good,
find
and
having
that
dsmr
can
be
then
merged,
and
then
we
just
iterate
on
it
and
start
adding
more
functions
on
here.
On
these
two
sets
and
to
me
conan
should
be
kind
of
in
the
middle
or
or
the
last
one,
because
there
is
this
personal
access,
token
encoded
in
jwt,
which
is
custom
to
conan,
but
we
can,
we
can
add
it
as
a
token
type.
C
E
B
F
The
idea
is
that
we
have
now
a
pattern
of
smart
component
component.
I'm
gonna
screen
shares
in
a
second
and
some
stuff,
and
and
so
ui
is
directly
regulated
by
dumb
component,
which
just
receive
props
and
emit
events,
and
then
there
are
smart
components
on
top
of
them
that
do
some
orchestration
and
attachment
attaching
to
the
save
manager
I'm
going
to
screen
share.
So
I
can
show
what
I'm
talking
about
screen
one
yes.
E
F
F
F
The
other,
the
corresponding
component
here
is
our
this
one,
for
example.
This
is
what
we
call
a
dumb
component.
It
doesn't
do
anything
that
presenting
some
html
and
use
some
interaction
for
the
user,
and
why
this,
why
this
approach?
This
actually
had
a
little
bit
of
water
trading
and
redundancy,
but
why
this
is
good
is
first
of
all
it's
much
easier
to
test.
Everything
is
isolated.
All
these
components
have
very
strong
unit
tests
around
them,
so
any
community
contribution
any
single
contribution
that
touches
them.
F
Second,
it's
easier
to
test
them,
because
the
wall,
adding
the
ux
and
stuff
add,
adds
a
lot
of
complexity
to
the
to
the
test
and
the
boilerplate
in
it.
This
needs
to
be
done
and,
and
third
it's
it
favors
parallel
work,
because
since
every
piece
of
ui
is
encapsulating
one
single
separated
component,
every
single
change
is
probably
a
different
file,
most
likely
different
file.
F
A
Yeah,
I
think
we
had
another
community
member
online
for
a
while,
but
it
looks
like
that
person's
dropped
off,
unfortunately,
didn't
have
a
chance
to
welcome
that
person.
But
oh
well.
Hopefully
he
wasn't
bored
or
anything
with
the
conversation,
but
I
was
thinking.
Maybe
we
could
have
done
a
better
job
of
like
screen
sharing
like
mrs,
what
we're
discussing
it,
but
oh
well,
better.
Next.
C
C
C
E
E
G
G
Yeah,
the
the
garbage
collection
database
stuff
is
so
enmeshed
with
the
you
have
to
really
take
in
a
lot
of
the
logic
of
the
container
registry.
I
think
we
do
have
one
issue
comes
to
mind
and
it's
not
it's
not
the
most
interesting
thing.
Maybe,
but
it
is,
it
is
something
that
would
be
nice
to
have.
Is
that
the
the
option?
Parsing
logic
for
storage
drivers
is
all
separate
and
everyone,
every
storage
driver?
Does
it
differently,
but
they're
all
doing
the
same
thing.
So
that
would
be
a
good.