►
From YouTube: 2022-06-21-Package Maintenance Team meeting
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
The
first
thing
is
session
at
the
collaborator
summit.
Well,
the
club
assignment
is
over,
so
I
think
we
can
close
that
one
out.
A
It
was
quite
good,
I
I
would
say
you
know,
given
there
were
fewer,
you
know
it
wasn't
as
big
a
conference.
I
think
because
of
you
know,
people
are
still
recovering
from
covet
and
being
willing
to
travel,
but
the
I
think
like
in
the
rooms
and
blue,
can
correct
me
if
I'm
wrong,
but
I
think
there
was
like
40
people
or
so
in
terms
of
the
collaborator
summit
sessions,
which
I
thought
was
quite
good.
A
You
know,
given
that
we
wouldn't
have
had
as
many
people
as
we
might
normally
have
had
so,
and
we
had
some
really
good
discussions
on
some
of
the
next
ten
there's
a
couple
good
deep
dives.
There
was
a
nice
discussion
on
typescript,
some
of
the
things
and
sort
of
types
that
we
should
do
some
good
stuff
around
tooling.
A
A
Luke
was
there
any
other
things
that
you
can
remember
that
highlights
that
I
missed
there.
I'm
sure
there
are
a
couple.
C
A
So
but
yeah,
I
think
that
went
well
and
the
other
related
thing
is.
You
know
we
are
talking
about
doing
one
along
with
node
coffee,
you
probably
a
few
days
before
the
conference,
and
you
know
in
devil
and
so
for
a
little
bit,
it'll
be
the
one
that's
a
little
more
friendly
to
people
in
europe.
So
maybe
we'll
see
other
people.
There
then.
A
A
A
A
Right,
okay,
so
basically
we
there
was
some
questions
and
lj's
added
support
info
for
some
of
his
packages,
which
is
great,
and
I
guess
I
need
to
do
a
publish
of
pkgs
support.
So
I'll
put
take
myself
a
note
to
do
that.
A
A
A
Right
so
that
one,
I
think,
since
we've
got
a
bunch
of
time,
maybe
we
should
discuss
this
one
and
figure
out.
You
know
what
we
should
do
or
not
do
on
that
one,
and
and
does
that,
make
sense
to
people.
A
D
Yeah
I'm
looking
at
it
now,
so
that
appears
to
be
the
case.
I
forgot
about
it,
but
it's
a
good
thing.
I
wrote
it
down
yeah,
I
think
the,
but
I
guess
for
context
for
anybody
new
to
the
issue.
If
it's
worth
just
grounding
that
was
well,
the
original
post
was
promoting
a
or
advocating
for,
I
guess
a
modernization
we'll
define
modernization
later,
but
a
modernization
like
audit
of,
I
guess
specifically
top
packages,
influential
packages.
D
D
So
there
wasn't
a
whole
lot
of
and,
as
I
think
jordan
pointed
out-
and
I
think
others
as
well
looks
like
beth
was
in
there,
but
I
think
her
to
my
latest
comment
was
more
or
less
the
takeaway.
From
our
last
conversation
as
a
team
was
you
know,
maybe
you
know,
I
think
we
agreed
that
modern
was
fairly
subjective,
but
that,
if
you
maybe
looked
at
it
from
the
perspective
of
kind
of
risk,
it
could
be
a
little
more
objective.
D
You
know
sure
batches
you
know
in
the
browser.
Fetch
is
fun,
but
you
know,
unless
someone
actually
takes
away
xhr
still
use
it,
you
know,
might
not
be
able
to
do
more
things
than
fetch,
but
if
it
only
does
the
one
thing
you
need,
you
know,
was
you
know
so
anyway?
I
guess
the
the
kind
of
the
takeaway
is,
you
know,
what
does
modern
mean
and
you
know
should
some
you
know.
D
Is
there
a
criteria,
that's
relevant,
maybe
at
least
in
the
context
of
this
group
or
just
in
general,
and
is
there
maybe
a
better
metric
or
indicator
of
you
know,
or
I
guess
ultimately
I
think
what
they
were
trying
to
get
at,
and
this
is
where
we
can
open
up.
The
conversation
was,
you
know,
maybe
more
around
maintenance
per
se.
I
guess
I
mean
that's,
certainly
a
risk,
I
suppose
is
kind
of
where
it
kind
of
comes
back
to
is
yeah
a
project.
D
That's
unmaintained
is
potentially
more
risky
because
certain
vulnerabilities
and
its
dependencies
haven't
been
updated.
You
know
not
that
it's
using
you
know
hdp
versus
fetch,
but
I
think
it's
still
worth
a
conversation
here.
You
know,
maybe
in
some
cases
there
are
apis
that
are
very
you
know,
funny
or
leaky
and
you
know
have
been
superseded.
Like
you
know,
maybe
some
could
make
a
really
great
case
for
not
using
date,
whatever
you
know
so
anyway.
I
guess
I'll
just
put
a
pin
in
it
and
the
point
was
to
talk
about
it,
so
I
should
stop.
A
I
know
like
at
red
hat.
We
have
some
stuff
we've
worked
on
and
I
suspect
that
you
know
maybe
owen
where
you
work,
there's
something
and
maybe
dominicus.
A
I
wonder
if
like
trying
to
set
like
trying
getting
broader
input
and
say
like
hey,
we
think
you
know
one
of
these
things
is.
We
think
this
is
an
interesting
topic.
A
A
D
I
mean
maybe
not
to
just
yeah,
totally
eliminate
kind
of
like
one
category
of
evaluation,
but
you
know
perhaps
michael
you
might
have
a
really
good
insight
is.
Are
there
legitimate
cases
where
at
api,
either
in
like
node.js
or
just
javascript
or
something
like
is
literally
like
please,
like
from
all
of
us?
No
one's
ever
going
to
fix
it?
It's
a
giant
security
hole
like
you
know,.
D
A
You
know,
like
request,
is
one
where
it
probably
works.
You
know,
could
still
work
fine,
but
it's
it
is
deprecated
and
the
maintainers
basically
said
move
to
something
else
right.
So
that's
one
of
the
checks
that
we
use
for
sure
is
to
look
for
things
doesn't
mean
that
it's
like
okay,
that's
a
problem
immediately,
but
there's
a
number
of
different
things
that
you
know
you
can
look
at
in
terms
of
that
kind
of
risk.
A
A
D
I
mean,
I
think,
you're,
I
liked
what
you're
saying
earlier
about
maybe
kind
of
crowdsourcing
the
valuation
strategies
or
kind
of
the
the
signals
that
others
use
in
terms
of,
like
you
know,
if
there
is,
you
know,
seems
like
the
most
likely
course
of
action,
at
least
within
this
group
is
to
at
least
document
whatever
is
shared
and
worth
preserving
and
yeah.
I
guess
well,
for
instance,
like
the
way
that,
well
I
mean,
I
guess,
yeah.
D
Ultimately,
I
guess,
as
it
comes
down
to
technology
or
something
else
like
the
way
that
socket
is
analyzing
dependencies
in
terms
of
like
hey
a
post-install
script
was
added
on
a
patch
release.
That
seems
really,
you
know
different,
or
you
know
this,
and
on
top
of
that,
the
owner
changed
since
the
last
release-
and
you
know
things
like
that,
so
yeah.
A
Yeah,
like
I
think
those
are
like
trying
to
do
short-term
analytics,
you
could
see
similar
like
some
of
the
similar
kinds
of
things
I
think
we
do.
Is
we
try
and
look
at
like
how
many,
how
active
has
the
project
been
over
the
last
x
months
right
and
that
doesn't
mean
that
it's
bad,
because
it
could
be
perfectly
fine
if
there's
no
updates,
but
maybe
it's
something
you
should
consider
right
and
similar.
A
You
know
because
it's
similar
like
if
the
owners
changed,
that's
that's
sort
of
like
if
it
changed
a
year
ago,
you
don't
care
so
much,
I'm
just
thinking
like
there
are
maybe
like
mirrors
of
each
other.
One
is
more
like
over
time.
The
trend
versus
short
term,
the
short
term
ones,
are
probably
more
security
related
versus
the
well.
It's
no
longer
you
know.
If
you're
going
to
choose
a
new
package,
would
you
choose
it
or
not?.
A
B
B
Then,
of
course,
there's
the
existing
vulnerabilities
and
potential
vulnerabilities
potential
vulnerabilities
are
only
an
issue
for
things
that
you
may
consider
as
unmaintained
and
they
may
or
may
not
happen
so
yeah,
that's
the
risk
assessment
right,
but
they
don't
really
like
hurt
anything.
There's
been
some
cases
in
a
very
recent
past.
B
I
think
in
the
past
few
months
where
there
was
an
issue
in
some
very
old
modules
who
everybody
thought
wasn't
maintained
and
just
assumed
that
it's
not
going
to
happen,
the
maintainer
stepped
up
and
released
a
patch,
and
you
know
so
making
all
of
these
assumptions
before
they
happen
is
a
little
bit
unfair
as
well
like.
In
some
cases.
These
modules
are
just
they
are
not
maintained.
Yes,
they
no
longer
receive
updates.
B
They
no
longer
receive
modernization,
maybe
because
they're
done,
maybe
because
there's
people
who
like
old
school
javascript
without
promises
and
costs,
and,
let's
arguably
and
there's.
A
B
B
Arguably
they
they
could
be
more
right
than
us
in
certain
respects
and
in
some
cases
they're
just
done
with
it,
and
but
that
doesn't
mean
that
the
module
will
become
vulnerable
in
the
future.
So
I
mean
that
plays
a
part
into
your
risk
assessment,
of
course,
but
recommending
such
a
module
as
this
group
or
recommending
somebody
that
they
don't
use
a
module.
As
this
group,
I
think
the
question
is:
are
there
things
that
are
better?
B
Of
course,
the
core
now
has
things
built
in
right?
There's
the
cli
parser,
there's
so
yeah
so
like
for
these
potential
things
potentially
and
maintained
modules,
which
may
potentially
not
receive
security.
Updates,
it's
hard
to
judge.
We
shouldn't
then
there's
the
deep
dependency
trees,
and
this
is,
I
guess,
by
nature
of
node.js.
They
are
deep
because
we
like
small
modules
and
that
obviously
means
that
there's
potential
for
one
of
those
to
just
slip
in
something
that
already
exists.
B
But
when
I
did
my
scan,
I
hadn't
done
the
scan
recently,
but
in
the
top,
1000
went
back
way
back
when
three
years
ago,
so
maybe
it
has
changed
right,
there's,
obviously
new
vulnerabilities,
although
from
what
I've
seen
on
our
internal
scans
in
the
like
really
popular
modules,
the
top
1000
their
npm
audit
does
not
report
much
on
like
if
you
scan
them.
If
you
scan
their
latest
versions
now
whether
people
are
using
these
latest
versions.
B
Internally,
that's
another
question
whether
the
deep
dependency
trees
are
using
these
the
latest
versions,
that's
also
but
like
it
was
like
across
all
the
1000.
There
was
less
than
10
vulnerabilities
reported
by
audit
right.
So
in
terms
of,
and
even
then
you
could,
you
know,
there's
always
the
base
like.
Is
this
regex
ddos?
Does
it
really
matter
because
right.
B
B
Yeah,
so
I
don't
know,
I
guess
I'm
just:
are
they
unsafe
yeah?
That's
what
I
mean.
I
think
what
I
hear
dummy
says
if
they're
not
reporting
vulnerabilities
now,
and
we
cannot
say
that
they
will
have
vulnerabilities
in
the
future,
and
we
cannot
say
that
the
maintainer
will
not
address
those
vulnerabilities.
Then
right.
B
There
is
a
problem
with
the
big
dependency
tree
when
you
have
something
very
deep
which
depends
on
an
old
module
and
because
we're
using
small
modules
and
everything
and
the
the
upgrades
do
not
necessarily
bubble
up,
and
that
is
a
bigger
problem.
But
then,
like
the
best
that
you
can
do,
is
if
it's
a
big
module,
then
you
need
to
fork
away
and.
B
A
B
A
A
A
B
A
B
B
Yeah
so,
but
I
think
that
where
we
could
focus
on-
and
I
think
I
said
in
the
past-
is
making
it
easier
to
fork,
making
it
easier
to
maintain
the
forks
against
the
upstream
and
like
as
a
holistic
approach
right,
making
it
once
again
as
a
community
effort,
maintaining
some
sort
of
a
risk.
B
B
I
think
cyprus
are
maintaining
their
own
request
form
and
what
they're
doing
is
whenever
a
vulnerability
is
in
request,
they're,
just
removing
features
which
they
don't
need
right,
but
it
is
yeah
like
these.
Some
of
these
features
are
pretty
obscure
better
than
adding
more
exactly,
and
I
mean
it
works
and,
and
they
take
away
the
vulnerability
as
they
make
the
scanners
happy.
And
but
how
do
you
highlight
all
of
these?
How
do
you
bubble
up
the
fact
that
this
fork
exists
and
it's
a
drop
in
fork.
A
B
You
use
a
certain
you
know
list
of
features,
maintaining
that
kind
of
a
library
maintaining
a
list
of
easily
drop-in
droppable
alternatives
like
if
you're,
switching
from
request
to
fetch
or
to
from
request
even
to
axios.
You
need
to
do
work
right,
but
the
cyprus
request
fork
is
mostly
drop
in
it's
it's.
The
good
old
request,
with
just
some
vulnerable
paths
removed.
B
This
is
not
a
an
endorsement.
I
haven't
looked
at
the
code.
I
just
stand
what
it's
trying
to
do
right
may
or
may
not
be
true.
Please
correct
me
somewhere
in
the
comments
or
in
the
issue,
if
I'm
wrong,
but
the
if,
if
if
it
were
true
that
that
is
a
good
way
of
doing
right
in
case
of
request,
we
know
that
it's
not
going
to
receive
patches
in
case
of
some
other
modules
they
may
receive
fixes
in
the
future.
When
the
maintainers,
you
know.
B
Want
to
go
back
to
maintaining
it
more
full-time,
and
in
that
case
you
do
have
an
issue
that
you
know
these
forks,
maybe
ideally
grow
back
together
and
you
know,
but
maintaining
all
of
these
distributed
forks.
I
think
that's
that's
the
right
approach
to
addressing
this
and
and
in
a
commercial
setting.
B
A
A
A
D
D
You
know
forking
or
you
know
a
lot
of
this
stuff?
Is
there
so
I'm
wondering
if
it's
a
just
a
matter
of
saying
hey.
This
is
a
good
idea.
We
have
documentation
already.
Do
you
have
some
suggestions
like?
Are
there
tips
tricks
non?
You
know
tip
the
scales
types
of
recommendations,
like
basically
from
your
point
like
like
hey.
D
What
do
you
use
when
evaluating
a
package
if
it's
not
in
the
document
open
a
pr
or
something
like
that?
Basically
right
based
on
so
you
know
any
of
the
in
any
of
these
situations.
We
would
just
keep
updating
that
dot
because
it
does
hey
it's
for
package
authors
to
actually
deprecate,
but
a
lot
more
of
it
is
actually
kind
of
more
from
the
consumer
perspective.
D
So
maybe
just
sharing
that
and
just
iterating
on
that.
With
these
additional
hints
signals,
you
know
experiences
whatever,
without
actually
calling
out
any
one
particular
package
or
whatever.
So
maybe
that's
a
way
to
kind
of
help
them
get,
or
at
least
kind
of
you
know,
get
their
thoughts
on
paper.
So
we
can,
you
know,
have
like
a
concrete
discussion
about
these
things
because
yeah
it's
a
dominance,
dominic's
point.
If
it's
doing
what
it
needs
to
do
now,
it's
not
sending
off
a
bunch
of
alarm
bells.
D
You
know
can't
pre-cog
what
the
maintainer
is
gonna
do,
but
for
the
time
and
place
so
yeah,
my
plus
one
is
to
steer
the
conversation
into
seeing
if
we
can
update
or
add
to
that
doc
because
it
seems
like
it
has
a
lot
of
what
you
know
has
been
brought
up
in
that
issue
already.
So
you
know
the
best
to
build
on.
A
You
know
I
see
right.
Okay,
so
would
you
want
to
comment
in
you
know,
add
a
comment
then
to
the
issue,
and
you
know
maybe
we
close
it
at
that
point.
Is
that
I'm
just
trying
to
think
like
what's
our
closure
on
on
this
one
we've
had
it,
we've
had
a
number
of
discussions.
D
Yeah,
I
would
say,
comment
and
then
give
them
another
meeting
cycle
to
see
if
they
reply
or
have
any
feedback
or
and
then
we
could
just
close
and
say
yeah
we're
closing
this
issue,
but
that
shouldn't
stop
you
from
wanting
to
contribute
or
share
this
document
and
have
other
people
contribute
to
it.
So
yeah,
I'm
happy
to
comment,
I'd
say:
leave
it
open
for
another
meeting
cycle
and
you
know
either
way.
I
think
part
of
it
is
just
you
know,
we're
all
kind
of
reminded
that
it's
there.
D
So
if
it
does
come
up,
hopefully
we
can
be
like
oh
great
yeah
check
this
out
and
you
know
go
from
there.
Okay,
again,
they
might
be
more
on
the
they
might
be
specifically
calling
out
things.
So
you
know
I
guess
it
depends
on.
If
they're
you
know,
I
haven't
seen
them.
D
Yeah,
so
I
think
that'll
be
good.
I
think
part
of
it
will
be
just
help
understand
if
you
know
where
they
kind
of
where
their
opinion
lies.
If
they're
more
into
like
actually
picking
winners
and
losers
or
if
they're,
you
know
happy
to
you
know,
go
on
a
more
a
less
more
objectively
but
yeah
either
way
I'll
I'll
comment
and
let
him
know.