►
From YouTube: Package Maintenance Team meeting - April 22 2019
Description
A
A
A
A
Okay,
if
we
think
that
that's
good,
then
I
can
go
ahead
and
submit
it
and
I'm
not
sure
when
they're
gonna
announce
the
agenda
but
we'll
get
it
in
there
and
see
what
see
how
it
goes.
If
there's
any
thoughts
you
know
between
I
guess,
I'll
submit
it,
we
can
always
revise
it.
So
if
you
have
thoughts
or
things,
you
think
we
should
add
or
change
just.
Let
me
know:
okay,
so
I'm,
just
gonna.
Take
a
note
review
the
in
today's.
A
B
A
A
B
A
A
You
know
having
a
test
a
few.
The
things
I
had
in
mind
is
like.
If
we
can
get
to
the
point
where
more
modules,
you
can
just
run
NPM
tests
and
actually
check
the
output
like
check
the
results,
because
I
think
you
know,
we've
tried
to
run
the
tests
on
modules
and
it's
not
always
that
easy
to
actually
run
them
and
confirm
that
you
think
that
everything
is
okay,
mm-hmm
example
on
different
platforms
and
stuff,
like
that,
so
some
guidance
around
how
to
get
to
sort
of
a
you
know
a
package.json
or
something
like
that.
A
A
And
if
there's
anything
we
can
say
about,
the
output
like
I'd
have
to
look
more
at
the
different
ones
like
I.
Just
and
maybe
I
can
ask
the
some
of
the
people
on
the
team
who
was
doing
some
of
this
work.
What
the
challenges
were,
but
it's
kind
of
like
if
you
run
the
test,
but
then
there's
no
way
to
tell
whether
you
passed
or
failed.
That's
not
as
good
as
yeah.
It
clearly
reports
that
you
passed
or
you
failed.
You
know
now.
C
A
To
expect
that,
most
of
the
time
it
should
report
that,
but
it
seems
like
it
wasn't
always.
You
know
obvious
how
to
just
run
and
get
the
test
to
do
the
right
thing,
but
I
think
that
could
be
done
as
a
second
like
a
follow-on
PR
right
like
so.
This
could
be
landed
as
a
first
draft,
and
then
we
could
try
and
see
how
we
add
stuff
to
it,
so
that
make
sense.
Okay,
any
other
comments
or
people
have
comment,
suggestions
on
that
front.
A
A
A
A
A
A
A
Okay,
then,
the
next
one
innocent
number
113,
which
is
which
problems
do
OSS
maintain,
errs
authors
face
today.
Unfortunately,
we
don't
have
Matteo
this
week,
I
think
he's
sort
of
been
leading
that
one
we
were
hopefully
Wes
had
mentioned
that
he
was
going
to
work
on
answering
the
questions
from
express
as
well.
A
So
I
think
we'll
just
need
to
I,
don't
know
if
we
should
see
if
there's
some
way,
we
can
figure
out
how
to
help
Matteo
on
that
one,
because
it
seems
like
he's
pretty
busy.
So
if
anybody
has
time
or
thoughts
on
how
they
might
jump
into
that,
just
talk
to
one
of
us,
otherwise,
I'll
we
will
look
to
see.
I
mean
Wes
was
going
to
just
sort
of
ramping
back
up
and
hopefully
we'll
get
the
express
side
engaged
as
well.
A
A
A
C
A
D
C
D
Ran
a
scan
of
two
scans
of
of
some
basic
data,
so
just
wanted
to
point
out
that
which
asked
more
questions
there
so
that
we
can
run
more
scans
for
that
data.
But
just
the
two
examples
that
I
have
there.
One
is
the
age
of
the
last
release
of
a
package.
So
in
the
top
1000
we
have
around
40%
that
have
not
been
released
in
the
year,
which
could
be
a
proxy
to
which
versions
of
no
they
have
been
tested
and
then
I
chicken.
D
D
A
D
D
At
the
very
least,
there
should
be
PR
open
to
update
all
of
these
Travis
llamo
files
to
actually
run
tests
in
in
in
more
nodes
and
brain
in
the
more
recent,
because,
looking
just
by
the
activity
of
these
packages,
they
might
not
have
being
actively
testing
in
CI.
So
there's
there's
more
question
that
we
can
ask
from
from
from
from
that
data
right.
C
D
A
That's
a
good
one:
I
mean
we'd
started
some
discussion,
slash
work
around
some
tooling
that
we
would
have
to
let
package
maintainer
opt
into
that.
Would
then,
like
potentially
generate
PRS
for
certain
for
different
things.
Like
you
know,
one,
for
example,
was
like
the
package.
Sorry,
the
the
new
buffer
constructors,
but
but
this
would
be
another
very
good
example
of
that
is
like
okay.
D
That's
probably
something
that
is
important:
yep
business
and
I
wonder
if
there's
a
more
active
engagement
needed
there,
I
like
the
optin
into
into
automatic
a
breach-
that's
that's
yeah,
but
that
can
actually
be
implemented
as
part
of
renovate
or
greenkeeper
I
suppose
as
a
plug
in
there
or
something
like
that.
But
the
broader
aspect
of
it
all
getting
that
actual
piece
of
maintenance,
that's
and
and
I
wonder
if
there's
a
way
to
you
know
to
actually
move
forward
that
stuff
in
a.
D
A
Yeah,
like
basically
test
on
the
latest,
move
up
the
testing
see
if
it
works,
if
it
doesn't
try
and
submit
PRS
or
whatever
right,
yeah
yeah,
yeah,
yeah
I
mean
I
I
like
that
idea,
and
that's
a
good,
concrete
thing.
I
guess
the
question
would
be.
How
do
we
get
that
list
like
you've
got
a
I
guess
you've
got
some
data
which
is
generating
a
list
of
how
many
it's
like,
which
packages?
How
do
we
choose
which
packages
to
sort
of
list
as
the
the
ones
to
try
and
get
people
to
go?
Look
at
yeah.
D
A
D
D
A
D
D
D
A
Okay,
so
in
theory,
if
you
have
a
Travis,
you
have
all
your
that's,
possibly
how
you're
using
to
test
yeah
I.
Think
that's
a
that's
a
thing.
You
know
that's
a
concrete
thing.
We
could
and
probably
fairly
manageable.
So
we
could
ask
people
to,
you,
know,
pick
some
and
we
can
see
how
that
works
out
or
not
right.
A
D
A
C
Okay
I
was
gonna,
ask
about,
seems
to
be
talking
about
Travis
a
lot,
but
obviously
it's
not
the
only
continuous
integration
platform
do
we
have.
We
talked
about
this
and
any
other
issue.
I
kind
of
did
a
quick
scan
now,
but
nothing
came
up
of
predefined
templates
for
different
CI
platforms
that
we
can
share
as
part
of
this
initiative
like
if
we
have
here's
the
best
setup
for
Travis,
here's,
the
best
setup
for
circle,
there's
a
best
setup
for
scrutinise,
ER
and
so
on
and
so
forth.
C
A
I,
you
know
that's
kind
of
where
I
was
hopeful
get
to
under
the
testing
stuff.
That
Emily
was.
You
know
we
had
the
very
first
top-level
description,
but
it'd
be
nice.
If
that
would
then
go
into
and
here's
you
know,
here's
how
you
can
set
up
some
testing
fer,
you
don't
for
Travis
for
those
other
ones
you
mentioned,
and
along
with
that
would
be
template.
So
definitely
I
think
that
would
be
very
useful
for
people
it's
kind
of
like
okay,
I,
don't
have
anything
I'll
just
take
that.
That's
probably
great
right
is.
A
C
C
A
C
We
haven't
really
figured
out
a
better
approach
yet,
but
somewhere
where
businesses
can
at
least
signal
or
indicate
their
interest
or
their
usage
of
certain
things,
and
then
we
can
then
facilitate
for
them
mechanism
how
they
can
contribute
as
well
or
help
their
team
members
contribute
so
again,
I
think
that's
an
ongoing
conversation.
I,
don't
think
we
have
a
particular
path
there
yet,
but
this
would
be
a
perfect
example.
As
there's
an
initiative
already
going
on,
we
have
identified
of
list
of
Mac
packages
that
we
might
want
to
prioritize.
A
I've
only
been
thinking
like
just
to
incentivize
the
businesses
to
and
I
think
you've
mentioned
like
ways
to
help
them
understand
that
they're,
using
these
modules
and
therefore
hey,
they
should
be
contributing,
I
think,
that's
so
that
that
doesn't
actually
even
require
them
to
say
these
are
the
ones
we're
interested
in
just
for
them
to
go.
Wait
a
sec.
Maybe
I
should
get
involved
to
help
right.
C
So
from
that
lens,
there
was
a
visibility
problem
for
all
the
businesses
to
even
know
what
they're
using,
if
it's
not
a
direct
dependency
of
theirs
right,
there
might
be
hidden
nested
deep
in
some
dependency
tree
I've
built
some
tools
for
to
that
end.
I
think
I'm,
happy
to
demo
them
perhaps
next
time
in
this
meeting.
I
might
also
try
to
demo
some
of
them
at
the
Thursday
meeting,
if
I
have
enough
time
to
clean
them
up
but
yeah.
C
The
idea
is
that
any
tools
or
any
methods
for
bigger
companies
to
even
understand
their
dependency
tree
or
at
least
just
have
visibility
into
it,
would
be
a
mechanism
for
them
to
be
more
interested
in
and
kind
of,
leaning
in
and
helping
out
with
those
kind
of
projects,
because
a
lot
of
time
people
only
see
what's
in
their
dependency.
Direct
dependency
is
not
downstream
or
down
the
tree
of
dependencies.
D
D
D
There's
also
the
case
that
I
I
recently
spoke
to
somebody
from
snake
and,
and
it
was
a
an
unrelated
conversation,
but
what
they
mentioned
is
that
they
have
some
data,
and
that
shows
that
the
businesses
that
use
snake
they
scan
a
different
set
of
packages
than
what
you
see
on
NPM,
that
are
the
most
popular
packages.
So
the
packages
that
are
widely
used
in
the
community
are
different
from
the
packages
that
are
widely
used
in
a
commercial
context.
D
A
C
I
mean
you
all
see
my
screen
all
right.
This
is
a
very
rough
demo
that
is
terribly
written
code
to
apologize,
but
this
is
a
prototype
that
I
pulled
together
in
a
short
amount
of
time.
You
can
actually
use
it
yourself
if
you
do
trust
me
accessing
your
github
repos
with
a
github
application,
so
I'm
not
actually
scraping
data.
Its
dependencies.
Org
is
the
domain.
C
Basically,
you
log
in
you're
able
to
add
an
organization
on
github,
just
as
typically
with
the
installation
of
a
new
org,
as
you
probably
has
seen
this
workflow
before
I'm,
not
going
to
add
anyone
once
you
add
it,
it
goes
in
and
scans
all
your
dependencies
and
actually
scans
for
everything
across
package.json
yarn
that
lock
package
lock.
That
json,
I'm
even
started
to
add,
like
other
non
javascript
stuff
like
a
composer
to
json
and
ruby
gem
scanning,
and
all
that,
basically,
it
finds
all
the
repositories.
Here's
a
massive
mona.
C
We
put
that
I
have
and
all
the
declared
and
resolve
dependencies
on
it.
Here's
a
simple
one:
it
just
basically
scans
and
parses
your
package
of
json
Pat
and
package
lock
of
JSON
and
then
gives
you
puts
them
in
a
database
and
then
through
an
ugly
UI,
as
you
can
tell
it
gives
you
information
about
those
packages
and
their
versions
across
your
org.
For
example,
here's
tap.
C
Here's
in
my
org
aka,
my
user
account
in
this
case,
like
I,
said
my
UI
is
not
that
great
here's
all
the
declared
versions
and
all
the
resolved
versions
that
I
have
off
tap
under
github.com,
slash,
administering
and
here's
all
the
repositories
that
depend
on
it
again.
This
is
not
too
helpful,
but
it
gives
you
a
high
level
view
of
basically
every
dependency.
You
have
and
then
helps
you
drill
down
and
say:
okay.
Well,
maybe
I
should
go
fix
this
because
10.3
is
has
a
vulnerability
or
too
old
and
I.
C
Can
you
can
start
I
can
I
want
to
build
start
start
building?
You
are
like
reporting
you
eyes
and
dashboards
are
more
helpful
or
meaningful
here,
for
example,
top
use
packages.
I
use
yours
a
lot.
You
know
here's
all
the
versions
of
the
arc
that
I've
declared
and
the
ones
that
got
resolved
and
here's
all
the
repositories
that
depend
on
it.
C
That's
be
much
it
in
a
nutshell.
I
think
there's
also
another
view
for
advisories.
This
is
not
perfect
by
any
stretch
of
the
imagination
but
I
kind
of
pull
on
the
adviser
information
and
just
list
all
the
vulnerabilities
that
were
detected
based
on
the
version
matching
again
across
an
org.
So
the
reason
this
is
interesting
and
different
is
because
it
does
it
on
an
org
level,
as
opposed
to
a
repo
level.
I've
seen
a
lot
of
tools
where
you
know
per
project,
you
just
run
it
in
your
local
environment.
C
C
Injections
problems,
so
it's
org
dependencies
I
also
send
this
link
in
the
group
chat
here,
but
yeah.
This
was
really
fastly
put
together,
just
as
a
proof
of
concept.
It's
not
that
pretty
as
far
as
the
UI
goes,
but
if
you
guys
want
to
contribute
or
participate
as
I'm
trying
to
clean
it
up,
I
have
a
big
long
stretch
of
refactoring
already
going
on
for
the
app
to
make
it
more
strengthened
and
useful
for
securing
that
data.
C
D
C
C
So
yeah,
this
is
a
fun
project
for
me
that
I'm
working
on
again,
it's
not
limited
to
node
or
JavaScript.
It's
just
the
ideas,
parsing
any
sort
of
package,
declaration
or
dependency
declaration
and
just
putting
it
at
the
database
doing
some
level
of
helpful
UI
so
that
organizations
can
get
that
visibility.
That
was
just
talking
about
earlier,
because
I
didn't
know.
I
had
all
these
dependencies
in
there
just
use
some
certain
ones,
and
then
they
pulled
in
thousands.
A
C
A
A
Okay,
so
next,
like
in
terms
of
next
things,
demonicus
you're
gonna,
create
the
issue
that
shows
like
here's,
the
ones
that
don't
actually
don't
appear
to
be
testing
with
ten
and
I
haven't
looked
but
I
will
to
see
if
Mateo
had
put
together
a
board
like
he
was
gonna.
Add
some
board
entries
if
he
hasn't.
A
Maybe
we
should
you
know
dominic
us
you
should
you
could
take
a
look
to
like
what
we
want
to
do
is
figure
out
how
we
start
to
build
something
that
looks
like
a
backlog
that
we
could
then
make
the
call
to
all
the
members
and
saying
okay,
we've
started
to
put
things
on
the
backlog,
and
it
sounds
like
these.
You
know
check
if
ten
check,
if,
if
the
ten
is,
is
supported
and
run
the
test
see
if
it
works,
maybe
submit
a
PR
or
might
be
a
good.
A
D
A
Okay,
if
not
I,
think
that
will
be
the
meeting
for
this
week.
I'm
not
gonna,
be
able
to
make
the
next
meeting
I'm
away
sort
of
Monday
to
Monday,
so
I'll
miss
the
next
one
or
else
I'll
see
if
Matteo
is
available
to
to
chair.
If
not,
you
know,
I'll
open
an
issue
asking
if
somebody
else
can
can
do
that
so
well,
talk
to
see
you
and
work
with
you
through
github
in
otherwise
I'll
see
you
in
a
couple
meetings
from
now
Thanks
bye.