►
From YouTube: 2020-04-08-Node.js Technical Steering Committee 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).
A
Okay,
welcome
to
the
node.js
technical
steering
committee
meeting
for
april,
8th
2021.
we'll
follow
the
agenda
that
was
in
the
issue
within
the
tse
repo
before
we
get
to.
That,
though,
does
anybody
have
any
announcements
that
they'd
like
to
share.
A
Yeah,
sorry,
okay,
yeah,
okay,
yes,
security
notes,
they
went
out
the
details,
there's
both
on
the
website,
there's
a
link
to
for
the
details,
and
it
went
also
went
out
to
the
node.js
mailing
list
in
case
you
want
to
make
sure
you
get
an
email
when
that
happens,
that's
a
good
one,
any
other
announcements
that
people
have.
C
Probably
that
there's
not
long
to
go
until
no
just
16
comes
out
and
the
proposals
open
the
last
release
candidate
expected
to
be
next
week.
There
have
been
a
few
majors
that
were
pulled
in
after
technically
after
the
cutoff,
and
so
I've
linked
those
seven
etsc
members
have
any
objections
to
those
please
make
them
known
and
open
reverse.
A
And
that's
probably
also
a
good
reminder
to
everybody
that
if
you're
still
using
node.js
10,
it's
going
to
go
end
of
life
end
of
april
as
well,
so
be
good
to.
If
you
haven't
already
it's
a
better
better
start.
Looking
at
how
you
move
off
onto
one
of
the
the
newer
lts's,
any
other
announcements,
people
have
to
share.
D
C
Yeah,
I'm
fairly
sure
it's
april
node
15,
I
think
we'll
go
end
of
life
in
june.
A
Okay,
so
if
that's
our
announcements,
we'll
move
on
to
cpc
and
board
meeting
updates,
I
don't
have
anything
top
of
mind
from
the
cpc
or
the
board
so
and
we
don't
have
mary
or
our
cpc
rep.
So
maybe
we'll
move
on
to
the
issues
so
go
ahead.
B
Is
going
to
mention
we
had?
We
do
have
in
the
tsc
repo
pull
request
with
charter
changes.
B
So
if
people
haven't
looked
at
that,
it
might
be
a
good
idea
to
take
a
quick
look
at
it
because
they
might
matter
to
you
but
and
that
that
that
can't
land
until
the
cpc
approves
it
yep.
A
Yep
good
point-
and
I
guess
it's
also-
I
don't
know
if
we
mentioned
in
a
meeting
before,
but
it's
good,
but
to
mention
that
mary
was
reelected
as
the
tse's
cpc
rep.
So
thanks
to
her
for
doing
that
for
another
year.
A
A
E
F
Yes,
yes,
yeah.
I
think
the
tobias
has
mapped
the
topic
completely
extremely
well.
So
the
last
comment
of
tobias
is
exactly
represent
exactly
my
sentence,
my
my
thinking
here
so
which
it's
like
I
put
as
I
put
a
minus
r
minus
one,
because
it's
using
callbacks
and
async
await
together,
it's
a
serious
site
for
blowing
things
up.
So
if
we
mark
those
as
legacy,
we
will
be
essentially
encouraging
people
of
mixing
them
up
and
that
it's
not
something
that
I
think
we
should
be
doing.
A
G
I
don't
I
just
have
a
quick
comment
on
this.
I
haven't
been
that
deep
in
that
issue,
but
but
one
problem
with
the
callback
api
as
it
is
today,
is
it's
fundamentally
unsafe.
G
G
A
That's
my
gut
feel
too
is
like
I
think,
to
matteo's
point
and,
and
tobias
is
one
there,
it's
it's
like
we're,
not
quite
ready
to.
You
know
if
we
said
all
the
fs,
all
the
callbacks
were
legacy
that
would
potentially
make
sense,
but
the
mixing
and
having
it
only
sort
of
being
halfway
there.
I'm
not
sure
personally
that
we're
ready.
A
I
guess
the
question
is
on
on
the
next
steps
here.
Like
do,
we
think
we're
working
towards
a
you
know
an
agreement
or
resolution
in
the
issue
itself.
A
Feedback,
do
we
want
to,
I
mean,
like
we
can
ask
more
of
the
tc
members
to
chime
into
the
issue.
We
could
you
know,
I
guess
we
don't
have.
B
Go
ahead
it
it,
it
seems.
Like
I
mean
it
seems,
like
the
I
mean
so
so,
okay,
so
so
there's
a
foot
gun
that
robert
brought
up
there's
a
foot
gun
in
the
in
the
api.
That's
that
in
the
callback
based
api.
Putting
that
aside
for
just
a
moment,
it
seems
like
there's
consensus
that
that
that
or
or
maybe
consensus,
isn't
the
right
word,
but
it
seems.
B
There
is
there
there
are.
There
is
a
reasonable
opinion
that
that
you
know
we,
we
shouldn't
mark
this
as
legacy
yet
because
we
don't
have
everything
in
place
so
that
people
can
just
use
promises
and
not
mix
it
with
call
backs,
and
so
on
so
forth.
My
understanding
am,
I
understanding
the
the
position
correctly.
If
so,
then
it
seems
like
we,
we
don't
need
more
discussion.
B
You
know
just
switch
to
promises
and
not
have
callbacks
mixed
in
somewhere,
and
this
is
this
is
where.
F
This
is
where
the
problem
lies
rich,
so
I
I
don't
see
a
good
timeline,
so
the
hard
problem
is
that
we
have
a
lot
of
like
we
have
certain
subsystems
in
node
that
are
really
call
back
heavy
and
mainly
because
they're
really
like
and
entrenched
into
an
old
way
of
structuring
code,
and
it's
not
super
easy
to
disentrench
them
from
those
apis.
F
So
that
is
the
main.
That
is
the
main
problem
and
it's
what
believes
me
a
little
bit.
That
leaves
me
wondering
when
this
will
happen.
Okay,
so
the
ma
the
major
the
major
ones
are
that
are
missing,
are
all
the
networking
parts
so
and
it's
not.
F
That
is
a
small
amount
of
work
to
ship
those
so
and
not
that,
by
the
way
we
are
working
on
it
in
the
sense
of
for
the
wall
of
hedp,
we
are
doing
undies
for
various
reasons,
including
supporting
promises
so
and
that
those
are
way
I
will
be
super
that
will
be
supported
out
of
the
box.
So
but
it's
still
like
it's
still
it's
work.
That
needs
to
happen
over
time.
F
Okay
and
then
there
is
the
whole
thing
around
node
streams
which
are
entrenched
even
in
c
plus
and
and
the
question
of
what
we
do
with
them,
especially
on
net
tls
on
net
and
tls.
So
those
are
the
key
questions.
I
know
james
is
working
as
plans,
but
I
don't
know
where
that,
where
those
are
so
yeah,
that's
you
know,
essentially
that's
the
james.
Now
sorry,
I
didn't
mention
the
surname.
So
that's,
that's.
I
don't
know
that's
the
situation,
so
I
just
wanted
to
point
out
it's
it's
fine
in
the
future.
B
So
I
mean
it's
I
mean
unless,
unless
we're
prepared,
I
mean
I
don't
know
that
we
need
a
path
forward
to
marking
something
as
legacy
I
mean.
Maybe
it's
just
like
it's
not
time
right
now
and
that's
okay.
We
don't
have
to
like
resolve
this.
We
don't
go
vote
on
it
or
anything,
it's
just
it's
it's
just
not
time
and
sorry.
It
would
be
nice
if
we
could
and
then
and
then
we
we,
you
know
we
could
think
about
what
we
want
to
do
about
the
the
undefined.
F
That's
rich:
we
discussed
that
it's
part
of
the
reason
to
you
that
the
fs
apis
were
done
towards
one.
The
first
down
was
what
jerry
said.
So
it's
it's
essentially
unsafe
and
it's
true.
B
Right
and
so,
and
so
I
mean
you
know,
conceivably,
you
know
yeah,
and
so
so
I
mean,
but
we
you
know
and
either
there's
you
know,
maybe
there's
something
we
can
do
about
it,
or
maybe
there
isn't
anything
that
can
be
done
about
it,
a
breaking
change
or
something
if
they're,
but
even
if
there
isn't
something
to
be
done
done
about
it.
A
B
Let's,
let's
leave
it
on:
let's
leave
it
on
the
agenda
on
you
know,
unfortunately,
or
you
know
me-
I
mean,
maybe
if
you
want
a
path
forward,
maybe
the
thing
to
do
is
for
somebody
to
reach
out
in
email
or
other
or
other
back
channel.
You
know,
because
I
I
don't
know
it
would
be.
It
would
be
nice
to
be
able
to
get
resolution
on
this.
B
That's
not
in
a
meeting
because
you
know
we're
having
trouble
getting
critical
mass
attending
the
meetings
right
now
and
and
yeah
and
and
if
we're
at
an
impasse
in
the
in
the
issue
tracker.
Maybe
we
need
to
go
about
it
some
other
way,
but
someone
has
to
champion
that
so.
F
It's
a
it's
a
reason
for
exam.
The
reason
for
legacy
is
the
typical
example
is
the
url
parser,
so
the
the
old
url
parser
it's
a
really
problematic
for
in
all
sorts
of
ways.
It's
a
security
footgan
at
it
best.
It
had
multiple
security
vulnerabilities
in
the
past
and
something
that
probably
should
not
be
like.
I
will
not
trust
it
to
be
spec
compliant
in
term
of
our
uri
is
a
url
is,
is
structured
so,
and
that
was
the
reason
it
we
can't
remove
it,
but
if
we
could
we
would,
but
we.
G
Can't,
but
in
this
case,
is
there
anyone
that
disagrees
that
we
would
like
users
to
use
the
promise
based
apis
when
possible.
B
For
the
for
the
benefit
of
people
watching
on
the
stream
there's
some
chatter
in
the
chat,
nikita
and
tobias
have
both
suggested
that
we
can
emphasize
the
promise
apis
in
the
docs
that
we've
done
that
in
the
past.
We
might
also
want
to
consider
if
it's
possible,
I
don't
know,
if
it's
possible,
but
emitting
a
warning
not
not
on
the
use
of
a
callback
and
not
on
closing
a
file
descriptor.
B
G
B
If
we
still
had
an
ecosystem
group
of
some
kind,
they
could
you
know
like
we
could
work
with
them
to
get
like
pull,
and
maybe
we
don't
need
an
ecosystem
group
to
do
this,
but
get
you
know
poorly
placed
into
popular
packages
or
something
not
necessarily
like
packages
that
get
a
lot
of
use,
but
packages
that
are
used
to
for
instruction
or
that
people
pull
examples
from.
I
don't
know
I'm
trying
to
think
of
something
here,
but.
B
And
tobias
is
saying
in
the
chat
that
ecosystem
adoption
of
promises
and
third-party
packages
is
important.
Many
packages
still
don't
support,
promises
themselves
and
mixing
them
with
promises
is
troublesome,
and
I'm
going
to
just
take
this
moment
when
I'm
not
going
to
take
this
moment,
that's
I'm
just
going
to
copy
and
paste
that
in
okay.
A
Okay,
so
I
think
we
should
try
and
move
on
to
other
issues
in
the
agenda.
I
guess
on
this
one:
we've
identified
a
few
possible
alternatives
as
well
as
if
we
could
find
a
volunteer
to
sort
of
champion.
The
discussion
to
like
you
know
bring
it
to
like
rich,
was
suggesting
taking
it
offline
through
email
or
whatever,
to
see
if
we
can
get
consensus
across
the
the
tse,
otherwise
we'll
leave
it
on
the
agenda
till
next
week
is
the
the
last.
B
Thing
and
if
and
if
it's,
if
it's,
if
it's,
if
this
is
a
you
know
a
super
important
issue,
and
perhaps
it
is,
you
know
this,
it
might
warrant
creating
a
small
working
group
of
motivated
people
to
you
know
frequently
talk
about
this
and
figure.
It
out
sounds
like
no
fun
to
me,
but
yeah.
A
Yep,
okay,
so
we'll
leave
it
on
the
agenda.
If
somebody
has
time
to
volunteer
to
to
to
try-
and
you
know-
push
it
forward
before
the
next
meeting
by
reaching
out
to
individuals,
we
can
do
that.
Otherwise,
hopefully
we'll
have
a
different
mix,
and
you
know
eventually
we'll
cover
off
everybody.
So
we'll
move
on
to
the
next
issue,
which
is
http
significant
performance
regression
on
master.
A
I
noticed
materials
mostly
resolved.
F
So,
probably
nothing
to
be
done
right
now
here,
okay,
I
just
wanted
to
call
in
if
you
see
that
there
is
code
that
might
potentially
affect
the
performance
of
http
event,
emitter
streams,
debug
log
and
some
other
really
small,
like
really
internal
part
of
node
core,
to
make
sure
to
run
the
benchmarks
before
we
actually
call
it
today
before
before
landing,
because
those
regret
we
it
could,
it
would
have
been
possible
to
spot
most
of
those
regressions.
A
Yeah,
I
think
we've
had
a
long
discussion
on
benchmarks
and
even
like
trying
to
run
these
kind
of
ones
more
regularly,
and
they
just
take
so
long
that
it's,
I
think,
we're
kind
of
left
to.
Unless
somebody
and
we
decharted
the
benchmarking
team,
it's
left
as
like
people
need
to
run
the
ones
they
think
will
affect
the
code.
That's
changing
versus
being
able
to
run
them
all
and
run
them
on
a
regular
basis.
B
A
J
G
There
is
one
possible
alternative
that
the
release
with
kinks,
for
example,
node.js
strings
and
node.js
http,
and
then
one
of
the
members
I'm
a
member
of
both
of
those-
could
run
the
benchmarks
and
just
give
a
heads
up
or
just
so
we
don't
forget
or
get
into
this
kind
of,
because
now
we
were
lucky
that
matteo
was
doing
the
benchmarks.
But
that
was
luck.
I
guess.
J
When
it
comes
to
these
regressions,
I've
seen
multiple
cases
where
it
was
actually
about
primordials
and
being
used,
and
this
is
something
I
would
like
to
discuss
in
general
a
little
bit
more
again,
because
these
are
really
difficult
to
spot.
Otherwise,
because
it's
just
like
non,
not
really
obvious
that
we
have
a
performance
decrease
when
just
switching
the
code
to
premium
audios.
F
I
am
in
total
agreement
with
you
reuben.
The
key
problem
here
is
that
people
with
knowledge
of
those
subsystems
are
not
being
tugged
into
the
primordial
pr,
so
it's
that
is
more
or
less
that's
a
reason.
I'm
just
like
I'm
putting
the
reason
on
that.
Okay,
I
asked
to
be
added,
and
people
were
not
doing
it
anyway,
so
yeah.
J
But
it's
not
only
about
dreams,
you
know
it's
like
lots
of
areas
in
our
code
base
is
performance
sensitive,
even
if
you
just
have
a
look
at
something
like
util
with
util.
A
J
F
A
J
J
A
A
A
Because
if
we've
seen
multiple
repeated
instances
of
this
causing
problems,
it
seems
like
you
know,
it's
it's
a
good
thing
to
discuss,
and
maybe
we
should
have
like
a
higher
borrower
for
anything
that
does
that
right,
like
in
terms
of
running
the
running
the
the
the
benchmarks
or
more
tsc
approvals
to
make
sure
that
we
we
do
have
people
looking
to
see
if
the
right
teams
have
been
mentioned.
If
that's
not
happening,
but
that's
probably.
B
Not
another
thing
to
consider
is
that
primordials
have
kind.
You
know
started
off
as
this
thing
that,
like
only
people
who
knew
how
you
know
the
very
very
internal
stuff
was
working,
they
would
be
implementing,
and
so
they
would
know
to
check
for
performance
because
they
knew
that
you
know,
and
then
it
sort
of
became
this
thing
that
was
like.
Oh,
this
is
almost
like
a
good
first
issue
because
it's
road,
it's
mechanical,
and
it's
really
not
there's
like
a
lot
of
there's
a
lot.
You
know
I
mean
you
know
I've
certain
I've.
B
Certainly
you
know
blown
up
that
landmine
myself.
No,
you
know
not
look,
no
disrespect
to
anybody
who
does,
but
you
know,
yeah
a
lot
more,
a
lot
more
care
and
attention
needs
to
be
paid
to
to
those
prs
a
lot
more
review,
and
I
don't
know
that
we
have
the
volunteers
to
to
really
do
that,
and
so
that's
a
so.
So
I
do
think
that's
a
good
issue
to
discuss
separate
from
this
issue
and
yeah.
I
think
you
should
open
that
up.
Reuben
that'll
be
great.
A
Then,
if
not
we'll
move
on
to
37
408,
which
is
refactor
timeout,
immediate
list
and
timer
class,
I'm
just
going
to
see
agenda
so
rich.
You
added
that
to
the
agenda.
I
see
you're
just
mentioning
to
make
sure
it
gets
more
attention
if
it
doesn't
hasn't
gotten
any
by
the
next
tsc
meeting.
B
Yep,
this
is
for
visibility,
okay,
because
you
know
december
out
of
caution
and
but
also
timers
hot
stove.
You
know
we
should
be
careful
with
it,
so
actually
this
is
probably
one
that
we
should
probably
run
a
benchmark
on.
I
think
that
we,
I
think
we
did,
though
yeah
we
did
it's
up
there.
Yep.
A
Okay,
so
we'll
move
on
to
the
next
one
deps
addyarn
1.22.5
that
one
we
discussed
a
couple
weeks
ago.
A
The
sort
of
next
steps
is,
we
were
waiting
for
a
volunteer
who
would
potentially
run
a
survey
to
gather
more
information
about
usage
and
need
and
so
forth
in
the
community,
because
that
was
brought
up
by
some
tc
members
last
time
rich,
you
also
mentioned
you
might
be
using
it
as
sort
of
a
initial
change
for
a
rfc
type
process.
B
Yeah
I'd
still
like
to
do
that,
but
I
obviously
have
not
put
in
the
time
necessary
to
make
that
happen,
so
I
think
either
we
need
to
decide
that
this
is
a
decision
that
can
wait
or
we
need
to.
I
think,
last
meeting
I
was
in
we
were
talking
about.
If
we
don't
have
progress
in
a
couple
weeks,
we
would
just
take
a
vote
or
something
like
that.
I
I
hate
to
see
that
happen,
but
I
hate
even
more
to
just
see
this
issue
stay
open
for
a
year
and
have
no
resolution.
A
Right
and
the
I'm
just
looking
seven
days
ago,
oh
wait
a
sec,
that's
not
right,
I'm
pretty
sure.
Well,
that's
exactly
the
recollection
from
the
last
meeting
that
I
had
is
like.
We
basically
said
if
it
looks
like
one
of
those
two
things
are
going
to
happen
we'll
hold
off,
but
otherwise
we
should
just
call
a
vote
and.
B
What
I
would
like
to
do
is
is,
since
this
is
a
I
would
like
to
give
an
opportunity
to
people
who
maybe
don't
talk
as
much
as
as
you
and
I
do
in
these
meetings
to
to
elaborate
on
their
their
opinions
on
this
if
they
have
any.
B
So
if
it's
okay
with
you,
I'd
like
to
just
sort
of
like
actually
call
call
on
people
who
haven't
said
much,
this
meeting
like
I
know,
danielle
has
not
spoken,
so
I
kind
of
want
to
want
to
know
she
has
an
opinion
on
on
yarn
and
bundling
yarn
or
not,
especially
since
she's
a
releaser.
K
Yeah,
I
actually,
I
was
interested
in
listening
to
the
comments
on
this
issue
because
I've
been
following
it,
I
so
in
my
opinion,
as
a
user.
I
think
that
it
would
be
great
if
there
was
if
it
was
bundled
if
node
was
bundled
with
some
version
of
yarn,
just
to
make
kind
of
like
that
initial
usage
a
little
bit
easier,
but
as
a
platform
maintainer,
I'm
less
in
support
of
it,
because
I
think
it
just
kind
of
like
adds
another.
K
First
of
all,
there's
already
a
package
manager,
that's
bundled
with
the
yarn
and
then
also,
I
think,
just
like
I
get
messages
or
I
I
get
kind
of
like
comments
all
the
time
with
people.
You
know
people
that
are
using
note
on
heroku
that
they're
kind
of
like
oh
well,
you
know,
like
my
they've,
been
like
digging
through
the
binary
and
they're
like
oh,
like
do
I
need
this.
Is
there
any
way?
I
can
like
take
this
part
out,
and
so
there's
just
like,
I
think,
like
floating.
K
It
would
be
an
issue
for
users,
but
I
don't
know
I
think,
as
a
user.
I
would
actually
like
to
see
like
a
little
bit
less
friction
if
I
was
trying
to
use
yarn.
E
I
I
mean
ideally
we'd
have
a
separate
core
and
a
separate
standard
library
and
separate
npm
and
separate
yarn
right
and
then
maybe
some
distributions
for
convenience.
I
I
don't
really
have
an
opinion
on
including
yarn,
it
might
be
convenient
for
some
people,
just
like
npm
is
convenient
for
many
people
and
it
might
be
better
for
some
people
to
only
have
note
without
any
package
managers,
maybe
for
embedded
systems.
E
There
is
always
the
option
to
build
from
scratch.
You
can
always
do
the
binaries
without
any
package
manager.
So
if
it's
convenient,
then
why
not
include
it
and
that's
completely,
leaving
out
the
aspect
of
the
additional
work
for
releases.
A
Yeah,
the
the-
why
not
is
like
I
know,
npm,
is
a
decent
source
of
reasons
why
we
have
to
do
a
security
updates
in
terms
of
dependency,
so
adding
another
tree
of
dependencies
is
something
I
wouldn't
be
looking
forward
to.
That
is
a
good
point
for
me.
It's
like
yeah,
it's
it's!
It
comes.
That's
one
of
the
key
things
is
like
it's
something
that
I
think
would
would
cause
us
more
security
releases.
A
I
I
think
you've
hit
the
nail,
like
you
basically
put
the
point
on.
What's
really
the
key
issue
here
versus
the
technical
side
of
things,
because
we
often
get
into
like
well
technically,
it
would
be
useful
or
whatever,
but
in
the
end,
I
I
think
it's
around
the
hey
one
is
in
there,
and
one
isn't
is
what
is
ends
up
driving
this
versus
the
technical
issues.
A
lot
of
the
time.
H
H
B
Big
way
into
beth's
comment
in
the
chat
which
I'm
going
to
read
for
the
benefit
of
streamers
and
people
watching
the
recording,
which
is
my
main
thought
is,
it
doesn't
seem
fair
to
hold
up
hold
it
up
on
a
survey
that
seems
like
a
lot
of
hoops
we're
asking
the
contributors
to
go
through
to
have
their
pr
considered
because
of
that
I'd
be
plus
one
for
it
to
go
to
a
vote.
So
it
leads
to
a
resolution.
B
But
but
in
contrast,
gaurish's
point
seems:
if
I'm
understanding
correctly
is
that
the
crux
of
the
issue
is:
what
does
the
community
get
out
of
out
of
us
bundling
yard?
How
much,
how
much
benefit
or
or
opposite
of
benefit
for
that
matter?
Would
they
get
out
of
us
bundling
yarn
and,
and
we
and
we
don't
really
know
that
without
consulting
the
community,
is
what
I
think
I'm?
What
I
think
you're
trying
to
say
greece,
is
that
correct.
H
Kind
of,
on
the
other
hand,
the
community
also,
I
mean,
take
some
responsibility
on
its
shoulders
to
say
what,
as
a
set
of
people
in
the
community,
what
exactly
are
our
priorities
when
it
comes
to
the
the
node.js
project
to
the
wider
ecosystem?
H
So
is
it
that
we
want
to
be
seen
as
fair
for
the
in
in
terms
of
the
npm
registry
vendors
versus?
We
want
to
be
seen
as
a
stable
piece
of
platform,
which
is
coherent,
minimal,
core
and
well
maintained.
A
Yeah-
and
I
think
my
related
concern
to
that
is
you
know
once
you
start,
including
multiples
of
the
same
thing.
Where
do
you
stop
right,
like
okay,
if
you
say
well,
it's
fair
to
have
the
second
one
in
well
what
about
the
third
one
and
the
fourth
one,
and
then
what
about
michael's
package
manager
right?
It's
that's.
G
A
Versus
a
technical
like,
if
it's
for
that
reason
versus
a
technical
benefit
or
a
true
value
to
the
end
users,
you
know
that
lets
them.
You
know
if
it's,
if
it's
huge,
it's
kind
of
like
if
it's
just
so
that
you
know
it's
it's
on
that
dimension,
then
yeah.
Where
do
you
stop
and
then
we've
got
like
five
more
sets
of
dependencies.
We
have
to
support
and
do
security
releases
of
because
and
so
forth,
right.
J
It's
just
a
tiny
insult
script
and,
and
then
people
could
choose,
we
would
have
to
still
and
decide
on
what
package
managers
would
be
allowed
to
be
added
to
such
install
script.
For
example,
michael's
package
manager,
as
you
just
said,
would
probably
not
be
a
good
one,
because
we
would
have
to
have
like
a
minimum
bar
of
usage
out
there
in
the
community
and
that
would
probably
be
a
good
way
of
handling
it.
Out
of
my
perspective,.
A
Right
and
that
that's
where,
like
back
to
you,
know,
I
kind
of
agree
with
with
beth
at
this
point
that,
like
saying,
we
won't
do
anything
until
there's
there's
a
survey,
a
survey
is,
is
a
bit
of
a
bar
I'd.
Also,
personally
think
it's
it.
You
know
if
we
don't
have
enough
information
to
say
it's
the
right
thing,
I'm
I'm
comfortable
saying
well,
no,
not
not
that
we
never
would,
but
that
know
that
we
don't
have
enough
information,
and
so
given
a
vote,
that's
going
to
be
the
answer.
A
So
it's
you
know
I
I
I'm
leaning
towards
the.
Unless
we
have
you
know
somebody
who's
volunteered
to
be
the
champion
to
lead
that
from
the
tse
right,
so
it
shouldn't
be
back
to
the
the
proposers
or
the
you
know,
rich.
If
you
were
gonna
like
well
next
week,
we'll
have
an
rfcs
process.
So
let's
do
that.
If
that's
gonna
drag
out,
you
know
I'm
still
back
to
like.
We
should
maybe
just
vote
on
this
particular
pr.
A
I
mean
there's
been
a
but
like,
like
you
know,
ruben
mentioned,
there's
been
alternatives
and
it
seems
to
be
like
all
sorts
of
different
things
are
being
tried
in
terms
of
pr's
and
suggestions
and
whatever
you
know,
and
maybe
it's
up
to
the
tc.
To
just
say:
look
we
don't
have
enough
formation
to
say
yes
on
this
or,
yes,
we
do
right
like
and.
B
I
mean
I,
I
do
like
the
ship,
a
ship,
a
package
manager
manager,
suggestion
that
you
know
has
been
made
in
the
past
and
that
reuben
just
brought
up
again
but
the,
but
like
the
the
one
thing
that
gives
me
so
much
pause
about.
That
is
that
it
it.
You
know
that
one
extra
step
of
having
to
install
package
manager
just
increases.
You
know
just
will
break
so
many.
So
many
workflows,
automated
and
otherwise.
A
B
F
I
just
want
to
say
that
we
have
there:
was
this
tool
called
corpac
being
built?
I
don't,
I
can't
remember
the
story
about
it,
but
I
don't
know
why
we're
not
actually
landing
this
that
will
solve
the
problem.
B
A
F
So
I
don't
know,
I'm
just
wondering
if,
if
somebody,
if,
if
this
is
done,
then
maybe
we
can
just
ship
this,
and
I
don't
know
I
would
prefer
to
ship
this
essentially.
A
I
I
think
so
that's
like,
I
don't
think
there
was
consensus,
so
maybe
we
would
need
a
separate,
a
separate
discussion
on
the
other
one.
Is
there
an
existing
pr
for
that?
I
know
we.
We
agreed
to
move
it
into
the
re
into
the
organization
to
sort
of
basically
incubate
it,
but
I'm
not
sure
I
remember
a
pr
to
bring
that
into
core.
Since
then,.
B
And
I
think
I
think
that
that's
just
extra
overhead
I
mean
I
could
be
wrong,
but
I
mean
npm
doesn't
exist
in
our
isn't,
isn't
in
our
our
org
either
you
know
we
bundle
it
and
you're
and
yarn's
not
gonna,
but
beth
just
commented.
Does
it
make
sense
for
the
tst
to
vote
on
both
both
pull
requests?
I
don't
know
I
don't
know
there
is
a
pull
request
for
core
pack,
but
certainly
we
could
just
say:
does
it
make
sense
for
me
for
the
tc
to
vote
on
both
proposals?
A
That
that
would
make
sense
to
me
right
like
in
terms
of,
and
maybe
I
don't
know
how
we
would
rank
like
I'm
thinking
there
could
be
people
who
would
be
like
well
I'd
I'd
prefer
neither,
but
if
you're
gonna
do
one.
This
is
the
one
I
prefer
right
like.
So
if
we
could
come
up
with
a
strategy
to
extract
that.
B
So
this
is
a
this
is
a
you
know,
big.
This
is
an
issue
a
lot
of
people
like
they
have
opinions
on.
So
I
I
do
want
to
the
two
people
we
haven't
heard
from.
I
want
to
make
sure
they
have
an
opportunity
to
weigh
in
if
they
have
any
say
it
would
be
nikita
and
robert.
G
Well,
in
my
opinion,
is
if,
if
you're,
adding
more
package
managers
just
for
fairness
sake,
then
it's
better
to
remove
npm.
If
that's
the
core
issue,
because
it's
really
a
pandora's
box
there,
as
michael
mentioned,
if
you
include
one,
what's
what's
the
clear
bar
that
another
packet
manager
has
to
pass
for
that
also
to
be
included,
so
a
package
package
manager
is,
I
guess,
a.
B
B
D
A
F
A
Okay,
I
guess
the
only
question
that
related
to
that-
and
I
I
don't
remember,
is
like
do
we
take
any
responsibility
if
it
makes
it
look
like
node
has
installed
it
for
them
versus
the
npm
dash
like
we're,
basically
replacing
the
hey,
I'm
going
to
do
npm,
whatever
yarn
with.
I
think
you
just
type
yarn
and
it
will
automatically
install
it
for
you,
so
somebody
may
not
even
know
that
it
was
installed.
It
could
look
like
it's
part
of
node
and
do
we
take
any
any
responsibility
having
done
that
versus
the
the
owner?
B
Themselves,
nikita
did
you
have
anything
you
wanted
to
add
to
this
this
topic
and
it's
okay.
If
you.
A
A
A
Yeah
I'll
take
the
action
item
to
open
an
issue
in
the
tc
repo
saying
you
know
we
discussed
in
the
recent
meeting.
Moving
this
to
a
vote
does
do
any
other
tse
members
have
comments,
concerns
and
so
forth
in
us
doing
that.
B
So
so
the
the
issue
michael
would
open
would
would
would
be
about
both
cork
pack
and
bundling
yarn.
Is
that
right,
michael.
F
Exactly
like
again,
it's
it's
for
me:
it's
either
one
of
them
or
none.
So
it's
a
it's,
not
a
yes!
No
is
it
right.
A
Yeah
I'll
try
and
come
up
with
a
question
like
a
set
of
questions
that
I
would
post
in
there
to
say
like
a
vote
and
here's
some
proposed
questions
that
would
try
and
get
that.
I,
that
subtlety
and
like
even
like
the
preferences,
because
there
can
be
different
preferences
in
there.
A
A
Actually
only
have
five
minutes
left,
so
we
have
a
number
of
issues
and
I
know
there
was
private
business
as
well.
So
I
think
we
should
look
at
what's
left
on
the
agenda
and
ask
if
there's
anything
we
absolutely
have
to
talk
about
today
or
otherwise
move
into
our
private
session.
A
B
I
B
B
Oh
nikita
put
his
yarn
comment
in
here
he's
against
bundling
yarn
directly,
but
in
favor
of
a
script
to
install
package
manager.
Okay,
I'll
make
a
note
of
that.
In
minutes,.