►
From YouTube: 📦Package Managers WG Weekly Sync March 12, 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
A
A
Icarly
tried
to
play
with
NPM
on
ipfs
and
found
you
had
some
problems
with
it.
Reliability,
wise
I,
think
he
came
across
an
issue
that
I
found
while
I
was
on
holiday,
which
I've
now
fixed,
which
is
about
how
how
we
construct
camp
shots
and
how
they
the
structures
and
changes
over
time
as
you,
edit
them.
A
C
We
have
ways
for
each
for
any
particular
package
method
to
be
able
to
do
some
of
those
things.
I
also
posted
an
issue
just
starting
the
conversation
about
publicizing
the
package
managers
working
group
and
making
the
either
the
repo
or
starting
a
fresh
repo
open
source
so
that
we
can
kind
of
have
a
bit
of
a
spotlight
for
package,
maintainer
x'
to
come
and
like
give
feedback
and
learn
things
and
contribute
directly,
rather
than
having
to
kind
of
have
this
like
public
conversations
and
private
conversations.
C
Because
everything
that
we're
doing
at
the
moment,
I
think
is
it's
fine
to
be
public,
as
I
wrote,
up
kind
of
a
absolute
laundry
list
of
every
possible
problem,
I
could
think
of
that
uses.
Package,
publishers
and
package
manager,
maintainer
x',
might
have
with
package
managers,
I'm
sure,
there's
things
that
are
missing
in
it,
but
I
thought
was
a
good
way
to
to
kind
of
look
at
the
problem
from
the
opposite
direction.
So,
rather
than
going
like,
oh
well,
what
can
we
what's
good
about?
C
Ipfs
that
we
can
bring
to
package
management
is
to
go
what
problems
does
package
management
have
and
what's
the
overlap
of
ipfs
features,
and/or
benefits
that
can
apply.
I
and
then
there's
a
whole
host
of
prioritization.
That
can
be
done
to
kind
of
go
like
this
things
here
that
really
help,
and
there
is
this
things
here
that
are
low-hanging
fruit
that
can
be
in
easily,
and
there
are
things
here
that
ipfs
can
have
no
impact
on
or
can
just
have
impacted
by
by
essentially
kind
of
kick-starting
conversations
that
then
can
lead
on
to
other
things.
C
And
then
I
actually
did
some
sis
ad
many
kind
of
stuff,
which
is
quite
outside
of
my
area
of
expertise,
but
it
went
fairly
well.
I
attempted
to
set
up
a
mirror
of
the
latest,
a
bun
to
apt
repository.
So
at
one
point,
two
terabytes
of
data
I've
got
a
machine
in
Paris
that
is
currently
are
syncing
things
on
a
regular
basis.
C
It
took
12
hours
to
add
one
point:
two
terabytes
to
ipfs
offline,
using
all
of
the
different
tricks,
I
found
on
different
issues
and
things
and
I
basically
wrote
up
almost
like
a
live
blog
on
the
issue,
with
a
number
of
outputs
of
different
terminal
kind
of
stats
for
the
machine.
It
didn't
look
like
it
was
doing
like
a
huge
amount
of
stuff
like
it
certainly
wasn't
pegged
on.
C
C
Whilst
another
arcing
kicks
off,
because
you'll
end
up
in
a
situation
of
kind
of
like
two
different
updates
at
the
same
time,
which
might
involve
building
something
cleverer
to
kind
of
schedule,
those
things,
but
probably
it
needs
to
be
faster
and
then
I
thought
I.
Do
I
also
tried
out
the
Badger
file
store
that
someone
suggested
that
ended
up
taking
18
hours
rather
than
12
hours,
which
was
really
surprising,
but
on
the
resync
it
did
have
the
same
error,
but
it
it
did
everything
that
didn't
error
went
through
in
less
time.
C
So
that
was
an
interesting
kind
of
aside
and
then
I
did
the
same
thing
for
a
much
smaller
repository,
because,
like
okay,
well
is
this.
This
is
a
problem
with
gigantic
ones.
I
picked
the
closures
repository,
which
is
the
maven
repository.
They
have
it
rsync,
which
is
convenient
for
a
copy
in
those
things
down
comes
to
about
60
gigs,
but
has
many
many
more
files
in
it.
I
think
it's
like
1.6
million
files
or
something
much
smaller
files,
but
just
lots
more
of
them
that
took
18
hours
as
well.
C
So
that's
something
like
20
times
slower
for
the
like
I
assumed
the
if
it
based
just
on
size.
The
closure
repository
is
20
times
smaller
than
the
apt
one.
It
maybe
would
take
20
times
less,
but
it
did
not
same
amount
of
time
but
the
redo.
So
we
are
synced
in
five
hundred
new
files
that
took
eight
minutes
the
third
time
around
that
I
ran.
It
is
25
minutes
for
it
and
then
like
it
continues
yet
faster
on
doing
this.
C
I
file
kind
of
and
what
proms
are
there
blocking
people
from
using
it?
My
internet
may
be
a
bit
rubbish
and
I
also
had
a
call.
Last
night,
with
Todd
gambling
of
the
SPAC
panic
package
manager
who
works
at
Lawrence,
Livermore
Lab
in
the
supercomputer
department,
so
massive
massive
computers,
and
was
he
was
quite
interested
in
seeing
how
they
can
add.
Ipfs
in
SPAC
is
actually
designed
based
off
homebrew.
So
it
actually
looks
a
lot
like
homebrew.
C
So
the
experiment
that
I
did
a
couple
weeks
ago,
maybe
to
add
ipfs
spot
homebrew,
could
be
easily
replicated
with
back
it's
written
in
Python
rather
than
Ruby.
But
it's
it
has
different
transport
supports
already.
So
it's
it's
very
similar
and
the
thing
that
I
found
that
was
the
first
call
I've
had
with
a
package
manager.
C
Maintainer
I,
had
to
spend
a
lot
of
time
getting
him
up
to
speed
on
the
basics
of
ipfs,
and
so
that
feels
like
I
need
to
put
together
a
primer
or
some
kind
of
specific
documentation
around
like
here
are
the
parts
of
the
ipfs
that
are
relevant
to
you
as
a
package
manager
maintainer
before
we
talk.
So
that
you
can
kind
of
get
people
up
to
speed
and
then
talk
about
the
stuff,
that's
specific
to
them,
rather
than
just.
Let
me
try
and
explain
ipfs
when
I,
don't
necessarily
have
the
best
working
knowledge
of
that.
C
No
not
yet
it
I
there's
a
couple
of
people
that
got
CC
doing
that
on
that
thread
and
had
commented
and
given
some
tips
and
I've
been
kind
of
retrying
with
different
options,
but
there's
definitely
like
more.
There
I,
just
not
fully
aware
of
what's
a
bug
and
what's
like
expected
behavior
at
this
point,
Jim
so.
C
C
F
Performance
of
course,
that
I
understood
cranking
out
as
well
and
I
think
they're
very
interesting,
but
to
get
to
the
point,
it's
extremely
actionable
stuff
for
the
go
team
will
be
deterred
on
some
more
like
profiling.
Flags.
A
little
bit
actually
like
here
are
the
functions
that
have
been
taking
a
lot
of
time.
F
C
That
was
a
pretty
cheap
machine
as
well.
That
was
the
the
cheapest
one.
I
could
get.
That
was
fairly
mid
to
me
with
enough
disk
space
to
fit
a
whole
mirror
plus
I
wasn't
sure
how
big
the
ipfs
directory
was
gonna
end
up
as
actually
it
was
quite
small
I
think
it
was
just
2
point
4
gigabytes,
so
it
wasn't
like
I
had
to
duplicate
everything,
which
is
the
problem
that
one
of
the
original,
a
bunch
of
community
people
had
last
year
was
like.
C
Oh
I
need
double
or
triple
the
disk
space
to
be
able
to
do
this,
but
some
of
the
changes
in
since
that
has
happened
has
made
it
so
that
the
disk
space
isn't
a
problem,
but
the
time
it
takes
to
run
is
still
the
critical
thing
there.
I
can
also
like
that
server
is
not
doing
anything.
I
can
give
anyone
else
access
to
it
if
they
would
like
to
have
a
play
around
or
I
can
just
like.
C
The
issue
has
all
the
scripts
to
be
able
to
run
it
yourself
on
any
machine
without
any
particular
setups,
but
it's
the
kind
of
like
digitalocean
style,
spin
up
a
droplet
and
try
and
run
a
mirror
rather
than
try
and
do
custom
hardware
or
raid
configurations
and
see
like.
If
you
can
make
the
machine
fit
to
ipfs.
We
should
definitely
be
going
the
other
way.
G
C
G
C
C
I'm
also
going
up
to
London,
Thursday
and
Friday
this
week
to
hang
out
with
Alex
and
Ollie
and
maybe
Alan,
if
he's
around
all
in
the
same
place.
So
that
would
be
good.
Some
high
bandwidth
conversations,
hopefully
getting
more
of
the
kind
of
shake
out
what
we
can
list
out
as
ways
for
other
working
groups
to
to
think
about
how
they
can
like
support
some
of
these
things
or
enable
more
stuff.
H
H
Think
both
getting
getting
more
of
this
information
out
in,
like
small
updates,
but
also
kind
of
more
holistically,
as
we
think
about
q2
and
the
chunks
of
work
that
we
should
be
taking
on
inside
the
Go
ipfs
team,
the
ipfs
cluster
team,
the
jsf
fest
team,
making
sure
that
there's
like
a
read
out
of
like
actionable
here
are
things
that
we
really
need
to
work
on
and
improve.
Like
all
of
this,
insight
that,
like
adding
to
ipfs,
needs
to
be
way
faster.
H
If
this
is
going
to
be
usable,
like
those
sorts
of
insights,
we
should
make
sure
they're
like
communicated
out
and
that
we
have
like
chunks
of
work
that
we're
prioritizing
within
these
different
working
groups.
So
maybe,
when
the
crew
of
you
guys
are
together
on
Friday
prepping,
some
sort
of
like
readout
that
the
other
working
groups
can
consume
and
use
in
planning
for
q2
would
be
super
super
useful,
and
we
can
you
know
we
can
schedule
an
hour-long
presentation.
A
E
Following
up
on
Molly's
point,
I
think
but
then
again
feel
free
to
discard,
but
like
having
some
kind
of
horizontal
laid
out
tree
where
you
have
these
multiple
requirements
right,
like
they're,
being
able
to
loathe
this
specific
data
set
in
less
than
one
hour
versus
twelve
being
able
to
update
a
name
in
West
and
ten
seconds
like
this,
it's
kind
of
like
requirements
that
are
like,
like
it's
almost
as
important
for
the
white,
because
team
to
understand
exactly
what
the
package
managers
are
doing.
It
is
important
for
the
very
first
team
and
Jesse.
E
They
seem
to
understand
what
are
the
expectations
from
these
use
cases
things
that
they
can
control
very
well
things
that
they
can
benchmark
for
things
that
they
can
test
for
etcetera
and
the
reason
why
I'm
saying
I'd
be
sorry
total
tree,
because
you
can
think
of
as
kind
of
like
boxes
get
checked.
You
kind
of
like
meet
new
milestones,
and
these
milestones
might
be
okay.
E
E
The
most
important
thing
is
this
list
of
requirements
like
what
do
these
groups
working
groups
need
to
achieve
in
order
for
you
to
be
able
to
do
this
in
the
package
when
they
go
sit
and
say
we
are
ready,
right,
go
for
it
like
try
it
try
it
out
without
fearing
it
they
might
fall
on
the
ground.
At
the
first
run,
you.
A
C
Each
group
has
a
documentation
element
to
it,
but
trying
to
get
and
trying
to
like
transpose
that
over
to
someone
else
be
like
here's
all
of
the
different
pieces
that
you
should
care
about
in
relation
to
making
this
work
is
currently
takes
like
days
to
be
able
to
load
everything
into
your
brain
to
be
able
to
like
go.
Oh
ok,
I
understand
this
universe
enough
now
to
be
to
see
how
I
can
I
can
model
or
how
I
can
work
around
the
fatigue.
There.
E
E
In
what
I
would
suggest
there
is
definitely
we
need
to
improve
documentation
in
something
that
the
project
as
part
of
its
roadmap,
to
like
really
tackle
this
year
and
not
only
like
improve
the
condition
once
but
actually
like
we
want
to
do,
is
create
a
support
structure
to
keep
improving
the
documentation
over
time.
Something
like
it
has
been
unclear
what
responsibility
lens,
but
I
yeah.
We
will
get
there.
My
recommendation
to
support
these
use
case
and
this
work.
E
He
is
really
drive
it
by
blog
post,
like
people
will
not
have
the
time
to
read
every
single
IP
aspect.
They
will
not
have
the
time
to
read.
Do
you
like
see
every
single
YouTube
video,
even
if
we
index
them
all,
and
even
if
we
like,
rewrote
the
documentation?
It
was
just
like
be
too
large,
but,
like
writing.
Some
like
5
to
10
blog
posts
that
like
break
it
down
about
all
the
package
managers,
can
adopt
ipfs
I,
like
basically
answering
their
questions
right
and
you
as
your
question,
your
questions.
E
H
Thank
you
that
I
think
I'm,
there's
there's
opportunity
here
too.
It's
kind
of
like
it's
the
lens
of
how
do
these
things
work
together
for
these
sorts
of
of
use
cases
and
like
the
the
metadata
that
should
an
ideally
would
live
a
documentation,
but
can
be
really
targeted
for
a
specific
audience
in
in
kind
of
like
these
how-to
guides,
and
actually
a
lot
of
these
aren't
even
documentation.
We
maintain
all
the
time
there.
H
There
are
like
in
your
like
step
by
step
occupation
that
sometimes
are
like
confusing
to
people
and
don't
have
all
of
the
right
information
so
to
the
extent
that
we
can
create
kind
of
canonical
guides
on
how
to
do
these
things.
Yes,
we
should
go
and
update
documentation
when
we
find
that
it
is
confusing
people-
and
we
should
be
chatter
about
that,
but
I
think
also
just
plan
to
produce
more
kind
of
tutorial
style
guides
for
people
to
do
things
in
the
package
manager
space
in
particular,.