►
From YouTube: Package Maintenance Team meeting - Nov 19 2019
Description
A
A
Ok,
so
if
we
have
no
announcements
this
week,
let's
move
on
to
the
issues
which
are
tagged.
The
first
one
is
an
OGS
Foundation
package,
maintenance,
team,
Express,
triage
sink
kickoff,
which
is
issue
number
284
I
just
tagged
that
for
the
agenda
more
for
mostly
for
awareness.
This
is
a
meeting
that
Jewish
is
setting
up
in
terms
of
bringing
to
bring
together
people
who
are
interested
in
getting
involved
in
the
Express
triage
effort.
I
know
jerusha's
talked
to
Wes
a
few
times.
A
A
You
know
the
best
way
to
sort
of
coordinate
figure
out
what
to
focus
on,
and
you
know
figure
out,
if
maybe
it's
like,
there's
a
monthly
meeting
in
Turlock
that
makes
sense
or
whatever
so
I
didn't,
necessarily
think
we
needed
to
get
into
this
other
than
to
let
everybody
know
what's
happening
and
answer
any
questions.
If
there
are
any.
B
And
I
think
Doug
also
said
this
is
we
should
pick
a
time
now
that
we
know
that
it's
going
to
happen?
We
should
we
should
collaborate
on
picking
a
time
so
that
we
can
have
some
of
the
TC
members
at
least
there,
and
then
also
I,
wanted
to
say,
I
think
miles
expressed
a
little
bit
of
interest
from
the
Google
side
on
this
topic
as
well
on
Twitter
to
me,
so
we
should
ping
in
as
well
and
see
if
he
wants
to
send
a
representative
to
this.
A
B
A
B
A
B
A
A
A
No
okay,
the
next
one,
which
I
added
a
bit
late
again.
So
sorry
people
haven't
seen
yet,
but
it
was
just
to
68
Club
summit
topic.
It
was
an
existing
issue
where
we've
had
a
discussion,
we're
just
not
too
far
off
from
the
the
the
actual
summit
itself.
I
think
it's
like
three
weeks,
so
we
need
to
close
and
I
just
wanted
to
make
sure
we
discussed.
A
B
A
F
A
Basically,
a
more
general
to
the
public
kind
of
thing
for
the
community
corner
and
then
a
club
collaborator
summit
session,
which
would
be
like
an
actual
working
group
for
us
to
work
on
particular
issues.
That
one
could
also
be
like
an
effort
to
try
and
get
more
interested
collaborators
from
you
know
involved
so
that
it's
really
up
to
us.
What
we
want
to
make
make
that'd
be.
A
That's
the
one
where
we
would
have
more
people
right
like
it's,
that's
the
general
attendees,
so
you
could
I
mean
you
could
actually
do
a
little
it
do
it
a
little
bit
of
both
right
in
that
you
know,
there's
the
core
collaborators
who
we
might
want
to
attract
and
you
might
get
well.
You
might
get
them
during
the
club
summit,
but
not
during
the
conference,
because
some
of
them
are
only
going
to
that
and
then
the
community
corner
is
the
one
where
it's
like.
This
is
the
bigger
group.
A
Everybody
so
certainly
number
one
would
be
hey.
This
is
what
it
is.
If
you're
interested
here's,
how
you
could
get
involved,
number
two
could
just
be
like
the
core
people
like.
Instead
of
having
a
video
meeting,
we
can
have
a
face-to-face
meeting
and
pick
some
things
to
work
on
or
we
could
choose
to.
A
D
To
get
might
as
well
just
saying
that,
like
I,
think
using
that
time
to
I
mean
allow
anybody
to
join
in
discussion,
but
using
the
time
to
actually
meet
up
in
person
and
work
on
specific
sort
of
anything,
that's
being
brought
up
over
the
last
couple
months
for
sure,
like
this
port
work
or
things
like
that,
where
it's
you
know,
that's
collaborating
on
trying
to
move
forward
with
that
stuff.
I.
D
A
So
but
that's
certainly
the
you
know
one
of
the
styles
that
that's
you
know,
but
they
have
different
styles
that
they're
thinking
about
this
year.
That's
exactly
one
of
the
styles
I
say
we're
just
gonna
get
together
we'll
come
up.
We
can
even
just
wait
to
come
up
with
an
agenda
together
once
we're
there,
and
then
you
know
work
through
those
things.
I
guess
the
question
on
that
one
would
be:
how
much
time
do
we
ask
for.
B
Depends
on
how
many
topics
we
want
to
cover
right,
I
think
one
thing
that
I'd
be
particularly
interested
in
so
we've
we've
talked
a
lot
about
the
support
stuff
to
me
that
has
been
making
some
progress
and
is
good.
I
would
really
like
to
talk
about
this
two-factor
publish
stuff
and
liken
tea.
Publishing
for
teams
I
think
that
would
be
a
great
topic
that
would
actually
benefit
from
some
face-to-face
time.
B
D
A
D
A
In
terms
of
topic,
so
I
guess
it's
like
how
long
and
what
kind
of
topics,
so
we
can
like
ask
for
an
hour
or
two
hours,
it's
sort
of
over
the
thing.
Is
it
overlaps
with
other
things
as
well
right,
so
everybody
always
has
the
conflict
of
wanting
to
be
everywhere.
At
the
same
time,
I
would
kind
of
off
the
top
my
head
guess
like
one
or
two
hours
as
reasonable
I.
You
know
once
you
get
longer
than
that,
it's
gonna
be
probably
lose
a
bit
of
steam
anyway,
yeah.
D
C
I
mean
I'm
looking
at
the
Uniting
268
now,
and
we
basically
have
people
essentially,
like
manual
said
you
know,
I
can't
make
it
we
know.
Who-Who
is
going
to
be
there.
That's
really
I
think
that's
the
item.
We
need
for.
We've
only
got
three
weeks,
I
think.
Perhaps
today
we
have
to
decide
who
is
going
to
be
there
and
and
try
and
make
the
end
of
it.
Who
will
be
there
and
their
take
their
interests
based.
C
H
A
I
I
B
So
we
had
Henry,
who
is
a
label
maintainer
in
at
our
office
last
week
and
said,
had
a
very
different
opinion
of
tide
lifts.
So
this
is
why
I
think
there's
some
interesting
stuff
for
maybe
us
as
a
group
to
have
some
experiences
or
ways
to
share
with
other
maintainer
x',
who
may
not
have
had
this
kind
of
who
don't
know
what
to
do?
It
might
be
a
topic
worth
yes,.
C
A
E
H
A
Don't
have
the
insight
into
how
successful
how
many
people
have
signed
up
that
kind
of
stuff.
The
the
the
interesting
slice
is
that
I
think
that
they
had
some
specific
things.
They
thought
were
important
if
it
was
to
be
associated
like
if
you
were
actually
part
of
the
foundation.
There
were
some
things
that
was
doing
it
thought
aligned
better
than
what
some
of
the
other
ones
were
doing,
but
I
off
I'll
find
that
out
and
bring
it
to
the
meeting
itself,
because
it's
not
coming
to
me
right
away,
which
is
not
good.
A
I
I
actually
have
something
I
want
I
would
want
to
put
in
that
document
since
Travis
just
launched
shareable
configs
last
week.
So,
for
example,
you,
like
I
posted
this
in
the
slack
channel,
but
like
you,
can
import
from
a
specific
shared
config
that
I
have
in
a
repo
and
as
long
as
I
keep
that
up
to
date,
as
new
LCS
is
changing
new
nodes
come
out,
which
I
will
you
automatically
get?
The
exact
support
like
semantically.
A
I
I
F
A
Ok,
so
I
think
that's
that's
a
decent
set.
We
can
you
know
if
you
have
more
a
done
to
the
a
to
the
to
the
issue.
We
can
you
know,
sort
of
prioritize
what
we
want
to
talk
about
when
we're
there
I
guess,
then
the
question
will
be
who's
gonna,
make
the
submissions
and
any
preparation
that
we
need
to
do
so,
I
guess
for
the
the
club
summit
session.
We
just
need
to
submit
a
request
which
isn't
gonna
take
too
much
right.
A
B
A
We're
talking
about
like
like
I,
can
actually
that
first
ones
fairly
easy,
so
I
could
I
could
volunteer
to
do
that.
The
next
one
where
we
need
to
put
something
together
if
we're
gonna,
do
a
clubs
like
the
community
corner
that
would
actually
probably
somebody
taking
some
time
to
put
together
some
slides
and,
and
you
know
the
and
we
did
have
the
slides.
We
can
possibly
reuse
some
of
the
other
ones,
but
it
would
take
a
little
bit
to
put
that
together.
So
I
don't
know.
A
A
Slides
and
create
slides
those
there
will
present
right
because
I
think
there's
enough
of
us
there
that
you
know
anyone
of
us
if
we
have
the
slides,
can
probably
go
through
them
and
give
people
the
background
that
kind
of
stuff
that
sounds
good
and
I'll.
Take
the
owner
Michael
to
submits
the
collaborator
summit.
Is
that
fair
enough?
Okay,.
D
From
our
standpoint.
It's
definitely
now
cued
up,
we've
done
an
internal
sort
of
like
RFC
on
the
work
that
would
be
required
and
it
looks
like
something
along
the
lines
of
scoped
auth
tokens
and
as
a
sort
of
a
first
pass
here.
We
would
essentially
create
a
new
auto
gain
that
specifically
gives
access
to
that
staging.
D
D
It's
not
a
full-on
baked
release
manager
where
you
have
a
nice
GUI,
but
that
could
be
something
we
have
a
sort
of
a
v2.
But
it's
definitely.
This
is
something
that
you
know.
We
do
think
is
important
and
from
NPM
standpoint
we
we
definitely
want
to
support
this
use
case
for
for
folks.
So
we
think
that
this
kind
of
that
that
approach
of
a
scope,
dot
token
with
the
net
new
capabilities
and
of
staging
releases,
will
unlock
a
lot
of
a
lot
of
what
people
are
looking
for
here.
A
A
D
D
Can't
commit
when
we
would
actually
have
that
out
a
lot
of
our
development
efforts.
Right
now
are
towards
NPM,
seven
and
so
a
lot
of
refactoring
work
has
gone
into
that
and
we're
doing
a
lot
cleanup
in
our
team
so
putting
a
net
new
sub
command
honor
on
a
radar
and
on
our
team,
the
infrastructure
teams
radar.
It
would
be-
maybe
not
by
the
end
of
the
year,
but
maybe
early
q1,
okay,.
A
D
We
we
see
a
lot
of
value
in
it,
there's
other
things,
other
capabilities.
This
would
unlock
other
sort
of
audit
capabilities.
This
might
unlock
for
our
team
and
yeah.
We
see
a
lot
of
value
in
it
for
for
the
community,
so
it's
definitely
something
I'm
championing
internally.
So
I
can
tell
you
that
okay.
J
B
D
Well,
we're
trying
to
do
our
best
actually
to
to
sync
up
with
this
group
and
I'll
be
doing
hopefully
doing
a
better
job
at
queuing.
Folks
up,
we
do
have
a
biweekly
meeting,
so
it's
pretty
regular
cadence,
usually
Wednesdays
2
p.m.
Eastern,
Time
and
I.
Try
to
post
very
similarly
to
the
node
foundation
agenda
about
a
week
beforehand,
if
possible
and
yeah
I'll
reach
out
to
folks
once
we
have
that
sorry
queued
up.
Okay,.
A
D
Isn't,
but
we
could
imagine
that
there
are,
we
do
have
web
capabilities
with
MDM,
so
we
could
imagine
that
part
of
the
RFC
would
be
to
create
a
new
hook.
Event
for,
let's
say
staged
stage,
really
be
yeah.
You
could
be
notified
when
that
had
happened
so
yeah,
that's
it.
That's.
A
very
good
point.
Definitely
wasn't
on
my
radar.
Initially,
ok,.
B
B
Working
on
it
is
all
I
ask,
but
I
but
I
have
to
say
this
will
unlock
a
lot
for
the
plans
for
how
expresses
is
being
published
today
and
I
think
it
will
hopefully
enable
us
to
move
quite
a
bit
faster.
So
the
impact
of
this
feature,
I,
think
will
be,
will
be
fairly
large
for
sure
yeah.
We
I
totally
agree.
J
So,
given
this,
what
are
the
next
steps
for
the
pull
request?
I
have
open
I
mean
we
should
probably
keep
it
open
until
we
get
some
more
concrete
details
to
move
on
I,
wonder
if
there's
any
interest
in
any
of
the
other
options,
such
as
remote
OTP,
because
I
know
like
in
Symantec
release
flow.
This
may
or
may
not
be
enough
depending
on
the
project.
Setups
and
yeah.
Is
there
any
interest
in
moving
forward
with
any
other
options?
You.
A
G
J
Regarding
the
staged,
publish,
I'm
sure
there
will
be
tooling
built
around
that,
and
hopefully
I
mean
we
can
flesh
that
out
in
the
RFC.
But
hopefully
there
would
be
an
API
which
allows
you
to
like
submit
a
list
of
modules
that
you're
publishing
like
approved
ten.
You
know
in
one
go
so
that
you
only
have
to
enter
the
OTP
once
and
you
know,
but
that's
that's
a
lot
of
UX
work.
I
J
Then
I'm,
just
looking
at
the
other
notes
that
I
have
for
the
release
manager.
Each
thing
is
the
standardization
around
alternative
registries,
because
I
think
one
of
the
issues
we
did
mention
around
other
2fa
approaches
would
be
other
registries
and
I.
Suppose.
There's
there's
more
discussion
to
be
added
in
the
in
the
pull
request
and
the
RFC's.
A
B
J
I
B
Well,
I,
don't
see
that
happening,
I
think
it
would
be
great
or
more
of
that
work
to
be
done
between
artifactory
and
if
anybody
needs
an
ally
there.
I
am
very
close
to
the
people
at
Netflix
who
manage
the
relationship
without
a
factory,
so
I'm
sure
I
could
put
in
a
good
word
for
for
working
together
on
that
kind
of
stuff,
because
it's
a
big
pain
that
artifactory
does
not
have
support
for
all
of
the
and
pmap
is
right.
I
For
those
of
us
who
are
stuck
using
it,
one
there's
also
just
like
just
speak
in
a
specific
thing
like
there's
bugs
and
like
in
there
be
a
new
we
had
to
patch
the
artifactory
implementation
in
order
to
make
it
do
some
things
that
again
does
around
like
FS
events
and
optional
dependencies,
and
things
like
that.
So
there's
this
because
there's
like
it
would
be
great
to
have
a
standard,
but
in
the
absence
of
a
standard
the
standard
is
whatever
NPM
does
and
if
we
are
interested
in
changing
that'll
to
pursue
doing
that.
I
That
would
clearly
be
good
for
everyone
to
have
like
a
test
suite
that
all
registries
can
run
against
like
like
for
the
language
there's
test
to
six
to
four
look
all
the
browsers,
some
sort
of
like
NPM
test
suite
that
you
can
run
against
you
know.
Cli,
is
and
against
registries
and
confirm
that
they're
valid.
B
H
H
D
Peers
are
always
welcome
and
we're
we're
actively
working
on
I
think
updating
all
our
test
coverage,
all
all
of
our
sort
of
like
we're
refactoring
a
lot
of
the
internals
of
NPM
right
now
for
exampie
m7,
so
I
think
there
is
a
lot
of
opportunity
for
us
to
be
more
collaborative
going
forward
for
sure
what
I
actually
posted
in
chat
there
Wes
was,
you
know,
it'd
be
great.
If
there
was
somebody
from
let's
say
artifactory
or
some
like
I,
don't
know
if
there's
anybody
from
github
that
can
be
joining
these
calls.
B
I
can
probably
make
some
of
that
happen,
so
I
recently
switched
teams.
The
team
I
joined
at
Netflix
now
is
in
charge
of
build
and
publish.
So
it's
mostly
a
Java
team
but
I'm
now
helping
them
ramp
up
some
of
the
JavaScript
support.
So
I
think
that
means
that
our
artifactory
install
will
come
under
my
team's
domain
and
I.
Think
the
same
thing
will
go
with
the
github
contact,
so
I
might
be
able
to
make
that
let.
B
D
I
know:
Brian
Clark
has
been
involved
in
passed
by
switch
roles
now
and
anybody
from
like,
let's
say,
github
or
artifactory.
It
would
be
great
to
having
these
discussions
because
I'm
I'm
all
for
standardizing
API,
is
an
implementation
here,
and
you
know
we're
trying
to
be
as
collaborative
as
possible
going
forward.
So
yeah
I
mean
it's
definitely
discussion.
I'd
love
that,
yes,.
A
B
A
A
A
Weather
like
the
much
much
less
common,
less
common,
so
I
did
change
it
just
to
be
a
little
bit
more
just
ordered
not
commenting
on
how
how
much
less
common
or
our
common
something
would
be
other
than
that
I
don't
see
any
new
like
substantive
comments.
Is
there
any
things
that
people
think
we
should
discuss
or.
A
H
A
I
B
What
so
common
cases,
so
this
is
where
it
gets
a
little
bit
complicated,
because
our
spec
is
rather
broad
and
can
handle
a
lot
of
different
types
of
input.
So
what
as
a
effectively
we're
talking
about
as
a
generator?
B
B
Do
we
because
it's
so
complicated,
so
the
package
I
wrote
I
tried
to
put
in
some
examples
and
I
tried
to
put
in
some
complicated
ones
and
I
was
actually
where
I
stopped
was.
How
do
we
ask
users
for
this
input?
Because
if
we,
if
we
want
to
support
all
of
the
ways
people
can
define
it,
it
can
get
quite
complicated.
B
So
do
we
think
it's
alright
to
support
just
the
very
basics
in
the
CLI
and
then
say
if
you're
interested
in
defining
more
complicated
structures
go
here
and
and
here's
your
reference
or
what
we.
I
Might
be
right,
I
think
we
can
ask
some
English
questions
to
like
you
know
our
pros
questions
rather
to
like
figure
out
what
kind
of
pocket
they're
in
so
you
could
say,
like
you
know
like,
so
we
made
a
bunch
of
like
shortcuts
for
common
semantics,
and
so
we
can
ask
them
like
what
versions
you
know.
So
the
first
question
would
be
like
what
versions
of
your
package
does
this
apply
to
and
then
in
fact
you
know,
I
have
a
way
for
them
to
specify
that
maybe
just
December
string
and
be
like
cool.
I
What
versions
of
nodes
do
you
support?
What's
your
plan
for
backports
or
you
know
whatever
the
stuff
we've
built
into
the
schema
which
I
don't
have
in
my
head
at
the
moment,
just
kind
of
get
a
general
question
and
then
like
at
that
point
we
could
ask
them.
Do
you
want
to
define
different
version
ranges
and
repeat
this?
You
know
the
thing
and
I
think
that
the
the
combination
of
enums
and
freeform
text
should
be
enough
that
we
can
be
pretty
exhaustive
in
the
wizard
right
and
like
at
any
point.
I
I
If
we
look
at
it,
we'll
be
able
to
come
up
with
a
couple
very
common
buckets
of
like
node
support
and
like
which
versions
does
this
apply
to
it's
probably
going
to
apply
to
you
know
the
latest
MAME,
the
latest
major
and
the
latest
minor
or
something
you
know
what
I
mean
like?
We
can
just
kind
of
look
at
it
and
look
at
a
few
like
a
bunch
of
packages
and
see
what
they
do
well.
A
I
think,
like
the
version
I
mean
I'm,
just
wondering
is:
is
it
going
to
be
common
that
people
have
different
support
statements
for
different
versions
of
the
package
like
that?
Maybe
one
it's
just
like.
Alright,
you
know
there'll
be
some
simple
cases
where
it's
like.
No,
you
know
I
just
want
to
mic.
My
current
support
thing
is
regardless
of
the
version.
All
versions
is
this
and
then
you
know
the
the
the
rest
of
the
questions.
I
If,
when
someone
typically,
when
a
package
creates
a
new
major,
they
kind
of
stop
supporting
the
previous
ones,
and
that's
for
like
the
transition,
for
that
is
something
we
can
think
about
separately,
but
the
the
people
who
are
coming
in
and
running
in
it
on
their
new
package
that
has
like
five
major
versions
already
their
support
policy
for
vert
v5
is
gonna,
be
different
than
for
me.
Less
than
five
and
I
think
that's
gonna
be
pretty
common.
H
B
B
Was
just
gonna
say:
I
posted
a
link.
I
started
a
PR
on
this
on
that
repo
to
do
it,
a
CLI
which
I
think
so
I
even
have
a
scaffold
for
a
set
up
command.
We
could
change
it
to
in
it
or
you
know,
whatever
the
naming.
It's
totally
work
in
progress,
but
I.
You
know
at
least
gets
started
in
that
package
to
have
some
of
this
okay.
A
A
A
A
A
Next
one
is
document.
The
current
top
10
expressed
issues,
number
233,
Wes
I,
don't
know
if
you
remember
what
yeah.
B
So
with
this
job
transition,
a
lot
of
my
things
have
been
put
on
on
hold
for
a
moment,
so
I
have
to
fix
the.
So
at
the
time
when
I
think
I
last
posted
the
status
board
was
the
update
was
broken
because
it
was
timing
out
so
I
turned
it
off
the
regular
job.
I
think
I
just
need
to
investigate
I
believe
that
github
made
some
updates.
That
would
make
that
either
more
visible
and
not
just
a
hang
it
because
of
what
it
did.
B
There
was
just
hang
and
it
wasn't
clear
that
it
failed
so
I
think
they
fixed
that
I
need
to
try
turning
it
back
on.
If
so,
then
the
status
board
will
be
updated
with
the
top
priorities,
lists
and
stuff,
but
I
don't
know
if
any
of
it
has
changed
since
the
last
time
I
built
it.
So
it
probably
is
still
up
to
date
and
I
think
we
should
I,
don't
know
if
there's
much
more
to
do
on
this
right.
A
B
A
Good,
okay,
the
next
one
is
next
up:
support
levels
in
packs,
Jason,
192
I
think
that's
the
one
that
actually
lists
out
a
whole
bunch
of
different
things
that
we
want
to
do
in
terms
of
you
know
closing
on
that.
However,
I
think
we've
already
discussed
our
next
priorities,
which
is
to
get
it
landed
and
then
work
on
the
tool.
So
I
don't
know
if
there's
anything
more,
that
people
want
to
bring
up.
A
C
G
A
A
B
Thing
it
relies
on
is
the
schedule
which
is
in
the
node
repo
it's
at
just
adjacent
file,
and
if
we
like
that
type
of
implementation
and
want
to
start
using
it
places
like
maybe
promote
it
to
github
or
Travis
as
the
way
to
do
some
of
this
alias
mapping
and
keep
it
up
to
date,
we
should
probably
standardize
that
schedule
Jason
and
make
sure
that
it's
not
going
to
go
away
or
change.
I,
don't
know
who
manages.