►
From YouTube: Package Maintenance Team meeting - July 28 2020
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
Maintenance
team
meeting
for
july
28th-
and
I
guess
I
should
now
say
working
group
since
the
working
group
has
been
chartered
be
four
weeks.
Sorry
go
ahead.
Oh
that
was
me
before
we
get
started.
Does
anybody
have
any
announcements
that
they'd
like
to
share.
A
This
was
opened
by
notter
and
I
guess
it
was
suggesting
it
was
asking
for
feedback
on
the
concept
of
you
know,
providing
some
way
for
maintainers
to
be
able
to
identify
that
a
vulnerability
doesn't
apply
to
their
package,
because
you
know,
we've
seen
some
some
recent
recent-ish
cases
where
you
know
vulnerabilities,
without
caused
a
fair
amount
of
work
for
maintainers
and
in
in
many
cases
they
really
didn't
even
apply
to
the
the
package
because
they
weren't
using
the
vulnerable
bits-
and
I
think
this
is
coming
out
of
some
of
that
discussion-
that,
like
hey,
it
would
be
great
if
there
was
a
way
to
say,
hey
I've
looked
at
this,
I
don't
think
I'm
vulnerable
well,.
B
So
I've
been
talking
with
leroy
snick
about
it
for
a
long
time
now
and
while
snick
seems
to
be
committed
to
coming
up
with
some
mechanism
to
mitigate
this
in
their
own
platform
that
only
helps
snake
users
and
less
right
unless
they
publish
that
data
in
a
way
that
npm
and
github
are
both
able
to
and
willing
to
access
and
use
so
like.
But
when
I've
had
this
discussion
with
npm
ever
since
npm
audit
has
existed,
I've
brought.
C
B
To
them
every
every
time
this
happens,
the
pushback
has
essentially
been
like
yeah
that
sucks,
but
like
we
need
people
to
be
able
to
trust
the
warnings,
and
that
means
like
like
and
essentially
like
we,
everyone
agrees.
We
want
people
to
be
able
to
trust
the
warnings,
but
some
folks,
like
myself,
think
that
false
negatives
erode
that
trust
and
other
folks
are
more
concerned
with,
like
false
positives
eroding
that
trust.
B
In
other
words,
some
of
the
folks
at
npm
seem
to
be
more
concerned
with,
with
letting
real
vulnerabilities
go
unreported
right,
whereas
I
am
more
concerned
with
undermining
the
entire
attention.
People
pay
to
security
advisories
by
letting
pretending
that
that
non-vulnerabilities
are
vulnerabilities
and
those
two
positions,
while
both
valid
in
various
ways
and
you
know,
are
sort
of
in
conflict
right
and
this
whole.
A
A
A
No
exactly
and-
and
I
guess
you
know
I
saw
some
of
the
discussion
in
there
was
around
well
what,
if
you
don't
trust
the
package
maintainer
to,
but
it
does
sound,
you
know
it.
I
I
think
the
point
was
made
that
the
package
maintainers,
if
they're
you
know
untrustworthy,
have
a
much
more
direct
way
to
cause.
A
B
If
you
depend
on
a
malicious,
maintainer,
you're
screwed
right
like
yeah,
it's
done,
but
the
other
one
is
a
more
tactful
term
than
incompetence.
Just
you
know
sure
lazy.
B
Anything
like
that,
but
but
just
a
maintainer,
that
it
ends
up
being
less
rigorous
for
whatever
reason
right,
and
that,
as
I
think,
where
this
concern
is
coming
from,
is
essentially
that
somebody
will
look
at
their
library
and
the
cve
and
be
like
well
that
doesn't
apply
and
then
no
one
sees
it
again
and
then
in
fact,
it
does
apply
and
the
any
system
that
empowers
a
security
aware.
B
B
Alerts
that
would
solve
both
of
those
problems
at
once
and
from
my
perspective,
as
a
security
aware
maintainer,
I
hope
I
don't
want
my
consumers
to
ever
see
a
security
alert
for
my
packages
period
like
in
other
words,
I
want
first
to
be
given
the
chance
to
fix
it
before
they
ever
see
it
sure,
and
then
I
only
want
them
to
see
an
alert
if
the
vulnerability
actually
affects
them
and
like
I
you
know-
and
I
do-
and
I
don't.
B
This
obviously
requires
that
I
be
responsive
right
like
I,
it's
fine
if
they
see
an
alert,
if
I'm
out
of
town,
I'm
not
paying
attention
but,
like
you
know
the,
but
not
every
maintainer
is
necessarily
going
to
be
that
on
top
of
it
or
that
concerned
about
it
I
mean
the
like.
The
lodash
maintainer
correctly
believes
that
the
there
was
a
cve
that,
like
just
hadn't
for
lodash,
that
that
was
the
I
think,
the
most
recent
thing
and
like
the
loadout
maintainer,
just
didn't
see
it
as
a
problem
because
it
wasn't
a
real
problem.
B
The
actual
problem
was
caused
by
the
alert
not
by
the
cve,
but
and
so
his
response
for
better
or
worse
was
to
ignore
it.
After
a
few
months,
there
was
somebody
who
had
maintainer
access
who
published
an
update
not
to
not
because
the
problem
actually
necessarily
needed
fixing,
but
because
everyone's
builds
needed
to
stop
spewing
audit
warnings
right
right
but
like
had
that
not
been
available.
C
B
I
don't
know
it's
just
it's
a
really
hard
problem
and
I
just
don't
know
how
it
can
be
solved
unless
we
get
enthusiastic
stakeholders
in
npm
github
and
you
know,
snake,
etc,
right
to
all
be
involved
with
coming
up
with
something.
C
A
Help
solve
the
difficult,
so
I
I
definitely
agree.
I
I
you
know
in
terms
of
concrete
steps
for
this
team.
Do
we
do
we
think
we
need
to
do
anything
beyond.
You
know
continue
the
discussion
in
the
issue
itself.
You
know,
and
my
only
the
other.
The
other
thing
I
was
thinking
about
myself
is
like.
Is
this
the
place
where
we
should
have
this
discussion
is?
Is
it
that
you
know,
should
we
as
a
package
maintenance
team,
try
and
pull
together
these
enthusiasts
stakeholders
and
try
and
make
them
enthusiastic.
A
The
the
other
thought
you
know,
the
collaboration
spaces
proposal
that
I
have
at
the
openjs
foundation
is
maybe
another
place
where
the
group
could
come
together
now,
that's
only
if
it
needs
like
sort
of
its
own
space
versus
just
fitting
in,
like
you
know,
issues
or
discussion
underneath
the
package
maintenance
team.
A
B
It
really
might
take
as
few
as
one
person
from
each
of
those
companies
right
who
wants
to
make
it
happen
like
it
does,
it
doesn't
even
have
to
be
both
of
them
if
one
of
these
players,
if
one
of
these
two
players
fixes
it
every
other
player,
is
going
to,
because
that
is
how
like
free.
You
know,
that
is
how
the
market
works
right.
C
B
B
A
B
B
Time,
okay,
yeah,
exactly
and
and-
and
I
mentioned
to
lauren
as
well-
that
if
snick
makes
it
available
such
that
github
and
npm
can
use
it.
They
may
do
that
right
and
right.
You
know
if
snick
is
actually
willing
to
do
the
work,
to
collect
this
data
and
share
it
then,
like
that
positions
them
better
in
the
ecosystem
anyway.
A
Even
be
that
like,
if
you
had
a
tool
like
that
that
says
you're
not
it
doesn't
apply
to
you
that
addresses
the
you
know,
not
people,
you
know
maintainers,
who
aren't
as
security
aware,
conscious
whatever
making
a
choice.
If
they
can
say
well,
this
tool
tells
like,
even
if,
even
if
it's
that
they
need
to
flag
it
themselves,
but
they
could
say
I'm
flagging
this,
because
this
tool
has
told
me
it
doesn't
apply.
That
adds
to
the
sort
of
safety,
credibility.
A
C
I
had
a
question
I'm
fairly
naive
to
a
lot
of
this,
but
I
was
just
wondering
if
kind
of
to
jordan's
point
is:
is
there
also
like
a
d?
I
I
I
I
assume,
maybe
there's
like
a
degree
of
education
that
needs
to
happen,
because
if,
if
the
cbe
was,
I
guess
better
at
explaining,
like
if
you're
in
this
situation,
if
you're
like
one
degree,
two
degree,
five
degrees
from
this
low
dash
dependency
like
that
increases
or
decreases
your,
I
guess,
responsiveness
to
it.
Is
it
something
in
the
cv
process?
B
Notifications,
so
the
cve
text
itself
is
usually
pretty
good
about
explaining
this
stuff,
like
about
like
in
these
subset
of
cases
using
this
package
as
a
problem
right.
The
the
issue
is:
is
that
there's
nothing
in
the
cbe
system
to,
for
example,
discern
which
of
the
48
apis?
This
package
provides
are
actually
insecure.
B
Nor
is
there
something
in
the
javascript
just
to
your
ecosystem,
to
say
which
of
the
apis.
This
package
provides.
Are
you
using
right
so
like
there's
just
no
way
to
from
like
this
is
one
of
the
great
things
about
small
modules
and
the
problems
of
big
ones?
Is
that
that's
the
only
boundary
we
have
to
cleanly
indicate
if
something
affects
you
or
not?
B
So
that's
part
of
it,
but
the
other
part
of
it
is
the
security
industry
in
the
same
way
as
like
programmers
used
to
be
incentivized
to
produce
more
lines
of
code
and
we've
all
learned.
Why
that's
a
bad
idea?
The
security
industry
is
incentivized
to
produce
cves
that
have
the
broadest
impact
possible,
and
so
you
know
there's
that.
B
That
phrase
is
that
it's
impossible
to
convince
a
man
of
something
when
his
living
depends
on
him,
not
believing
it
something
to
that
effect
and,
like
the
I'm
misquoting
it
I'm
sure,
but
something
like
that
so
like
out
of
no
malice
alone,
but
like
I
think,
it's
really
difficult
to
convince
folks
in
the
security
industry
that
overly
broad
cves
are
worse
than
than
missing
a
vulnerable,
a
vulnerable
like
call
site,
and-
and
that's
that's
the
philosophical
discussion
I
hinted
at
in
the
beginning
and
like
I
I
I
I
yeah
it's
just
the
what
I
know
for
sure
is
like,
as
in,
for
example,
I
maintain
a
bunch
of
popular
eslint
plugins
and
the
catastrophic
regular
expression
ones
the
attack
vector.
B
That's
not
an
attack
vector
right,
like
all
you're
gonna
do
is
when
you
put
that
in
your
ci
is
not
gonna
pass
right
like
who
cares,
but
there
is
no
way
for
me
to
block
that
cde
from
applying
to
the
eslint
plugins
right,
and
so
what
that
means
is
that
I
have
to
make
some
sort
of
update
or
just
leave
the
the
thing
alone
and
like
so
the
cve
is,
is
valid
in
the
sense
that
there
is
a
vulnerability
here
right,
like
user
data,
can
be
cause
bad
things
to
happen,
but,
like
the
real
issue,
is
that
that's
okay,
right,
like
something
where
you
have
to
attack
yourself,
is
not
a
vulnerability
conceptually,
but
the
security
industry
as
it
treats
it
as
one
the
one
with
minimist,
where
you
could
craft
some
command
line.
B
A
Talking
about
that
was
part
of
the
problem
may
be
that
it's
only
showing
one
side
of
the
information.
So
like
one
approach
to
this
is
like
you
tag
it
and
just
say
this
is
not
applicable
to
my
module
right,
but
maybe
something
in
between
where
you
can
tack
on,
like
the
maintainer,
can
tack
on
and
say
you
know:
I've
reviewed
the
cve
and
it
does
not
apply
to
my
module
for
blah
blah
blah
blah
blah,
and
you
know
consumers
could
choose
whether
they
wanted
to
automatically
act
on
maintainers.
A
Saying
that
you
know
hey,
I
don't
think
it
is
an
explanation
or
simply
show
that
there
was
a
vulnerability
as
well
as
the
explanation
from
the
maintainers
that
says,
oh,
but
I
don't
think
this
applies
so
today
you
just
get
here
are
all
my
vulnerabilities
and
that's
all
you've
got
right
and
I
think
in
organizations
they're
like
I,
you
know.
A
The
only
thing
I
can
ask
for
is
for
that
to
not
be
there,
because
I
don't
have
any
more
information
where
maybe,
if
it
was
like
here's
the
vulnerabilities,
here's,
the
responses
from
the
maintainers
that
say
why
this
isn't
actually
applicable
would
provide
more
information
to
the
end
user,
and
you
know
the
people
who
then
demand
that
they
be
fixed
to
say.
Okay,
well,
we're
comfortable
that
it's
fine.
B
C
B
To
start
allowing
this,
but
like
right,
even
at
the
top
level,
there's
no
way
for
me
to
say.
I
know
that
this
cbe
doesn't
apply
to
me
right
right
and,
like
that's
even
separate
from
the
like
package,
maintainer
level,
and
so
there
isn't.
That
mechanism
would
have
to
exist.
For
that
maintainer
explanation
to
be
to
help
right,
but
then
the
other
thing
is,
I
suspect,
if
that
exists,
if
everyone's
like
well,
you
can
trust
the
maintainers,
you
already
trust
or
not.
I
think
people
you
know
and
do
more
work.
B
A
A
B
Yeah,
so
I
don't
want
to
discourage
anyone
from
continuing
to
try
to
do
stuff.
I
just
like
personally
feel
like
I've
largely
exhausted.
My
options,
and
all
I
can
do
is
keep
bugging
people
whenever
this
comes
up,
but
other
people
are
like,
I
hope,
can
help,
because
I
want
this
yeah.
A
D
To
try
so
when
you
volunteer
for
this
committee,
you're
really
volunteering
to,
as
I
just
said
before,
to
grapple
with
the
harder
esoteric
moral
dilemmas
and
if
somebody
somebody
doesn't
put
their
hand
up
and
say
well,
yeah,
I'm
going
to
address
it,
it
won't
get
addressed
and
it
will
become
a
problem
and
it
it
is
already
a
problem.
D
We
know
this
that
right,
I'm
not
going
to
speak
for
everybody,
but
I
imagine
a
lot
of
people
have
similar
attitudes
to
security
alerts,
because
the
sheer
number
of
them
they've
lessened
their
sort
of
sterling
value,
and
that
needs
to
be
remedied
like
if
somebody
says
you
know
the
sky
is
falling.
D
E
In
terms
of
what
this
group
can
do,
is
I
don't
think,
there's
any
best
practices
to
the
recommendations.
I
mean,
as
jordan
rightly
points
out.
There
is
no
obvious
way
to
as
a
consumer
of
the
package
to
mark
certain
audit
failures
to,
as
as
something
you're
bound
to
ignore,
or
even
silence
them
for
a
duration
which
something
like
snake
file
snake
policy
file.
E
It
allows
you
to
silence
a
certain
vulnerability
for
a
duration
of
time
right
and
then
it
starts
alerting
again
if
it
hasn't
been
fixed
which
allows
you
to
sort
of
at
least
continue
with
the
builds.
But
aside
from
that
dealing
with
that
in
in
a
way
of
of
the
cells
in
a
way
of
ignoring
things,
are
there
any
other
best
practices
that
are
defined
as
a
consumer
that
you
can
do
so
that
we
can
at
least
teach
people
how
you
deal
with
that
as
a
consumer?
E
When
you
see
these
alerts
and
when
you
know
that
these
are
either
not
going
to
get
fixed
or
are
going
to
get
fixed
after
a
while
or
there's
debates-
and
at
least
then
you
can
guide,
people
to
you
know
address
that
on
their
side,
which
is
also
something
that
you
know
we.
We
have
to
sort
of
accept
the
fact
that
vulnerabilities
are
there
and
as
somebody
who
has
to
look
into
snake
failures,
quite
often
on
in
in
in
the
day
job.
E
If
you
start
off
with
a
base
ubuntu
container,
which
is
ubuntu
and
mlps
ubuntu
version
you
could
have
even
in
the
base
container,
you
would
have
at
least
100
vulnerabilities
before
you
actually
start
installing
anything
right.
Your
report
would
be
100
vulnerabilities
and
I
I
pointed
out
that
out
to
some
folks
in
snake
as
well,
that
you
know
it's
kind
of
hard
to
even
begin
to
assess
the
impact
of
that
right.
E
But
this
is
a
starting
point
for
the
os,
and
yet
we
are
in
a
situation
where,
as
a
javascript
ecosystem,
which
is
huge,
we
are
saying
that
you
know.
E
Oh
one
package
has
one
vulnerability
which
is
in
non-vulnerability
and
then
all
of
a
sudden,
all
of
the
ci's
go
red
and
there's
you
know
something
to
be
said
that
maybe
we're
doing
something
wrong
in
there
as
well,
and
maybe
there's
you
know
even
even
calls
for
discussion
from
the
wider
community,
because
you
know
there's,
there's
a
random
guy
coming
in
and
saying:
oh,
I
have
a
red
build,
please
fix
and
they
never,
you
know
come
back,
but
some
of
those
people
they
they
would
probably
have
an
opinion.
A
Right,
certainly,
I
I
like
the
the
the
embudu
case
that
you
mentioned.
I
I
think
that
causes
similar
heartburn
to
some
organizations.
Right,
like
I
know,
certainly
like
you
know
the
more
I
work
with
the
people
at
red
hat,
the
more
you
know,
I'm
there's
a
pretty
strong
focus
on
their
containers,
not
having
reporting
issues
and
internally
you
know.
A
I
I
I
think,
like
that,
that
sort
of
like
having
a
good
way
where
it's
it's
just
not
like
you,
you
don't
even
see
the
vulnerability,
will
help
to
help
a
lot
of
teams
because
actually
trying
to
go
to
the
security
organizations
and
saying
oh,
this
one
really
isn't
an
issue
doesn't
seem
to
work
very
well.
No,
you
need
you
need
some
more
official
backing
like
I
think
if
there
was
in
a
way
that
said
well
look,
but
the
maintainer
said
this
didn't
apply.
C
Well
is
that
where
the
I
mean
again
naive
observer
here,
but
is
because
I
heard
jordan
make
that
point
as
well.
Is
there
some
sort
of
middle
ground
where
the
tooling
could
help
where,
like
the
cbe
is
broad,
but
your
package
json
is
very
specific
and
somewhere
you
could
find
the
intersectionality
of
the
apis
that
are
statically
analyzable
from
your
code
and
basically
like
that
could
thread
the
needle,
be
like
oh
wow.
I
analyzed
your
code
and
yeah
you
hit
seven
of
these
ten.
C
You
know
flagged
api,
so
that
and
then
there's
an
algorithm
that
helps
calculate,
and
then
you
with
that
and
with
that
score.
If
that's
like
community
effort,
then
you
could
say
like
well.
The
reason
why
I
think
this
is
an
issue
is
because,
when
you
dig
into
the
code
I'm
not
vulnerable
based
on
you
know
the
use
cases
presented
in
the
api.
It's
you
know,
I'm
using
the
other
api,
not
the
other,
so
could
go
both
ways.
So
just.
A
B
Mean
there's
whole
businesses
built
on
the
algorithms
you're
describing
owen
right
like
that's,
that
is
snick's
business
model.
Is
that
they're
doing
more
in-depth
analysis
of
the
code?
And
you
know
so
like
it's
great,
but
I
I
would
imagine
a
snake
representative
would
say
that's
why
you
should
pay
for
our
product.
A
It
tells
you
that
you're
not
vulnerable,
which
is
great,
but
then
there's
no
way
for
you
to
pass
that
on
to
the
consumers
of
your
module
right,
like
is,
which
is
what
we're
talking
about
now.
You'd
like
to
say:
we've
invested
the
effort
or
the
money
by
you
know
paying
somebody
to
to
run
their
analysis,
and
we
know
we're
not
we're
not
vulnerable.
A
C
That
github
is,
you,
know,
kind
of
in
the
middle
of
both
of
it.
So
so
yeah,
I
don't
know
if
it's
just
I
mean
yeah,
it's
probably
not
something
this
team.
Well,
it's
surprising.
This
team
can
push
forward,
but
I
require
the
combination
of
the
right
people
and,
like
some
sort
of
prototype
concept
of
you
know,
because
I
I
get
yeah
I
mean
I
get.
C
Stick
has
its
market
position,
but
since
google,
since
get
ups
doing
all
the
hosts
and
npm
is
doing
all
the
publishing,
you
know
they're
more
or
less,
you
know
facilitating
the
production
at
both
ends.
So
you
know.
A
B
Right,
I
mean
it's
also
worth
noting
that
npm
7
is
both
likely
to
at
some
point,
add
the
api
we
talked
about
about,
like
as
a
top
level
app
owner
being
able
to
indicate
which
reports
you
don't
care
about,
but
also,
I
believe
that
their
npm
audit
output
is
going
to
change
so
that
if
you
have
a
transitive
dependency,
that
has
a
cve
but
the
like
something
farther
up
the
chain
could
be
updated
and
it
would
fix
it
like.
B
B
So
I
I
have
a
feeling
that
it's
gonna
be
improved,
but
it's.
I
think
it
would
still
be
highly
helpful
to
have
a
meeting
like
you're
talking
about
with
miles
and
lauren,
and
ideally
someone
from
npm
as
well
to
try
and
figure
out
a
way
that
maintainers
can
specifically
say
for
my
package.
This
cve
doesn't
apply
right,
yeah,
github
and.
D
B
I
don't
know
if
npm
offers
any
early
warning
to
maintainers
the
way
that
the
cve
system
often
does
right
like
so
it
would
be
really
great
to
be
able
to
say
like
even
if
the
cve
is
not
on
my
package.
If
it's
on
any
of
my
dependencies,
please
give
me
a
heads
up
like
at
least
an
hour
before
the
public
sees
it.
You
know
right,
because
then
I
have
the
opportunity
to
fix
it
before
then.
A
A
A
A
A
Snick
snick
to
our
next
meeting.
Yes,
yes,
maybe
miles
darcy
loren
for
a
discussion
to
see
if
there's
any
opportunity
to
work
together
on
the
issue.
A
Yes,
no
sounds
good.
Okay.
I
will
paste
that
and
we'll
plan
to
to
see
if
we
can
get
them
to
come
to
the
next
meet
and
talk,
so
we've
actually
used
quite
a
bit
of
good
time.
That
was
a
good
discussion,
though
so
I'd
suggest
we
move
on
to
the
next
issue.
Unless
anybody
has
more,
they
want
to
add
to
that
one,
no
okay.
So
the
next
one
is
defining
documenting
a
process
for
request
for
help
rfh.
This
is
373.72.
A
C
C
There's
now
kind
of
like
an
entry
point
if
any
maintainers
looking
for
like
a
one-stop
shop
for
what
we
have
as
a
group
to
offer,
and
hopefully
that
will
expand
over
time
but
yeah
I'll
remove
the
label.
A
Okay,
that
sounds
good.
The
next
one
is
like
you
don't
have
to
remove.
Now
that
it's
closed,
it
should
just
not
show
up
on
the
issue.
I
think
it
must
have
been
that
it
was
closed
after
the
issue
was
generated.
That's
all.
C
A
The
next
one
is
pkgs
org
for
workgroup
supported,
tooling.
This
is
271.,
you
know
it's.
It's
all
been
approved,
we've
been
chartered
it's
just
sort
of
moving
along
with
sort
of
moving
in
the
direction
of
establishing
the
org,
as
we
suggested
making
sure
it's
ready
to
move
over
to
the
node
organization.
A
A
We
don't
really
have
a
way
to
you
know
under
the
the
previous
governance
to
to
to
select
the
initial
set,
but
I
I
just
selected
it
based
on
you
know.
What's
what
came
in
in
the
new
governments,
in
terms
of
who
I
I
thought
met,
the
requirements
and
kind
of
had
it
in
need
does
need
slash
desire
to
help
manage
the
pkgs
organization.
A
A
We
could
we
can
always
change
it
too
if
we
think
it's
stretching
out,
but
that
yeah
we'll
leave
that
for
now
and
then
you
know
we'll
basically
do
that
and
then
I
think
the
next
sort
of
thing
we
need
to
just
audit
the
the
pkgs
orgs
to
make
sure
we
think
they
have
all
the
licenses
and
everything
that
we've
said
they
would
and
then
we
can
probably
plan
the
move
of
the
org
over
to
the
node.js
or
the
yeah
move.
It
move
the
org
over
the
node.js
project.
C
Just
a
quick
question:
was
it
14
days
or
four
approvals
or
14
days.
A
E
A
A
A
A
So
then,
the
next
one
in
the
agenda
is
next
steps
on
support
levels
in
package.json
that
one
we've
landed
a
number
of
updates.
I
have
a
pr
open
which
has
the
documentation
updates
and-
and
you
know,
the
thing
I
want
to
mention
here
is-
I
think
after
we've
landed
that
those
documentation
updates,
which
I'm
hoping
will
be
in
the
next
few
days.
A
A
Yep,
okay,
thanks
and
if
anybody
has
a
chance
to
read
the
doc
that'd,
be
great
thanks
to
jordan
for
taking
a
look
and
pointing
out
the
thing
about
mpx.
That
was
good.
I
added
that
in
found
a
bug
that
in
the
dependencies
like
since
I've
installed
it
to
test,
they
didn't
didn't
fail,
but
when
I
tried
mpx,
one
of
the
dependencies
was
in
the
wrong
place,
so
cool
okay.
So
let's
move
on
the
next
one
is
a
suggested
modules
from
pkgs
that
could
benefit
from
cicd
implementation
via
github
actions.
For
hard
case
examples.
D
That
was
mine,
so
the
feedback
from
the
testing
document
is
glenn.
You
need
actually
hard
cases
and
I
said
yeah
those
will
exist
in
the
integration
ci
cd
document,
but
I
think
what
we
need
to
do
is
actually
I've
got
cases
I'm
working
on
on
as
a
part
of
the
express
triage
team.
For
basically,
you
know
get
action
if
I
create
docker
files
run
them
integration
test
them
with
order
differently.
D
You
know
postgres
redis
just
do
basic
stuff,
but
I
think
if
we
choose
our
own
module
to
say
this
is
a
an
example
of
how
to
do
it.
So
if
we
you
give
me
one
in
pkgs
that
we
want
to
do,
I
will
go.
Do
it
using
github
actions,
I
will
run
all
whatever
is
being
done
on
it.
I
will
turn
it
into
the
dockerfile.
I
publish
it
to
my
own
one
I'll,
provide
lots
of
examples.
D
We
can
work
on
them
and
we
will
run
integration
tests
on
it
and
say
this
is
an
example
of
how
to
do
this
case
and
I'm
after
which
ones
we
want
to
do
so.
We
want
to
refer
to
them.
D
We
want
to
refer
to
hard
examples
in
the
ci
cd
document
and
say
this
is
a
case
of
how
to
do
it
so
dominic,
because
you've
got
to
speak
up
now,
because
this
is
your
ask-
and
I
think
it
was
a
good
ask,
don't
just
say:
go:
do
it
on
github
actions
or
or
circle
ci
cs.
This
is
a
case
of
how
to
do
it.
This
is
an
example.
D
This
is
using
the
free
tooling.
This
does
everything
you
need
to
do.
You
may
copy
this,
and
this
might
be
a
good
use
case.
E
Yeah,
so
I
think
we
have
several
repos
there
and
I
think
you
can
just
go
and
do
either
one
of
those
what
I
haven't
done
is
so
I
will
be
starting
work
on
detect
mode
support,
reading
from
github
actions
as
well.
So
we
may
as
well
add
one
on
detect
note
support,
because
that's
what
I
use
for
my
test
house,
there's
so
many
bugs
I'm
sorry
real
bugs
on
ammo
doors.
E
So
yeah
the
tech
note
support,
could
use
a
github
actions
example,
but
what
I'm
also
thinking
is
that
maybe
we
should
just
start
preparing
for
the
next
step
as
well
and
see
how
we
can
build
out
the
I
configured
actions,
because
that's
something
I
haven't
really
thought
about
deeply
or
done
enough
research.
So
we
do.
We
do
have
the
ci
config
travis,
which
is
you
know,
yeah.
E
E
I
don't
remember
off
the
top
of
my
head
right,
so
if
we
could
start
building
that
out
and
then
that
could
be
a
good
example
of
how
you
set
up
a
ci
on
your
on
your
repo
on
your
package
that
you're
working
on,
but
I
also
have
to
get
back
to
to
to
one
one
of
my
pet
peeves.
E
There
is
that
we
also
have
some
wording
there,
which
says
the
icd
pipeline,
and
I
I
specifically
have
a
problem
with
the
word
pipeline,
because
it
could
mean
a
lot
of
things
to
a
lot
of
people.
So
if
we're
going
to
define
what
a
cicd
pipeline
is,
maybe
we
should
see
what
it
means
to
us
and
what
it
means
in
the
context
of
a
node
package.
D
Yeah,
I
agree,
I'm
less
worried
about
the
words
but
more
worried
about
there
being
real,
hard
examples
that
people
can
go
to
meaning
like
this
is
how
you
do
it
well.
This
is.
A
D
A
D
A
D
What
I'm,
what
I'm
referring
to
is
a
little
bit
more
than
that.
That's
the
kind
of
thing
you
do
with
travis.
What
I'm
really
talking
about
is
you
you
do
this.
You
run
your
integration
tests,
but
then
you
see,
if
you
you
know,
you
want
to
publish
10
p.m.
You
want
to
build
a
docker
image
with
your
module
and
then
you
actually
run
your
module
in
a
dock
image
to
a
full
integration
test.
Does
it
work
rather
than
just
running
that
a
full?
D
B
D
You
know
you
know:
you'd
have
to
you'd
have
to
actually
when
you
build
an
image
to
actually
run
it.
You'd
have
to
actually
run
then
your
if
it
will
say
like
you're
you're
talking
about
a
ci
cli
tool,
we'd
actually
have
to
run
the
cli,
but
actually
run.
Actually,
you
know
do
proper
integration
tests
rather
than
just
unit
tests.
B
E
E
I
don't
think
that
many
people
do
it
whether
we
want
to
strongly
recommend
it.
I
I
don't
think
that
a
lot
of
people
should
do
it,
but
I
can
take
back
the
example
of
the
techno
support.
I
don't
have
an
automated
thing,
but
I
do
have
a
very
small
short
script,
which
just
executes
the
thing
and
just
and
what
I
check
before
I
publish
is
that
at
least
it
doesn't
crash
when
it
does
these
very
basic
things
right.
E
So
I
I
don't
think
it's
a
bad
thing
to
recommend
and
if
we
can
make
it
easy,
then
it's
nice,
it's
never
easy.
Like
you,
the
higher
you
go
up
the
test
pyramid,
it
gets
harder
but
yeah.
If
we
want
to
write
that.
A
Up,
but
I
guess
like
I'm
familiar
with
you
know,
if
you're
building
an
application
using
the
various
tools,
those
people,
you
know
and
deploying
that
application,
those
there's
there's
often
a
ci
cd,
ci
cd
pipeline,
you
know
using
tecton
or
something
else
that
says.
Okay,
I'm
going
to
take
all
my
components,
not
only
I'm
going
to
test
them,
I'm
going
to
publish
you
know
package
it
up
into
the
way
I'm
going
to
deploy
it
to
to
to
production.
A
B
I
think
we're
talking
about
a
few
different
things
like
if
you're
generally,
I
think
of
the
things
as
there's
apps
and
there's
packages.
Apps
are
deployed,
packages
are
published
and
regardless
of
the
fact
that
when
you
have
an
app,
you
may
package
it
up
into
an
artifact
and
quote
publish
that
to
production
like
realistically,
that's
not
what
I
think
this
group
is
focusing
on.
That's
like
it.
You
know.
Certainly
you
may
have
a
pipeline
there.
You
may
have
integration
tests
right,
but
the
but
for
a
published
package
that
other
things
consume
or
invoke
right.
B
The
I
think
that
we
that
the
scope
of
our
group
should
be
like,
first
of
all,
documenting
things
that
are
already
done
right
right,
like
what
does
the
ecosystem?
Do?
Here's?
How
you
do
that,
and
here
is
why
we
suggest
this
approach
right.
Also,
if
there's
any
new
thing,
we
can
add
like
the
support
stuff,
which
is
largely
like
little
to
no
configuration
which
is
sort
of
like
here's,
a
tool
that
no
one's
running
really.
But
if
you
run
this,
you
get
these
extra
benefits
go
nuts
right
like
that's
something
we
could
recommend.
B
I
think
that
it's
a
tall
order
for
our
group
to
recommend
that
people
write
a
whole
new
brand
of
tests
to
like
to
do
integration
like
not
that
it's
a
bad
idea
or
that
people
shouldn't
do
it.
They
probably
should-
and
it's
probably
a
great
idea
but
like
I
think,
it's
a
really
tough
thing
like
we're
still
trying
to
get
everyone
on
like
yep
run,
rci.
D
B
D
Agree-
and
I
probably
think
you're
right
for
this
group,
but
I
do
believe
that
will
be
the
way
so
github
actions
offer
this.
It's
free
and
a
lot
of
the
things
that
you
already
see
that
you
have
in
travis
for
lts
and
so
forth.
They
don't
exist
yet
in
github
actions,
there's
a
rather
limited.
You
know
you
might
see
the
most
400
stars
or
50
stars
it
that
there's
you
know
a
recommendation
for
a
github
action.
D
A
D
I
think
the
obvious
thing
is
just
as
probably
at
this
stage
is
to
make
sure
that
they
have
a
matrix
set
up
and
they
run
integration
tests
same
things
that
we're
doing
with
travis,
but
it
does
hold
the
possibility
and
I'm
doing
it
now
and
some
of
the
express
things
to
you
know
you
can
really
build
your
image
and
run
your
image.
I
mean
it's
obviously
docker,
so
it's
all
line
x.
So
there
are
some
limitations,
but
you
can
actually
run
the
code
and
run
integration
tests
on
it.
D
So
it's
more
like
the
sit
gym,
type
thing
right,
but
obviously
it's
it's
has
limitations
because
you're
not
in
control
of
the
environment,
but
it
does
offer
that.
But
we
should
move
on
because.
A
D
C
D
C
Good
what
it's
worth,
but
I
I
think
I
understand
the
the
use
case
you're
presenting
it
definitely
there's
I've
seen
apps
like
like,
I
think,
webpack's
a
good
example
where
a
lot
of
they
have
tests.
They
refer
to
them
as
test
cases.
They
literally
like
stuff
out
like
a
file.
A
file
b,
run
webpack
on
this
directory
and
literally
verify
the
cumulative
output
yep,
and
I
think
you
see
a
lot
of
that
with
like
maybe
static
generator
sites.
C
Like
you
know,
you
want
to
literally
you
might
unit
test
your
internals,
but
you
might
still,
like
literally,
want
to
mock
out
a
directory
of
like
some
markdown
and
write
your
your
command
line
tool
and
make
sure
it
spits
out.
You
know
html
on
the
other
side,
so
yeah,
I
think
maybe
I'm
also
open
for
an
issue
like
on
that
particular
strategy
that
could
be
done
after
one
of
these,
and
I
could
definitely,
I
think
I
know
what
you're
you're
going
at,
maybe
not
to
lose
it.
B
C
A
Yeah,
the
testing
that
that
you
describe
in
terms
of
like
running
the
command
line
tools,
that's
what
we're
doing
in
part
in
the
support
testing
and
that
it
does
run
the
client
on
like
here's,
the
input
that
we
expect.
Here's
the
output
that
we
expect,
and
so
there's
probably
even
some
overlap
from
that
perspective.
D
I'll
I'll
I'll
put
in
the
agenda
for
another
time
to
show
you
but
you're,
probably
right.
I
think
let's
get
them
to
do
different,
let's
do
lts
and
unit
tests
and
the
basics.
I
sometimes
run
away
of
myself
expecting
too
much.
I
think
we've
got
to
get
majority
of
people
to
do
the
basics.
D
Get
out
now
I've
avoided
that
in
yeah
the
camps
and
now
we
don't
want
to
sell
that
war
again.
A
Right,
okay,
so
let's
we're
yeah
we're
down
to
five
minutes.
So,
let's
move
on
to
the
last
issue,
which
is
testing
doc
final
review
number
370.
D
Okay,
that's
have
I
linked
it
to
the
wrong.
One
hang
on
that
looks
like.
D
C
Well,
the
only
thing
I
had
was
just
removing
the
draft
parentheses
table
of
contents.
I
think
it's
good,
I
think
what
you
have
is
you
know
enough
to
remove
the
draft
labels.
D
D
A
D
Okay,
if
we're
good
with
that,
because
I
didn't
know
quite
what
to
do
with
jenny's,
because
it
was,
it
was
just
kind
of
sitting
there.
I
addressed
an
issue
here
today
and
I
want
to
get
on
to
the
cicd
open
parenthesis
pipeline
close
premises.
D
Try
ignore
the
word
pipeline,
so
we
can
refer
backwards
and
forwards
between
the
two,
because
I
think
you
know
for
basic
stuff
for
lts
in
unit
testing.
There
are
a
number
of
different
options.
You
know,
so
we've
got
github
actions,
we've
got
travis,
we've
got
circle.
What
other
ones
do
we
use?
C
D
Okay,
so
you
think
you've
addressed
all
of
tierney's.
I
think
I
think
so
I
just
today
he
didn't
like
he's
right.
He
said
the
word
guarantee
was
a
bit
strong,
so
I
changed
it
because
I
thought
yeah
that
that
probably
is
a
bit
strong
and
I
use
the
word
to
indicate
that
we
believe
it
will
work
on
the
latest
versions
of
node
rather
than
guarantee
okay,
yeah.
A
Okay,
any
other
discussion
on
that
before
we
move
on.
C
Good
stuff,
thanks
for
working
through
it.
D
Because
yeah
I
want
to
get
on
to
cicd,
actually
interests
me
quite
a
lot,
I
think
quite
a
lot
and
it
can
be
done
in
this
area.
Quite
a
lot
of
encouragement.
It
is
free
and
it
does
work,
and
the
basics
are
quite
simple,
like
we
just
encourage
people
to
do
them.
C
Yeah,
I
think
if
we
just
make
it
really
easy
for
people
to
get
pr
three
check
marks
and
a
little
you
know
little
branch
maintenance,
that'll,
be
a
nice
sweet
spot
for
jumping
off.
I
think
so
we're
almost
there.
A
Okay,
I
think
that's
pretty
much
then
we're
at
the
end
of
our
list.
I
did
want
to
thank
I'm
just
saying
rhodian
for
all's
help
on
the
support
package.
He's
done
a
number
of
investigations,
comments,
reviews
for
me,
so
thanks
a
lot
for
doing
that,
because
it's
been
very
helpful
in
moving
that
forward.
A
Thanks
thanks
and
I
guess
we'll
talk
to
everybody
next
time.