►
From YouTube: Package Maintenance Team meeting - Aug 27 2019
Description
A
So
welcome
to
the
node.js
package
maintenance
team
meeting
for
August
27
2019
we're
going
to
follow
through
on
our
standard
agenda,
which
was
in
issue
actually
I.
Don't
remember
the
issue
off
the
top
my
head,
but
it's
in
one
of
the
top
ones
in
the
repo
40k
242,
okay,
242,
and
does
anybody
have
any
announcements
that
they'd
like
to
share
before
we
start
going
down
the
issues
tag
for
the
agenda.
A
A
The
first
one,
which
I
tagged
on
to
the
top
was
document
the
current
top
ten
Express
issues.
Wes
I
noticed
that
you'd
and
I'd
yeah.
We
do
have
Wes
I
noted
this
notice
that
West
had
added
some
detail
there
and
I
thought
it'd
be
very
useful
for
him
to
sort
of
take
us
through
that
and
give
us
an
update.
Sure.
B
So
we
discussed
in
our
TC
meeting
a
couple
weeks
ago
now
how
we
thought
it
was
best
to
maintain
these
lists
across
you
know
all
the
repos
and
orgs
we
have.
They
became
pretty
clear
that,
like
managing
it
in
a
central
place,
was
not
going
to
be
a
good
idea.
You
know
these
things
pop
up
and
then
go
away.
You
know
in
new
ones,
you
know:
are
there
all
the
time?
B
So
we
thought
we
would
use
github
tags
to
do
that,
unfortunately,
because
the
project
is
structured
in
such
a
way
that
the
work
is
being
done
so
distributed,
we
didn't
have
a
central
place
to
so
we
were
looking
at
like
just
github,
have
a
good
way
to
do
a
search
that
we
could
direct
people
to.
That
would
have
the
tags
from
all
the
repos
that
matter,
but
then
we
have
reposed
that,
like
are
in
the
orgs,
but
aren't
maybe
focuses
so
like
do
the
tags
in
those
repos
count.
B
Anyway,
there
was
a
bunch
of
little
discussions
around
how
we
wanted
to
manage
that.
So
what
we
landed
on
was
we
needed
a
tool
that
pulled
them
all
together
for
us.
So
that
is
what
I
went
ahead
and
built
I
posted
a
link
to
the
page
in
the
express
issue
for
that
so
I
Ono
is
the
issue
in
here
for
that,
but
I'm
not
seeing
right.
B
So
so
the
basic
idea
served
the
purpose
of
express,
really
well,
but
I
think
also
sort
of
extends
to
what
we're
doing
with
a
bunch
of
different
projects
that
are
unrelated
I.
Also
so
I
just
posted
a
link
to
my
comment.
There
I
also
think
it
applies
a
little
bit
to
the
work
that
the
open,
JSF
JS
foundation
is
doing
where
there's
a
ton
of
different
projects
with
things
in
different
states,
but
there's
a
lot
of
work
that
needs
to
be
tracked
across
all
the
different
repos.
B
So
the
goal
here
was
to
pull
those
tags,
so
III
posted
some
screenshots,
but
you
can
also
click
the
link
and
go.
You
know
it's.
It's
very
much
a
work
in
progress,
so
you
know
don't
judge
too
harshly,
but
the
idea
is
this:
is
infrastructure
'less,
so
that
was
I.
Think
one
of
the
key
requirements
I
wanted
to
set
was.
This
could
be
run
straight
off
github,
so
with
github
actions
that
made
it
a
little
bit
easier,
but
the
first
iteration
was
I
just
ran
it
on
my
local
machine.
B
Did
the
index
job
and
then
push
to
a
github
pages
branch
that
you
know
is
not
real-time,
so
with
github
actions,
I've
got
it
so
that
it
will
run
every
two
hours
and
it
does
re
index
and
then
rebuilds
the
github
pages
branch
I'm
pulling
in
a
bunch
of
random
things
here
that
you
know
like
I.
Have
this
top
contributors
list
we
could
discuss?
You
know,
I,
think
what
what
value
people
see
in
showing
here
but
I
think
the
big
thing
that
targeted
this
issue
was
these
tags
on
the
left.
B
B
Maybe
if
it's
just
you
know,
analyzing
the
ideas
that
are
being
presented
and
giving
an
opinion,
and
then
we
have
meetings,
obviously,
for
you
see
meetings
but
then
top
priorities,
the
top
10.
So
as
I
think
the
version
I've
built
here
only
has
two
labeled,
but
we're
starting
to
roll
out
those
labels
on
more
of
the
issues,
we're
waiting
on
one
for
typescript
support
that
Blake
Amberly
was
supposed
to
open,
but
I
think
hasn't
yet
because
that
was
one
of
our
other
top
issues
yeah,
and
so
so
this
is
just.
B
This
is
an
idea
if
you
know
I
bets
I,
have
it
pushed
on
this
PK
gjs
organization,
I'd
be
happy
to
you
know.
If
people
want
to
collaborate
or
have
you
know,
input
and
ways
and
directions,
we
could
take
this,
so
it
makes
it
more
valuable
to
this
group
specifically
or,
if
there's
other.
You
know,
other
projects
that
have
a
similar
structure
to
express
that
that
could
see
a
lot
of
gain
out
of
centralizing
the
work
so
that
they
can.
B
You
know,
direct
new
users
to
one
place
instead
of
logo
read
through
the
you
know,
four
orgs
and
40
repos
and
get
up-to-date
on
all
the
issues
that
are
being
tracked.
You
know
so
so
this
is
a
start,
and
then
we
have
some
plans
for
writing.
Some
automation
on
automatically
tagging
things
with
these
specific
tags,
so
we're
gonna
write
the
next
thing.
I'm
gonna
work
on
now
that
I
finished.
B
B
That
would
help
us
get
more
people
involved
without
necessarily
needing
them
to
have
commit
access
right
away.
We'd,
obviously
love
to
move
them
to
commit
access,
but
you
know
on
Express
were
a
little
bit
more
cautious
with
that,
since
the
impact
of
the
project
is
so
large
so
anyway,
so
that's
sort
of
a
synopsis
here.
That's.
B
One
repo
you
already
have
this
right,
so
if
you
have
one
project
repo
and
that's
it
you
know-
that's
already
solved
by
github.
This
is
specifically
for
the
use
case,
where
there's
lots
of
work
being
done
in
different
repos
and
there's
a
need
to
centralize
the
the
status
you
know
of
the
of
the
project.
Cuz.
A
B
To
Jory
on
this
on
the
foundation
side-
and
she
was
saying
one
of
the
most
valuable
things
would
just
be
centralizing
the
list
of
meetings
you
know
and
all
the
issues.
So
all
the
the
docks
and
the
you
know
meeting
notes.
You
know
she
was
saying
it's
really
hard
for
her
to
manage
that
across
all
the
projects
in
the
open.
You
know
Jess
foundation
node
similarly,
and
the
package
maintance
working
group
as
soon
as
we
start
those
phases.
B
A
The
meetings
like
if
they're,
basically
based
on
a
tag
like
our
auto-generated
meetings,
there's
you
can
go
to
our
calendar,
but
the
ones
that
are
actually
like
the
issues
again.
You'd
have
to
go
to
each
individual
repo
to
find
all
those.
So
it's
actually
it
would
be
it's.
It
sounds
interesting,
so
it's
that
definitely
sounds
good
to
see
if
this
is
like
something
that
at
the
open,
jazz
level
can
be
rolled
out
across
the
other
projects
as
well.
A
B
This
is
I,
say
it's
a
work
in
progress.
We
got
a
lot
of
work
to
do
so
technically.
This
is
the
sort
order
as
by
as
per
the
level
DB
database.
So
I
have
no
put
no
sorting
into
this
at
all.
It's
just
I'm,
stuffing
them
in
level
DB
and
whatever
order
they
come
out.
Then
I
take
the
first
three,
so
we
would
probably
want
to
make
that
a
lot
better.
B
B
Yeah
I
think
I
think
a
sort
of
composite
approach
might
be
best
because
I
think
newness
is
good
here,
but
also
activity.
Yeah
yeah
anyway,
I'd
be
open.
If
you
want
to
collaborate
on
that
and
what
would
be
the
best
way
to
show
this?
Maybe
we
could
you
could
open
an
issue
on
that
repo
and
we
can
start
discussing
it
like.
A
D
A
So
I
think
it's
it's
important
to
make
sure
that,
like
we,
what
we
do
if
we
focus
and
raise
awareness
and
like
try
and
encourage
people
that
it
is
focused
on
here,
the
things
that
really
the
Express
team
will
in
this
case
will
say
hey.
This
is
great
that
we're
having
more
help
on
these
versus
there's
a
huge
discussion
on
this,
but
I'm
not
really
interested
kind
of
thing
before.
C
Maybe
more
than
one
kind
of
section
or
so,
especially
as
we
talk
about
the
node
or
open
Jas
level,
where
it's
like
the
mo
used
tag
or
something
like
that
like
tag
cloud
style
where
it's
like,
it
seems
that
a
lot
of
people
are
having
problems
with
x
tag
type
of
issues.
Maybe
that's
a
larger
opportunity
at
the
open,
J
s
level
to
come
up
with
some
sort
of
broader
solution
that
helps
the
community
at
large
kind
of
a
thing.
B
So
what
this
is
doing
is
just
looping
the
the
items
in
the
in
the
lovely
B,
so
they're
coming
out
in
an
order,
and
oh
this
is
very
valid
feedback.
You
know,
please
feel
free
to
open
an
issue
and
or
or
go
solve
it
in
the
code,
because
it's
you
know
over
there
accepting
PRS,
it's
not
very
clean,
so,
like
I,
said,
don't
judge
too
harshly,
but.
B
A
B
A
Right
this
guy,
oh
yeah
and
I,
should
be
able
to
just
click
that.
So
if
we
go
there
and
we
say
I'm
just
looking
like
what
concretely
can
we
try
in
point,
you
know
we
had
a
number
of
people
who
showed
interest
like.
Is
this
something
that
we
should
now
can
now
say,
hey
here,
the
things
that
you
know?
If
you
have
time,
can
you
go,
try
and
help
and
look
at
yeah.
B
So
we
we
still
have
some
work
to
do.
This
was
to
centralize
the
tags.
We
still
have
some
work
to
do
into
getting
more
of
the
tags
on
the
issues
and
come
so
we
discussed
you
know
open
source,
sometimes
moves
a
little
bit
slow
and
we
have
the
plan.
Now
we
just
have
to
execute
on
some
of
the
ideas,
so
it
is
still
a
little
bit
light.
The
discussion
and
Help
Wanted
we've
used
for
a
long
time.
So
those
ones
if
you
click
on
the
header
that
shows
more
than
just
the
top
three.
B
Oh,
maybe
not.
What
did
I
do
wrong
here.
Maybe
go
back
and
click
on
just
top
issues.
Sorry,
you
know
this
is
my
weekend
project.
Okay,
this
is
all
of
them,
so
this
would
maybe
be
the
page
to
start
with.
If
we
wanted
to
link
people
to
again
open
to
like
better
ways
to
present
this,
because
it's
just
a
big
long
list
and
that's
not
super
helpful
right.
A
And
so
is
it
is
it?
Do
you
think
it's
you
know,
do
you
do
you
think,
there's
it's
worth
waiting
a
little
bit
longer
before
we
try
and
go
out
and
say:
hey
here's
what
you
know,
here's
the
things
that
could
really
use
some
help
or
is
it
worth
you
know,
starting
with?
What's
there
or
I
just
want
to
get
a
feel
for.
A
B
C
In
terms
of
what
I've
seen
especially
like
under
the
discuss
tag,
it's
pretty
common
for
conversations
to
have
ended
and
the
tickets
just
to
not
have
been
like
automatically
closed,
or
anything
like
that.
Some
might
be
helpful
for
whoever
wants
to
take
it
on
to
start
by
implementing
or
putting
together
a
PR
or
an
issued
ticket
for
implementing
something
that
Wes
was
talking
about
the
other
day
about
adding
some
kind
of
automatic
ticket
closer
or
issue
closer.
B
And
if
somebody
wants
to
open
up
that
ticket
I
will
then
or
that
issue
I
will
tag
it
as
a
temporary,
because
that's
definitely
one
of
them
you'd
have
to
so.
The
issue
here
is
that
you
have
to
go
to
all
these
repos
and
do
it
right
so
that
they're
spread
out
everywhere.
So
any
buddy
who
takes
this
on
is
gonna
have
to
do
a
cross
repo
effort
right
there
open
up.
Probably
you
know
thirty
PRS
to
do
that,
which
is
great
I
mean
if
somebody
wants
take
that
on,
though
be
that'd
be
phenomenal,
is.
A
C
B
A
B
My
only
concern
with
this
repo
is
that
the,
if
it's
so
for
beyond
yes
or
the
specific
goal
of
on
Express,
we
need
to
get
that
rolled
out.
I
would
like
to
at
least
have
one
in
that
discussions
repo,
so
that
Doug
and
the
other
maintainer
czar
aware
that
this
is
something
we're
moving
forward,
make
sense
they
won't,
they
won't
pay
they.
They
might
be
paying
attention
to
this
repo,
but
I
wouldn't
count
on
that.
So.
A
B
A
Feedback-
and
then
maybe
we
can
figure
out
is
like
hey.
Is
this
something
we
publicize
at
the
open,
J's
level
as
a
tool
that's
available
to
the
projects
and
then
whoever
else
actually
or
actually
you
know
I
could
just
see
like
you
know,
as
part
of
our
package
maintenance
effort
here
we
want
to
publicize
tools
to
make
it
easier
for
the
the
maintainer
Xand.
A
B
In
a
weird
way,
this
status
board
could
be
a
launching
ground
for
that
too,
because
one
of
the
thing
you
you
have
to
do
to
set
this
up
is
list
all
of
the
repos
right,
and
this
pulls
what
like
a
bunch
of
metadata
about
what
type
of
reposts
are
like,
for
example,
you're,
not
gonna,
submit
a
auto
close
issue
bot.
Well,
no,
an
auto
close
issue
like
you
would,
but
like
things
like
updating,
you
know
other
code
related
things
you'd
want
to
look
at
like.
Is
it
a?
Is
it
a
JSP
right?
B
A
B
Yeah
and
so
one
of
the
things,
if
you
go
to
the
projects
thing
so
I
haven't
done
this
yet,
but
it's
on
my
to-do
list,
I
have
a
to-do
list
on
the
repo
for
this
status.
Word
thing,
so
I
got
a
bunch
of
badges
here,
I'm,
not
sure
how
valuable
all
of
them
are.
But
what
I
really
want
to
add
is
things
like
little
icons
for
does
it
have
typescript
type
things?
Does
it
have,
and
we
could
add
this
kind
of
thing
does
it
have?
Is
auto-close
bot
enabled?
B
So
you
could
then
look
at
the
project
and
say:
hey
Oh,
which
ones
don't
have
it
I'll
go
at
it
to
those
ones
yeah
or
which
ones
don't
have
typescript
type
things
today,
let
if
I'm
the
typescript
person
who's
really
into
it.
I'll
go
down
this
list
this
and
just
find
anyone
that
doesn't
and
open
a
PR
that
that
shows
that
so
so
the
idea
would
be
to
put
more
information
in
here.
I
know
it's
already
a
busy
page,
so
maybe
there's
some
designer
help
that
could
be
done
to
make
that
sound.
B
Right,
I
completely
agree:
I
I
started
with
this,
mostly
because
we
had
this
thing
called
badge
board
and
it
was
being
poorly
maintained
and
had
the
restriction
of
was
only
worked
on
one
organization,
so
I
was
hoping
to
do
a
little
two
birds
with
one
stone
here
and
make
this
a
replacement
for
the
badge
board
as
well.
As
you
know,
centralization,
for
so
this
page
is
not
optimal.
I
would
love
to
get
some
design
input
on
how
we
could
make
this
more
valuable,
but.
B
A
B
B
A
E
C
A
A
A
F
E
A
A
A
A
And
I
think
the
the
there's
definitely
some
synergy.
What
I
think
is,
though,
that
not
all
packages
will
necessarily
join
a
fountain.
You
know
a
foundation
or
even
the
open
jazz
foundation.
So
the
the
group
that
we
would
you
know
that
the
foundation
that
will
be
foundation
members
is
probably
a
subset
of
the
packages
that
we
potentially
want
to
target
helping.
A
Now
the
foundation
has
had
some
discussed.
There
have
been
some
discussions
that
level
sort
of
like
a
GS
Commons,
which
would
be
like
resources
and
help
for
you
know
beyond
just
members,
so
maybe
there's
some
some
overlap
or
synergy
as
that
gets
ramped
up,
but
there
hasn't
really
been
too
much
work
at
that
level.
Yet.
E
A
G
A
Okay,
so
at
this
point
probably
not
too
much
for
us
to
discuss
in
the
meeting
itself,
we'll
wait
for
that
feedback
and
I
think
it's
still
worth
you
know
we
can
always
adjust
our
support,
documentation
so
package,
the
supporting
four
in
the
package,
because
it's
still
a
draft.
So
we
don't
necessarily
need
to
block
on
that,
but
it
will
wait
on
this
feedback
and
then
incorporate
it.
Make
sense.
A
F
B
Said
I
second,
that
I
think
we
can
I
think
we
can
merge
the
questions.
There
were
new
entrants
into
the
conversation
and
I
think
we
have
went
over
all
of
their
concerns
at
some
point
or
another
they're,
not
invalid
concerns.
We
just
have
already
at
least
partially
addressed
them,
and
we,
if
we
hold
up
you,
know
just
because
we're
waiting
on
new
people,
I
think
it'd
be
just
easier
just
to
make
edits
once
we
merge
it,
then
it
will
be
to
you
know,
continue
to
hold
this
very
long
issue
long.
E
A
So
then
I
think
we
want
to
write
up
a
blog
which
which
produces
introduces
it
reduces
it.
Along
with
some
of
the
the
contentious
points,
you
know,
live
non,
live
right
so
basically
says
to
give
night
and
I
think
cuz.
One
of
the
comments
was
that
providing
that
context,
along
with
the
doc
is
actually
quite
useful.
So
if
we
actually
wrote
up
a
blog
that
says,
hey
we've
been
working
on
this.
This
is
what
we've
currently
got.
Here's
the
discussions
we've
already
had
in
terms
of
you
know.
Should
we
do
this?
Should
we
diet
this?
A
This
is
the
rationale
for
why
we
chose.
What's
there
now
and
then
basically
use
that
to
drive
like
cuz.
You
know
we
thought
this
was
at
least
you
know
our
group.
The
core
group
has
a
consensus
on
what
we
look
like
now:
let's
get
the
broader
consensus
and
to
sort
of
drive
that
that
review
through
say
so,
a
blog
post
with
the
additional
context
and
then
hopefully
use
that
feedback
to
revise
and
then
promote
it
to
to
non
draft.
H
And
I
just
want
to
add
from
NPM
side
we're
really
looking
forward
to
having
some
sort
of
solution
for
this,
as
a
lot
of
people
will
have
realized.
Most
recently,
there's
been
some
progression
in
the
community
for
trying
to
get
funding
and
sort
of
support
landed
in
and
some
experiments
that
are
being
had
and
we're
fully
akhmad
could
be
here
on
this
call,
so
I'm
sort
of
standing
in
here
on
his
behalf
from
MPM,
but
we're
totally
behind
getting
something
like
this
landed
and
supporting
it
as
quickly
as
possible
and
so
I'll
be
also
contributing.
H
E
Darcy
as
well,
if
there's
an
open
RFC
by
Katie
Mitchell
for
a
sustainability
property
that
sort
of
overlaps
like
technically
conflicts
but
spiritually
overlaps
with
with
this
proposal.
So
it
would
probably
be
useful
if,
if
NPM
is
planning
on
adopting
this
proposal,
you
know
with
or
without
your
suggestions.
It
would
probably
be
useful
to
at
some
point
soon
indicate
that
on
that
RFC
for.
H
B
B
I
said
I
could
be
a
conduit
from
from
them
to
this
group,
so
I
think
it's
awesome
and
Ken
Mitchell
and
make
mix,
Irvine,
I,
think
and
a
few
others
just
sort
of
I
think
they
want
to
continue
with
their
experiments.
You
know,
god
bless
them
for
doing
that
for
the
community,
because
it's
obviously
drawn
a
lot
of
ire
from
people.
B
You
know
go
for
it,
but
I
might
not
want
to
be
on
the
forefront
of
that,
but
I'm
happy
to
take
any
you
know
input
they
have
and
bring
it
back
to
this
group,
and
then
you
know
I
linked
to
them.
I
posted
an
issue
in
that
funding,
repo.
That
said,
hey
do
you
want
to
collaborate
and
I,
think
Frost
said
yeah
and
he
actually
has
win.
The
next
meeting
of
this
was
I
posted
a
link
to
this
I.
B
A
A
H
A
D
A
A
Whoops
absolutely
we'll
put
something
together
and
get
the
the
overall
team
send
it
send
it
or
like
probably
in
an
issue
in
this
repo,
so
everybody
can
comment
and
help
improve
it
before
it
actually
goes
in
and
so
and
just
to
confirm,
like
it
sounds
like
we're
all
comfortable
landing.
That
I
mean
there's
no
objections
in
the
issue
itself,
but
if
nobody
has
any
here,
we'll
go
ahead
and
land
that
and
then
move
on
to
that
the
blog
post
is
the
next
issue.
Next
step,
I.
E
H
A
A
H
H
A
H
A
A
A
H
A
B
Thing
I
didn't
think
about
until
you
just
brought
this
up
here
is
doing
this
when
the
LTS
window
shifts
a
so.
If
you
drop
support
for
no.28,
when
the
LTS
window
shifts
that's
a
major
version
bump,
you
can't
get
around,
you
have
to
change
it
right,
so
you
know
this
doesn't
necessarily
come
safe
or
that
and
I
didn't
think
about
it
until
now.
So
we
should
maybe
do
we
feel
like
that,
would
need
to
be
resolved
before
we
merge,
or
are
we
alright
well
following.
E
But
it
still
might
be
a
cember
major
change
and,
like
so
I
think
like
if
we
put
in
LTS,
if
you
put
in
let's
say
LTS,
active
and
then
already
put
in
maintained,
and
then
eight
drops
off
you
unless
you
have
published
a
semper
major
version,
you're
still
obligated
to
maintain
support
for
no
date
on
that
package.
Now
you
can.
C
E
E
E
Wonder
if
maybe
we
like
in
the
same
way
we
have
regular
and
where
you
can
put
in
any
value
and
then
after
you're
committing
I,
wonder
if
we
could
change
these
keywords
to
indicate
the
lowest
current
like
the
lowest
current
value
or
something
or
you
know
like
so
you
could
say
like
LTS,
active,
:,
10
and
then
it's
all
the
current
LTS
actives
since
10
was
active
or
something
or
I.
Don't
know.
If
that's
too
much
complexity,
maybe
we
should
just
drop
the
keywords
and
we
should
just
use.
Cember
ranges.
E
F
Ahead
regarding
the
keywords,
and
so
the
actual
node
versions,
that
a
specific
release
supports
is
a
fixed
thing
right
if
it
is
if,
for
example,
you
have
expressed
for
it
supports
node,
6,
8
and
10
right.
If
you
want
to
drop
node
6,
you
need
to
bump
major.
However,
the
support
field
and
the
keywords
they
indicate
the
intent
and
the
policy
of
what
you
intend
to
do
so
come
October.
F
We
will
start
supporting
12,
which
is
not
a
timber
major
right,
but
until
you
say
we
support
LTS
active,
which
means
come
October,
we
will
support
nodes
12
and
whether
you
maintain
support
for
node
8
when
no
days
drops
off
they
intent
in
your
policy.
You
say
that
you
know
we
will
support
active
LTS
releases.
One
snow
day
drops
off
all
bets
are
off,
that's
the
only
thing
that
it
says
right
and
one
snow
rate
can
drops
off
B
of
their
support,
and
you
do
want
to
drop
the
support
for
no
date.
F
Then
you
publish
a
semi
major
and
then
you
no
longer
support
node
8,
but
in
the
support
policy
field
you
say
that
LPS
active
means
that
when
the
new
lps
comes
out
we
will
start
supporting
it
and
when
the
LPS
drops
off,
we
may
or
may
not
support
it
anymore,
but
we
don't
have
a
commitment
to
support
it.
Now,
when
we
drop
support,
we
will
have
to
bump
major,
but
we
don't
have
a
commitment
to
continue
supporting
this
version.
Sir.
E
But
there
is
a
commitment
there
too,
in
that,
like
if
you're
in
v1
and
eight
drops
off,
there
is
a
commitment
to
not
publish
a
version
of
the
one
after
that.
That
does
not
support
notate
good
and
there
is
a
I
think
it's
worth
considering
that
like
that,
may
not
be
super
apparent
to
everyone
like
right
now.
It's
really
obvious
when
you
change
your
engines,
value
or
when
you
delete
a
matrix
from
Travis
EML
that
you
like.
It's
really
obvious
that
you're
dropping
support
for
an
ode
version
and
it
in
pull,
requests
and
stuff.
F
B
Right,
so
the
change
there
would
actually
be
pretty
simple
is
when
the
window
shifts.
If
the
maintainer
cares
to
say,
yeah
I
still
do
commit
to
supporting
this,
all
I
have
to
do
is
do
a
PR
that
makes
it
take
changes
it
from
the
string
LTS
to
an
array
of
eight
comma
LTS
right
or
whatever
the
you
know.
The.
E
Road,
that's
kind
of
the
thing,
though,
is
that
the
best
practice
that
we
should
be
encouraging
should
not
be
just
casually
drop
support
for
something
the
instant
it
goes.
Eoeo,
l,
that's
there
may
be
some
people
that
agree.
That
think
that
that
should
be
the
best
practice,
but
I
would
say:
there's
not
consensus
on
that,
both
in
this
group
and
in
the
combiner
community,
and
we
shouldn't
come
up
with.
We
should
be
careful
not
to
come
up
with
a
versioning
scheme
that
implicitly
pushes
one
of
the
sides
of
that
debate.
E
E
I
think
we
should
do
that
here
too
and
like
at
some
point
like
sure,
I
could
put
LT
s
comma
eight
and
then
you
know
I've
supported
committed
to
supporting
eight,
even
when
it
drops
off,
I
can
do
LTS
and
then
eight
and
then
ten
right
but
be,
and
that
would
achieve
the
good
semantics
that
no
one
disagrees
with
of
as
new
things
enter
LTS.
We
definitely
support
them,
but
that
at
that
point,
you're
kind
of
defeating
the
purpose
of
having
the
key
word.
E
F
E
Is
the
intent
to
add
support
for
new
things
as
they
enter
a
category
which
is
great,
no
controversy
there?
The
other
is
the
intent
to
drop
support
for
things
as
they
leave
a
category
and
that's
something
that
I
think
it
is
really
important
to
not
be
implicit
to
not
be
silent,
like
it
should
be
an
explicit
manual
choice
in
order
to
drop
that
support,
and
it's
totally
fine.
E
A
I
think
I
think
you
could,
we
could
add
additional
key
like
maybe
not
with
the
existing
key
words
other
than
having
to
you
know,
I
think
you
could
express
that
as
you've
already
said,
but
then
you'd
have
to
actually
change
things,
so
I
think
adding
potentially
adding
some
keywords
or
qualifier.
So
that
might
make
sense
you
know
so
that
could
be
a
PR
to
add
those
additional
Pete
quality
keywords:
slash
qualifiers
to
express
that
intent,
because
our
goal
is
to
let
you
most
easily
express
the
intent
of
what
you're
going
to
be
doing
going
forward.
F
And
it's
not
just
that
the
as
a
package
consumer
when
I
open
up
the
package
for
the
first
time,
I
want
to
see
what's
going
to
happen
with
that
package
next
year.
Right
so
just
as
know
at
the
end
of
the
year,
you
might
add
eight
to
the
list,
and
you
will
say
that
we
support
eight
and
obvious,
but
you
would
also
like
to
say
that
we
will
not
in
definitely
support
node,
eight
right
and
and-
and
you
do
need
to
express
that
as
well.
So
this
is
just
providing
the
vocabulary
to
express
certain
things.
F
So
the
the
key
words
they
do
have
their
place
there
in
terms
of
letting
people
say
these
things
right,
because
nobody
would
ever
expect
anybody
to
keep
maintaining
node,
six
or
no
date
indefinitely.
I
do
point
six
on
all
my
packages
indefinitely
IIIi
down
to
great
this
is
this
is
truly
the
right
commitment,
but
not
all
of
us
can
afford
to
do
that.