►
From YouTube: 2016-11-15 Node.js Version Management Meeting
A
A
A
You
know
not
really
resources,
but
maybe
the
like
testing
infrastructure
that
node
uses
and
things
like
that,
and
so
my
thinking
was
that
I'd
like
to
see
it
go
into
the
node
foundation,
since
that
seemed
to
be
the
best
foundation,
most
appropriate
foundation
for
it
to
go
to
so
I
raised
the
question
and
as
I
feared,
there
was
a
lot
of
distraction
around
other
version
managers,
of
which
there
are
many.
You
know,
and
we
all
know
those
so
my
it
sounds
like
the
node
CTC
or
tsc.
I
can
never
keep
them
straight.
It
like
over.
A
A
My,
like
a
number
of
you
I,
think
maintain
some
of
those
other
projects,
oh,
my
hope,
was
in
bringing
nvm
n
was
not
at
all,
of
course,
to
squeeze
out
other
projects.
It
was
too
just
like
primarily
move
that
one
project
into
the
foundation
and
then
the
goal
of
developing
some
sort
of
more
holistic
version
management
solution
to
me
was
a
separate
thing
that
moving
nvm
in
would
assist.
But
not
you
know,
I,
don't
see,
I
didn't
see.
A
B
So
I
do
want
to
a
note,
unlike
be
the
idea
of
like
a
more
holistic
thing
or
like
that,
nvm
is
like
leading
into
that
or
whatever
I
mean
it's
partially,
driven
by
the
fact
that,
like
I,
don't
know
the
installers.
We
have
aren't
that
great.
So,
like
the
Installer
project
is
like
there
to
have
like
a
better
GUI
installer,
but
it's
kind
of
stalled
out
partially
because,
like
the
actual
you
like
actually
managing
the
versions
behind
that
kind
of
needs
to
be
back
by
something.
A
A
A
So
for
I
agree
that
in
the
that,
if
nvm
were
to
come
in
and
then
nvm
choices
for
better
or
worse
were
kind
of
enshrined,
as
this
is
the
way
version
management
is
done,
then
that
would
not
especially
because
of
a
lack
of
Windows
support,
but
just
in
general,
because
that
way
it
wasn't
designed
with
everyone
in
mind.
Initially,
that
would
not
be
a
good
thing
for
node
users
as
a
whole,
but
I
don't,
I
see
it
is
actually
somewhat
necessary
for
the
project.
A
If
anything
were
to
happen,
that's
unforeseen,
then
the
project
screwed
and
all
of
nvms
current
users,
which
are
a
decent
subset
of
node
users,
are
screwed
as
well
and
so
moving
the
project
into
the
foundation
helps
protect
those
because
it
creates
a
path
to
resurrect
the
project
or
you
know,
gracefully
transition
people
off
of
it
if
necessary.
If
something
like
that
were
to
happen,
I
don't
want
any
of
those
things
to
happen,
but
you
know
I'm
trying
to
be
cognizant
that
those
things
can't
happen.
Yeah
Jeremiah,
I.
B
D
B
A
E
A
Sure
on
so
in
general
terms,
which
I
think
apply
to
this
any
software
project,
that's
in
a
foundation
gets
a
large
number
of
benefits.
It
gets
the
benefit
of
licensing,
knowledge
and
research.
That's
been
done
so
you
know
any
licensing.
Questions
foundations
generally
provide
guidance
there
and
have
you
known
own
foundation
being
part
of
the
Linux
Foundation.
There's
a
lot
of
legal
staff
available
to
assist
so,
and
these
are
issues
that
nobody
cares
about
most
of
the
time,
but
when
it
does
pop
up
it's
a
huge
deal.
A
Number
two
is
a
like
governance,
so
most
software
projects
tend
to
be
at
the
whims
of
their
maintained.
Errs.
If
you
know,
I
decide
like
to
become
a
bad
actor
for
some
reason.
Like
I
I
mean
I
can
just
go
close,
pull
requests
or
you
know,
delete
features
and
break
people,
and
that
doesn't
really
matter
later
life
size
I
mean
that
that
that
does
matter
it
affects
people,
but
there's
nothing.
A
Anybody
can
do
to
stop
me,
except
for
10,
and
similarly,
if
Tim
decides
to
do
something
like
that,
he
could
go
delete
me
from
the
project
and
you
know,
delete
all
the
features
and
so
on
and
so
forth,
like
all
these
things
can
happen
and
their
unexpected
and
nobody
wants
them
to
happen,
but
they
do
happen.
There's
been
maintainer,
you
know
large
maintainer
ship
issues
with
a
few
projects.
You
know
notable
need
to
go
into
so
I.
Think
governance
is
a
big
important
one.
So.
A
Well,
nvm
has
nothing
to
do
with
JavaScript,
it's
written
in
shell
scripting
and
it's
managing
node,
which
does
of
course
run
JavaScript.
But,
like
that's
a
that's,
a
somewhat
tenuous
link
and
at
the
time
that
I
made
the
request,
the
GS
foundation
didn't
exist,
but
I,
but
I
also
don't
think
it's
the
most
appropriate
place
for
it.
Certainly
if
the
node
foundation
is
not
interested
in
hosting
the
project,
I've
been
working
with
the
jas
foundation
for
quite
a
while,
so
I
mean
I
would
seek
putting
it
in
there.
But
I.
E
It
ya
know
so
the
only
reason
I
mentioned
that
in
particular
and
I
mean
you
know
I'm
already
coming
wanting
to
support
you
on
this
sorry
hold
on
one.
Second,
it
was
more
along
the
lines
of
I.
Think
one
of
the
biggest
things
that
we've
struggled
with
obviously
is
avoiding
a
conflict
here
and
not
trying
to
support
one
over
the
other,
and
then
you
know
we.
The
project
itself
has
struggled
as
a
foundation
figuring
out
where
projects
that
are
not
core
fit
in,
but
at
the
same
time
you
know
we
have
things
like
build.
E
A
E
Foundation,
though
40
for
what
it's
worth
is
not
that's
good
to
know,
yeah,
it
was
brought
in
as
a
mentor
project
and
Jeremiah
may
be
able
or
William
actually
would
probably
know
the
exact
details
of
it
better
than
myself.
But
essentially
we
brought
an
Express
as
a
mentor
project
to
help
them
figure
out.
You
know,
building
a
governance
structure,
but
it
was
not
an
official
member
project.
That's.
F
I
think
the
important
thing
I'll
diversion
manager
is
the
question
of
whether
or
not
one
day
note
will
ship
with
a
version
manager
which
I
have
received
phenomenal
feedback
about,
wanting
that
I've
never
I've
never
seen
her
reactions
so
strong
about
it
before
from
developers.
So
that's
really
interesting.
So
I
think
that
the
desire
is
out
there
and
if
that's
the
case,
if
nodes
going
to
be
shipping
it,
if
it's
ever
a
possibility,
then
I
certainly
think
being
in
the
node
foundation,
is
the
right
place.
So.
B
We
actually
talked
about
this
on
I.
Guess
that's!
What's
at
the
tsc
meeting
now
this
is
not
really
TSE
domain.
I
measured
by
chipping
it,
but
I'm
like
it
was
suggested
there
that
probably
we
could
ship
something
just
fine
that
wasn't
in
in
the
foundation
under
that,
like
we
I
mean
we
ship
em
p.m.
already
right.
So
we
might
do
that
regardless.
Well,.
E
B
Tool
that
ships
with
it
so
I
mean
then
our
installers,
not
the
actual
package.
The
backshell
package
probably
would
not
come
with
it,
but
the
installers
would
then
give
you
like
an
option
to
install
using
a
virgin
manager
person
who
I
think
I
might
actually
make
a
poor
request
with
that.
If
everyone's
okay
with
it
to
at
least
get
discussion,
I
think.
F
C
Like
to
take
a
quick
second
address,
Jordan's
question
from
a
while
ago,
I
thinkin
Corey
art,
really
where
a
starting
point
is
for
this,
because
you
know,
especially
in
this
call,
we
may
not
identify
what
the
best
approach
is
going
forward
with
anything.
But
the
reason
that
I've
been
advocating
setting
up
standards
initially
is
more
stuff
from
all
the
confusion
that
I've
seen
with
users.
So
with
the
nvm
windows
project,
the
biggest
mistake
I
made
was
actually
calling
it
nvm
windows,
because
it's
not
exactly
the
same
as
nvm.
C
C
What
note
or
what
a
note
installation
actually
is?
Do
you
I'm
windows?
Do
you
look
in
the
registry
to
identify
the
version
or
you
look
at
a
file
path?
Or
you
know
those
kinds
of
questions
were
coming
up,
so
there's
been
confusion
as
to
what
actually
defines
a
no
distal,
so
I
think
that's
why
I've
been
advocating
starting
with
standards,
because
what
that
would
allow
us
to
do
is
at
least
come
together
on
the
same
page
and
the
existing
projects
out
there
could
either
adapt
to
that
as
opposed
to
kind
of
setting
a
standard.
C
So
we
have
that
we
have
a
problem
where
we've
got
some
several
different
version
managers
out
there
that
I'll
do
a
great
job,
but
they
are
tweaked
in
an
opinionated
manner.
Whereas
if
we
have
a
standard
that
we
can
all
come
around,
then
we
can
move
forward
without
restricting
ourselves
to
the
specific
workflow
or
to
a
specific
ideology.
So
Jordan
I
hope
that
addresses
the
original
question
that
you
had.
But
that's
to
me
that
seems
more
fundamental
than
necessarily
bringing
in
a
project
as
much
as
I'd
like
to
see.
C
You
know
several
projects
involved
because
I
also
agree.
You
know
and
I
can
properly
echo
the
same
sentiment
the
Jordan
has
had
about
you.
Nvm
windows
would
definitely
benefit
from
the
same
things
that
Jordan
was
discussing
that
D
governance
or
you
know,
testing
infrastructure.
Any
of
those
kinds
of
things
would
be
fantastic
to
have
something
along
those
lines,
but
again
taking
a
step
back
to
him.
To
start
I'm.
Sorry
back
to
standard
seems
like
more
that
baseline.
We
can
all
come
together
and
so
I
just.
A
C
Only
concern
I
have
with
that
is
what
does
that
say
to
the
public,
because
it's
not
like,
if
we
say,
okay,
nvm
or
nvm
windows
or
noticed
or
any
of
those
other
any
of
the
other
projects
come
in.
Is
that
the
standard,
because
there's,
unfortunately,
a
lot
of
people
just
make?
You
know
assumptions
about
things,
so
it
would
need
to
be
clearly
delineated
that
this
is
just
a
project
that
is
coming
in
and
then
the
standards
are
separated
and.
C
Clear
then,
maybe
there
isn't
a
problem
but
I'm
frankly,
just
concerned
about
assumptions,
because
I
get
users
all
the
time.
They're
posting
issues
that
they
have
with
nvm,
because
they
tried
to
install
nvm
on
windows
as
opposed
to
my
project.
So
they
get
that
that
confusion.
We
learn
again
that
that
goes
back
to
just
my
personal
experience
in
a
very
poorly
named
project
at
the
it
you
know
in
retrospect,
but
that
that's
more,
my
concern
is
the
assumptions
that
people
make
about
how
oh
well.
This
is
a
version.
Versioning
works
here.
G
Did
never
quite
understood,
or
rather
I
would
say.
Standardization
is
important
for
me,
but
standardization
across
managers
feels
kind
of
unnecessary,
because
if
you
have
multiple
managers
that
implement
the
same
standard,
then
what's
the
point
of
having
multiple
manage
managers,
but
standardization
from
the
point
of
view
of
we
want
to
have
a
version
management
approach
that
works
for
all
platforms
is
kind
of
desirable,
I.
G
A
A
It
does
not
mean
this
is
official
or
endorsed,
or
the
only
way
it
is
supposed
to
only
mean
the
foundation
is
caring
for
in
some
way
the
project-
and
I
think
the
node
foundation
is
concerned
about
sending
a
message
that
you
know
this
project
or
that
project
is
kind
of
blessed,
but
that
concern
only
arises
because
they
have
not
yet
adopted
projects,
and
I
think
that
as
the
node
foundation
adopts
projects,
that
concern
will
completely
evaporate,
because
it
will
be
very
clear
that
these
things
are
not.
You
know,
blessed
solutions.
A
Picture
nvm
has
the
widest
usage.
I
think-
and
I
only
claim
that
because
of
its
travis
CI
installations
outside
of
travis
CI
and
and
if
you
perhaps
correct
for
the
bump,
it
probably
gets
for
being
used,
there
I
suspect
it's
probably
no
more
common
than
any
of
the
others.
Certainly
not
you
know,
but
the
through
top
three
as
I'm
aware
of
for
linux,
at
least
our
nvm
and
and
nave-
and
you
know
there
are
a
few
other
smaller
projects
and
then
there's
nvm
windows
is
the
only
one
I
know
of
for
windows.
A
At
this
point
there
has
been
others
in
the
past,
but
I
think
they're
all
defunct,
but
the
the
popularity
isn't
really
the
concern
as
much
I
mean
like
somewhat
in
the
sense
that
Travis
CI
is
driving
a
lot
of
nvm
installed.
Installs
but
I
mean
I
have
commit
access
to
their
cookbooks
and
stuff
so
like
we
can.
We
can
make
changes
there
if
needed,.
E
Don't
I
don't
speak,
you
know
for
the
entire
core
team,
but
for
myself
when
I,
when
people
are
on
a
nick
system
and
in
our
having
issues
with
node,
especially
around
versions,
nvm
is
my
go-to
to
suggest
and
I
I've
played
with
a
whole
bunch
of
the
different
version
managers,
and
primarily
because
it's
written
in
pathak's,
so
there's
no
possibility
that
a
botched
a
note
or
NPM
instance
on
the
machine
is
going
to
cause
a
problem.
So
that's
always
been.
You
know.
E
For
me,
what
is
kind
of
put
it
at
the
top
of
my
list
for
suggesting
is
that
way?
If
people
are
having
system
issues
they
can
drop
nvm
in
and
then,
if
that
trims,
the
path
that
usually
can
like
allow
them
to
start
moving
forward
without
having
to
like
figure
out
what
they
botched
on
on
their
system
itself.
I
do
think
some
of
the
solutions
that
we've
talked
about
moving
forward,
such
as
an
installer,
a
double
click
installer
that
can
handle
version
management,
may
make
something
like
that.
E
A
moot
point,
something
like
an
electron
based
version
manager,
is
something
that
I
could
see
working
really.
Well,
it's
one
of
these
kinds
of
it's
a
bit
of
a
catch-22:
I
see
a
lot
of
value
in
the
version
manager
being
written
in
JavaScript
I
for
one
have
tried
to
dig
into
the
nvm
source
code,
and
it's
just
it's
hard.
E
You
know
like
it's
all
politics,
it's
not
it's
not
a
friendly
thing
to
jump
into,
whereas
if
we
had
something
that's
written
in
JavaScript,
that
would
be
way
easier
for
people
to
jump
in
and
get
involved
in
sure.
But
you
do
have
this
chicken
and
egg
problem
into
me
at
least
right
out
of
the
gate.
The
value
of
being
able
to
run
the
Installer
on
most
systems
without
having
to
have
anything
installed,
outweighs
the
benefit
of
making
it
easier
to
contribute.
E
Now,
if
we
move
towards
something
like
having
a
double
click,
installer
or
an
electron
based
version
manager,
that
can
do
things
using
UI,
we
move
into
a
different
different
area
where
things
becomes
a
little
bit
simpler.
This
is
for
myself
Marcel,
where
I
actually
see
a
lot
of
value
in
some
sort
of
standardization.
I
was
the
one
who
had
open
the
threads
specifically
around
standardizing,
how
we
are
shimming
the
path
and
standardizing
how
we
are
actually
storing
the
information
on
the
system.
E
But
you
know,
if
you
have
a
standardized
path
and
a
standardized
location,
someone
could
use
a
double
click
installer
to
install
it.
They
could
then
use.
You
know
something
in
their
toolbar
for
switching
between
versions
or
use.
Something
like
nvm
to
switch
between
version
right
when
nvm
itself
is
running
is
not
really
doing
anything.
All
it's
doing
is
changing
the
path,
so
standardizing
these
things
would
really
simplify.
E
Being
able
to
have
multiple
tools
that
can
work
together
at
various
levels,
in
the
stack
and
of
various
complexity,
because
we
have
users
who
want
to
live
in
the
command
line.
We
have
users
who
would
love
to
have
something
in
a
UI.
We
may
even
want
people
who
want
to
do
it,
programmatically
and
so
having
a
baseline
for
that
could
really
simplify
things
and
my
opinion
at
least
important.
A
And
and
but
for
what
it's
worth,
I
think,
regardless
of
where
nvm
lives
for
nvms
users
regard.
You
know
it's
separate
from
the
discussion
of
how
many
there
are,
because
that's
not
really
relevant
I
would
need
there
to
be
a
migration
path,
and
so
whether
nvm
is
in
the
foundation
or
not,
the
the
things
that
are
important
to
me
are
the
use
cases,
not
the
implementation
details,
and
as
long
as
nvms
use
cases,
nvm
users
use
cases
are
met,
then
I
will
happily
transition.
A
You
know
figure
out
a
transition
path
to
get
people
over
to
it.
So
there
was
an
earlier
question.
I
think
Marcel
asked
is
nvm
the
standard
I,
don't
think
that
matters
I
think
that
that
the
use
cases
nvm
serves
are
critical,
but
I
think
that
the
use
cases
that
every
version
manager
serves
are
likely
critical,
and
I
think
that
that
process
of
researching
that
and
figuring
out
what
are
the
use
cases
that
are
important.
A
You
know
command
line
or
GUI
or
Windows
or
Mac,
or
you
know
raspberry
pie
or
you
know
all
those
things
like
getting
a
complete
list
of
that
is
important
and
I.
Think
that,
as
we
make
that
list,
all
of
the
projects
should
try
to
converge
at
that
point
to
where
Marcel's
comment
was.
If
we
have
a
standard
that
multiple
version
manager
to
implementing,
why
I
have
multiple
ones,
I
think
that's
exactly
where
we
want
to
be.
A
We
want
to
get
to
the
point
where
the
standard
is
sufficient,
such
that
it
doesn't
matter
that
there's
multiples
anymore,
and
then
we
have
you
know
and
then
it's
then
we
can
just
kind
of
pick,
one
of
them
as
the
official
implementation
or
build
a
brand
new
one.
According
to
that
spec
and
everything
solved,
or
we
never
have
to
do
that,
and
we
can
just
say
cool
now:
we've
got
this.
A
This
standard,
like
promise,
is
a
plus
and
all
the
promises
lives
out
there
or
you
know
whatever
so
I
think
that
I
think
that
it
is
definitely
critical
as
miles
and
Corey
have
said
to
move
towards
the
standard.
We
should
speak,
slow
and
cautious
about
standardizing
things,
because
we
are
definitely
going
to
run
headlong
into
use
case
conflicts
if
we're
not
careful
but
I.
Think
as
we
do
that
we
should.
We
have
the
opportunity
to
get
all
of
these
projects
in
the
ecosystem
to
converge
on
these
standards
and.
A
I
think
and
so
to
me,
the
the
process
of
figuring
out
the
whole,
the
holistic
official
solution
and
the
standards
there
in
our
is
a
long,
slow
one
and
it
needs
concert.
You
know
cooperative
effort
between,
as
many
version
manager
authors
as
possible
to
try
and
drive
that
so
yeah,
so
I
guess
I,
like
I'm
totally
on
board.
With
that
message,
I
just
you
know,
I
still
think
that
nvm
would
be
best
in
the
foundation
in
the
meantime
and
I
totally
agree
with
confusion.
A
Corey's
as
a
problem,
I
mean
I,
get
nvm
windows
users
filing
bugs.
On
my
repo
to
you
know
the
that's
a
big
issue,
but
that's
going
to
be
an
issue
regardless
and
especially
because
of
the
existing
user
basis
of
all
of
our
tools,
any
like
we're
always
going
to
have
to
provide
a
migration
path
or
be
screwing
over
some
people,
and
so
I
like
I.
Think
we
would
that
if
nvm
went
in
the
foundation
tomorrow,
I
would
want
it
to
be
tightly
coupled
and
loudly
coupled
with
a
bunch
of
messaging
around.
A
This
is
not
the
standard
for
version
management.
This
is
not
a
blessed
project.
This
is
not
the
only
one
that
should
ever
exist.
This
is
just
the
first
step
in
caring
for
version
manager,
projects
in
the
ecosystem,
so
that
the
node
foundation
as
a
whole
can,
you
know,
get
a
complete
picture
of
all
of
the
important
use
cases
so
that
we
can
evolve
towards
an
ideal
solution
for
everyone
for
all
node
users.
Like
that's
you
know,
maybe
they're
there.
A
D
A
A
A
Linking
that
to
you
know
some
other
path
or
using
a
shim
to
proxy
into
that
path,
and
so
forth,
like
the
both
nvm
solution
and
a
shim
solution,
for
example,
don't
care
where
the
actual
binary
lives,
they're,
intercepting
the
request
somehow
and
then
making
sure
that
that
you
know
that
command
gets.
You
know,
hits
the
correct
binary
yeah,
so
I
don't
actually
see
a
conflict
there.
A
It
certainly
might,
if
we're
not
careful,
create
a
situation
where
some
version
managers
are
penalized
because
they
have
to
go
to
jump
through
extra
hoops
to
make
their
approach,
work
and
I.
Don't
want
to
do
that
and
that's
part
of
why,
like
I,
think
we
need
to
get
as
much
input
as
possible
before
making
these
standards
in.
A
You
know
like
that,
XKCD
with
the
spacebar
and
the
overheating
of
the
computer,
like
figuring
out
all
the
things
that
people
are
doing
and
try
to
use
that
to
inform
a
future
facing
voice,
and
that's
part
of
the
reason
why
don't
want
to
rush
into
making
a
standard
as
well,
because
I
as
soon
as
we
say
this
is
a
standard,
it
becomes
really
hard
to
walk
back
from
that.
So.
A
G
C
A
I
I
We
talked
about
how
I
think
it
would
be
nice
to
have
the
you
know
the
nvm
and
JavaScript
or
some
form
of
envian
and
nvm
in
JavaScript,
but
then
it
could
be
a
chicken
and
egg
problem
and
envy
you
know,
I
looked
at
nvs
does
seem
to
you
know,
does
have
a
solution.
I,
you
know.
Is
it
the
right
solution?
I,
don't
know,
but
it
it
did,
have
a
solution
for
that
hairy
problem.
A
A
Okay,
if
we
end
up
in
a
situation
where
we
do
have
enough
standards
so
that
people
can
write
cross
platform
tools,
but
maybe
the
node
installer
prompts
one
of
three
different
version
managers
based
on
that
your
needs,
like
maybe
that's
the
solution
we
end
up
being
and
then
we
don't
have
one
size
fits
all
version
manager,
but
we
have
enough
version
managers
to
cover
all
the
use
cases
that
interoperate
cleanly.
Like
you
know,
I'm
not
sure.
A
I
think
that
nvs
is
approach
will
likely
cover
a
lot,
but
there
are
likely
as
well
use
cases
where
it
won't
work.
You
know
because
of
the
footprint
of
running
a
note,
installation
or
the
the
weight
of
downloading
it
or
so
forth
and
I
think
we
can
explore
those
more
deeply
over
time,
but
but
I
certainly
I
think
I.
Think
NBS
is
the
closest
we
might
have
to
an
ideal
implementation
so
far,
I'm
so
excited
about
the
possibility
of
not
having
to
ever
write
pauses
again.
Let
me
tell
you.
I
Maybe
you
know
just
this
baby
did
make
me
extremely
happy
again
again.
To
be
honest.
Yes,
you
know,
there
are
a
couple
things
I
think
could
probably
be
done.
You
know,
could
probably
be
done
better
in
terms
of
I
think
in
terms
of
downloading
an
old
version
of
node
and
then
using
a
new
version.
I,
don't
really
yeah
I.
Don't
really
like
that
to
be
honest,
but
otherwise
it's
at
least
it.
At
least
you
did
something.
A
A
Nvm
does
not
do
that.
Nvs
does
not
do
that.
Nvm
windows
does
not
do
that.
You
know
we
all
try
to
serve
our
niche.
The
best
we
can
and
but
I
think
that
we
need
to
that.
If
we
want
to
come
up
with
a
blessed
solution
than
we
need
to
be
very
careful
not
to
exclude
anyone.
That
is
that
note
officially
includes
that
makes
sense
so
I.
So
yes,
like
I,
think
nvs
is
a
great
model
and
I
think
Jason
is
really
good.
B
Absolutely
so
like
I
want
to
mention
like
this
is.
This
is
really
like
even
another
step
forward
in
my
mind,
because
I
mean
there's
not
much
really
that
unified
in
a
node
installs,
as
as
it
is
right
now,
like
you,
have
a
Mac
installer
that
installs
it
a
certain
way.
You
have
a
windows,
installer
installs,
a
certain
way.
B
You
don't
have
linux
installers,
but
you
can
install
them
through
package
managers,
I,
guess
really,
if
they're
the
ones
that
we
build,
that
note
source
but
I,
there's
other
ways
you
can
install
like
just
the
raw
packages,
so
I'm
like
personally
I'm,
not
really
sure
if
it
matters
that
much,
at
least
on
that
end
of
things
so
like
if,
if
the
mac
installer
installs
a
mac
version
manager
for
it
that
works
a
way,
that's
compatible
with
no
mac
OS
and
then
the
windows
one.
Does
it
a
way
that
works
best
with
windows?
B
A
Yeah
I
mean,
I
think
I
think
it
is
important
to
note
that,
as
long
as
the
experience
on
the
same
machine
for
the
same
user
is
consistent
across
the
tools
that
are
available
to
them,
then
we
I
think
we
have
well.
We
will
have
achieved
quite
a
lot,
even
if
things
are
not
identical
across
two
different
computers.
E
Yeah
I
think
to
build
on
what
Jeremiah
was
saying.
I
do
think
that
we
don't
need
to
pigeonhole
ourselves
into
making
a
single
solution
for
all
platforms
if
that
doesn't
prove
to
be
the
best
way
of
approaching
it.
Now,
if
nvs
is
showing
that
there
is
a
path
forward
on
that,
that's
great,
but
at
the
same
time
you
know
like
if
we
can
get
like
the
installers
that
we
have
and
Jeremih
didn't
get
too
far
into
it,
but
I
mean
like
it
is
really
bad
legacy
stuff.
E
We
have
a
massive
issue
right
now,
for
example
with
the
OSX
installer,
where
there
is
no
way
that
I
have
at
least
been
able
to
yet
digging
in
get
the
installer
to
remove
files
before
installing,
which
means
the
node
modules.
Npm
folder
doesn't
get
removed
before
it
gets
reinstalled,
and
this
has
left
us
in
this
terrible
case
where
we
have
artifacts
that
are
left
over
between
installs
and
it's
caused
really
really
really
weird
edge
cases.
E
So
to
me
you
know
having
a
semi
bespoke
solution
that
performs
better
on
a
platform
and
is
better
for
that
particular
platform
as
an
install
option.
You
know
if
we
have
a
generic
installer,
that's
built.
An
electron.
Just
is
like
a
high
level
idea
that
in
itself
allows
you
to
select
from
a
group
of
you
know,
version
managers
that
all
work
somewhat.
Similarly,
I
see
that,
as
like
a
great
win,
I.
H
B
From
like
the
shipping
node
side
of
things,
I
mean,
maybe
my
perceptions
is
wrong,
but
I
feel
like
that.
Like
file,
systems
on
unix
and
windows
are
like
really
quite
quite
different
in,
like
where
you
put
everything
and
to
install
so
like
I
mean
you're.
The
install
story
is
always
going
to
be
a
little
bit
different,
even
if
you're
you're
running
the
same
tool
right
I
think
like
the
biggest
thing
is
like
for
like
platforms
that
are
really
similar.
You
can't
you
kind
of
want
a
way
that
you
can
be
like.
B
A
I
think
even
in
that
world,
like
like
file,
paths,
are
different,
but
the
core
path
module,
provides
consistent
interfaces
that
abstract
that
away
and
I
think
that
its
total,
like
on
Windows,
you
have
the
registry
and
on
you
know
you
like
Linux,
you
have
environment
variables
and,
like
thing
you
know,
there's
there's
lots
of
different
ways
to
configure
things
and
I.
Think
it's
fine.
If
those
are
different,
but
whatever
those
are,
we
need
to
be
able
to
write.
A
H
Something
I've
dealt
with
in
developing
nds,
trying
to
implement
equivalent
functionality
on
windows
and
non
windows
platforms.
What
most
of
the
code,
of
course
is
crop
cross-platform,
but
major
differences,
of
course
are
when
you
want
to
edit
to
use
the
profile
tap.
You
either
edit
a
batch
RC
file
on
unix.
Are
you
ready
to
Windows
registry
profile
and
windows,
and
then,
if
you
want
to
install
link
to
a
system,
location
and
you're,
going
to
program
files
on
windows
or
user
local
on
unix,
there
are
differences
like
that.
A
F
Kissed
a
topic
that
I'll
that
I
probably
should
bring
up
from
the
tsc
call
for
anyone
that
didn't
listen
into
it.
It
was
you
know,
rod
had
morphine,
but
he
really
doesn't
want
to
see
in
the
node
foundation
is
to
have
a
anything
brought
in
that
that
just
goes
dead
and
then
it's
just
some
code.
That's
no
one's.
Maintaining
it's
just
sitting
there
and
I.
Think
I
got
the
sense
that
many
people
were
against
having
multiple
things
pulled
in
so
just
throwing
that
information
out
there
is
I
mean
my
takeaway
from.
A
A
If
it's
in
the
foundation,
because
then
the
foundation
can
come
in
and
market
deprecated
or
it
can
come
in
and
help
a
known
instrument,
a
transition
or
whatever
you
know.
I
can
certainly
understand
not
wanting
a
flood
of
projects
to
come
in
to
just
like
quote
be
in
the
foundation,
but
I,
don't
think
that
has
to
happen.
A
Nor
do
I
think
that
acceptance
of
a
project
or
two
projects
or
three
projects
in
any
way
guarantees
you
know
or
forces
the
Foundation's
hand
and
accepting
a
fourth
project
and,
if
necessary,
I
think
with
each
you
know
induction
it
can
be
made
very
clear.
This
is
not
setting
a
precedent.
This
project
on
its
own
merits,
you
know
for
its
own,
you
know,
for
these
reasons
should
be
in
the
foundation
and
so
forth.
I
guess
I
see.
A
A
F
Again,
I'm
just
trying
to
echoing
my
what
I
Drive
doubt
of
sentiment,
I
think
it
was
more
like
wasn't
no
chip,
something
like
that
was
pulled
in
and
and
there's
been
dependencies
on
it
and
when
something
goes
wrong
with
it.
There's
just
the
problems,
sit
there
and
continue
to
be
problems
that
people
complain
about
and
nobody
addresses
and,
and
so
it
just
becomes
more
more
management
of
things
that
are
just
being
brought
up
as
issues
and
never
addressed,
and
it
kind
of
a
negative
vibe
to
it.
E
E
A
E
E
In
my
opinion-
and
this
is
not
you
know
on
the
record
facts,
but
we
don't
like
we're
still
trying
to
figure
all
those
things
out
right,
like
so
expresses,
is
a
slightly
different
thing
than
a
version
manager
in
that
like
it
would
be
a
completely
tangential
thing
to
the
project
itself,
and
so
there
would
be
no
clear
way
that
we
could
say
hey.
You
know
this
has
its
own
governance.
E
It's
over
here
doing
its
own
thing,
but
it's
like
within
the
foundation,
because
we
don't
even
know
what
that
really
means,
or
at
least
I,
don't
and
maybe
William
and
people
on
the
tsc
or
the
board
may
have
a
better
idea
about
that.
But
as
far
as
I
know,
right
now
you
know
the
foundation
is
primarily
just
housing,
node
and
everything
that
falls
under
that
right
now.
You
know,
like
the
thing
that's
furthest
from
core
that
we
have
in.
E
There
is
maybe
like
our
build
infrastructure,
but
are
all
directly
serves
node
itself
and
the
release
of
node
and
the
maintenance
of
node.
So
I
think
that
unless
we
were
in
a
position
where
we
were
shipping,
a
version
manager
is
not
entirely
clear,
now,
I
think
a
version
manager.
At
the
same
time,
though,
is
probably
the
closest
thing
that
we've
had
that
is
expressed
interest
in
joining.
That
makes
sense,
but
but
but
it
still,
you
know,
could
fall
under
the
idea
of
a
tool
so
like.
A
E
F
Someone
touched
on
this
earlier,
I
think,
really
comes
into
this,
whether
it's
hold
it's
a
project,
that's
pulled
in
our
projects,
that's
created
under
node,
because
we
do
have
a
lot
of
tools
when
you
consider
some
of
the
things
we
have
for
post-mortem.
Something
to
that
effect.
You
know
that
people
are
working
on.
The
things
have
been
created,
started
under
node
and
and
they're
fine
they're,
not
disputed,
but
pulling
something
in
is
just
a
some
reason.
So
much
different
it.
F
Certainly
some
of
the
things
that
have
been
created
under
note
are
and
what
I'll
call
rotting
and-
and
so
it's
it's
kind
of
a
strange
thing.
I,
don't
really
know
the
right,
the
right
mentality
to
have
around
those
things,
but
for
some
reason
the
external
projects
have
bigger
trouble.
I
I
would,
like
you
know,
to
have
more
discussion
with
the
TSE
like
what
is
the
difference
here?
What
are
we
talking?
I
think
it
has
to
do
with
licensing.
Maybe
but
I.
Don't
know
that
for
sure.
F
A
A
B
I
think
licensing
is
not
that
big,
a
concern
I
think
concerns
are
like
existing
ecosystem
competition
and
also
like
just
general
responsibility
for
for
stuff
that
the
people
who
are
currently
doing
you
know
in
the
foundation
in
the
tsc.
Probably
don't
have
time
for
like
if
it
was
just
abandoned
and
I
guess
like
as
an
extension
of
that
like
we,
don't
really
want
to
become
like
a
place
where,
like
everything,
just
comes
and
sort
of
dies
so
work
that.
A
But
like,
if
that
were
to
happen,
all
you
would
have
to
do
is
say
this
project
needs
an
owner.
You
know
if
it
does
not
have
an
owner
within
X
period
of
time.
You
know
we'll
make
that
might
make
the
revo
private
or
I
don't
know
whatever
makes
sense
for
that
project
and
spin
it
off
to
someone
else
like
it
doesn't
have
to
stay
in
the
foundation
forever.
That's
it's
just
like
the
whole
purpose
of
the
vit
being.
A
There
is
because
it
should
thrive
there,
and
if
it's,
if
being
in
the
foundation,
is
somehow
worse
than
being
out,
then
it
shouldn't
be
in
there,
but
I,
don't
think
like
I,
don't
think
we
need
to
fear
a
project
dying
like
any
project
could
die.
No
chip
could
could
be
dead.
You
know
like
if
something
better
comes
along
or
whatever
you
know,
I
think
that's.
Okay,
I
think.
When
that
happens,
you
move
the
better
one
into
the
foundation
and
you
perhaps
move
the
worst
one
out.
C
C
Here,
as
far
as
looking
for
I
guess
examples
or
precedents,
you
know,
in
my
opinion,
I
kind
of
look
at
the
w3c
a
little
bit
as
a
potential
example
for
where
the
node
foundation
could
go
or
where
we
could
go
as
well
and
that's
again
focuses
back
on
the
whole
point
of
standards.
But
the
point
is
that
if
there
is
concern
about
project
or
something
that
is
going
to
die
or
is
dead
or
whatever
the
kids
going
to
be,
the
standard
can
still
live
on,
and
that's
not
something
that
necessarily
needs
to
be.
C
A
Yeah
I
mean
I
agree:
a
standard
will
and
should
live
longer
than
the
projects
that
implemented
yeah,
I,
guess,
yeah,
there's,
yeah,
okay,
I
think
we'll
need
to
have
more
chats
with
the
tsc
or
whichever
to
clarify
those
concerns
over
time
as
well.
Okay,
what
we're
just
about
out
of
time
I
think.
Maybe
we
should
do
another
call
in
a
couple
weeks,
just
a
touch
base,
but
will
probably
wait
to
schedule
that
until
there's
new
developments
there
any
thoughts
anyone
has
before
we
close
off.