►
From YouTube: Open RFC Deep Dive Meeting - Wednesday, March 25th 2020
Description
In our ongoing efforts to better listen to and collaborate with the community, we're piloting an Open RFC call that helps to move conversations and initiatives forward. The focus should be on existing issues/PRs in this repository but can also touch on community/ecosystem-wide subjects.
A
Also,
okay
and
we're
live
on
YouTube.
Thank
you
again
for
everybody
who's
joining
these
calls.
This
is
the
open,
RC
deep
to
have
call
which
were
but
essentially
running
bi-weekly
alternating
with
the
open,
RC
call
we're
NPM
and
community
air
since
they're,
going
through
sort
of
the
backlog
of
RFC
RFC's
that
are
open.
Today,
we're
going
to
deep
dive,
essentially
into
the
RC
number
92,
which
is
for
essentially
stage
publishers,
quick
housekeeping
notes.
A
/,
RFC's
and
essentially
the
designer
come
here,
is
to
hopefully
further
dig
into
a
specific
topic
on
these
calls,
and
in
this
case,
we're
going
to
into
the
RCS
are
sort
of
the
staging
publish
staging
published
stage,
publishes
RC
that
was
keyed
up
by
Daniel
Soho,
but
also
championed
by
other
folks
here
on
the
NPM
side
and
so
yeah.
If
we
want
to
quickly
go
around
and
do
a
quick
round
of
into
introductions,
I
can
start.
My
name
is
Darcy
Clarke
I'm,
the
engineering
manager
for
community
and
open
source
here
at
MPM
and
Roy.
C
D
And
it's
just
a
jump
on
I'm
Jordan
I'm,
a
NPM
package
author,
among
other
things,
interested
in
staging
awesome.
E
What
hey
I'm,
Wes,
NPM
package,
author
I?
Think
that's
a
nice
way
to
it
thinks
that's
a
good
house
I'll
seal
that
but
also
I
work
at
Netflix
on
the
build
team.
So
you
know
we
do
a
bunch
of
stuff
with
trying
to
figure
out
better
ways
to
support
package,
publishing
and
stuff
like
that
inside.
Our
our
infrastructure
awesome
to
make
this.
B
G
A
E
A
For
this
first
set
of
work,
also
trying
to
identify
I
think
use
cases
would
be
really
good
because
that's
what
seems
to
be
you
know
the
talking
points
and
and
I
think
I've
bunch
of
people
on
this
call
have
different
differing
opinions
or
understandings
of
the
use
cases
which
they'd
like
to
see
with
this
future
support,
and
then
we
can
talk
a
bit
about
the
nitty-gritty
implementation
details
in
terms
of
artifacts.
In
terms
of
you
know,
you
know,
API
is
in
terms
of
that
sort
of
thing.
C
Thanks
so
I
think
the
the
thing
that
has
has
made
this
one,
somewhat
interesting
and
and
right
for
for
a
deep
dive
is
that
we
actually
have
a
handful
of
different
use
cases
and,
depending
on
how
we
optimize
for
one
or
more
of
those
these
cases,
we
may
end
up
sort
of
making
it
harder
to
to
deliver
on
some
of
the
others.
So
my
goal
is
to
to
make
sure
that
we
can.
C
The
first
is,
you
know,
which
was
kind
of
the
the
initial
push
for
this
is
the
the
goal
of
publishing
from
CI
and
then
having
a
subsequent
step
where
we're
in
a
a
human
being,
promotes
that
stage
publish
to
the
actual
version
and
there's
there's
quite
a
lot
of
Devils
in
the
details
around
you
know
off
stuff.
We've
we've
already
established
that
anything
about
you
know
any
any
differences
in
in
authentication
or
authorization
that
are
required
to
to
promote
from
staging
to
full
publishes
is
kind
of
a
secondary
concern,
and
it's
essentially
a
registry.
C
You
know
a
registry
issue
right
from
the
CL
eyes
point
of
view.
It
has
no
knowledge
of
who
is
allowed
to
what
it
just
tries
to
do
it
and
either
it
can
or
it
can't
which
is
you
know
you
don't
want
your
you,
don't
want
your
authorization
and
authentication
didn't
live
client-side,
you
kind
of
want
that
to
live
server-side.
C
So,
from
the
point
of
view,
that's
RFC
it's
secondary,
but
that
being
said,
if
we
want
to
deliver
on
that
on
that
promise,
that
opens
some
doors.
For
you
know
some
some
questions
for
like
how
visible
should
stage
publishers
be
how
easy
should
it
be
to
to
fetch
them
and
what
are
the
steps
that
are
that
a
is
going
to
be
likely
to
go
through
prior
to
you
know,
to
like
vet,
something
prior
to
promoting
it
to
a
full
publish,
and
so
there
are
some
other
use
cases
that
kind
of
fell
out
of
this.
C
C
So
this
is
a
thing
that
that
I've
personally
run
into
quite
a
few
times
in
kind
of
interactions
between
folks
working
on
on
tap
and
folks
working
on
the
Istanbul
side,
because
there's
a
lot
of
points
of
integration
between
those
two
projects
and
both
of
them
are
made
up
with
multiple
different
packages.
So
when
we
get
into
a
case
where
NYC
is
is
working
on
a
beta
or
Istanbul
is
working
on
a
beta
for
a
new
version.
If
I
want
to
pull
that
into
a
working
version
of
tap
it's
there
are.
C
There
are
quite
a
few
challenges
that
end
up
being
presented
when
we
just
try
to
use
dis
tags
and
pre-release
versions,
because
owing
to
two
facts,
one
is
when
you
publish
something
to
a
pre-release
disk
tag,
it
can
still
be
pulled
in
by
the
normal
kind
of
semver
resolutions
right.
So
if
I
say
you
know,
version
version
1
is
on
latest
and
version.
2
is
on
next,
that's
fine,
because
nobody
who's
depending
on
one
is
likely
to
get
to
by
accident.
C
And
so
you
know
if
it's,
if
it's
one
or
two
things,
it's
not
that
bad!
You
just
install
the
pre-release
version
and
check
and
make
sure
everything
works.
Fine,
but
if
you
have
something
where
NYC
is
depending
on
Istanbul
Istanbul
reports
just
a
bonus
and
that
tap
is
depending
on
T
report
and
T.
Compare
and
everything
else
then
going
through
and
updating
all
those
things
to
have
the
the
proper
assembler
pre-release
is
pretty
tricky.
So
this
kind
of
the
the
beta
testing
or
they've
been
a
pre-release
use
case
really
falls
into
two
different
categories.
C
One
being
within
my
team
and
the
other
being
people
who
use
my
package
outside
of
my
team,
because
I
may
want
to
also
say:
okay
do
a
you
know:
npm
install
tap
at
next
and
and
maybe
even
reach
out
to
some
external
users
and
get
them
to
just
sort
of
easily
pull
this
in.
So
if
it's,
if
it's
a
huge
ownerĂs
process
for
them
to
go
through,
and
do
that,
it's
gonna
be
much
harder
to
sell
them
on
it.
C
You
know
doing
doing
three
seconds
of
work
to
try
out
a
new
version
is
fine
doing
30
minutes,
as
probably
just
people
won't
do
it,
and
so,
where
this,
where
we
got
into
the
weeds
I,
think
in
the
biggest
way,
was
how
how
public
should
stage
publishes
B
implementation
wise
the
easiest
way
to
to
approach
this
is
to
say
that
they
are
just
visible
and
I.
Think
most
of
the
like
most
of
the
the
technical
blockers
to
that
we've
pretty
much
ironed
out.
It's
gonna
require
a
little
bit
of
registry
work,
but
not
a
ton.
C
If
we
wanted
to
say
that
pre-release
versions
are
are
not
possible
to
install
which
may
be
safest
if
they're
kind
of
in
a
in
a
if
they're
treated
as
a
security
issue,
then
that
makes
things
a
lot
more
challenging
to
do.
The
beta
testing
use
case
as
well
as
imposing
some.
You
know
harsher
or
more
difficult.
C
Server-Side
requirements
on
them
I
the
the
solution
that
I
proposed
in
the
RFC,
which
is
is,
which
is
actually
already
implemented
in
p.m.
pick
manifest
as
just
kind
of
a
thing
that
I
was
playing
with,
is
that
we
essentially
D
prioritize.
So
a
unless
you
do
include
stage.
Do
you
never
see
stage
versions,
and
even
if
you
do,
they
are
fully
D
prioritized,
so
you'll
only
get
a
stage
version.
If
it's,
the
only
thing
that
satisfies
nothing
else,
does
so
yeah.
That's
kind
of
my
spiel
I
see
that
Jordans
hanazad.
D
So
I
was
originally
raised
my
hand
because
I
was
thinking.
Oh
well.
If
this
is
a
use
case,
you
have.
Why?
Don't
you
like
in
your
string
of
depths
like
say,
like
carrot,
1.2.3
or
a
pre-release,
including
cember,
and
then
I
realized?
Why
that
wouldn't
work,
because
then
regular
users
would
get
it.
It
wouldn't
be
opt-in.
It
would
be
like
forced
almost
so
like,
but
I
feel
like.
Maybe
this.
D
D
But
the
implementation
detail
is
irrelevant
when
we're
talking
I
think
when
we're
talking
about
the
RFC,
which
is
like
the
semantics
of
it
and
I,
think
these
are
two
very
distinct
semantic
features
that
are
gonna,
be
used
by
different
constituencies
in
different
ways
and
at
different
times
and
but,
although
and
also
sometimes
used
together,
but
like
I,
think
the
current
RFC
conflates
the
two.
So.
C
There's
yeah
I
mean
you're
talking
about
like
a
draft
published
almost
more,
you
know
if
we
just
sort
of
like
remove
the
word
staging
out
of
it,
and
just
say
this
is
like.
G
D
And
I
think
the
gray
area
there
is
because
the
the
the
wordpress
URL
for
that
draft
is
not
discoverable
or
guessable
in
any
way
it's
and-
and
they
were
computable
so
like
it's,
not
actually
that
much
of
a
hazard
to
make
it
viewable.
Whoever
has
the
link
where,
as
a
package
name
and
a
an
upcoming
version,
number
is
highly
guessable
and
like
discoverable,
so
like
I
I,
think
that
there's
probably
some
some
way
that
could
be
mitigated.
D
C
C
So
the
difference
the
difference
in
the
implementation
as
it
stands
at
least
kind
of
the
group
of
concept
as
it
stands
today,
is
that
it
would
be
a
thing
if
you
were
to
look
at
the
packing
mint.
You
could
see
hey,
there
is
a
there
is
a
draft
publish,
I'm,
gonna
go
and
run,
and
Kim
install
staged
or
deaf
to
include
Stage
two
to
pull
it
in,
but
it
would
still
be
opted
in
and
you'd
be
almost
it'd
be
almost
impossible
to
get
by
accident.
D
D
A
E
E
I
think
if,
as
long
as
it
is
like
actually
maybe
originally
Jordan
you,
you
were
really
going
for
the
like,
it
should
be
only
installable
by
the
publishers,
but
I
think
it
sounds
like
maybe
you've
backtracked
a
little
bit
and
said
actually
maybe
be
fine
if
it
was
like
the
WordPress
URL
where
it's
non
guessable,
then
we're
not
worried
about
the
off
as
much
we're
more
worried
about
the
inability
for
somebody
to
accidentally
couple
to
a
stage
right.
Yeah.
E
So
so
yeah
my
big
vote,
my
vote
would
definitely
be
for
the
I'll,
take
it
one,
which
is
as
long
as
it's
not
easily
foot
gun.
You
know,
territory,
that
is
where
I'm
I'm
super
in
favor
and
then
going
back
to
and
I'd
really
like
to
make
sure
we
deeply
go
into.
This.
Is
resolutions
of
some
sort
which
I
don't
want
to
say
like
go?
E
So
if
you
did
like
the
next
tag
on
a
pre-release
and
then
had
resolutions
to
say,
resolve
everything
that
is
NYC
to
dis
tag
next
right,
that
would
actually
be
a
really
easy
workflow,
especially
if
you
could
do
that.
You
know
through
one
install
command
that
what
I
think
fully
satisfy
your
use
case,
and
then
we
would
be
able
to
maybe
decouple
these
and
ship,
something
that
does
maybe
not
off
but
not
easily
guessable
install
commands
and
then
just
the
pure
initial
intent
feature,
which
was
have
a
staging
area
for
a
CI
publish,
workflow
right.
E
If
we
pull
those
two
things
fully
apart,
I
think
we
actually
get
to
like
the
staging
thing,
and
maybe
we
have
to
rename
it
or
whatever
being
just
what
we
initially
intended,
which
is
to
enable
the
CI
workflow,
would
be
easy.
It'd,
be
not
an
authentication
problem
or
or
nightmare
on
the
seal
on
the
registry
side,
and
then
also
we
can
tackle
the
really
important
feature,
which
is
you
know.
E
C
C
That's
that's
reasonable.
However
I
don't
have
to
then
load
ten
other
WordPress
drafts
in
order
to
read
your
draft
right.
So
it's
if
those
if
those
URLs
aren't
in
some
fashion,
you
know
resolvable
by
the
CLI,
then
we
run
into
the
problem
where
okay
I
need
you
to
I
need
you
to
run,
and
this
you
know
thousand
character.
Long
npm,
install',.
C
Sieze
and
all
of
NYC's
dependencies,
and
so
on
and
again,
this
is
this
is
also
sort
of
a
challenge
with
approaching
this
with
something
like
resolutions
where
it
would,
it
would
have.
There
would
have
to
be
a
convenient
way
to
specify
like
not
just
package
by
package,
but
for
an
entire
branch
of
the
tree
right
that
all
of
these
things,
I,
want
to
I
want
to
pull
in.
Anything
that
is
dependent
upon
by
any
stage
package
should
also
be
allowing
the
stage
versions
to
be
pulled.
In
now.
C
Npm
install',
tap
at
next
include
staged
and
what
our
includes
staged,
equals,
tap
and
so
tap
and
all
of
its
dependencies
and
all
of
their
dependencies
will
pull
in
the
staged
versions.
But
you
know
you
have
to
specify
specifically
like
I
wish
to
get
the
staged
version
of
tap
and
everything
it
depends
on
which,
which
would
you
know,
take
us
down
from
99%
likely
to
not
get
by
accident.
You
know
99.9
percent
well,.
D
Then,
especially
if
it
allows
you
to
target
a
specific
stage
like
if
I
could
stage
three
things
and
then
do
three
different
install
commands
that
install
it
each
of
those
to
test
them
all
and
compare
them
like.
That
starts
to
be
a
really
powerful
thing.
That
is
akin
to
a
resolutions
like
feature
without
stepping
on
the
toes
of
that
feature.
Right
and.
D
C
C
It
makes
a
list
of
all
the
versions
that
satisfy
the
the
spec
that
you
provided
and
then
it
sorts
them
by
I,
don't
I,
don't
recall,
actually
ordered
this
I
think
it
sorts
them
first
by
whether
or
not
they're
deprecated
and
then
by
whether
or
not
they're
staged
so
or
it
could
be
they're
around
anyway.
It
goes
basically
all
of
the
non
deprecated
non
staged
versions.
Then
all
the
deprecated
versions
that
are
not
staged
than
all
the
stage
versions,
so
the
the
impact
of
that
is
when
the
stage
versions
get
promoted.
D
C
C
Would
probably
yeah
sure
we
would
probably
still
want
to
sort
of
cascade
it
down
the
dependency
graph,
because
I
might
promote
tap
before
NYC
is
out
of
staging?
That
would
be
obviously
not
something
I
ought
to
do,
but
it
will
probably
happen
or
or
I
may
want
to
say,
like
I
want
to
pull
in
the
staged
versions
of
all
of
taps
dependencies.
You
know
there
may
be
a
patch
version,
that's
being
staged
right
and
so
I
want
to
make
sure
that
that
patch
is
actually
a
bug
fix
and
not
going
to
break
something.
C
D
C
D
F
E
Else
isn't
that
why
that's
kind
of
why
I
was
saying
at
next
in
the
include
stage
right,
because
you
want
to
say:
don't
it's
not
just
tap
at
fifteen,
you
might
want,
you
might
have
a
staged
version
of
different
patch
different
patches.
Oh
I
guess
you
could
then
do
tap
at
15.1
include
stage
tab.
Okay,.
D
A
C
C
So
I
can
go
through
some
of
the
some
of
the
the
plans
that
I
think
make
the
most
sense.
We
did
a
lot
of
back
and
forth
of
hashing
this
out
with
like
what
do
the
disk
Tech's.
What
did
the
dislike,
where
I'm
and
I
can't
really
find
any
serious
problems
with
this
if
we're
gonna,
if
we
assume
that,
like
for
the
time
being
okay,
this
like
includes
staged
equals
package
name,
is
acceptable
to
kind
of
reduce
the
scope
of
the
potential
foot
guns.
C
Then
there's
the
question
of
what
gets
saved
into
the
package
lock
JSON
and
how
do
we
sort
of
like
make
builds?
You
know
minimize
build
breakage
while
also
handling
cases
where
I've
pushed
a
new
staged
version
of
it
at
the
same
version
number
you
know,
maybe
one
of
my
beta
testers
found
some
critical
problem:
I
fixed
it
and
I
staged
the
new
version
with
the
same
December
version
mm-hmm,
and
so
this
is
also
sort
of
owing
to
some
registry
architecture.
C
C
So
I
definitely
want
to.
I
definitely
want
to
continue
to
keep
this
the
way
that
it
is
and
what
that
means
is
the
the
URL
for
the
staged
tarball.
The
best
way
to
do
that
is
to
no
longer
use
the
the
version
number
as
kind
of
the
the
name
and
version
number
is
kind
of
the
key,
because
that
obviously
now
is
going
to
be
something
that
could
change
the
prior
to
being
promoted.
C
So
my
my
thought
there
is:
we've
essentially
put
a
a
URL
safe
version
of
the
integrity
of
artefact
integrity
into
the
URL
and
then
so.
The
staged
the
staged
tarball
URL,
would
look
something
like
registry
and
Kim
JSON
org,
slash
package,
name,
/,
slash
staged,
/
content
address
slash,
you
know
poo
1.2.3
tvz.
Could
you
nod
sorry
as
it
could
you
write
that
out?
Just
for
know
keeping.
C
C
C
There
are
some
advantages
and
there
are
some
places
where
we
take
advantage
of
the
fact
that
that
registry
tarball
artifacts
have
a
consistent
shape,
and
so
I'd
want
to
be
really
careful
about
that
kind
of
a
move
and
be
really
clear
about
what
it
actually
buys
us,
but
I
think
having
the
the
name
and
version
number
is
kind
of
the
the
only
dependencies
on
the
the
fully
published
version
would
be
fine
in
that
that
URL
would
just
basically
404
until
it's
been
fully
promoted.
Sorry
so
break
this
out.
C
D
D
A
D
D
A
C
A
B
The
reason
I
was
thinking
about
it
is
that,
especially
if
we
go
not
only
the
mutable
but
multiple
versions,
thing
is
that
people
are
going
to
I
mean
maybe
it's
too
much
control
and
not
letting
people
hack,
but
they
intend,
for
these
staged
versions,
is
to
get
published
or
not
exist,
so
the
publish
and
not
exist.
What
we
can.
It
can
be
enforced
right,
be
done
on
the
registry
site.
B
So
maybe
it's
not
on
part
of
this
discussion,
but
it
seems
to
me
that
if
you
don't
publish
a
version
that
you
staged
then-
and
it
starts
to
live
on
for
a
long
time.
People
would
just
start
using
these
staged
version,
especially
if
it's
an
important
bug
fix
and
then
that
stage
version
becomes
essentially
ingrained
and
it
becomes
legacy
and
it
can
never
be
removed.
A
A
A
E
D
C
E
First
is
if
so
so
a
few
different
ways
here,
so
we've
brought
up
a
few
things
since
we
initially
talked
about
this
that
maybe
will
help
mitigate
some
of
it.
So
if
the
install
fails
when
includes
staged
is
not
passed
and
a
staged
version
is
in
the
lock
file
that
would
break
a
build
right
because
again,
two
jurors
point:
it
takes
one
person
running
at
one
time
for
everybody
on
the
team
to
get
it
and
if
they're,
not
passing
inclusive.
E
A
D
D
Would
will
you
I
mean
if
that's
a
good
thing
cool,
but
then
that's
that's
still,
breakage
that
the
developer,
who
who
included
staged
in
the
first
place,
might
have
left
the
company.
And
then
you
have
a
thousand
people
for
four
years
who
have
been
relying
on
this
and
then
all
of
a
sudden.
It
stops
working.
And
no
one
knows
why,
because
it
was
a
staged,
build.
D
B
Okay,
so
I'll
go
on
the
other
side.
If
we
do
not
include
it
in
the
package
lock,
then
it
becomes
really
tricky
to
use
it
to
try
it
out
in
other
places,
because
all
of
a
sudden
he
needs
to
modify
your
CI
config.
So
suppose
you
have
it's
the
example
we're
using
suppose
you
have
a
new
version
stage
version
of
NYC.
You
want
to
use
it
in
tap.
All
of
a
sudden.
You
have
to
modify
tap
CI
config
to
change
the
npm
install
command
so
that
you
can
take
that
other
thing
in.
E
B
I
think
that
if
we
set
the
expectation
right
about
the
stage
version
getting
removed
just
going
to
play
with
the
idea
right,
then
every
time
you
install,
you
could
see
that
it's
getting
removed
soon.
If
somebody
staged
it
and
it
got
removed,
whoever
staged
that
they
know
that
it
will
get
removed
and
I
mean
things
do
happen.
Things
do
move
away,
but
as
well,
if
the
package
did
get
removed
and
we
still
have
some
metadata
that
it
was
staged
at
some
earlier
point,
then
we
can
also
give
a
remediation
saying.
B
You
know
there
was
a
staged
version.
It's
no
longer
there
because
it
expired.
You
can
go
use
this
other
version
right,
but
I,
don't
think
that
there
is
a
way
to
avoid
these
staged
versions
getting
into
package
JSON
or
package.json
textual
objects.
Alright,
if
it's
in
a
package
JSON
it's
not
even
in
the
lock
file,
then
you
know
we
have
to
respect
it
right,
listen
if
it's
pinned
to
a
specific
version
which
is
still
staged
right.
We
still
have
to
respect
that
right.
Well,.
C
I
want
to
I
want
to
actually
dig
into
something
that
Dom
said
like
if
I,
if
I
want
to
try
out
this
this
new
version
and
see
if
the
bug
fix
fixes
my
bug,
the
then
I
run
npm
install
a
hood
sage,
bla
bla
bla,
it
updates
my
log
file
and
I.
Go
great.
Everything
looks
you
know,
works
on
my
machine.
Let
me
push
it
to
see
I
to
see
if
it
works
there
too,
like
what
I
actually
want
is
the
locked
file
to
pull
the
URL
for
the
tarball.
C
C
If
it's,
if
it's
promoted,
then
the
content
address,
didn't
change
and
I
still
get
the
same
artifact
with
the
same
integrity
at
the
same
URL
and
yeah.
It's
kind
of
not
the
canonical
official,
just
a
version
number
of
that
URL,
but
it's
fine
and
we
can
even
have
it.
Have
it
return
a
301
moved
or
something.
C
If
we
want
to
tell
NPM
to
resolve
it
at
this
other
location
instead
and
that
can
actually
just
automatically
update
the
lock
file,
because
now
my
my
resolution
changes
so
I
I,
don't
I,
don't
know
like
keeping
it
out
of
the
lock
file.
It
seems
like
it
only
speaks
to
this
goal
of
I
want
to
make
sure
that
nobody
fetches
staged
things.
C
Even
even
machines,
fetch
stage
things
without
kind
of
that
explicit
opt-in
at
the
install
command,
which
I
don't
know
it
just
it
feels
like
it
feels
like
a
little
bit
of
an
overreach,
because
now,
if
I
want
to
try
out
that
thing,
I
have
to
actually
not
just
install
it
test
it
push,
it
I
have
to
install
it
test.
It
update
my
Travis
CI
or
my
github
actions,
workflow
install
command,
and
it's
just
like
much
more
work.
F
You
would
find
those
kind
of
problems
quickly
and
hopefully
before
it's
gonna
have
a
large
impact,
and
it
also
seems
consistent
with
we're
not
trying
to
introduce
a
new
way
of
getting
it
packages
forever
right.
It's
like
this
is
the
you
know.
This
is
a
small.
You
know
we
just
want
them
to
be
staged
until
we
can
promote
them.
C
It's
just
it's
one,
zero
forever,
right
and
and
that's
actually
not
great,
because
what
that
means
then
is
like
we
don't
have
that
kind
of
really
nice
ability
to
track
back
and
say
here
was
you
know
this
is
a
cember
bump
and
like
this?
Is
the
version
number
that
it
was
and
if
we
had
a
week
feels
a
week
feels
short
to
me.
Yeah
I'm,
with
Amelia
I,
would
lean
more
towards
like
a
month,
but
then
also
we
could.
We
could
at
least
still
say
we
could
print
a
warning.
It's
like
hey.
C
D
I
had
two
comments.
One
was
perhaps
to
mitigate
the
what
the
breakage
that
would
happen
when
a
staged
version
goes
away.
The
lock
file
should
store
two
URLs,
the
staged
tarball
on
stage
star
ball,
and
that
way
you
don't
have
to
like
alter
the
lock
file
in
order
to
have
the
tarball
that
you
would
fall
back
to
the
the.
How
that
is
also
relevant
is
my
second
comment,
which
is
staged
versions
in
a
package
lock
like
it's.
D
Definitely
who
cares
fine
right,
like
there's,
there's
use
cases
around
that
for
like
a
a
nap
for
you
know,
companies
mono
repo
things
like
that,
but,
like
it's
not
gonna,
infect
the
ecosystem,
because
its
package
lock
but
NPM
shrink
wrap,
is
just
a
different
name
of
package
lock
that
does
in
fact
ecosystem.
Can
we
somehow
make
it
so
that
staged
versions
don't
work
when
they're
in
a
published
shrink
like
when
you're
there
inside
node
modules
and
perhaps
having
both
URLs
and
the
tarball
would
be
a
really
trivial
way
to
do
that.
C
So
the
tricky
thing
having
both
URLs
in
the
tarball
is
trickier
than
it
sounds
just
because
of
some
assumptions
sort
of
throughout
the
system.
That
thing
resolves
to
a
single
thing:
I.
A
E
A
little
bit
actually,
you
I
think
that
to
URLs
solves
some
interesting
problems,
so
I
think
we
should
consider
that
more
so
I
don't
want
to
totally
change
topics
but
I
think
going
back
to
the.
If
we
auto
expire
them
and
say
we
do
a
month,
you
have
a
build,
that's
been
working
for
a
month
and
now
suddenly
it's
broken
is
really
a
tough
scenario.
To
put
people
in
so
I.
E
Think
I
I'd
actually
err
on
the
side
of
go
way
too
short
to
very
forcibly
prevent
people
from
like
pushing
something
and
going
home
for
the
day
and
then
having
the
CI
be
broken
like
it'd,
be
better
if
it
was
like
broken
that
day,
like
within
a
couple
of
hours,
so
they're
very
clearly
aware:
oh
yeah
I
pushed
today
a
staged
version.
That's
probably
what
broke
the
build,
which
is
a
lot
harder
to
do
a
month
later
so
yeah.
A
We
might
take
I
mean
you
can
pin
this
against
our
unpublish
policy,
so
72
hours
would
be.
You
know
we
have
something
that
we've
already
decided,
that
there's
a
policy
with
some
sort
of
time
limit
and
we
aren't
creating
something
out
of
nothing
in
terms
of
you
know
arbitrarily
deciding
on
time
timeline.
We
already
have
a
policy
for
unpublish
and
we've
decided
that
saying
three
hours
is
you
know
what
we're
going
to
pin
that
against?
Maybe
we
could
utilize
that
as
the
as
a
time
if
we
are
gonna,
go
down
that
way
that.
A
F
B
Only
concern
there
I
mean
there
is
the
restage
that
does
work.
My
own
concern
there
is
that
it
probably
works
in
a
commercial
business
setting,
because
that's
your
day
job
and
you
look
at
things
day
in
day
out,
whereas
in
open
source
world
things
move
a
bit
slower,
especially
if
you're
asking
somebody
to
review
something
I'll.
A
E
E
Oh,
we
also
have
a
cron
job
and
that
cron
will
check
to
see
if
it
is
not
yet
published
and
not
yet
merged
to
master,
then
continually
re
staged
every
day
right
or
something
like
that
and
that'd
be
a
fairly
easy
setup
that
would
get
us
really
close
to
what
we
want,
even
for
the
open
source
use
case
where
we
might
want
it
to
sit
for
a
month.
What.
G
About
doing
something
sort
of
like
the,
what
do
you
call
it
to
factor
auth
code
prompt,
we're
automatically
up
to
72
hours?
You
have
to
go
to
it.
The
package
will
fail
to
install
unless
you
go
to
an
open,
a
URL
click
on
the
link
to
say
yes,
I
actually
want
to
install
this
version,
just
to
sort
of
add
a
step,
and
it's
it's
still
there
and
it
would
still
work
and
then
just
one
person
in
your
organization
or
your
team
or
your
project
needs
to
click
that
URL
and
it
reactivates
it.
So.
A
D
C
C
But
again,
the
stage
the
include
stage
command
is
only
about
version
resolution
against
the
PAC
unit.
It's
not
about.
Does
the
URL
work,
the
URL
works
like
it's
it's
out
there
and
we
we
give
up
a
lot
in
terms
of
efficiency.
If
we,
if
we
try
to
make
a
lot
of
too
many
conditions
on
that
thing,
working,
we
can
delete
it
easily
enough
and
refresh
the
caches,
but
having
having
other
mechanisms
like
you
know,
putting
other
other
hooks
on
it,
it
gets
kind
of
tricky.
A
So
I
just
want
to
be
mindful
here
again,
we
are
sort
of
beyond
time
and
I
apologize.
We
got
started
late.
That's
on
me,
there's
two
things
that
we
should.
It
should
get
to.
I
know
that
this
RC
originally
was
kicked
off
by
Daniel
I'm
looking
for
somebody
to
champion
this
going
forward
so
that
we
can
get
some
updates
actually
to
it.
Based
on
the
fact
that
I
think
we've
talked
a
lot
about
implementation
details
here,
which
aren't
at
all
defined
in
the
RC
as
it
stands
today,
so
I'm,
not
sure
Isaac.
C
A
I'd
be
ideal
just
to
essentially
make
some
of
this
a
bit
more
actionable.
If
we
can
actually
see
you
know,
I
think
there's
a
lot
of
good
pieces
in
what
we've
talked
about
it.
Just
in
this
call,
along
in
terms
of
you,
know,
time-to-live
or
like
essentially
an
expiry
of
stage
packages
sounds
interesting,
the
way
in
which
that
actually
gets
action
on
or
like
you
know
whether
it
goes
away
access
is
forbidden
or
we
have
some
sort
of
like
prompt
I.
A
Think
it's
like
like
a
nuance
detail
that
we
can
talk
about
in
the
actual
RFC,
but
if
we
can
actually
update
based
on
the
fact
that
the
initial
r0
is
very
broad,
very,
very
broad
and
and
some
of
the
terminology
that
we're
using
is
not
in
the
karnar
see,
including
include
stage
even
that
kind
of
change
will
make
us
get
us
closer
to
getting
consensus.
I
think
so
well,
yeah
with
that
in
mind,
I
just
wanted
to
say
thanks
for
everybody
to
jump
it
on
this
call.
Hopefully
we
can
continue
out
these
discussions.