►
From YouTube: Package Maintenance Team meeting - Oct 8 2019
Description
A
Okay,
so
welcome
to
the
nodejs
community
package
maintenance
team
meeting
for
October
8
2019
will
follow
the
agenda,
which
was
in
the
issue
in
the
repo
it's
issue
number
264
in
case.
Anybody
wants
to
open
that
up
and
follow
along
before
we
get
going.
Does
anybody
have
any
announcements
or
news
that
they'd
like
to
share.
A
A
B
A
B
A
B
A
A
B
A
A
There
were
a
number
of
different
sort
of
bike
shedding
ones
to
made
so
ad
hoc
as
available
no
committed,
no
well
SLA
good
intentions,
trihard
willing
open
time
permitting.
There
was
a
suggestion.
Maybe
we
needed
to
be
careful
because
and
I
and
the
original
PR
was
a
suggestion,
because
best
effort
was
actually
a
term
used
in
legal
wording,
so
we
did
make
a
request
to
the
foundation
for
some
advice.
A
A
A
D
B
B
There
is
well
so
optic,
the
the
the
the
the
small
proof
of
concept
that
we
built
is
sort
of
okay.
The
problem
with
it
is
trust,
there's
two
levels:
there's
one
is
trust
and
the
other
one
is
it
needs.
It
relies
on
firebase,
which
means
you
need
to
have
a
server
and
you
need
to
maintain
it,
and
that
includes
cars,
so
I
wouldn't
want
to
run
it
myself.
B
I
run
on
my
personal
server,
but
you
know
that's,
obviously,
that's
something
you
want
to
talk
to
the
community,
but
also,
if
some
randos
start
running
it
and
asking
people
to
use
it.
There's
the
case
that,
even
though
it's
open-source
you
don't
know
what
it's
doing
with
your
tokens,
so
there's
a
bit
of
a
trust
aspect,
so
I'm
thinking
of
collecting
some
information
of
companies
that
already
do
some
other
things
and
trying
to
reach
out
to
them
whether
they'd
be
willing
to
provide
something
similar
as
a
service.
So,
for
example,
do
all
mobile.
B
They
do
have
remote
approval
with.
Basically,
you
get
notification
and
an
apple
button
in
your
phone.
They
provide
that
as
an
API,
whether
it
comes
back
as
an
OTP
or
something
else
that
you
know
to
be
discussed,
but
there's
other
companies
working
in
in
the
in
that
space
and
they're
sound.
Those
are
very
involved
in
open
source,
which
is
all
zero,
so
I'll
see
if
there's
ways
to
reach
out
to
those
I
think
these
aren't
the
paths
that
I
will
be
pursuing
for
that,
but
yeah.
B
D
A
A
A
E
F
Yeah
and
I
sort
of
looked
at
that
I
did
watch
I
wasn't
able
to
join
when
I
brought
that
case
up
it's
very
valid
for
sure.
But
at
some
point
you
do
access
the
package
so
at
some
point,
you're
kidding
around
the
firewall.
So
hopefully,
if
there
was
a
secondary,
unnecessary,
secondary
HTTP
request
required,
then
you
would
be
able
to
make
that
happen.
If
you
needed
that
we
had
a
10:00
p.m.
we
started
doing
an
open,
RFC
call
very
similar
to
these,
and
we
had
a
bit
of
a
discussion
which
I
think
West
joined
I.
F
Think
two
weeks
ago
around
this,
because
the
discussion
has
happened
in
three
or
four
different
places.
I
know
this
is
primarily
I,
think
where
it
should
reside
and
some
of
the
thoughts
that
I
started
to
formulate
around
the
speckies
is
today
and
I
haven't
had
time
to,
or
last
month
haven't
had
time
to
go
back
and
put
that
feedback
into
the
actual
I
guess
the
actual
talk,
but
it
seems
like
the
schema
as
it
stands.
Phase
is,
is
like
threefold.
F
It's
trying
to
do
three
different
things
which
is
making
it
very
contentious
in
lots
of
different
areas.
One
is
it's
trying
to
set
up
a
funding
mechanism
and
then
identify
existing
funding.
Backers
right.
Another
is
its
tried
to
who
creates
an
SLA
between
the
package
maintainer
and
the
consumer,
and
then
the
third
is
I
think
I
had
it.
There
was
a
third
which
I
was
like
it.
Just
seemed
like
there
was
like
three
different
options.
F
A
Engines
is
basically
at
least
my
understanding.
This
is
what
it
will
run
with.
The
target
is
intended
to
communicate
more
future.
Looking
like
these
are
what
we
will
run
on
going
forward
right
so
target
you
know,
target
is
like
you're
gonna
get,
it
runs
on
ten,
it
runs
on
eight,
it
doesn't
run
on
seven,
whereas
the
target
is
intended
to
communicate
the
information
more
about
what
you
plan
to
support
like
LTS
like
I'm,
going
to
support
all
the
LTS
versions,
or
so
the
engines.
B
A
In
and
that
doesn't
really
work,
because
fourteen
will
be
a
current
first
and
you
may
not
support
it
as
the
current
yeah.
That
is
true,
Islam
like
if
you
look
at
the
the
description
and
probably
a
scenario
where
still
needs
more
explanation,
but,
like
those
are
more
they're,
not
like
a
concrete
list,
we
did
include
a
sender
list
only
because
you
know
people
wanted
multiple
combinations,
but
the
intent
is
is,
is
to
have
the
more
fuzzy
ones
which
are
like
I
want
to
support.
A
All
of
them,
which
are
any
any
LTS
ever
is
what
my
plan
is
to
support
or
I'll
support
the
LTS
and
the
currents
like
so
that
when
people
look
at
the
package,
they
know
where
they
can,
they
can
it's
going
to
be
there.
The
plan
is
to
support
it
and
you
know:
does
that
fit
with
their
upgrade
cycle,
those
kinds
of
things,
so
it's
it
was
intended
for
a
definitely
a
different.
B
Purpose
and
there's
also
the
case
that
it
communicates
that,
even
though,
if
you
were
to
drop
support
of
a
specific
version
right,
if
you
change
your
engines
field
and
you
drop
support,
say
for
version
six,
you
are
obliged
to
bump
major,
but
it
also
communicates
that
I
will
not
drop
the
support
until
hope.
The
package
is
until
that
version:
right
gets
the
end-of-life
right,
so
it
or
I
will
want
major,
but
I
will
support
the
previous
version,
which
does
support
node
six
after
it
reaches
portrait
right.
A
It's
just
that,
like
the
engine
is
like
physically
does
it
run
not
physically,
but
like?
Does
it
actually
run
on
this
or
not?
It
doesn't
tell
you
anything
about
future
directions.
Plans
at
all.
You
know
what
you're
trying
to
do
as
opposed
to
what
you're
actually
doing
today.
That's
the
difference.
Okay,.
F
F
A
F
Could
we
have
breaking
this
out
into
separate
aspects,
I
respect,
it's
like
separate
fields
like
funding
would
be
a
separate
field,
backing
could
be
a
supper
field
and
then
support
would
be
specific
to
you
know
it,
because
support
is
such
a
like
umbrella
term.
That
I
think
is
also
kind
of
the
reason
why
everyone
is
taking
different
approaches
or
wants
to
simplify
the
implementation,
like
the
ultimate
implementation,
which
is
just
let's
just
go
with
it
being
a
reference
to
a
URL
all.
A
F
A
Guess
the
one
the
one
tricky
the
only
thing
I'm
looking
at
that
like
is
there
any
reason
why
things
like
the
response
and
the
backing
couldn't
be
in
a
separate
like
the
target,
some
of
them
like
through
the
discussion.
Some
of
them,
like
the
target,
are
kind
of
related
to
the
the
say,
the
response
and
that
you
might
want
to
say
for
the
LTS
versions.
A
This
is
kind
of
the
response
or
support
we
might
offer
versus
some
other
combination,
and
then
the
there
was
that
we
ended
up
through
the
discussions
ending
up
with
like
a
some
versioning
information
that
says
like
for
these
versions.
This
is
what
I'm
saying
in
other
version.
So
if
you
split
them
out
ie,
then
you
might
have
some
issue
with
like
how
do
you
then
communicate
that
other
version,
information
right.
F
F
B
Example,
straight
happy
GS
they
just
I
mean
it
is
also
an
interesting
concept
in
how
you
would
put
that
into
package.json,
because
it
is
now
released
as
two
separate
namespaces
at
commercial
happy
and
you
can
get
at
happy
happy
and
but
it
does
offer
two
levels
of
support.
One
is
the
open
source
one
you
get
basically
time
permitting
essentially
latest
LTS
node
and
that's
it
no
I
all
SPS
versions,
I
think
and
then
the
commercial
one
it
has
the
extended.
It
has
a
specific
commitment
to
timelines
in
how
fast
the
issues
will
be
addressed.
B
It
has
a
commitment
to
how
long
there
will
be
no
major
bones
or
if
there
are
major
bumps
how
long
each
major
release
will
be
supported
in
in
and
and
which
node
versions
it
will
be
using
so
I
think
happy,
16
will
be
going
will
be
supported
all
over
the
next
year
and
it
will
work
on
low
date.
I
could
be
making
this
up,
but
I
think
that's
that's
roughly
the
idea
there.
F
B
So
if
you
were
to
look
at
the
happy
itself
will
be
published
as
two
separate
packages
right.
One
is
the
commercially
licensed
one,
which
may
include
extra
features
and
has
extended
support
and
in
the
open
source
one
they
both
live
in
the
same
repo.
So
they
are
in
a
way
sharing
the
package.json,
but
in
a
way
they're
not,
but
it
is,
it
does
have
two
levels
of
support.
It
has
the
commercial
with
all
the
commitments
and
it
has
the
non-commercial
one,
the
open-source
one
so.
A
Think
if
they
have
different
information,
I
mean
like
you
know,
we
can
go
back
and
we
can
talk
about
the
content
and
whether
it
can
be
separate
or
not.
I.
Think,
though,
like
in
the
discussions
we've
had,
it
seemed
to
be
that
we,
you
know
we're
fairly
okay
with
the
content
and
and
I
think
for
people
not
using
things.
It's
easy
to
just
not
include
a
section
because
I
don't
think
they're
mandatory,
but
the
the
thing
that
there
was
discussion
and
I
think
you
know
that
you've
called
out
and
other
people
called
out.
A
Even
is
that
that
you
know
there's
two
thoughts.
There's
two
there's
two
kind
of
schools
of
thought
that
are
causing
a
lot
of
the
discussion.
One
is
like
it
needs
to
be
in
the
package
Jason,
because
that's
the
one
place
in
the
package
we
have
where
we
can.
You
know
you
basically
get
it
with
the
package.
We
know
it's
going
to
be
there.
We
know
it's
going
to
be
available
and
the
other
side
is
well.
This
data
can
change,
so
it
doesn't
belong
in.
A
F
So
that's
what
I'm
trying
to
essentially
consolidate
those,
because
I
know
that
I
guess
the
best
of
both
worlds
would
be
that
we
remove
the
mutable
data
from
the
spec
and
get
the
rest
of
the
spec
into
the
going
forward
or
somehow,
if
we
can
bridge
that
gap,
if
that's
possible,
if
it's
not
possible,
as
you
say,
right
wanna,
you
wanted
to
find
something
that
is
mutable.
Then
I
think
that
we
have
to.
Basically
everybody
has
to
get
on
board
with
it
living
somewhere
else
outside
of
the
package
just
right.
E
I
mean
go
ahead.
Sorry
would
it
compromise
because
I
mean
these
are
two
binary
opposites.
Really
these
are
two
camps
and
if
there's
kind
of
no
winning
currently
of
the
conversation,
but
would
perhaps
a
compromise
be
if
we
have
it
in
the
package
yeah,
but
if
we
have
an
external
link
that
it
does
exist,
that
means
that
would
supersede
what
is
in
the
package,
meaning
they
may
have
been
a
life
change
but
maintain
as
they
can
no
longer
support.
The
level
have
committed
to
is.
Is
that
not
a
reasonable
compromise?
E
F
I
mean
it
comes
down
to
the
tooling
like
what
are
we
going
to
do
with
this?
This
field
right
so
like
if
you're
asking
us
for
to
support
an
object,
a
URL
and
then
do
mapping
when
we
see
one
or
the
other,
that's
gonna,
add
some
complexity
in
terms
of
anything
that
an
PM
is
gonna
I
think
implement
the
the
first
first
aeration
that
we
were
even
looking
at
it's
just
like
having
a
sub
command
that
just
spits
out
information
right.
So.
E
If
we,
you
know
because
everything's
gonna
everything
in
the
world
is
a
compromise,
if
we
just
choose
one
of
them
for
the
tooling
to
work
upon,
and
we
make
it
beholding
upon
you
user
day
if
they
ever
exist,
it's
really
down
to
them.
I
know,
tooling,
is
a
very,
very
important
issue,
but
otherwise
we're
not
gonna
be
able
to
satisfy
both
camps
and
we
won't
get
a
decision.
E
F
F
A
F
A
F
F
A
I,
don't
think
it's
it's
when
you
go
on
vacation
I,
think
you
know
your
policy
should
it
should
be
more
generic
that
says
generally,
this
is
gonna.
You
don't
say
you
get
24/7
but
except
when
I'm
on
vacation
right.
Unless
that's
what
you
write
into
your
to
your
policy,
it
should
be
a
more
generic
than
than
that
right.
A
Well,
I,
don't
I,
don't
know
that
these
will
be
updated
frequently,
but
if
you
get
new
backing
or
if
you
get
new
stuff,
then
you
know
you,
you
might
want
to
add
that
in
I'm,
hoping
you're,
you
know
the
idea
that
in
part,
is
to
close
the
communication
gap.
So
if
you
change
it
every
other
week
that
really
doesn't
help
a
lot
right.
It
should
be.
This
is
what
I'm
planning
to
do,
and
you
know
things
change,
but
not
every
other
week
or
something
like
that.
A
You
know
I
expect
that
once
you
know,
if
you're,
if
you're,
if
it's
basically
you
know
something,
you
do
you're
doing
as
a
hobby
and
you've
said
time
permitting.
That
will
probably
be
the
way
it
is
for
quite
a
long
time
until
something
significant
changes.
Right
then
same
with
your
targets
like
if
you're
basically
saying
I'm
gonna
support
all
LTS
versions
and
that's
your
intent.
B
C
B
N,
you
can
have
as
many
changes
as
you
want
on
on
get,
but
once
you
publish
it
on
any
M,
it
stays
there
and
then
can
we
we
I
mean
that's,
that's
a
given
right
want
to
publish
the
package,
it
has
a
package.json.
The
information
is
there,
but
you
do
have
other
objects
around
that
you
have
the
Packer
meant
you
have
the.
B
If
you
have
the
disc
tags
right,
which
can
point
to
different
versions
or
you
know,
maybe
they
could
find
something
else.
Is
there
a
way
to
the
I
mean
I,
wonder
how
much
of
that
is
related
to
the
technical
problem?
Much
of
that
is
related
to
the
actual
underlying
concepts
that
we're
discussing
here.
Yeah.
A
B
G
As
colleges
I'm
hopping
under
this
conversation
a
little
bit
later,
but
my
question
is,
if
you're
at
patch
version
10-
and
you
really
only
want
to
change
the
support
field
and
so
you're
gonna
push
patch
version,
11
sona's
patch
version
10,
they
say
you
said:
you'd
offer
24/7
support
to
patch
version.
10
I,
don't
have
patch
version
11
installed,
so
I
don't
really
care
that
he
changed
it.
Have
we
discussed
that
sort
of
correlation
between
the
version
of
the?
What
is
arguably
a
and
the.
E
G
The
point
people
have
been
making
there's
a
arguable
SLA
like
legal
risk
right.
If
the
argument
can
be
made
that
I
don't
have
the
latest
version,
and
even
though
you
said
that
the
latest
version
is
the
version,
I
should
respect,
you
know,
I,
don't
have
the
ability
to
quote
unquote,
upgrade
to
the
latest
version
and
therefore
I
expect
like
24/7
support
like
if
that
are
given.
G
You
may
think
you
know
why
not
limit
the
risk
by
having
the
link
and
just
having
NPM
support,
retrieving
that
field
and
presenting
that
information
on
the
NPM
module
page
rather
than
having
it
be
part
of
the
package.
I
know
the
argument
has
been
well
if
I'm
on
a
plane
and
I
want
to
know
what
the
service
level
agreement
you
know,
if
I
don't
have
access
the
internet
or
I
want
to
do
my
work.
G
E
I'd
like
to
spend
just
a
few
more
minutes
on
this
when
you
drive,
because
the
thing
is
yeah,
you
make
progress
on
it,
yep
other
than
just
going
through
the
agenda
that
it's
worthwhile,
because
I
want
to
ask
some
questions
from
the
registry.
Perspective
is
if
it's,
the
president
is
the
legal
worry
and
they
prefer
a
link
shouldn't
that
trump
or
technical
worries,
because
it'll
be
this,
it's
the
same
for
everyone
in
most
circumstances,
and
we
have
we
live
in
a
world
of
rules
and
that's
just
the
way
it
is
so.
A
I've
made
Darcy
the
host
to
be
honest,
like
I
I'm,
I
I
won't
oppose
either
way.
You
know,
I
have
my
eye
so
anyway,
I'll
call
anyway.
That's
what
I'll
say:
I'll,
let
you
invade
Iraq
continue
to
come
to
the
continue
discuss
and
if
you
can
put
in
what
the
result
of
that
discussion
is
in
the
issue
and
we'll
go
from
there.
Thanks
awesome.
A
C
I,
move
on
and
I
can't
talk
too
much.
Cuz
I've
got
a
sleeping
baby
here.
It's
still
6:00
in
the
morning
right
so
Jordan,
who
has
been
one
of
the
most
vocal
people
against
the
link,
has
said
very
specifically
in
issues
that
he
is
all
right
as
long
as
NPM
can
host
something
that
can
be
updated
and
then
gets
into
the
package
Aysen
on
install
time.
So
I
just
want
to
make
sure
that
we
don't
go
too
far
down
the
other
route.
C
G
To
that
point,
it
would
be
like
not
directly
related
to
the
patch
number.
It
would
be
dynamically
added
when
you
npm
install.
So
if
somebody
happened
to
clear
their
local
NPM
cache
and
they
hadn't
changed
the
version,
they
would
still
get
the
latest
and
to
Darcys
point
that
puts
a
potentially
significant
load
on
NPM
to
provide
support
for
a
field
that
we
validated
is
going
to
be
essential.
G
F
Support
maintenance,
support
parts
of
this
spec,
which
is
why
I
sort
of
alluded
to
could
we
break
this
out
into
you
know
two
different
two
different
fields
which
would
better
I
think
focus
the
conversation
backing
could
or
funding.
If
we
called
it
could
be
again
a
link
or
an
array
of
links,
you
know
the
source
of
funding
or
where
to
find
that
right
right
now,
I
think
in
that
speck,
it's
just
thought
it
open,
so
I
apologize,
I,
think
right
now,
in
that
speck
it
is
yeah,
it's
just
a
ray
of
links,
its
first
sponsored.
F
This
is
something
that
I
imagine
we
could
support
today.
This
is
something
we
could
quickly
implement.
So
a
portion
of
this
this
this
proposal
is
something
that
we
could
actually
action
on
see.
If
people
use
it
see
how
they
use
it,
and
we
could
even
do
something
on
our
side
to
promote
that
use
with
a
sub
command
as
it
stands
today
and
it
could
even
it
could
go
into
a
minor
release
for
like
MP
m6,
and
if
we
want
to
change
that
functionality,
then
we
could
break
the
chain
that
in
MPM
segment
right.
F
So
this
is
kind
of
like
where
you
know,
then
we
get
the
best
of
both
worlds.
We
can
try
something
out
in
the
ecosystem,
see
if
it
helps
solve
some
of
the
problems
that
we've
seen
with
funding
and
which
is
separate,
I.
Think
from
this
you
know:
what's
the
what
level
of
maintenance
am
I
expecting
from
from
this
package?
G
What
I've
heard
so
far,
it
seems
like
we
need
to
take
the
conversation
back
to
the
roots
out,
bring
back
to
fork
in
the
road
that
we
want
to
get
to
which,
like
a
phased
approach
of
doing
step,
one
backing
field,
near-term
support
in
step.
Two.
If
that
pans
out-
and
we
see
that
there's
like
a
huge
or
to
the
group
or
they
leave
that
widened
option.
F
B
C
Yeah
I
think
I
built
some
tooling
around.
What
was
in
the
issue
just
to
you
know,
get
some
implementation
out
there
and
see
if
that
helps
anybody,
but
I
don't
have
much
to
add
other
than
it
as
it
stands.
The
the
the
package
that
I
liked
there
should
be
usable,
for
you
know
people
to
write
some
integrations
with
I
used
it
to
do
github
action
to
update
the
test
matrix
in
my
repos.
It
seemed
to
work
and
I.
Don't
know
if
everybody.
C
Likes
I,
don't
know
the
aliases
we've
defined,
but
it
seemed
to
be
pretty
fully
fleshed
out
to
me
and
I'd
be
on
board
with
getting
it
merged
because
it
you
know,
after
implementing
it
was
pretty
easy
and
straightforward.
The
language
wasn't
too
hard
to
understand
to
get
an
implementation
out
so
I
think
that's
that's
good.
C
B
D
C
F
F
F
B
F
C
Like
first
week
of
the
pankaj
maintenance
working
group
issues,
they
were
all
just
like:
let's
post
some
ideas,
I
think
it
would
be
healthy
just
to
close
them
all
and
yeah,
and
if
anybody
opposes
just,
they
can
open
up
a
new
issue
with
the
topic
they
want
to
talk
to
work
with
it's
just.
There
was
a
lot
going
on
at
that
point,
so
yeah.
F
So
the
intent
here
would
be
like
this
is
being
around
for
over
a
year
now,
I'm
just
wondering,
like
you
know,
what's
the
help
in
maintaining
this
thread,
keeping
this
thread
open
with
the
with
the
be
the
suggestion
there
is
to
ask
to
break
this
out
into
separate
issues.
If
the
anybody
has
like
something,
that's
more
actionable.
B
I
think
some
of
these
issues
we
will
want
to
read
it
after
we,
you
know,
try
to
go
a
larger
scale
and
at
the
moment
we
said
we're
going
to
try
to
do
some
other
packages.
What
I
was,
of
course,
to
plan
10
months
ago,
but
I
think
once
we
start
going
wider,
we
may
want
to
like
for
this
particular
issue.
We
might
want
to
run
a
wider
open
source
community
survey
or
something
like
that,
and
we
can
always
be
open
this
year.
So
I'm
not
opposed
to
closing
lines.
Yeah.
G
So
the
thread
of
this
discussion,
we
should
probably
come
up
with
some
sort
of
standard
for
tickets,
like
an
explanation
of
what
the
expected
outcome
is
or
like
a
template.
I
have
to
make
sure
that
these
tickets,
any
close
without
you,
know
some
sort
of
everyone
voting
as
just
impractical
in
this
river.
So.