►
From YouTube: 2020-03-25-Package Maintenance Team meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
B
So
welcome
to
the
node.js
package,
maintenance
working
group
meeting
on
the
25th
of
march
2021.,
the
issue.
The
agenda
is
in
the
package:
maintenance,
repo,
it's
issue:
456
are
there
any
announcements
folks
would
like
to
make
at
the
start
of
the
session
today.
B
C
C
Will
I
break
you
and
it's
basically
a
tool
that
we're
trying
to
build
and
experiment
with
in
how
you
could
have
something
that
allows
you
to
verify
that
whatever
you're
building
does
not
break
any
downstream
dependence
that
basically
depend
on
your
package
and
there
have
been
some
tools
in
in
sort
of
similar
area
over
time.
This
does
things
a
little
bit
differently
in
that
it
tries
to
run
the
downstream
tests
of
the
dependents
using
the
tooling
that
these
dependents
use
right.
C
So
if,
if
a
dependent
is
tested
using
github
actions,
it
will
try
to
run
these
github
actions
the
way
it
approaches.
That
is
it.
Basically,
when
you
run
witty
in
your
package,
it
tries
to
link
that
version
of
that
package
that
specific
git
version
of
that
package
into
your
dependence
and
then
it
either.
Well.
C
We
don't
have
that
functionality
yet,
but
it
basically
pushes
a
branch
into
the
dependent
repositories
and
that,
in
theory,
triggers
the
ci
of
these
dependent
packages
using
the
exact
same
setup
that
they
would
be
using
if
a
regular
pr
were
to
be
opened,
which
maybe
gives
you
some
better
results,
but
also,
maybe
it
results
in
less
maintenance
and
also
spreads
out
the
usage
of
of
ci
minutes.
If
you
are
constrained
there,
so
I'm
going
to
give
a
quick
demo
of
where
we
are
right
now
we're
kind
of
approaching
mvp.
C
But
let's
see,
let's
see
where
we
are
and
let's
see
what
the
response
is,
and
maybe
we
can
start
to
on
board
at
least
some
people
to
try
it
out
in
some
other
republics.
So
what
I
have
here
is
I
created
a
new
repository
called
parent,
and
this
repository
is
used
by
the
following
three
downstream
packages.
One
of
those
will
always
pass
if
you're
on
ci,
one
of
those
will
always
fail,
and
the
last
one
has
multiple
checks.
One
will
fail.
One
will
succeed.
C
I
have
already
set
up
this
repository
to
have
a
web
json
web
json
defines
a
list
of
dependents
that
you
want
to
test
in.
You
just
list
out
the
repositories
that
you
would
be
pulling
against
in
the
current
incarnation
of
it
it
it
needs
push
access
to
these
repositories
right.
C
So
at
the
moment,
you
would
probably
be
only
running
it
in
your
organization
that
you
own
or
you
could
create
the
forks
of
these
dependents
that
you
want
to
make
sure
you're
not
breaking
in
an
organization
that
you
control,
which
may
even
be
a
better
option,
because
at
the
end
of
the
day
you
may
not
want
to
be
opening.
Many
testable
requests
against
the
repositories
that
you
don't
own.
So
there's
definitely
a
theme
for
tooling
to
build
out
there.
C
If
this
is
an
approach
that
works,
so
I
have
a
web
json
which
defines
a
list
of
repositories.
We
want
to
test
against
and
I
have
a
webby
I'm
going
to
be
testing
with
some
things,
with
my
local
version
that
I
just
have
for
this
demo,
because
it
has
some
fixes
that
I
uncovered.
While
I
was
preparing
for
this.
So
suppose
you
have
a
parent
repository
and
you
want
to
test
some
dependents
and
you
want
to
kick
that
off
with
a
github
action.
C
So
we
have
a
web
workflow
that
you
can
use
and
I
prepared
a
command
that
you
can
use
in
your
repository
to
install
webby
in
the
first
place
right,
so
you
you
could
run
with
the
you
could
run
with
just
directly
in
the
command
line
right.
You
could
do
vb
test
from
the
command
line,
and
maybe
we
can.
We
can
take
a
look
at
that
as
well.
Maybe
I
should
start
with
that.
Actually,
let's
start
with
that
suppose
I
am
on
a
new
branch
test.
C
C
This
okay,
so
we
have
a
new
branch
and
I
am
going
to
link
that
into
my
dependence
by
doing
npx
will
be
test,
so
this
will
loop
through
all
the
dependents,
but
you
could
also
just
do
a
single
dependent.
I
think
you
do
dependent
and
you
give
it
a
get
up.
Url.
C
If
that
were
a
dependent
right,
so
if
I
run
nbxv
test
what
it
will
do
is
it
will
tell
me
that
I
don't
have
my
token
in
the
environment
right,
so
it
will
pull
down
these
sorry.
It
will
push
the
changes
to
all
the
dependents
that
I
am
depending
in.
So
what
happened
here
is
in
my
repositories
in
each
of
those.
I
now
have
a
vb
test
branch
that
is
pushed
in
and
what
the
branch
contains
is.
C
Basically
it
tells
you
know
we're
going
to
be
testing
with
we
be
test
parent
from
get
up
from
this
branch
and
that
kicked
off
the
ci
job
which
in
this
case
in
the
failed
repo.
It
eventually
failed.
C
C
It
will
go
and
test
the
status
checks
for
that
specific
branch
that
we
pushed
on
these
repositories.
So
I
can
see
that
in
the
postural
I
have
one
check
which
failed
one
check
which
succeeded
yeah
and
that's
basically
the
cli
approach
of
how
you
would
be
using
it.
You
push
a
package.json
update
to
link
in
your
package
directly
from
git
and
you
run
the
tests
there.
Then
you
can
collect
the
results
yeah
so
to
obviously
you
probably
don't
want
to
be
doing
that
from
your
local
machine
like
the
the
greatest
benefit.
C
Is
you
if
you
can
install
it
in
your
repository
and
then
you
know
you
can
do
things
there,
so
we
have
it
too
get
a
workflow
install.
So
what
did
I.
D
C
E
D
C
C
It
cannot
push
to
existing
branches
because
yeah
there's
enough
work
to
be
done
because
it
will
reuse
the
branch
name
based
on
the
name
of
the
branch
that
I
have
in
my
package
here,
which
would
allow
you
like.
If
you
were
working
on
multiple
packages
that
have
the
same
dependents,
you
could
use
the
same
branch
there,
and
then
you
could
link
both
of
these
packages
that
you're
working
on
into
the
single
defendant
and
then
you
can
test
them
together.
C
So
the
way
you
kick
off
with
the
at
the
current
approach
is
it's
not
ideal?
There's
some
gotchas
there,
because
one
is
there's
a
bug
in
europe
which
basically
does
not
correctly
assign
the
permissions
to
the
person
posting
the
comment
and
because
you
don't
want
to
be
to
have
any
random
person
coming
in
and
you
know
running
ruby
test.
You
want
only
the
collaborators
doing
that
alternative
approaches
to
use
labels.
C
So
something
like,
you
would
add,
a
label
which
says
kick
off
wibby,
which
already
has
permissions
assigned
to
only
people
who
have
at
least
triage
permission.
I
believe,
and
then
that
would
kick
off.
But
it's
a
bit
trickier
to
implement
and
maybe
doesn't
have
as
nice
flow
a
flow
in
terms
of
how
you
go
end
to
end,
but
I
mean
remains
to
be
seen:
we'll
need
to
get
some
feedback.
So
if
I
post
a
comment
will
be
test.
C
C
What
happened
here
is
it
just
like
before
it
created
the
branches?
It
kicked
off
the
ci
jobs
there
and
you
know
now
you're
waiting
for
the
results
and
to
get
the
results
you.
Similarly,
as
you
would
do
in
the
cli,
you
do
with
the.
C
Results
yeah:
this
finished
is
finished,
and
this
finished.
If
it's
in
progress,
it
would
just
report
that
it's
in
progress
you
do
a
result
which
in
turn
kicks
off
another
action
which
once
again
checks
the
permissions
and
then
it
goes
off
and
collects
the
result.
It
takes
a
short
moment.
C
B
C
E
C
No
way
to
tell
to
tell
our
original
pr
back
that
you
know
I'm
done,
and
so,
if
you
don't
have
a
way
to
post
that
via
the
post
back
by
the
hook,
you're
short
of
you
basically
can
only
do
polling.
And
if
you
want
to
do
polling,
it
means
that
you
are
running
an
action
all
the
time
doing
the
polling
and
that
action
consumes.
The
good
of
minutes
right.
B
F
F
C
Yeah,
that's
an
option.
The
goal
that
one
of
the
design
goals
here
is-
and
this
is
the
reason
why
it's
a
github
workflow
and
it's
using
this
funky.
You
know
github,
install
workflow
thing
as
opposed
to
a
github
application,
is
that
this
does
not
need
any
server
setup.
I
don't
want
to
be
running
any
service
setup.
I
don't
want
to
be
maintaining
a
ci
server.
I
don't
want
to
be
maintaining
an
application.
I
don't
want
to
share
secrets
with
the
team.
I
don't
want
to
be
doing
all
of
that
work
right.
C
What
you
want
is
for
the
thing
to
just
work.
Get
up
does
provide
a
way
to
run
actions
on
a
schedule.
So
in
theory
you
could
have
a
workflow
which
every
10
minutes
goes
off
and
checks
the
results
for
all
the
prs
that
are
open
and
and
reports
the
results.
The
problem
with
that
is
that,
even
if
you
do
it
once
every
10
minutes,
you
will
still
end
up
with
4.
000
runs
a
month
which
is
still
a.
C
A
F
C
C
Is
something
new
I'd
really
appreciate
any
kind
of
ideas
on
on
how
to
improve
this,
because
you're
you're
rightfully
saying
this
is
slightly
less
than
an
ideal.
You
know
yeah
situation
and
and
the
workflow
there
but
yeah.
C
Basically,
you
need
to
kick
off
the
check
manually
and
yeah
and
the
check
reports
the
result
and
it
reports
the
results,
because,
basically
it
went
out
and
it
checked,
and
it
saw
that
you
know
some
of
these
repositories
were
failing
the
ci
and
then
it
completed
with
a
with
an
error
and
it
reported
that
back
to
the
action
and
basically
that's
where
we
are
right
now.
There's
lots
of
improvements
to
be
made
like
this
details
link.
Ideally
it
would
link
you
know
to
here.
C
There's
there's
permissions,
there's
tokens
a
little
bit
because
you
for
now
you
need
push
access,
but
I
think
glenn
volunteered
to
implement
the
pr
approach,
which
means
that
you
could
be
opening
pull
requests.
You'd
still
need
a
fork
of
some
sort,
so
we'll
you'd
need
to
maintain
something
to
to
to
to
to
to
deal
with
the
forks,
yeah
and
then
and
then
yeah.
The
comment
together.
Results
is
less
than
ideal
and
reusing
the
branch.
C
It
still
needs
a
little
bit
of
thought
on
how
to
best
approach
if
the
branch
exists,
because
in
some
cases
you
might
may
want
to
rebase
that
branch
you
may
want
to
check.
In
some
cases
you
might
not
be
able
to
automatically
rebase
that
branch,
but
yeah
there's,
there's
some
gotchas
there,
so
implementation
details
but
yeah.
This
is
where
we
are
right
now.
A
C
I
mean
at
the
moment
you
need
to
you,
need
push
access
and
that's
the
limitation
there
right
now
right.
The
problem
with
the
push
access
is
that
if
you
grant
there's
there's
security
implications
there.
So
what
I
thought
initially
with
this
is
that
we
be
in
in
with
json.
You
could.
C
Have
something
like
this
would
link
to
the
repository
of
of
the
actual
dependency
that
you
want
to
test,
and
then
you
would
have
another
configuration
option
which
says
organization
for
forks
and
it
would
automatically
fork
the
thing
would
maintain
automatically
the
branches.
B
C
C
I
think,
ideally,
what
what
I'd
like
to
see
is
that
when
you,
when
you
do
a
fork,
you
would
be
opening
a
pull
request
against
against
these
things
that
would
like.
If,
if
you
are
a
large
organization,
then
then
you
can
probably
afford
to
have
a
separate
repository
with
all
the
setup
and
maybe.
C
Can
help
do
that
setup?
If
you
are
a
sort
of
critical
package,
then
similarly
the
way
sid
jim
works
right
is
you
you,
you
work
together
with
the
people
yep
that
are
maintaining
these
original
packages
to
to
sort
of
arrange.
All
of
that,
but
there's
also
there's
there's
the
thing
with
opening
pull
requests
rather
than
running
this
just
on
forks
and
implying
the
setup
is
that
you
would
be
distributing
the
actions
minutes
as
well,
which
is
also
a
constraint
right.
D
A
A
A
Yep
yeah,
it's
interesting,
we
could
even
I
know
you
were
asking
about
modules.
Last
time
I
was
just
thinking
like
even
maybe
some
of
the
modules
we
have
within
the
node
repo
might
be
candidates.
At
some
point
I
mean
no
doubt
on
api
comes
to
mind,
but
that
one
might
be
trickier
since
it's
actually
got
native
code.
But
who
knows
I
did.
A
I
did
ask
in
the
note
shift
org
and
I
don't
think
we
found
any
that
were
particularly
good
candidates
just
because
there
were
limited,
limited
dependencies
or
they're
more
like
samples
or
something
versus
a
real
package.
F
It's
interesting
that
this
is
the.
This
is
the
approach
that
we're
taking
the
or
the
org
one,
at
least
because
microsoft
does
something
similar.
I
don't,
I
don't
think
it's
very
public,
I
think
there's,
maybe
a
blog
post
about
it.
The
org
used
to
be
public.
It
is
no
longer
public,
because
people
were
confu,
rightfully
confused.
Why
microsoft
had
a
an
org
that
had
every
module
we
depended
on,
but
microsoft
does
something
similar
where
we
have,
we
basically
fork
every
repo
into
an
org
and
then
run
its
tests.
F
We
run
it
on
our
infrastructure,
so
we
generalize
it
and
just
run
what
like
we.
We
don't
try
to
enable
custom
infrastructure
like
that
just
get
too
expensive
and
also
we
have
our
own
infrastructure
but
yeah.
This
is
like
not
far
off
from
what
we
currently
do.
I
think
with
you
know,
I
don't
think
the
expected
expectation
is
we're
checking
to
see
if
we're
breaking
people
but
you're
you're,
not
far
off
of
what
microsoft
has
already
gone.
The
path
we've
gone
down
for
javascript.
F
I
I
if
it
I
could
probably
track
down
the
people
who
run
it.
It's
called
terrapin.
I
could
track
down
the
people
who
run
it,
probably
if
you'd
want
to
talk
to
them.
If
that'd
be
a
helpful
thing
to
see
like
what
problems
they
had
and
like.
C
Right
yeah
we'll
see:
where
do
we
take
this
forward,
and
I
mean
the
the
the
I
think.
Overall,
it
depends
on
on
what
people
want
right.
It's
easy
enough
to
extend
it
to
just
run
and
bmt
locally
against
some
of
these
repositories
right
you
just
but
yeah
they're
still
in
that
was
already
built
to
do
that.
C
A
Yeah,
I
know
I
I
mean
this
from
back.
I
think
it
was
not
this
last
december,
but
the
december
before
the
the
discussion
at
the
node
plus
js
interactive,
I
think
it
was
called
at
the
time,
was
like
all
around
this.
You
know
making
it
a
cooperative
thing
where
you
can
run
in
the
dependencies
and
use
the
actual
tests,
and
you
know
get
around
a
bunch
of
the
problems
you
would
have
by
just
trying
to
run.
Npm
tests,
which
you
know
we
know,
doesn't,
doesn't
quite
solve
the
problem.
So.
C
A
Yeah
so,
but
it's
great
to
see
you've
pushed
you
know
gotten
it
this
far
where
people
could
start
to
try
out
the
concept
because
we
were
like.
We
think
this
is
a
good
idea
and
but
to
see
whether
people
will
like
opt
in
and
let
somebody
else
run
their
tests
and
stuff
is,
is
a
you
know,
yeah,
it's
still
the
open
question,
so
yep.
B
Okay,
thanks
for
the
lemon,
I
guess
back
to
the
other
items
on
our
agenda
and
we've
got
the
suggested
list
of
modules
to
help
get
support
info
into.
I
think
this
has
been
on
the
agenda
for
a
little.
While
does
anyone
have
any
updates
on
this.
C
B
We
have
any
further,
like
advocacy
for
this
kind
of
planned
in
the
pipeline
like
further
blogs
or
anything.
A
F
A
F
I
I
I
think
the
thing
that
they'd
want
to
do
is
like
they'd
want
to
do
it
across
everything
which,
like
they
try
to
be
consistent
with
stuff.
We
even
have
like
an
internal
package
spec
for
how
we
structure
packages
and
stuff
so
yeah.
I
will.
I
will
see
if
that's
a
thing,
we
could
do.
F
The
cl-
I
I
don't
think
it's
oh
gosh,
it
might
be
public.
Let
me
look
coco
soft
package.
Oh,
I
don't
remember
the
repo.
It
was
like
a
year
and
a
half
ago
that
I
was
working
on
it
with
them.
There
is
a.
F
It
was
run
by
brian
brian
turtleson's,
the
one
who
like
owns
it.
So
I
can
ask
him
but
yeah
I
will
see
I
don't
I'm
not
seeing
it
so
I'm
guessing
not
like
searching
package
in
the
microsoft
org,
but
yeah,
not
yeah
I'll
I'll,
get
answers
to
both
those.
B
So
probably
nothing
further
on
that
one.
Let's
keep
keep
track
of
our
progress
next,
one
on
the
list
is
suggest
ignoring
of
vulnerability
by
package
maintainer.
A
So
that
one
works,
I
think,
as
I
understand
it,
the
the
collaboration
space
is
still
being
kicked
off.
So
I
haven't,
I
haven't,
seen
the
sort
of
kick
off
yet,
but
it
I'm
hoping
it's
any
time
now.
B
A
Should
be
like
you
know,
darcy
was
talking
about
a
like
a
doodle
for
people
who
are
interested
and,
and
I
think
at
least
a
blog
post.
You
know
I
I
I'd
asked
and
rachel
and
darcy
were
working
on
a
blog
post
to
sort
of
present
and
explain.
You
know
the
provide
some
context
and
say
hey.
Would
you
like
to
get
get
involved?
Come
come
over
here,
fill
in
this
doodle
and
we'll
get
started
right?
Okay,.
B
Okay,
that
seems
to
be
everything
we
had
on
the
agenda.
Are
there
any
pressing
issues
folks
know
of
that?
We
should
go
through
and
talk
about
today.
F
One
thing
there
is
the
admin
request
to
move
the
labeler
issue
or
labeler
github
action
is
that
I
I
asked
the
question
in
there
of
is
that
something
that
we'd
want
to
do
or
we'd
like
it
would
make,
would
it
make
more
sense
under
the
pkg.js
org,
since
it
seems
like
it's
relatively
tooling,
that's
within
package
the
scope
of
package
maintenance
and,
like
I
don't
know
if
it
go
into
a
home
other
than
like
generic,
it
exists
in
node.
Otherwise,
is
that
something
we
want
to
talk
about.
A
Yeah,
I
I
guess
my
my
very
first
I
did
read
that
one.
My
ver
very
first
thought
is
like
I
thought
this
one
was
more
like
tools
being
worked
on
by
the
package
maintenance
team,
as
opposed
to
just
general
things.
Yeah,
and
I
didn't
use
the
note.
I
would
just
say
why
don't
we
just
pull
it
into
note
if
it
makes
sense
right,
okay,.
F
Yeah,
it
seems
like
something
that
would
be
related
to
our
work.
So
that's
also
kind
of
part
of
the
question
there
is.
Is
this,
like
you
know,
related
enough
to
the
package
maintenance
stuff?
But
if
not
that's
fine
too
yeah.
What
does
it
do?
I.
F
It
seems
to
be
an
auto
labeler
for
github
issues.
Basically,
I
could
be
off
on
that.
I
was
looking
at
it
during
a
meeting,
so
I
you
know
I
could
be
wrong.