►
From YouTube: Package Maintenance Team meeting - January 28 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
Okay,
if
there's
no
announcements,
let's
move
on
to
the
things
that
are
tagged
with
the
agenda,
so
the
first
one
is
engaging
enterprise
teams
to
better
understand
challenges
at
scale.
So
this
is
number
138.
Unfortunately,
I'm
add
who
opened
this?
Let
me
know
he
wasn't
going
to
be
able
to
make
it
this
week
he's
flying
on
a
plane,
I
guess
with
no
Wi-Fi.
A
In
addition,
so
the
idea
between
this
one
is
kind
of
two
things
he's
helping
to
lead
the
packet
or
so
the
the
user
feedback
initiative
around
enterprise
and
there's
sort
of
two
pieces
one.
The
first
one
is
like
you
know:
how
can
how
can
we
leverage
the
experience
from
those
enterprises
in
terms
of
you
know,
providing
feedback
to
the
project
and
so
forth,
and
the
other
one
I
know
that
I've
talked
to
em
at
and
a
number
of
other
people
about
is
how
do
we
basically
help
enterprises?
A
B
A
Yeah,
so
anybody's
got
comments
anybody's
watching,
please
jump
into
the
issue
start
discussing,
but
that's
you
know
I
think
one
of
very
the
very
key
things
so
I'm
gonna
suggest
we
add
that
we
have
sort
of
had
three
things
we
were
focusing
on.
I
would
add
that,
as
our
fourth
thing
to
focus
on
as
we
sort
of
get
boots
dropped
and
kicked
off
I.
C
A
A
Okay,
okay.
So
having
said
that,
let's
move
on
to
the
next
one,
which
is
baseline
practices,
brainstorm
the
initial
list
that
is
number
one
19,
so
the
status
where
we're
at
on
that
one.
This
is
kind
of
one
of
our
baseline
practice.
This
is
one
of
our
this
sort
of
three
now,
hopefully,
four
key
areas
we're
focusing
on
to
make
some
progress
on
the
status
on
this
one
is
I,
think
we're
we.
There
was
some
good
discussion
and
we're
kind
of
a
couple
of
them.
A
The
members
are
so
gentian
and
mementos
we're
going
to
sort
of
work
to
provide
a
good
summary.
The
one
concrete
thing
I
think
we
can
dive
into,
though,
on
that
front
is
I
created
a
PR
for
an
initial
best
practice
in
one
of
the
areas
had
been
discussed
in
a
few
different
issues,
and
this
is
around
its
number
one.
Thirty-Nine
pull
request
number
one
and
it's
around
documenting
support
levels.
A
A
Think
if
you
know
people
jump
in
and
have
other
ideas
will
will
evolve.
That
sort
of
the
four
dimensions
that
I
had
under
support
were
like
the
target.
So
what
target
level
is
a
maintainer
thinking
about
providing
what
kind
of
response
you
can
expect
and
I
I
don't
know
if
this
is
right,
but
I
included
two
different
flavors
a
response
and
a
response
paid.
So
you
could
have
something
that
says:
hey
if
you
just
consuming
open-source.
You
can
get
this
kind
of
response.
A
If
you're
willing
to
pay,
you
could
get
this
kind
of
response
and
then
backing
which
was
the
one
that
kind
of
reflected
the
business
model
and
in
their
sort
of
so
it's
not
it's
it
for
each
of
those.
It's
not
intended
to
be
like
an
ordered
list
or
anything
like
that.
It's
more
like
licenses,
where
you
can
define
what
you
think
your
it,
your
your,
whatever
you're,
providing
on
those
dimensions.
A
So,
for
example,
the
support
target-
you
know
the
list-
that's
there
now
is
abandoned.
That
would
sleep
really
it's
not
recommended
be
used
as
deprecated.
So
there's
that's
like
don't
use
it.
There's
none
which
is
you
know
it's
not
that
we're
telling
you
not
to
use
it
but
use
it
your
own
risk
because
there's
no
support
and
this
dimension
is
sort
of
like
what
levels
of
node
would
be
supported
in
subset
in
some
sense,
so
like
node
latest.
This
will
only
support
the
latest
version
of
node
node
LTS.
A
So
it's
maintained
for
all
the
active
versions
of
node
LT
of
node
that
our
LTS,
so,
for
example
today
that
would
be
six
eight
ten
and
you
wouldn't
need
to
take
semver
major
breaking
change,
because
you
would
get
critical
fixes
for
those
those
releases
and
then
node
superset,
which
means
that
you
know
would
be
maintained
for
more
than
the
LTS
and
you
would
specify
what
that
is.
Is.
B
A
B
A
A
A
B
B
Engine
so
like
what
npm
version
is
minimum
or
what
npm
version
ranges
are
acceptable
and
also
what
node
version
ranges
are
acceptable.
This
also
is
in
just
node
an
NPM,
though
it
could
be
like
what
your
inversions
are
acceptable
or
something
like
that
like
it.
Doesn't
it's
not
specific,
alright,
so.
C
A
It's
it's
it's
good
to
think
about.
If
there's
something
existing,
we
can
reel
Everage
for
sure
I'm.
Just
like
I
I'm
I
can
I
think
we
yeah
well.
Let
we
probably
don't
need
to
figure
it
out
now.
So
I
can
take
another
look
at
what
engines
means
I'm.
Just
my
first
thought
is
there
potentially
overlapping
in
some
way
like
you
might
be
able
to
drive
the
engines
from
the
support
target
yep,
but
not
necessarily
the
other
way
around
yeah,
maybe
yeah,
but
yeah.
D
A
Worth
explaining
no
matter
what
it
would
be
worth
explaining
how
they
might
relate
so
yeah,
okay,
so
there's
kind
of
the
support
target.
That's
the
dimension!
The
support
response,
then
is,
you
know,
has
the
how
quickly
you
might
expect
to
respond.
So,
like
you
know,
is
it
abandoned?
So
you
don't
expect
a
response,
best
effort
which
is
like
okay.
This
isn't
my
day
job,
but
if
I
have
time
I'll
get
to
you,
you
know
I
have
regular
7a,
regular
one
which
is
like
hey.
A
A
You
know
single
maintainer
but
depends
on
sponsorship.
Bounty
bounty,
backed
project,
there's
a
project
behind
us.
For
example,
we
have
a
number
of
modules
and
no
J's
foundation.
I
guess
maybe
that's
that's
a
little
bit
conflicting,
maybe
with
the
next
one,
which
is
foundation,
so
it's
maintained
and
supported
under
the
auspices
of
a
foundation
company,
so
it's
maintained
by
a
company
and
then
commercial.
A
So
it's
in
this
case
company
and
commercial
I,
just
spelled
out
as
one
is
like
Kay,
it's
it's
backed
by
a
company,
but
it's
not
necessarily
part
of
their
business
and
commercial
is
like
this
is
part
of
our
business
to
deliver
so
I.
You
know,
I,
guess
any
comments
or
thoughts
on
that
that
people
have
I.
E
A
A
Yeah,
just
I
wonder
whether
it's
possible
to
be
able
to
make
regression
right
like
lately
like
licenses,
you
know
is
it
that
people
will
have
their
different
combinations
of
what
they're
willing
to
provide,
and
they
won't
necessarily
be
able
to
pick
one.
If
it's
in
a
progression,
I
see
Joel
has
his
hand
up.
F
Just
have
a
like
quick
caution,
and
maybe
I'll
be
back
so,
first
of
all,
for
these
support
filled
in
package.
That
Jason
is
it
something
that
anyone
can
simply
add
to
their
package
station
and
publish
to
NPM?
Is
that
what
we
are
thinking
or?
Is
it
something
that
will
be
add-on
by
NPM
when
they
publish
package
that
I
don't.
A
A
Think
if
we
agree
that
this
is
a
good
idea
and
we
you
know
once
we
we've
lost
it
down,
I
think
going
to
NPM
to
at
least
ask
for
like
a
default
to
be
added
for
in
an
NPM
minute
or
submitting
PRS
to
try
and
do
that
would
be
a
good
thing
so,
but
yeah
it's
it's
something
I
think
we
could
just
do
by
hand
to
start
some
sort
of
support
from
NPM.
If
we
can
yeah.
F
A
Well,
it's
yeah
I
mean
it's
until
until
it
gains
traction,
you
wouldn't
necessarily
be
able
to
rely
on
it,
but
so,
for
example,
like
you
can
scan
for
licenses,
you
can
then
make
tools
that
could
scan
for
particular
support
levels.
Right
and-
and
so
you
know,
if
you
wanted
to
say
that
we
have
a
preference
for
modules
that
support
LTS
all
know
the
node
else
yeses,
you
would
be
able
to
figure
that
out.
I
mean.
A
F
You
know
an
upfront
level
one
when,
for
example,
we
first
goes
hey
I
want
to
use
that
package
and
I
have
to
look
in
document.
It
looks
good,
it
looks
like
it's
gonna
meet
our
needs.
Obviously,
we've
never
been
concerned
with
like
going
forward.
What
what
kind
of
support
can
we
get
and
can
we
pay
for
some
some
usage
if
we
really
need
it
with
that,
topic
has
never
really
gotten
on
our
mind
much
but
I
think
having
this
feel
would
be
useful.
You
know,
at
least
by
we.
F
F
It's
it's
getting
to
be
a
more
sort
of
a
slight
problem
because
we
have
teams
who
refuse
to
upgrade
from
no
six
I
mean
at
this
point,
I've
pretty
much
gotten
everyone
to
upgrade
to
at
least
know.
Six
I'm,
like
anytime
I
found
out
someone's
do
using
no
for
the
first
thing,
I'm
going
down
there
like
personally
and
say
we're
upgrading
the
nose
at
least
no
six
today
I
mean
but
I
woke
up,
correlators
LTS,
but
yeah.
F
A
F
Of
the
times
we
found
that
no
diversion
problem
is
because
of
people
like
use
new
syntax
and
these
day
would
type
scrip
pretty
much.
Everything
needs
to
be
trying
to
spoil
anyway.
So
so
we
found
that
most
90%
of
the
time
any
any
time
a
module
has
a
like.
We
need
no
version
DS.
That
is
because
of
the
JavaScript
syntax
or
something
and
news
read
aids.
They
transpire-
or
at
least
they
have
option
of
saying
we,
you
know
if
you
are
using
no
version
lower
than
that.
You
need
to
require
that
extra
file.
F
So
so
that's
not
a
big
problem,
and
usually
the
problem
is
around
vulnerability
or
security
problem
that
that's
found
and
I
guess.
Then
nodejs
has
been
keeping
up
as
long
as
LTS
support,
so
I
guess
version
4,
Co
and
our
table
wasn't
version.
6
is
still
getting
getting
some
patches
for
security
issues.
So
that's
why
we're
we're
still
kind
of
say
we
support
no
6
yeah.
A
No
6
goes
out
of
service
at
the
end
of
April,
so
yeah
yeah
I
mean
the
like
in
terms
of
the
node
LTS.
It
was
intended
to
get
that
same
level
of
you
know.
Think
it'd
be
like
if
people
are
willing
to
do
that
to
get
a
similar
level
of
support
along
the
lines
of
the
LTS
releases,
now
you're
saying
that,
like
I,
guess,
I'm
trying
to
understand
a
little
bit
the
the
typescript.
F
F
A
C
A
B
Yes,
I
mean
the
the
path
I
would
go
is
abandoned
at
the
bottom.
I
mean
like
thinking
about
it.
As
the
LTS
chart
abandoned
effectively
max
maps,
the
eol
then
actually
no
none
abandoned
node,
LTS,
node,
superset,
endo
latest
and
honestly.
I
also
don't
know
if
node
is
even
needed
there
like.
That
seems
since
this
is
like
that
no
part
is
not
necessarily
needed
and
I
would
I.
E
A
So
it's
not
related
to
maintenance
of
note
itself.
It's
just
that
the
well!
It's
that
the
module
is
trying.
You
know
if
you're
generally
I
think
people
likely
upgrade
their
applications
to
new
versions
of
node
infrequently.
So
when
you
do
that,
you
meet
you,
that's
a
good
time
to
say:
okay
I'm
moving
from
node
8
to
no
10.
At
that
point,
I'm
gonna
have
to
retest.
So
I
can
you
know,
take
new
versions
of
modules.
I
can
take.
A
You
know
minor
tweaks
for
Semra
major
changes
stuff
like
that,
and
at
that
point
it
makes
sense
to
do
everything
and
do
all
those
updates.
Whereas
if
I'm
got
an
app,
it's
in
production,
I've
got
the
same
version
of
a
node
and
I
have
to
take
us.
You
know
assembler
breaking
change
in
a
package,
that's
probably
more
of
a
challenge.
A
E
A
E
D
A
E
A
B
A
B
Mean
I
think
we
probably
need
to
be
as
flexible
as
NPM
in
terms
of
how
they
do
like
NPM
scripts,
where
you
can,
just
like,
add
a
prefix
or
a
suffix,
and
it
works
in
terms
of
like
parsing
this
or
we
want
to
be
recuperated
like
either
of
those
works,
but
I
think
that's
where
we
need
to
kind
of.
We
need
to
figure
out
that
before
we
go
down
the
path
of
like
building
this
out
more
it's
like
do.
A
B
B
A
A
Okay,
that's
all
I
had
to
say
on
the
baseline
practices.
Otherwise
we're
going
to
you
know,
outline
a
set
and
then,
similarly
to
this
one
start,
opening
PRS
I
did
open
that
one
like
we
have
a
draft
subdirectory.
So
we'll
probably
start
them
into
into
draft
and
then
once
we're
happy
enough,
we
can
promote
them
into
the
regular
doc.
A
A
A
A
E
Thank
you.
Sorry.
I
have
been
completed
connected
in
the
sense
that
there's
been
a
lot
of
discussions
on
github
and
more
or
less
they
kind
of
exhausted,
exhausting
themselves,
and
fortunately
I
didn't
sum
it
up.
So
I
think
the
discussion
is
almost
ready
to
be
summed
up
somehow,
but
I
have
been
completely
taken
off
to
do
other
stuff,
so
I'm,
sorry,
yeah.
A
You
know
a
set
of
a
set
of
package
maintainers
that
we
would
go
and
ask
if
they
had
a
bit
of
time
to
try
and
give
us
feedback
on
what
the
biggest
problems
they
had
and
I.
Think
Wes
was
gonna
put
together
a
list
of
some
initial
packages
like
friendlies,
so
that
was
gonna
be
part
of
it
and
if
people
have
other
suggestions
of
who
we
should
reach
out
to
I,
think
you
know
if
we
can
summarize
that
and
then
come
out
with
a
list
that
says
this
is
what
we
got
from
an
internal
discussion.
A
A
No,
but
his
next
action
was
to
basically
open
three
new
issues
which
were
around.
Let
me
see
if
we
have
any
new
issues.
Three
new
issues
that
were
for
the
specific
pieces
of
the
sort
of
proposal
that
he'd
proposed
there
in
terms
of
the
steps,
and
so
basically
that's
the
the
next
step
on
that
front.
So
we're
just
waiting
for
those
issues
and
then
we'll
start
to
push
along
those.
A
A
It's
trying
to
see
if
there's
any
we
did
discuss
a
little
bit
have
to
go.
Look
look
back
at
the
last
minutes
in
terms
of
deprecated
and
using
it
was
around
that
you
know,
there's
already
there's
already
a
deprecated
option
and
p.m.
and
do
we
need
some
sort
of
evangelization
around
suggesting
people
use
that
deprecated.
Now
we
did
think
that
we
needed
to
be
a
bit
careful
on
that
front,
because
then
that
may
cause
you
know
as
people
install
and
whatever
you
get
deprecation
messages
right.
B
A
F
F
Concerned
with
deprecated
packages
yourself,
to
be
honest,
probably
something
that
we
we
should
look
into
more.
That's
when
you
know
nowadays,
every
time
any
one
of
our
apps
when
you
know
when
they
do
a
npm
install
because
they
have
a
package
lock
or
they
have
some
kind
of
lock
that
that
list
of
these
package
deprecated
messages
is
getting
longer
and
longer,
and
no
one,
as
is
raising
any
concern
about
that.
As
long,
we
have
a
ton
of
functional
tests
and
unit
tests
that
that
gets
takes
and
our
to
run.
A
F
F
Mean
most
of
our
developers,
they're
they're,
so
so
scared
of
like
getting
a
p0
on
life
site
that
they
would
enter
having
the
support
is
that
they're
very,
very
cautious
about
operating
anything
it
anytime.
We
make
a
some
new
release
ourselves.
It
takes
out
a
lot
of
effort
trying
to
convince
people
to
upgrade
right.
F
A
A
F
A
So
on
on
this
one
I
guess
the
the
next
step
is.
We
need
somebody
to
like
I
guess
we
kind
of
need
to
decide.
Is
this
something
like
we
could
write
another
baseline
best
practice
on
practice,
which
would
be
we
recommend
that
you
deprecated
I,
don't
know
Terry
Turney.
Do
you
have
any
interest
in
doing
that?
B
A
Would
basically
be
a
recommendation
for
yes
when
when
and
how
you
should
use
the
deprecated
command?
Okay,
right,
like
you
know,
the
comment,
was
it
exists
there
it's
underused.
So
if
we
actually
have
you
know
our
baseline
practice,
it's
like
okay
and
here's
how
we
recommend
you
use
it,
and
then
you
know.
C
A
A
A
A
A
So
this
one
yeah
I
guess
it's
it's
on
the
agenda,
because
it's
it's
interesting
and
that
there's
there's
a
bunch
of
resources
templates
that
an
even
automation
that
would
be
really
useful
for
maintainer
x'
and,
having
you
know,
a
base
set
that
people
could
use
you
know
not.
Everybody
will
use
the
same
ones.
But
you
know
if
there
was
a
baseline
set.
B
Ahead,
I'm
sorry
I
was
I.
Think
having
like
a
for
us
so
like
thinking
about
this.
From
a
more
like
real
point
of
view,
I
know
that,
like
as
a
devrel,
if
there
is
an
something
that
like
I,
can
go,
contribute
a
time
template
to
for
my
company,
I
will
usually
end
up
going
going
and
doing
that
I
know
a
bunch
of
others
do
that
as
well
yeah.
So
perhaps
a
good
approach
to
this
might
be
you
actually
set
up
like
here
are
the
things
we
want.
B
So
like
you're
testing
on,
like
all
of
the
note,
all
of
the
live
like
not
ul,
node
versions,
your
testing
on
Windows,
Mac
and
Linux,
and
then
like
a
couple
of
like
whatever
other
things
we
want
to
use
in
terms
of
that
and
then
be
able
to
actually
go,
have
a
repo
of
like
JavaScript,
CI
templates
or
module.
Ci
templates,
maybe
is
what
we
would
want
to
name
that
and
then
how
people
like
community
members
can
come
and
contribute
that
I
know
like
I
have
one
that
I've
been
using
for
Travis
CI.
B
That
I
would
be
happy
to
go,
contribute
and
also
enhance
cuz
like
this,
isn't
something
people
do
so
I.
Think
that,
having
that
like
guideline
of
your
here's,
the
checklist,
if
you
want
to
contribute,
make
sure
it
has
these
things
or
if
it's
a
limitation
of
your
platform
like
it
can't
do,
Windows
built,
which
is
like,
was
Travis
for
a
long
time
right.
B
A
So
yeah
I
mean
I,
think
cuz,
yes,
I
think
Wes
had
mentioned
or
LJ
harp
I
can't
remember
who
you
know.
One
of
them
had
some
already
some
templates
for
Travis
to
test
across
things,
so
I
think
you've.
You
know
you
hit
the
nail
on
the
head
that
there's
a
bunch
of
resources
out
there.
What
we
need
is
a
structure
that
says
you
know
as
a
maintainer.
What
are
the
common
things
you
want
to
do
in
the
templates
and
automation
that
will
help
you
and
then
we
can.
Let
people
fill
that
in
you.
A
Want
to
take
a
cut
it
that
sort
of
top-level
structure
of
here's,
what
the
kind
of
things
you
want
and
week.
You
know
we
just
need
to
figure
out
okay.
How
do
we
get
that
into
this
repo?
And
then
you
know
we
can
sort
of
ask
people
say
hey
if
you
got
something
you
know
contribute
to
get
these
things
in
here.
Yeah
awesome
sounds
good,
so
I'm
gonna
save
Turney
volunteered
to
provide
some.
F
B
One
thing
I
will
say
that
I've
kind
of
gone
and
tried
to
do
is
I
actually
wanted
to
give
me
ideas
section
and
made
a
proposal
for
this.
I
can
probably
turn
it
into
an
RFC
eventually,
but
basically
it's
extending
the
ignore,
ignore
script,
flag
or
Norse.
Myths
fled
to
be
extensible.
So,
basically
right
now,
if
you
use
the
ignore
scripts,
and
also
this
is
something
your
team
can
do
right
now.
B
But
if
that's
something
that'll
help
your
team.
That
might
be
something
you
want
to
look
at.
Do
I
did
follow
up
with
you
on
that,
but
I've
proposed
basically
an
extension
to
that
where
it's
ignore
and
then
the
script
name
so
like
in
your
case
it
would
be
a
ignore,
install
written
which
would
effectively
allow
you
to
have
a
little
bit
more
customization
around
that
and
control
I've
been
discussing
with
the
NPM
team.
They
seem
unconvinced
about
why
it
would
be
needed
or
why
it
would
be
useful.
B
So
if
you
have
that
kind
of
feedback,
that
would
be
super
nice
to
get
your
feedback
in
that
thread.
I
posted
that
in
the
in
the
zoom
chat,
and
it's
all
for
community
listeners,
it's
NPO
dog
community,
and
that
it's
on
MP
about
community
and
it's
the
thread
is
add-
ignore
script
scripts
in
in
the
ideas
category.
E
E
F
Totally
agree
with
that
and
we
do
have
us,
we
do
have
a
standard
practice
on
how
to
do
that,
but
they're
there.
You
know
that
teams
who
who
prefer
to
run
their
own
no
development
on
their
own,
so
they
do
everything
on
their
own
land
that
subtract
one
of
the
practice
they
do
every
time.
I
see
some
mentions
that
I.
The
first
thing
I
do
like
you
cannot
do
that.
F
E
E
As
a
theme
for
this
specific
problem,
though,
it
might
be
very
good
to
have
some
defined
resources
on
how
to
define
a
deployment
pipeline
to
mitigate
the
problem.
Is
that
the
way
people
everybody's
doing
it?
Okay?
So
it's
just
a
matter
of
writing
this
thing
down
and
setting
out
to
set
up
a
proper
pipeline.
Yep
totally
agree.
Yeah.
A
E
C
B
I
mean
in
that
case
you
would
build
the
you
would
I
mean
you
shouldn't
yeah.
You
would
be
putting
the
in
node
modules
directory
inside
of
the
container
or
installing
it
and
and
in
a
multi-stage,
build
and
then
using
the
final
kind
of
finally
built
container
and
shipping
that
part
to
production
exactly
and
so
like
yeah.
You
still
wouldn't
be
NPM
installing
in
production,
yeah.
A
F
A
A
Okay,
I
did
ask
in
the
chat
I
about
a
few
minutes.
Five
minutes
ago.
I
did
paste
into
the
chat
for
a
YouTube
saying.
If
there's
any
questions,
please
ask
them
now:
I,
don't
see
anything
so
I
think
we
don't
have
any
QA
this
week.
So
thanks
for
everybody
who
attended
and
thanks
to
everybody
who
took
some
actions,
I'll
capture
them
in
the
minutes
and
send
those
out
and
we'll
talk
in
two
weeks
again
and
obviously
through
github.
Hopefully
we
can
make
some
good
progress
between
before
that.