►
From YouTube: 📦Package Managers SIG Weekly Sync July 16, 2019
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
Hello
and
welcome
to
the
package
managers
weekly
sync:
we
haven't
done
one
of
these
in
a
while,
because
we've
been
reorganizing
things,
and
so
this
seemed
like
a
good
time
to
discuss
what
we
should
do
with
this
meeting
and
the
kind
of
areas
we
should
focus
on
or
the
format
of
it
that
we
should
have
on
an
ongoing
basis.
I
still
think
is
a
good
idea
to
have
a
public
call
that
is
recorded
and
kind
of
gives
a
nice
output
of
what
we're
working
on.
A
B
A
And
like
write
it
down
just
had
that
meeting
before,
but
it
wasn't
recorded
or
public.
It
was
just
like
let's
review,
Zen
hub
and
kind
of
see
if
anyone
is
blocked
on
anything.
The
output
of
that
isn't,
like
isn't
obvious
entirely.
I
guess
is
it's
mostly
just
like
aligned
with
the
issues
that
are
in
the
in
progress
column
and
if
you're
not
going
to
be
progressing
on
those
I,
guess
they
go
into
the
backlog,
Michelle's
nodding.
So
that's
that's
this.
C
A
A
C
A
Why
do
we
choose
to
focus
on
that?
Because
it
is
kind
of
the
of
in
the
package
managers,
repo,
there's
a
nice
file
about
the
kind
of
different
levels
of
implementation,
as
you
go
down,
and
the
file
system
based
package
managers
are
the
simplest
in
terms
of
getting
the
whole
thing
onto
ipfs,
because
everything
is
file
based
the
indexes,
as
well
as
the
individual
tarballs,
are
all
nicely
contained
in
simple
files,
which
I
think
is.
A
I
haven't
actually
spoken
to
many
process
based
package,
many
maintainer
z',
but
it
comes
across
as
it's
set
up
for
operational
simplicity,
for
the
ability
to
easily
allow
copying
and
mirroring
using
traditional
Linux
tooling,
without
needing
to
to
build
extra
databases
or
to
run
applications.
You're
literally
able
to
use
HTTP
servers
and
rsync
and
ftp
servers
to
enable
many
people
to
run
their
own
mirrors
of
package
managers,
and
then
everything
is
signed
as
well.
Like
that's.
A
A
A
So
that's
kind
of
where
we
shook
out
and
said
like
this
seems
like
a
good
one
to
start
with,
and
then
once
we've
done
that
successfully,
then
we
can
move
on
to
looking
at
how
to
how
to
support
the
other
kinds
of
package
managers
once
we've
got
filesystem
base
ones
working
well
that
cover
off.
Why
we
came
out
with
that.
Pretty.
C
A
And
then,
like
inside
of
that,
we
kind
of
have
a
few
things
that
we
already
know
from
the
past
few
months
of
a
package
manager,
special
interest
group
of
the
kinds
of
of
challenges
that
are
involved
in
just
getting
file
system
based
package
managers
on
to
ipfs
the
performance
of
importing
the
performance
of
updating
and
then
the
challenges
of
updating,
as
well
with
different
api's
and
the
user.
Experience
of
doing
that
from
a
maintainer
side
and
then
on
the
flip
side
is
the
the
consumer.
Has
performance
and
UX
challenges
as
well?
A
We've
kind
of
formed
our
okrs
around
that
a
little
bit
but
I
think
to
begin
with
we're,
focusing
mostly
on
the
maintainer
side,
so
setting
up
mirrors
and
then
being
able
to
regularly
update
those
mirrors
they're
fairly
large,
looking
things.
So
the
stats
for
likethey
at
apps
repository
is
almost
a
million
files
across
some
50,000
directories.
A
Inside
of
a
single
root
directory
they
get
updated.
Maybe
every
I
think
they're.
The
average
is
somewhere
between,
like
the
suggested.
Sync
is
every
four
to
six
hours.
If
you
end
up
being
a
primary
so
that
a
lot
of
the
mirror
setups
appear
to
be
like
primary
and
secondary
secondary
ones,
they're
like
oh
try
and
try
and
update
every
every
day,
every
24
hours,
some
of
them
are
like.
Oh
you
can.
You
can
sync
every
10
minutes
if
you're
using
this
particular
kind
of
our
sync
script,
but
to
be
a
primary,
you
usually
the
mirror.
A
Dominic
is
been
working
on
some
interesting
efforts
around
being
able
to
mount
ipfs
as
a
file
system,
which
would
enable
us
to
link
directly
into
IP
FS,
which
would
be
really
cool,
because
then
we
would
only
need
to
to
rehash
this
stuff
that
has
changed,
and
that
would
work
directly
with
existing
tooling
that
package
manager
maintain
is
used
rather
than
having
to
create
and
maintain
particular
tools
for
package
management.
If
we
can
work
with
existing
UNIX
tooling,
then
that's
wonderful.
It
means
we
can
kind
of
lean
on
all
of
that.
B
Was
taking
a
look
at
the
cue
tree?
Okay,
ours
for
this
group
and
I
noticed
that
the
the
number
zero
okay
R,
which
is
the
system
based
package
manager,
should
be
able
to
take
a
large
truck
tree
of
files
and
import
it
into
ipfs
from
scratch
in
an
amount
of
time,
that's
reasonable
and
then
update.
It
doesn't
have
any
either
initiatives
or
or
metrics
around
it.
B
B
Okay,
then
my
alternate
feedback
loop
is
effectively
of
you.
Have
three
okay,
ours,
one
around
hey:
we
should
we
should
measure
some
stuff
measuring
is
important
and
I'm
very
supportive
of
that.
That's
great
one.
That
is
like
research
and
stuff.
We
should
understand
some
things
and
one
that
is
we
should
be.
We
should
be
happy
and
we
should
be
functioning
as
a
team.
All
of
those
are
great
things.
None
of
those
is
actually
make
the
package
manager
experience
great
using
ipfs,
like
many
of
those
is
actually
the
end
work.
C
Can
also
say
for
me:
it
was
a
bit
of
like
well
we're
in
an
interesting
space
where
I
know
we
talked
a
teen
week.
It's
like
okay,
word
might
be
doing
a
lot
of
tests
and
Shipyard,
for
example,
and
be
able
to
say,
we've
done
all
this
and
we've
done
like
ten
pocs,
and
we
think
that
this
is
the
way
to
do
it,
but
we're
not
confident
that
we
actually
can
get
anything
into
like
the
core
implementations,
because
that's
not
us,
it
kind
of
is
us
anyways.
C
B
We
think
needs
to
happen,
whether
that's
a
capability
that
we
think
needs
to
be
added
or
whether
that's
like
a
performance
improvement
to
a
specific
area,
and
yet
from
reading
these
initiatives
like
they,
they
don't
seem
that
which
is
you
know
if
these
are
like
super
high
level,
and
these
point
to
like
four
issues
which
is
like
do
this
thing
in
this
thing.
In
this
thing,
that's
cool,
but
then
I
think
it
needs
really
precise
metrics
for
how
we're
gonna
measure
this
of
like
hey
we're,
gonna.
Take
like
these.
C
Now
I
just
feel
like
it's
gonna,
be
really
hard
for
you
to
measure
any
of
these
things.
Yes,
well,
we
hope
to
get
there.
The
whole
point
is
that
we
don't
actually
know
what
improvement
means
yet
and
that's
part
of
what
our
job
is.
This
quarter,
we
don't
know
if
it
means
that
it
XYZ
needs
to
be
faster
or
ABC
news
faster.
A
So
I
think
the
the
work
that
I'd
kind
of
lined
up
to
focus
on
this
week
was
to
generate
a
document
that
lines
up
like
as
the
be
kind
of
this
section.
Sorry
terrible
internet.
So
basically
going
like
here's
the
like
the
summary
of
everything
file
system
based
for
from
the
past
three
months,
including
all
of
the
like
known
blockers
and
the
existing
metrics
that
were
collected
group
them
out
into
areas
which
would
be
research
of
like
what's
the
like
here
are
the
things
that
have
been
experienced
and
then
like
do
they?
A
How
would
they
go
about
being
fixed?
Do
they
even
should
they
even
be
considered,
or
should
they
just
be
thrown
out
as
like?
That
is
not
the
right
way
to
use
ipfs
for
this
thing,
then,
the
metrics
that
we
already
have
so
like
36
hours
to
do
ipfs
ad
from
scratch
for
the
apps
repository
results
as
one
of
those
like
his.
This
is
the
only
the
only
way
you
can
do
this
like
without
ddossing
the
DHT.
A
A
We
don't
think
it's
worth
investing
in
that,
but
I
think
that
the
conclusion
will
line
up
with
their
the
things
that
we've
got
there
and
then
being
able
to
actually
talk
to
a
package
manager.
Maintainer
x'
will
inform
this
imagining.
We
will
be
doing
a
lot
of
course
correction.
Once
we
have
people
with
the
knowledge
of
ipfs
internals,
more
kind
of
on-boarded
into
the
things
that
we've
got.
A
A
Direction
on
a
regular
basis
to
be
an
effective
way
to
like
thinking
about
the
end
user.
The
whole
time
will
be
something
that
will
be
front
of
mind
and
which
is
why
we
kind
of
put
the
key
result
as
maintain
there
should
kind
of
be
like
successful
and
it
there
should
be
like.
If
we
do
it
right,
people
will
start
to
mirror
stuff
and
we'll
be
able
to
like
track
that,
but
maybe
putting
a
key
metric
that
says
there
are
X
number
of
mirrors
is
kind
of
putting
the
wagon
in
front
of
the
horse.
I.
B
B
Just
the
data
point
is
like
getting
to
a
place
where
you
can
actually
measure
this
key
result
for
this
area
is
like
it
I
completely
agree
like
that's
what
we
should
be
aiming
for:
I,
don't
think
we
should
be
pivoting
somewhere
else.
I
just
think
that's
hard
to
measure,
and
so
looking
at
other
data
points
you
can
use
and
what
you
already
have
that
you're
using
to
drive
the
work
and
feeding
that
nadir
okay,
ours
could
be
really
useful.
B
Otherwise,
you
have
to
create
some
sort
of
pulling
mechanism
for
all
package
manager,
repository,
maintain
Ares
and
ask
them
these
questions
and
get
them
to
respond
and
to
get
them
to
have
a
delta.
Before
and
after
and
like
we're,
not
gonna.
Do
that
because
that's
overhead
and
we
have
engineering
work
to
do,
which
is
a
little
bit
folks.
A
How
we
can
do
that
right,
I
kind
of
imagined
me
being
a
proxy
of
the
maintainer
zazz.
Well,
I'm,
not
sure
if
that's
necessarily
a
good
idea,
but
definitely
kind
of
being
like
oh
I,
can
try
it's
our
mirror
again
and
again
and
kind
of
repeatedly
say:
I
didn't
have
a
good
time.
It
was
slightly
better
than
last
time,
but
it's
still
not
good.
C
B
A
If
anyone
else
wants
to
propose
a
topic
for
a
week,
then
maybe
throw
in
that
issue
as
well,
and
we
can
we
can
kind
of
iterate
on
how
we
do
these
meetings
on
a
weekly
basis
and
get
kind
of
more
of
a
community
summary
or
like
interesting
areas
of
kind
of
information
in
these
meetings-
and
we
can
maybe
like
hopefully
get
our
okay,
our
kind
of
things
into
the
the
weekly
review
area
that
we
have
I
think
there's
also
an
OPR
meeting
towards
the
end
a
week.
The
weekend
we
can
follow
up.