►
From YouTube: Open RFC Meeting - Wednesday, February 2nd 2021
Description
In our ongoing efforts to better listen to and collaborate with the community, we run 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
And
we're
live,
welcome
everyone
to
another
npm,
open
rc
call.
Today's
date
is
wednesday
february
2nd
2022.
I
will
be
following
along
in
the
agenda
that
was
posted
in
the
rfc's
issue:
520
on
npm,
slash,
rfcs,
rebound
github.com
I'll
paste.
A
The
link
to
that
ticket-
if
you
haven't
already
feel
free
to
add
yourself
to
me,
note
stock,
which
I've
spammed
here
in
chat
for
folks
and
just
quick
reminder,
these
calls
and
all
comms
on
the
rc's
repo
our
covered
order
of
code
of
conduct,
which
we
ask
you
to
please
abide
by
and
in
these
calls
we
ask
to
please
be
mindful,
as
other
folks
are
talking
and
await
your
turn.
A
Please
raise
your
hand
if
someone's
talking
and
we'll
call
upon
you
and
yeah,
ideally
just
be
kind
to
each
other
and
quickly
want
to
give
some
space
for
any
announcements
folks
might
have.
A
The
one
thing
that's
been
on
our
radar
for
last
little,
while
is
just
the
open,
js
world
conference
that's
coming
up.
Hopefully
it
sounds
like
there's
going
to
be
collab
summit,
also
at
this
time,
which
our
team
has
participated
in
historically,
which
we'd
love
to
see
folks
there,
ideally
in
person,
fingers
crossed,
but
also
virtually
if
that
can
also
be
possible.
So
it's
definitely
an
event
that
I'm
looking
forward
to
personally
and
hopefully
we
can
see
a
lot
of
folks
there.
They
do
have
a
cfp
that
is
still
open.
A
A
That's
the
first
conference
I'll
be
going
to
in
about
two
years
so
exciting,
any
other
announcements
before
we
move
on
to
the
agenda.
A
If
not,
let's
dive
in
so
the
first
rc
that
we
have
pr
that
is
open
for
335.
This
is
a
make.
Npm
install
log
level.
Warn
output:
quieter,
I'm
just
gonna
reference.
This.
A
Okay,
well,
this
might
be
a
short
rfc
call
today,
if
we're
not
able
to
check
out
rc's,
I
know
at
least
we've
got
one
that
we
have
checked
out
in
a
branch
that
we
could
talk
to,
which
is
the
distributions
one.
Let's
see
quickly,.
C
It
seems
that
it
is
like
every
like.
I
opened
up
gist
and
it's
down,
so
I
assume
it
is.
If
you
want
to
pull
up
one
that's
checked
out,
I
would
recommend
that
and
if
it's
resolved
at
the
end,
that's
I'm
getting.
D
D
D
You
can
start
with
mine
the
next.
The
next
point.
There
is
deprecated
packets
that
one
I
also
have
checked
locally.
I
could
share
my
screen.
A
Sorry
say
that
again
right
I
did
catch
the
last
little
bit.
D
I
can
share
my
screen
here
if
you
want
for
that.
One.
B
So
I
I
don't
know
you
may
not
have
seen
them
then,
but
I
made
some
comments
on
the
distributions
rfc
before
everything
died,
so
we
can
certainly
have
a
chat
about
that.
If
that's
what
we're
talking
about.
F
A
Some
examples
that
I
think
that
was
the
first
thing
I
saw
in
terms
of
your
suggestion
was
missing
some
examples
of
the
other
types
of
conditions
that
you
can
use.
B
For
the
what
was
that
and
in
your
example,
all
of
the
default
consumers
of
my
packages
omit
tests,
but
I
want
to
be
able
to
have
folks
like
myself,
opt-in
to
including
them,
and
if
I'm
forced
to
do
that
by
publishing
a
separate
package,
that's
actually
fine.
I
could
make
some
throwaway
package
scope
for
that
and
publish
everything
under
it
right,
like
I'm
very
happy
with
that.
B
A
A
I
want
to
talk
to,
and
maybe
in
the
time
that
we
look
over
roy's,
we
can
actually
look
at
that
rc
together.
So
roy
did
you
want
to
jump
into
your
ux
improvements
to
deprecation
warnings.
D
A
Okay,
I
mean
the
one
thing
that
I'll
note
about
the
that
I
think
you
were
speaking
to
then
jordan
about
the
your
specific
use
case
and
what
you
were
looking
for
from
package
distributions.
A
I
don't
think
we
would
support
that
condition
from
the
outset,
but
I'm
not
saying
that
we
couldn't
add
in
the
future
like
a
condition
that
you
could
use
to
then
do
that
so
right
now
we
want
to
limit
the
scope
to
just
information
that
we
currently
use
specifically,
for
you
know,
engine
strict
or
like
other.
A
B
B
I
jumped
to
optional
dependencies
because
it
seems
there
is
one
or
two
package
clusters
I
know
of
that
are
doing
this
brand
new,
very
rare,
very
niche
use
case
of
I
want
to
make
a
sort
of
dis
proxy
dispatching
package
and
use
me
as
a
way
to
like
bootstrap
the
actual
package
you
want
for
your
platform.
B
That's
a
pretty
rare
use
case
because
most
things
published
are
no
javascript
programs
and
don't
require
that
so
the
more
common
use
case,
I
think,
is
actually
optional
dependencies,
which
is
underutilized,
because
you
can't
specify
that
I
have
these
seven
optional
dependencies,
but
really
it's
just
one
depending
on
which
platform
you
have
or
which
you
know
which
os
or
which
engines
and
so
to
me
the
like.
B
With
optional
pens,
you
should
you're
just
saying
this
dependency
at
this
version
and
you
have
to
rely
on
it,
compiling
and
failing
to
compile
in
order
to
not
be
installed
where
it's
not
needed,
and
you
can't
actually
avoid
trying
to
install
it
where
it's
not
needed,
whereas
this
sort
of
distributions
format
that
I
saw
suggested
to
me
a
better
schema
for
optional
dependencies.
Where
you
can
say
this,
dependency
should
only
be
attempted
under
these
conditions
and
under
these
conditions,
perhaps
you
want
it
to
be
required
and
not
optional.
B
I'm
saying
that
the
ability
to
replace
the
package
itself
that
for
one
package
to
say,
replace
me
with
something
else,
that's
a
brand
new
thing.
That
is
very
much
not
a
common
use
case,
and
I
don't
even
know
if
it's
a
good
one.
It's
just
one
that
a
couple
that
two
very
one
or
two
very
specific
examples
have
recently
the
thing
that
is
a
very
broad
use
case
and
is
a
good
one.
B
Is
I
have
a
a
one
conceptual
dependency
that
needs
one
of
a
set
of
packages
depending
on
those
conditions,
meaning
like
I
need
puppeteer
or
like.
I
need
a
file
watcher
and
my
file
watcher.
Is
this
package
on
a
mac
in
this
package
on
linux
and
this
package
on
windows,
but
I
need
only
one
file
launcher
but
I'll
I
shouldn't
be
it's
not
successful.
If
I
don't
have
one
file
watcher
right,
like
that's
a
common
use
case,
the
the
the
sort
of
I
think
it's
es
build
is
one
of
them,
that's
sort
of
like.
B
A
So
the
reason
really
how
this
is
the
reason
why
this
is
getting
attention
and
and
was
getting
attention
six
months
ago
and
getting
attention
like
we
we
considered
this
even
like
a
year
ago
and-
and
this
is
constantly
come
up-
is
for
shipping
binaries
that
are
specific
to
the
platform,
and
that
is
today.
A
What
happens
is
we're
trying
to
eliminate-
and
I
can't
pull
this
up
right
now,
but
the
language
that
I
was
trying
to
use
in
the
rfc
specifically
is
implying
that
we're
trying
to
get
this
to
this
place,
where
there's
enough
features
available
to
people
to
limit
their
usage
of
install
scripts
to
do
any
kind
of
builds
to
introduce
any
kind
of
like
build
step,
post
installation
right
like
or
like
you
know,.
A
B
Just
I
can
see
how
the
distributions,
as
you
seem
to
have
phrased
it,
how
that
sort
of
solves
the
problem
when
the
variants
are
all
made
by
the
same
author,
meaning
if,
if
if
the
use
case
is
a
bunch
of
people
want
to
depend
on
es,
build
and
all
of
the
different
variants
of
es
build,
are
published
by
the
es,
build
project
and
like
that,
this
sort
of
would
allow
that
to
be
abstracted
away
so
that
the
consumers
of
es
build,
don't
have
to
know
or
care
about
those
details
and
especially
can
actually
just
sit
right.
B
So
I
get
that,
but,
like
the
file
watcher
use
case,
those
might
be
completely
distinct.
Packages,
chakadar
doesn't
make
a
windows
version
right
and
so
chocolatar
won't
declare
if
you're
on
windows
use
this
other
thing
they
might
but
like
they,
you
shouldn't
be
expected
to
because
they
don't
make
it
and
they
can't.
You
know.
C
B
B
A
So
I'll
quickly
respond
to
that
and
then,
when
I
see
your
hands
up,
I
don't
think
like
at
we're
trying
to
work
around,
not
updating
the
log
file
or
having
that
change
in
different
environments,
but
there
seems
to
be
like
we
can't
really
solve
all
the
problems
if
you
are
want
to
essentially
swap
out
one
package
for
another,
the
cons
there's
a
real
concern
there
that
the
apis
are
completely
different
and
so
like
they
are
not
potentially
interchangeable.
A
So
that's
why
this
is
so
maybe
scoped
or
are
specific
to
the
I
potentially
own,
all
these
packages
that
are
distributions
that
are
pre-built
with
the
proper
binaries
that
they
they
need.
That
are,
you
know,
just
essentially
the
exact
same
package,
but
built
for
and
having
explicit
constraints
about
the
environment
that
I'm
gonna
be
installed
in
to
and
used
like
under.
A
There
might
be
here
like
what
you're
speaking
to
there
might
be
a
separate
feature
that
we
can
add
that
is
going
to
address
the
other
types
of
concerns
that
you
have
or,
like
the
other
other
wants
that
you
have
right.
So
it
sounds
like
it's
not
a
concern.
It's
just
like.
Hey,
can
we
apply
this
kind
of
idea
to
your
your
wants.
B
Right,
it's
my,
I
think
it's
that
the
problem
and
sorry,
oh
and
I
keep
replying
the
the
the
it's
that
the
issue
is.
Actually
the
problem
is
the
same,
but
the
like
the
broader
conceptual
problem,
which
is,
I
want
to
use
something
and
that's
platform
dependent,
but
the
you're
right.
That's
some
in
that.
It's
not!
B
I
think
that
the
that
it
would
be
just
it
is,
it
would
be
inappropriate
to
say
people
should
use
aliases
to
handle
this
just
like
it
would
be
inappropriate
to
say
people
should
use
distributions
to
handle
this,
because
both
of
those
are
heavily
exclusionary
to
like
the
rest
of
that
big
actual
conceptual
problem
set.
B
So
like
it's,
it's
important
to
consider
that
this
is
a
distinct
pile
of
use.
Cases
like
the
es,
build
thing
versus
like
the
file
watcher
thing
but
like
it
seems
worth
trying
to
tackle
it
holistically
instead
of
piecemeal.
You
know
I'll
be
quiet
for
a
while.
Now.
G
Yeah,
I
just
wanted
to
add,
I
think
more
to
like
the
the
es
built
or
seeing
a
lot
of
similar
cases
and
in
not
sure
how
many
of
you
familiar
with
stack
blitz.
But
you
know
that's
a
great
case
where
they
don't
allow
post
install
scripts.
So
you
can't
build,
for
you
know
the
particular
operating
system
so,
and
I
think
it's
maybe
come
up
before.
G
I'm
not
sure
if
it's
tied
to
this,
because
I
can't
see
the
issue
but
that's
you
know,
potentially
a
more
emerging
use
case
for
I
own
the
package
and
I'm
going
to
pre-build
the
binaries.
And
then
you
know
something
like
stack
blitz
can
pick
like.
Oh
I'm
running
on
this
figure
out
through
the
matrix,
the
right
one,
but
I
think
to
jordan's
point.
It
would
be
interesting
to
see
you
know
how
many
people
or
how
many
authors
are
providing
variants
that
they
don't
they
themselves.
G
G
So
anyway,
I
don't
sure
how
many
of
you
familiar
with
stack
blitz,
but
it's
getting
a
lot
of
traction,
especially
with
web
containers,
and
you
know,
maybe
it's
a
way
to
encourage
more
developers,
and
maybe
that's
something
npm
or
github
can
do
to
be
like
here's
tools
and
resources
for
you
to
own
that
distribution
end
to
end.
You
know:
here's
a
template
of
how
you
could
pre-build
like
es
bill.
G
Does
you
know
leverage
their
experience
so
far,
some
of
these
kind
of
more
rusty
or
other
type
of
tool
chains-
and
you
know
maybe
that
goes
into
like
the
package-
maintenance
working
group-
something
like
that.
You
know
so,
but
yeah
maybe
again
jordan's
point.
I'm
not
sure
how
you
gather
that
data,
but
you
know
doing
surveying
that
might
help
you
understand
if
there
is
any
niche
or
if
it's
split
down
the
middle
or
you
know
you
know
anyway,
just
throwing
that
out
there,
but
I
think
very
useful
in
terms
of
conceptualization.
A
Yeah,
I
I
just
want
to
comment
one
to
one
thing
and
then
roy,
I
see
your
hands
up
yeah,
so
I
I
think
that
this
initial
set
of
conditions
is
because
we're
so
focused
on,
like
the
platform
information
is
not
limiting
to
the
eventual
you
know.
Could
we
potentially
introduce
other
types
of
conditions,
other
information
that
we
can
utilize
to
to
expand
the
scope
of
of
of
the
use
cases
that
we
support?
A
So
this
is
sort
of
a
cursory
like
understanding
of
where
we
think
the
need
is
the
most
and
like
this
is
definitely
directed
at
a
subset
of
package
maintainers.
This
is
a
small
group
that
are
have
this.
This
problem,
which
they
are
solving
through.
I
would
say
what
we
consider
to
be
like
on
optimal.
A
You
know
a
ways
like
bespoke
ways
that
are
that
we're
trying
to
patch,
essentially
by
considering
completely
turning
off
people's
ability
to
to
run,
install
scripts
right
like
so
that
that
that's
like
one
of
the
things
that
like,
if
we
don't
do
this,
how
do
we
can
we
address
this
other
thing
and
so
providing
some
kind
of
mechanism
for
people
to
you
know?
Do
do
this
specific
thing,
which
is
to
ship
a
version
of
themselves
that
is
specifically
pre-built
that
addresses
you
know
the
conditions,
hopefully
incentivizes.
A
D
Sure
yeah,
I
was
basically
going
to
say
that,
but
I
I
also
had
a
second
part
that
oops,
oh,
my
god,
can
you
hear
me
yeah
yep,
so
yeah,
okay,
yeah?
Basically,
I
was
going
to
also
mention
that
our
idea
here,
jordan,
or
at
least
what
I
discussed
previously
with
darcy
when
we
were
reviewing
this
rfc,
is
also
to
go
in
parts.
D
I
know
we
didn't
that
in
the
past,
with
the
workspaces,
like
we
split
that
in
many
parts
like
there
was
at
least
four
different
rfc's
that
I
worked
on,
that
were
just
continuation
of
the
work
on
workspaces,
so
the
idea
here
would
be
similar
so
that
this
could
provide
the
initial
support
for
distributions
or
away,
and
now
we're
focusing
on
this
on
this
binary
use
cases
distribution,
but
then
in
the
future.
That
will
stop
us
for
adding
different
ways
to
maybe
filter
optional
dependencies
at
the
moment
of
install
and
have
that
also
be
consumed.
D
Alongside
of
the
distributions
right,
so
you
can
see
how
we
can
incrementally
build
from
this.
So
this
would
be
the
foundational
step
to
start
to
work
on
supporting
different
variants.
Distributions.
B
So
my
sort
of
response
to
both
of
those
is,
I
think
you
can
already
do
this
with
optional
dependencies
es
build,
could
have
an
optional
dependency
on
all
their
things
and
have
a
tiny
file
to
compile.
That
does
nothing
except
fails
if
it's
on
the
wrong
arch
and
they
could
have
everything
else,
be
pre-compiled,
it's
awkward,
it's
not
ergonomic,
and
it
still
requires
all
the
variants
to
be
installed,
but
it
would
actually
that
would
work
just
fine
with
no
changes.
B
No
post
install
scripts,
just
the
build
scripts,
which
are
already
a
thing
and
improving
the
ergonomics
of
that
by
adding
conditions
to
optional
dependencies
in
some
way
would
solve
every
problem
all
at
once,
and
so.
B
It's
just
like
that
to
me
seems
like
a
better
plan,
and
it
took
me
about
three
minutes
of
thinking
to
come
up
with
it
and
like
maybe
it's
a
terrible
idea
for
for
reasons,
but
like
I
think
that,
there's
that
a
more
holistic
look
is
probably
a
better
approach
than
trying
to
jump
straight
to
a
solution
you
know
like
it
seems
like
it
seems
like
an
xy
problem
to
me
right,
like
the
if
the
the
x,
if
the
problem
that
we
think
we
have
is
we're
using
install
scripts
for
this
one
use
case
like
well.
A
Yeah,
definitely,
I
think
we
did
see
at
one
point
and
I'm
just
trying
to
find
it.
Somebody
referenced
this
type
of
here.
I
think
I
found
it.
It
was
in
a
discussion
where
we,
which
I
think
we
had
previously
brought
up
here-
discussion
440
in
the
rfc's
repo
peer
dependency
groups,
where
they
were
essentially
considering
like
credibility,
groups
and
alternatives
to
those
it's
a
little
bit
similar
to.
A
I
think
what
you're
saying
jordan
in
terms
of
like
optional
dependencies
on
steroids,
with
like
new
new
feature
set
of
conditions
and-
and
I
think
I've
even
seen
another
reference
of
folks
asking
for
something
similar
to
what
you're
saying.
B
Right
because
I
mean
the
other
advantage,
there
right
is
that
the
the
optional
dependencies
have
sort
of
been
like,
like
the
fact
that
they're
optional
is
not
really
the
important
bit
there.
It's
just
the
way
that
the
feature
has
been
achieved
like
the
important
bit
is
like.
I
have
a
thing
that
may
or
may
not
exist
and
it
and
what
it
when
it
exists.
B
A
A
Essentially,
like
that
bootloader
script
that
yes
build,
has
or
other
other
people
are
trying
to
re-implement,
you
know,
time
and
time
again
to
see
which
optional
dependency
was
installed
and
then
essentially
pro
and
then
pass
that
through,
like
the
the
that
to
me,
is
kind
of
the
unergonomic
like
making
it
hard
for
the
ecosystem.
A
To
like
do
that
right,
not
saying
that
again
like
there,
it
seems
like
there's
two
two
use
cases
that
maybe
we
can
use
some
of
the
similar
similar
idea
to
approach
these
things
right
so
use
you
want
this
feature
in
optional
demand
sees
itself,
so
you
can
write
conditions
for.
B
Your
options,
it
doesn't
have
to
be
in
there
it's
just
conceptually.
What
I
want
is
to
like
the
the
it's,
the
aliasing
that
makes
me
really
concerned
like.
I
also
am
wondering
if
this
is
a
security
concern,
because,
like
somebody
could
make
a
package
that
only
on
a
target
platform
swaps
out
the
package
for
a
malicious
one
like
it's
like
a
new
attack
vector.
A
B
You
have
to
turn
on
install
scripts,
there's
a
built-in
presumption
in
that,
which
is
that.
That
is
that.
That
behavior
is
something
that's
actually.
We
want
to
encourage
the
people
to
build
to
ship
lots
of
compiled
things
wanting
to
enable
it
is
a
very
different
statement
than
wanting
to
encourage
it.
A
That
to
me
is
like
we
want
to
prevent
that,
and
so
how
do
we
provide
a
new
means
of
you?
You
know
like
doing
that
in.
A
Like
yeah
like
yeah,
that's
the
hope
with
this,
like
I
think,
but
I
I
would
like
to
address
like
the
not
concerns
but
like
the
use
cases
that
you're
bringing
up
they
may
it
may
just
be
a
separate
rfc
or
maybe
maybe
we
can
like
split
this
out
in
some
way
that
it.
B
Matches
yeah
yeah
and
I
don't
think,
there's
any
pushback
for
me
or
anyone
else
on
the
goal
of
like,
let's
find
a
way
to
remove
the
need
for
install
scripts.
Like
everyone
wants
that,
so
you
know
I
I
I'm
just.
I
hope
that
we
spend
more
time
thinking
about
everything
holistically
instead
of
kind
of
tunnel
visioning
on
in
individual
iterative
solutions,
but
yeah.
A
That's
all
yeah
like
the
thing
is
like
we
can't.
I
don't
think
we
can
turn
them
off
until
we
have
other
avenues
for
the
for
all
the
use
cases
people
have
today
for
for
using
them
and
so
like
that's
kind
of
the
chicken
in
the
egg.
It's
like
what's
going
to
come
first
here
and
and
I'm
hoping
that
with
this,
if
we
land
something
like
this,
it's
enough
so
an
incentive
that
we
can
go
out
to
those
folks
and
say
hey.
A
Can
you
start
to
build
this
and
then
I
really
think
it's
a
huge
win
if
we
get
people
distributing
all
their
software
on
the
registry
right
like
if
there's
no
references
to
get
repos
there's.
No,
you
know
like
like
removing
all
of
that.
You
know,
and-
and
so
that
is
to
me-
is
a
huge
win.
I'm
very
concerned,
obviously
about
you,
know
any
kind
of
reference
to
a
dependency
that
is
not
on
the
registry.
That
is
my
biggest
biggest
concern
personally,
that
is
not
a
package
like
if
it
was
up
to
me.
A
I
would
consider
that,
like
a
flaggable
offense,
if
you've
got
a
reference
to
a
gab
repo
in
your
package
today
like
we,
we
should
like
you,
consider
even
choosing
not
to
install
those
you
know
as
a
security
issue.
So
anyways,
that's
that's,
I
think,
a
really
good
synopsis
of
what
we're
aiming
at
with
distributions
it
just
got
opened
today.
So
I
know
a
lot
of
folks
may
not
have
had
a
chance
to
read
the
the
document.
A
Yet
it
sounds
like
I
have
to
go
back
and
edit
some
of
the
examples
I
apologize
there,
jordan
there's
some
missing
references
that
I'm
sure
would
make
things
a
lot
more
clear
as
well,
but
really
excited
for
folks
to
to
give
their
feedback,
and
we
can
keep
it
open
for
for
a
couple
weeks
here
and
have
discussion
so
great
if
github
is
back
up.
Maybe
we
can
jump
back
to
the
beginning
of
our
agenda
here,
and
this
is
pull
request.
A
I'm
not
sure
is
debris
or
dave
on
the
call
nope.
A
D
But
there
is
also
the
the
message
about
like
how
much
how
long
it
took
them
can
install
command
to
run
so
yeah
like
they
were
saying
like
like
to
get
rid
of
everything,
hold
you
out,
but
yeah.
So.
D
Yeah,
but
I
think
it's
just
for
warning,
if
I'm
not
mistaken,
because
they
would
only
they
would
not
want
to
silence
everything,
they
would
still
want
to
be.
D
Aware
if
there
was
a
warning
on
our
narrow
right,
so
basically
this
might
also
play
with
some
of
the
things
luke
luke
was
working
on
in
trying
to
clear
clean
up
the
er
extended
error
in
standard
output
story
on
the
client.
I
know
luke
has
been
talking
to
that
so
yeah.
I
basically
basically,
I
just
wanted
to
to
bring
this.
A
I'm
not
sure
luke.
If
you
have
any
thoughts
on
this
because
I
know
you've
been
digging
here
as
as
yeah.
F
It
is
related
to
an
rfc
or
an
rrc
that
I
commented
on
that
is
on
the
agenda
for
later.
As
for
this
specific
one,
I'm
not
sure
I
have
enough
context
right
now.
I
do
remember
looking
at
it
originally,
but
then
have
not
taken
a
second
look,
but
it
does
feel
to
me
like
this.
F
If
it's
an
issue,
I
don't
think
this
is
the
right
change
to
make.
I
think
the
issue
is
making
the
output
better
and
silent
as
like
a
way
to
turn
off
all
output
is
the
right
lever
to
pull
for
like
not
wanting
to
see
it,
but
just
we
shouldn't
have
too
verbose
of
output
and
then
possibly
changing
stuff
from
warnings
to
different
levels.
So
I
feel
like
it's
more
like
a
case-by-case
basis
of
specific
output
and
making
it
better.
F
So
people
want
to
see
it
and
then
changing
levels
for
specific
messages,
so
that,
but
I
don't
think
this
is
the
right
change
to
make
for
this
specific
problem.
A
It
definitely
seems
like
we
don't
have
the
like.
We
sort
of
have
these
groups
with
cascade
and
there's
no
way
to
like
have
explicit
omissions
or
inclusions.
A
So
it's
it's
like
warning
will
or
log
level
warm
will
include
info
because,
like
that's
the
the
lowest
level
or
highest
highest
level
or,
however,
we
want
to
look
at
that.
Adverse
sort
of
thing
is
that
is
that
accurate
kind
of
like
what
I'm
saying
like
it
seems
like
if
we're
gonna
show
warren
warnings,
we
also
sure
show
notices
and
info
right,
like
that's
how
those
that
works
right.
F
Yeah,
I'm
not
exactly
sure
what
the
levels
are
currently
they're,
also
in
flux.
A
little
bit-
and
I
know
of
at
least
one
bug
where
setting
flags,
not
the
log
level
flag,
will
change
your
log
level
like
timing,
but
that,
like
bumps
it
to
a
different
level,
which
will
then
include
hdp
messages,
so
I
do
think,
there's
probably
some
auditing
to
do
there
and
seeing
if
we
still
agree
with
like
what
levels
are,
are
what
and
how
they
cascade
onto
each
other.
But
I
believe
warning
is
second
below
error.
F
So
if,
if
that's
true,
then
yeah,
then
this-
and
this
could
just
be
a
bug
too,
because
they
said
I
just
reread
the
first
paragraph
where
they
said
they
did
try
log
level
air
and
that
wasn't
good
enough
to
hide
this
stuff.
And
I
think
that's
because
some
of
these
messages
just
are
standard,
get
printed
to
standard
out,
not
as
a
log
message,
which
is
another
thing
I
wanted
to
address
in
my
other
rfc
kind
of
okay.
A
Okay,
great
yeah,
I
I
just
also
made
the
quip
that
it
doesn't
help
that
we
alias
all
the
log
levels
to
like
d
d
d,
so
it
seems
like
it's
like
you
know:
you're
expanding
the
scope
versus
having
more
granular
flags
for
like
include
exclude
kind
of
like
what
I
was
saying
before,
like
to
be
able
to
include
this
type
of
warning.
A
Actually,
this
type
of
more
more
confined
like
granular
control
over
logs,
so
yeah,
you
might
be
right,
it's
just
potentially
just
a
a
bug
that
we
can
fix,
or
it
might
be
like
some
actual
refactoring
work.
We
could
have
to
do
to
like
get
this.
Okay.
Did
you
want
to
go
roy
speak
a
little
bit
to
the
deprecation
deprecation
ux.
D
Sure
yeah,
so
let
me
just
basically
introduce
it
again.
We
did
we
did
this
last
week,
but
I
know
jordan's
here
today
we
have
some
other
folks
that
are
not
so.
Basically
it
is
about
cleaning
up
the
output
during
npm
install.
It
is
basically
the
natural
evolution.
D
We've
been
cleaning
the
the
output
since
v7
we
took
away
the
all
the
lifecycle,
scripts
output
from
the
from
install
and
basically
we're
trying
to
converge
into
the
notification,
this
kind
of
notification
system
we
have
at
the
end
so
we'll
let
you
know
about
how
much
vulnerabilities
there
might
be
in
your
install
tree.
We
will
let
you
know
about
the
package
that
are
looking
for
funding,
so
we
might
as
well.
Just
let
you
know.
Oh
there
are
some
deprecation
and
the
currently
installed
free.
D
So
please
take
a
look
at
it,
so
this
rfc
is
basically
proposing
the
that
new
ux.
So
one
take
away
from
the
last
meeting
that
we
want
to
do
here
is
to
clean
up
and
make
sure
this
session.
There's
a
session
here
about
the
improving
the
current
some
other
existing
methods
like
ls,
and
I
think
I'll
take
that.
D
Basically,
let's,
let's
take
that
part
away
from
this
rfc,
let's
focus
only
on
the
npm
install
side
of
the
store
here,
so
it
will
be
just
stop
logging
directly
to
to
standard
output
during
the
install
with
all
these
warning
messages
and
present
a
notification
system
at
the
end,
letting
you
know
there
are
these
many
packets
that
are
deprecated
and
needs
your
attention,
and
then
we
need
to
provide
a
top
level
command
or
some
other
type
of
command
to
basically
print
the
list
of
deprecated
packages.
D
A
I
mean
I'm
a
plus
one
on
the
you
know,
consolidating
the
output
a
lot
of
folks
consider
it
scary.
I
think
that's
what
we
referenced
last
week,
a
lot
of
newcomers,
the
first
time
running,
install
seeing
deprecated
errors
can
be
scary,
especially
if
they
can't
do
anything
about
them,
so
at
least
even
consolidating
them
into
a
single
line
just
for
awareness,
I
think
a
key
with
like
how
we've
consolidated
the
logs
or
sorry
that
output
today
and
in
v7
for
a
lot
of
those
other
kind
of
audit,
outputs,
etc.
A
Like
like
packages
changed,
is
for
awareness
and
then
like
having
a
separate
top
level
command.
I
think
makes
sense.
We
talked
about
that
last
week
in
terms
of
we
have
a
top
level
cam
command
for
depth
to
deprecate,
so
it
seems
kind
of
like
okay.
Why
not
have
a
top
level
command
to
show
like
the
list
of
deprecated
packages
that
are
found?
A
Ideally,
it
would
be
great
if
we
had
a
consolidated
view
of
all
those
all
this
kind
of
metadata
and
information
about
your
packages
and
consolidated
single
consolidated
view,
but
there
was
no
like
immediate
place
that
I
think
made
sense,
because
we
sort
of
take
that
approach
to
filtering
right
now,
with
outdated
and
with
you
know
like
ls
is
specifically
extraneous
or
deduped.
So,
like
you
know,
those
are
sort
of
the
states
in
which
we've
bucketed
these
commands.
So
I
think
I
think
this
approach
makes
sense.
H
Go
ahead,
reese
if
you're,
not
yeah,
thanks,
sorry
yeah!
I!
This
is
partly
like
related
to
jordan's
comments
on
this
one
as
well.
Like
I
had
a
little
bit
of
hesitation
on
the
idea
of
having
it
automatically
at
the
end
of
install.
It
could
be
nice
to
make
this
an
opt-in
command.
Initially,
if
that's
not
too
much
hassle.
Things
which
can
be
good
for,
like
90
of
people,
can
still
have
massive
unintended
consequences.
H
You've,
probably
seen
with
like
npm
audit,
actually
don't
even
order.
I
mean
when
you
run
install,
and
it
says
you
know,
you've
got
the
vulnerable
packages.
It
can
sometimes
lead
to
like
kind
of
like
an
online.
You
know
almost
like
harassment
of
people
in
the
open
source
ecosystem,
which
I
think
is
what
jordan's
worried
about.
H
So
I
mean
so
and
if
you
remember
the
there's,
a
blog
post
fairly
recently
like
half
year,
at
least
by
dan
from
react,
you
know
kind
of
like
saying
this
all
sucks
and
it's
basically
because,
like
people
run
npm
and
stall,
they
get
told
they've
got
vulnerabilities,
they
figure
out
where
they
came
from
and
then
they
go
and
harass
the
package
that
they
came
from
he's
like
none
of
these
are
relevant
kind
of
thing.
H
So
if
you
then
end
up
with
the
same
crowd
behavior
due
to
like
deprecated
packages,
whereas,
like
jordan
says
like
this,
is
you
know
that's
my
responsibility?
Yeah!
I
just
it's
just
like
a
potential
unintended
consequence
where
you
end
up
with
the
the
crowds
with
pitchforks.
Again,
you
know
chasing
open
source
maintainers
to
like
replace
that
deprecated
package
and
things
like
that.
B
Yeah,
so,
okay,
so
I
have
some
responses
and
a
concrete
proposal.
So
the
response
is,
I
probably
already
stated
some
of
these
things,
but
I'm
gonna
restate
them.
Somebody
should
never
simply
should
never
see
deprecation
warnings
for
transitive
dependencies.
It's
neither
business
a
security
warning,
it's
their
business.
That's
some
in
some
way.
Right,
like
you,
want
to
know
if
a
transit
dependency
has
a
security
issue
that
could
affect
you.
B
If,
knowing
that
someone
10
levels,
deep
typed
npm
deprecate,
regardless
of
what
they
type
in
that
message,
doesn't
matter
it's
not
in
your
business.
That
is
the
business
of
the
person
who
depended
on
that
package.
The
package
you
depended
on
it
so
like.
If
somebody
wants
that
information-
okay,
great,
it's
fine,
if
they
can
find
it,
but
it
shouldn't
ever
be
shown
by
default,
because
it's
never
actionable
and
it's
just
not
relevant.
It's
not
useful
requests
maintainer
and
chose
to
deprecate
it.
B
For
example,
that's
fine
they're
entitled
to
do
that,
but
something
that
is
indirectly
depending
on
request.
Who
cares
if
the
thing
they
depend
on
cares?
That
thing
will
depend
on
something
else
and
if
it
doesn't,
who
cares
right?
Like
it
still
works,
when
you
trust
a
package,
you
are
trusting
that
package
to
delegate
responsibility
to
its
own
dependencies
and
it
should
be
none
of
your
business,
which
ones
those
are
except.
B
You
know,
modulo
security
issues,
okay,
so
my
concrete
proposal
all
take
every
different
case
in
a
deprecation
message
that
would
normally
print
during
install
collapse
them
all
to
a
single
line
that
says
x,
runtime
dependencies
and
y
dev
dependencies
have
deprecation
warnings,
run
this
command
to
see
them.
B
You
run
it
with
a
package
specifier
argument,
and
it
does
what
my
deprecations
package
does
and
it
lists
the
deprecation
messages
by
version
on
that
package.
If
you
run
it
without
a
package
specifier,
it
just
runs
on
your
tree
and
you
can
just
like
every
other
npm
command.
You
could
do
dash
dash,
dev
or
dash
dash,
prod
and
filter
down,
but
it
just
and
but
by
default
it
would
have
a
depth
of
zero
and
not
the
depth
command,
because
that
is
problematic
for
reasons.
B
But
by
default
it
would
only
show
directs,
and
then
you
can
add
an
additional
option
if
you
want
to
be
shown
the
full
tree
and
see
all
the
transitive
deprecation
warnings,
but
that
yeah
just
kind
of
yeah
I
like
use
because
mpmls,
I
think
it
made
me
last-
shows
the
whole
tree
by
default,
but
it
doesn't
anymore,
no
okay.
Well,
then
great,
just
like
that,
even
better
precedent
and
and
then
the
the
the
result
would
then
be
there.
B
Somebody
if
there
are
deprecation
warnings
that
some
they're
actionable
somebody
sees
a
notice,
hey
check
out
check
this
out,
just
like
they
see
a
one-line
message
about,
run
npm
fund
or
run
npm
audit
great.
That
meant
that
that
separate
command
lets
them
be
as
verbose
or
filtered
as
they
want,
and
the
default
behavior
of
that
command
is
also
the
actionable
thing,
which
is
show
me
deprecation
messages
of
the
direct
dependencies
that
I
have
runtime
and
dev.
A
I'm
done
so.
I
appreciate
that
and
hopefully
we're
capturing
everything
you
said
I
see
you're
saying
still
up.
Did
you
have
a
comment?
You
want
to
sorry?
Sorry,
no,
I
just
forgot
to
take
it
down,
although
the
next
item's
also
is
one
for
me,
sure
sure
and
we'll
we'll
try
to
cap
this
for
another
couple
minutes
like
one
or
two
more
minutes
so
that
we
can
get
to
one
or
two
more
roy.
I
said
your
hands
up.
D
Yeah,
I
was
basically
answering
to
jordan
here.
One
thing
I
think
we
me
and
you
the
rc
we
went
over
the
last
time.
I
think
it
is
the
idea
of
maybe
npm
the
application,
this
top
level
command
it
just
prints
by
default,
just
for
your
top
level
dependencies
and
you
use
all.
I
think
this
is
what
darcy
was
saying
like
in
mls
behaves
like
that
since
v7.
So
if
you
want
to
see
all
your
dependency
trees,
you
need
to
use
them
camera
ls
dash
all
so
it
will
behave
the
same
like
in
case.
D
D
I
don't
know
if
it
would
cause
more
problems
than
what
is
there
already
today
right,
like
with
all
this
warning
message
being
printed
directly
to
during
the
npm
install,
like
you
could
say,
there's
enormous
potentials
for
for
for
action
for
reaction
from
the
community
too.
By
seeing
those
alerts
there.
H
So
on
deprecation,
there's
just
one:
it's
a
little
bit
too
easy,
also
to
accidentally
deprecate.
I
think
some
maintainers
don't
understand
that
if
they
deprecate
the
latest
version,
then
the
mpmjs.com
shows
the
whole
package
as
deprecated,
and
so
they
also
can
be
ones
where
they
didn't
intend
it
to
be
deprecated.
H
D
H
I've
seen
people
they
put
out
a
bad
release
and
then
people
telling
them
your
release
is
bad
and
they
kind
of
panic
and
they
like
deprecate
the
last
release
they
did
and
it
actually
ends
up
like
they're
marking
the
whole
package
as
as
deprecated.
That's
just
the
kind
of
the
way
it
works
right.
A
We
have
a
backlog
to
do
to
actually
warn
before
doing
a
deprecate
identification
which
you
would
be
removing
all
versions
from
or
deprecating
all
versions.
So
I
think
there
somebody's
flagged
that
to
us
before
for
sure
that
that's
a
common
common
mistake
that
happens.
There's
also,
I
think,
some
policies
that
we've
changed
internally
about
unpublishing
because
of
the
somebody
accidentally
publishing
the
first
version,
deprecating
it
or
unpublishing
it
and
then
being
in
sort
of
like
this
window
of
they
can't
publish
a
new
version
type
thing.
A
A
We
should
do
this
incrementally,
because
I
think
it's
easier
for
us
to
ship
in
a
minor
the
improvement
to
consolidate
the
the
logs
today
and
show
that
nice
consolidated
messaging
and
provide
actually
a
flag
for
no
deprecation
similar
to
no
audit
no
fund,
so
that
you
can
actually
configure
and
opt
yourself
into
that
completely
clean
state.
And
then
we
can
have
that
discussion
about
whether
or
not
we
want
that
to
be
the
default
switch
that
flip
that
bit
for
v9.
A
If
we
want
to
do
that
because
I
don't
think
that
it
would
be
good
to
go
all
the
way
and
we
can't
within,
I
would
say
this,
this
major
release
line
to
remove
these
warnings.
I.
B
Think
by
default
like
well,
if
you're
saying
we
can
consolidate
them
and
put
them
in
the
other
command
and
change
the
default
output
of
that
command
to
not
include
all.
If
that
seems
like
something
that
we
can
do
in
sember
minor,
which
it
does
to
me
because
programmatically
you
can't
rely
on
those
things,
then
I
don't
actually
think
there's
any
point
in
ever
changing
the
default
to
hide
deprecation.
The
deprecation
summary
on
install,
because
at
that
point
it's
one
line.
A
Yeah
yeah,
so
I
think
we
have
that
document
that
way,
so
I
feel
it
feels
good
like
there's
enough
information
for
you
to
go
off
and
find
out
more.
I
think
it's
it's
good
to
keep
it
there,
notably
deprecations,
can
actually
be
resolvable
by
end
users.
Consumers
using
overrides
now
recently
shipped
right,
like
you,
can
actually
with
this
information,
so
so
to
go
back
to
one
of
the
points
that
you
made
jordan
about.
This
is
not
your
problem.
A
B
B
It
would
be
harmful
to
continue
to
show
transitive,
deprecation
warnings
and
also
widely
more
widely
communicate
that
people
can
use
overrides
for
this,
because
then
they
will
be
more
inclined
to
do
something
that
is
unlikely
to
be
correct,
whereas
if
we
hide
them
by
default,
then
that
capability
is
a
wonderfully
powerful
thing
and
is
great.
But
you
know
it's
not
a
foot
gun.
A
B
B
Of
those
unwanted
pull
requests
that
that's
not
that's
not
actually
great
behavior,
usually
there's
usually
a
reason.
Something
is
using
a
deprecated
like
still
using
a
deprecated
package
and
that
reason
is
usually
not
affected
by
the
reason
for
the
deprecation.
B
Yeah,
I'm
sure
there's
all
over
the
place,
but
an
unmaintained
package
that
already
works
perfectly
is
fine.
There's
no
reason
to
change
that,
and
if
the
maintainer
of
that
of
the
package
using
it
isn't
concerned
about
it,
then
nobody
else
has
the
credibility
to
for
has
more
credibility
than
the
maintainer.
For
that
opinion,
yeah.
A
I
apologize
we're
almost
basically
that
time.
I
know
there
was
one
more
race.
You
said,
there's
one
that
you
want
to
get
to
yeah
number.
H
Four
on
the
agenda:
the
refi
lifecycle
hook.
A
H
There's
a
few
goals
here,
but
the
primary
goal
is
to
give
the
ability
for
people
to
have
some
form
of
external
gatekeeping
to
block
an
unsafe,
install,
so
malicious
packages,
in
our
case
is,
is
the
primary
use
case,
although
I
think
this
would
also
add
a
useful
option
in
future
for
like
more
mature
use
where,
like
enterprises
want
to
be
able
to
have
policies.
H
To
kind
of
you
know,
so-called
shift
left
and
just
like
stop
someone
installing
a
package
which
has
been
put
on
a
you
know,
deny
list
or
something
like
that.
But
essentially
our
goal
was
to
be
able
to
preempt
an
npm
install,
an
npm
update
or
any
other
command
where
dependencies
would
be
downloaded,
and
you
know
scripts
could
potentially
be
executed.
H
So
that
was
and
we've
we.
We
found
that
inserting
that
as
a
refi
hook
worked
for
our
purposes
perfectly.
A
So
I
think
this
is
sort
of-
and
I
think
I
gave
some
internal
comments
about
this-
you
you're
at
white
source-
is
that
right,
yeah
yeah
yeah.
So
I
think
this
is
something
we
have
to
be
we're
pretty
careful
about,
because
we're
concerned
about.
A
You
know
one
changes
in
the
api
going
forward
because
we're
trying
to
essentially
parse
out
the
context
in
which
lifecycle
scripts
are
being
used
today,
whether
you're,
the
consumer
or
the
one
being
consumed,
is
sort
of
the
typical
two
contexts
we
see
and
and
then,
when
these
fire
off
and
and
what
the
api
looks
like
that
people
are.
C
A
Is
all
consolidating
to
one
place
right
now,
which
is
not
great?
Everybody
uses
scripts
and
pre
and
posts
and
small.
C
A
Etc,
so
we're
definitely
concerned
about
like
adding
this,
especially,
I
think
you
know
having
a
a
safe
window
in
which
npm
can
essentially
operate
and
build
the
ideal
tree
and
then
also
go
and
reify
without
there
being
any
kind
of
action
happening
by
the
packages
that
are
being
installed.
A
H
H
We
make
it
simpler
by
this
hook.
You
know,
essentially,
is
like
immutable
and
that
it's
not
allowed
to
change
the
result,
because
really
all
we're
after
is
just
the
ability
to
like
you,
know,
pull
the
rip
cord
when
something
is
bad.
H
You
know
like
and
and
for
example,
the
motivation
for
this,
so
we
we've
been
detecting
and
reporting
about
100
malicious
packages
a
week,
and
it
sometimes
takes
up
to
three
days
from
us
reporting
them
for
them
to
be
removed
from
their
registry
and
like
we
just
have
no
way
that
we
know
they're
bad
and
we
can't
protect
anybody
from
them.
Until
you
know
someone
logs
in
on
monday
morning,
you
know
and
like
goes
through
the
the
backlog.
A
Is
the
way
that
the
tool
works,
and
I
I
apologize-
I
don't
have
the
context
here
so
is:
do
you
have
the
ability
to
and
I'm
going
to
go
back
to
overheads
to
create
essentially
a
blacklist
or
sort
of
like
a
essentially
a
bad
list
of
packages
that
you
know
about
to
to
then
be
used
and
keep
that
up
to
date
to
to
essentially.
H
H
Yes,
although
we
also
let
people
have
control
where
they
could
say,
don't
allow
something
to
be
installed.
That
is
so
new.
It
hasn't
even
been
scanned
yet
so
it's
not
necessarily
like
you
know
a
deny
list.
It's
also
like
a
pending
list
in,
in
some
cases
where
you
know,
someone
was
to
sort
of
run
like
npm
update
just
at
a
very
unlucky
time,
so
yeah,
it's
essentially
like
there
is
a
in
our
past.
We
we
submit
just
a
set
of
fingerprints.
H
You
know
representing
like
a
hash
of
all
the
package
versions
and
if
any
of
them
have
a
hit
or
an
arrow,
now
you
know
or
unknown
to
us.
We,
depending
on
the
policy
that
was
set.
We
can
then
stop
the
install
from
going
so
one
of
the.
So
I
wanted
just
just
some
more
context
like
so
like
this.
This
is
something
that
is
possible
and
implemented
in
like
young
one,
young,
2
and
pnpm.
H
Also
we
pioneered
it
in
bundler.
So
it's
not
like
complete,
like
science
fiction.
You
know
we're
asking
for
something.
That's
like.
Can
this
be
done
in
theory
like
like
practically
speaking
just
this
concept
of
before
things
are
downloaded?
We,
you
know,
send
that
kind
of
list
off
somewhere
external
and
then
block
the
install
if
it
doesn't
like
it.
It's
it's
like,
in
my
opinion,
a
proven
concept.
A
Yeah
and
I
see
rose
hands
up
here.
What
I'll
say
is
like
I
have
seen
other
tools
come
out
like
mpq
that
essentially
wrap
install
npm
to
to
block
on
and
provide
some
sort
of
like
extra
policies.
H
Around
you
know,
the
her
goal
is
not
to
wrap
the
fork,
though,
really
would
like
that
you
know
someone
opts
in
obviously
they've
got
like.
I
think
they've
got
to
install
it.
You
know
in
their
project,
but
when
they
do
that,
the
other
other
you
know,
participants
in
the
project,
don't
have
to
have
a
custom
manager
or
run
a
custom
script
like
npm,
safe,
install
or
anything
like
that,
like
because
people
just
forget.
D
A
C
D
At
the
end
of
oh,
it's
only
at
the
end,
it's
not
did
my
parts
of
the
treatment
of
the
mutation
of
the
tree.
I
thought
that
it
was
going
to
encompass
you
know
before
the
right
before,
but
you
already
know
what
is
the
actual
tree,
the
virtual
one,
then
maybe
one
once
you
got
the
ideal
tree
ready
and
then.
E
A
Right
so
the
problem
there
is
that
we're
gonna
have
to
read
from
potentially
you're
like
building
up
the
the
tree.
You're
gonna
have
to
you're.
Gonna
have
to
have
installed,
and
this
is
the
problem
with
the
post,
install
script
or
pre-installed
script.
What's
what's
a
pre-install
script,
when
does
it
run
right?
Because
you
have
to
download
the
thing
to
actually
figure
out,
you
know
what
you're
going
to
install
and
that's
why.
D
D
You
do
have
a
life
cycle
script
that
gets
triggered
right
before
refi
right,
like
you
already
have
all
the
trees
together,
you
can.
You
can
do
this
kind
of
logic
and
see
if
there
is
a
bad
package
in
it,
and
you
want
to
prevent
the
install,
then
you
can
just
throw
and
it
should
just
break
everything
right,
prevent
the
the
cold
from
continuing.
H
Kind
of,
like
a
you
know,
a
get
you
know
you
know
when
people
are
using
get
kind
of
hooks
more
aggressively.
Now,
just
to
you
know,
stop
a
push.
You
know
if
it
doesn't
meet
certain
criteria
locally.
We
just
want
that
kind
of
ability.
A
Do
you
have
like
like
this
is
the
concern
that
we
have
with
these
hooks
and
how
they're
being
used
historically,
how
they
can
be
used
like
to
keep
us
in
the
cycle
of
mutation
during
installation,
which
is
not
like
the
complete
opposite
of
what
we're
trying
to
push
towards,
and
I
totally
understand
that
yarn
and
pmpm
have
the
ability
for
a
very
advanced
hook
system
right,
like
I
know
that,
there's
prior
art
in
this
space,
like
it's,
you
know
the
pushback
is
really
where
we
want
to
go
in.
A
H
H
Then
that,
like
maybe
solves
a
lot
of
your
concerns,
if
it's
like
really
intentionally
meant
to
be
a
policy
thing
like
yes,
you
know.
Yes,
I
mean
we
made
it
generic
to
make
it
simpler.
But
if,
instead
of
a
generic
book,
it's
more
of
a
policy
check
about
the
ones
and
then
then
you
don't
have
to
worry
about
it,
mutating
anything
yeah.
So.
A
C
A
A
Yeah
yeah,
so
I
apologize
we,
I
know
we're
about
10
minutes
over.
I
would
love
to
keep
this
keep
talking
about
this
and
then
keep
it
open
for
now,
if
you're,
okay,
with
keeping
on
for
another
week
and
we'll
try
to
give
it
more
time
next
week,
yeah
sure,
thanks
for
combinating
it
late
today,
awesome
I
apologize.
A
If
we
didn't
get
to
one
of
your
rfcs
today
or
or
I
know
we
had
a
stacked
stacked
agenda,
there's
actually
gonna
be
probably
another
rfc
coming
down
the
pipeline
from
our
team,
which
we're
pretty
excited
about
for
next
week.
So
I'll
try
to
give
folks
lots
of
time
and
lots
of
warning
beforehand,
but
yeah.
Thank
you
for
jumping
on
today
apologize
for
the
glitch
early,
but
I
will
see
you
folks
next
week.
Hopefully
cheers
I.