Debian Nodejs Package Maintainer

[Rick Waldron]

Dearest Community, 

I'd like to ask you all to step up and do your part for a better Node.js ecosystem. The current maintainer of the Node.js Debian Package has decided that it's too burdensome and without sufficient merit to update the Debain Node.js from 0.6.x to 0.8.x. A Debian core committer reached out and asked for some input on this, so I posted to the bug explaining the waf-to-gyp change, which was met with a nasty response. I don't think I can be constructive at this point, so I'm asking for help.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=692312

Contributions to the bug/discussion should be emailed to: 692...@bugs.debian.org

Rick

[Bradley Meck]

writing

[kapouer]

Of course nodejs is going to be updated in debian, it's only a matter of time.

It is not small work to do, so you can help... or just wait, but don't hold your breath.

Instead of working i just spend two hours on that matter tonight. Will you give me

back those two hours by helping packaging nodejs in return ?

Jérémy.

[Rick Waldron]

On Mon, Jan 14, 2013 at 4:56 PM, kapouer <hol...@gmail.com> wrote:

Of course nodejs is going to be updated in debian, it's only a matter of time.

6 months?

 

--
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

[kapouer]

On Monday, January 14, 2013 11:01:31 PM UTC+1, Rick Waldron wrote:

On Mon, Jan 14, 2013 at 4:56 PM, kapouer <hol...@gmail.com> wrote:

Of course nodejs is going to be updated in debian, it's only a matter of time.

6 months?

You have no right to consider me as an asset.

 

[Rick Waldron]

What the hell are you talking about? 

I wanted to ignore your incredibly rude comment on the bug report: "Please ignore provocations like Rick Waldron does", but now it's clear that you've either grossly misunderstood my motivations or you're just being hostile. I was asked by Paul Tagliamonte, a Debian core developer, to help get that bug report "motivated"; I made a short and to the point post that identified one of many possible issues that holding back at 0.6 would cause and linked to the long form list of changes. How does this earn me the response I got from both Jonas and you? Jonas was hostile to everyone else and you just fed into it—real nice attitude. Instead of making nasty posts on a mailing list, why don't you give me a call and say it to me yourself? 857-540-9264. If I don't answer, just text me and I'll call you right back—I promise. If not, then piss off.

Rick

[Ben Noordhuis]

On Mon, Jan 14, 2013 at 10:56 PM, kapouer <hol...@gmail.com> wrote:
> Of course nodejs is going to be updated in debian, it's only a matter of
> time.
> It is not small work to do, so you can help... or just wait, but don't hold
> your breath.
> Instead of working i just spend two hours on that matter tonight. Will you
> give me
> back those two hours by helping packaging nodejs in return ?
>
> Jérémy.

The new stable, v0.10, is around the corner, probably end of this
month. You may want to consider skipping v0.8 altogether.

[Arunoda Susiripala]

Install binaries from nodejs.org or use a tool like nvm - https://github.com/creationix/nvm

Thats the best way to get update yourself.

--
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

--
Arunoda Susiripala

@arunoda

https://github.com/arunoda

http://www.linkedin.com/in/arunoda

[Chad Engler]

+1 for nvm, I got really tired of waiting for package updates in different distros.

 

-Chad

[Paul Tagliamonte]

On Tue, Jan 15, 2013 at 11:50:20AM -0500, Chad Engler wrote:
> +1 for nvm, I got really tired of waiting for package updates in different
> distros.

So, let me jump in this before it becomes a dogpile on Debian, which I
think is unfair, frankly.

I hate that Debian *unstable* is out of date -- no matter what. If not
(because of a big, important package), I'd expect it to find it's way
into Debian Experimental.

However -- remember, Debian isn't a "for developers" Distro, like, at
all. It's reputation is for *stability* -- think of it this way -- 99%
of the users of Debian (and downstreams, like Ubuntu, Knoppix, Mint,
etc) don't even know what their app is written in.

If you do production work, you know it *sucks* when your distro removes
something from under you -- and that's what stable branches are for.

It's our job (as Distro hackers) to keep things *stable*. The issue with
updating our Stable branch too quickly is that API breaks on core
packages (like Node) and all the apps using it break.

We don't package for developers :)

If we update all the apps to latest upstream all the time, what's the
point in a stable release? :)

So, to directly address this; that is expected. Developers can't be
expected to be happy with the default version of Python or Node or Ruby
in *any* production-worthy distro, because it's going to be (by virtue
of being tested) out of date.

That being said, I do think Node should be updated in Experimental
(since we're in freeze, we can't update testing / stable, so we need to
keep that path clear).

From a huge node fan,
Paul

>
>  
>
> -Chad
>
>  
>
> From: nod...@googlegroups.com [mailto:nod...@googlegroups.com] On Behalf
> Of Arunoda Susiripala
> Sent: Monday, January 14, 2013 10:49 PM
> To: nod...@googlegroups.com
> Subject: Re: [nodejs] Re: Debian Nodejs Package Maintainer
>
>  
>

> Install binaries from [1]nodejs.org or use a tool like nvm
> - [2]https://github.com/creationix/nvm

>
>  
>
> Thats the best way to get update yourself.
>

> On Tue, Jan 15, 2013 at 4:04 AM, Ben Noordhuis <[3]in...@bnoordhuis.nl>
> wrote:

>
> On Mon, Jan 14, 2013 at 10:56 PM, kapouer <[4]hol...@gmail.com> wrote:
> > Of course nodejs is going to be updated in debian, it's only a matter of
> > time.
> > It is not small work to do, so you can help... or just wait, but don't
> hold
> > your breath.
> > Instead of working i just spend two hours on that matter tonight. Will
> you
> > give me
> > back those two hours by helping packaging nodejs in return ?
> >
> > Jérémy.
>
> The new stable, v0.10, is around the corner, probably end of this
> month.  You may want to consider skipping v0.8 altogether.
>
> --

> Job Board: [5]http://jobs.nodejs.org/
> Posting guidelines:
> [6]https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines

> You received this message because you are subscribed to the Google
> Groups "nodejs" group.

> To post to this group, send email to [7]nod...@googlegroups.com

> To unsubscribe from this group, send email to

> [8]nodejs+un...@googlegroups.com

> For more options, visit this group at

> [9]http://groups.google.com/group/nodejs?hl=en?hl=en
>
>  
>
> --
> Arunoda Susiripala
>
>  
>
> [10]@arunoda
>
> [11]https://github.com/arunoda
>
> [12]http://www.linkedin.com/in/arunoda
>
> --
> Job Board: [13]http://jobs.nodejs.org/
> Posting guidelines:
> [14]https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines

> You received this message because you are subscribed to the Google
> Groups "nodejs" group.

> To post to this group, send email to [15]nod...@googlegroups.com

> To unsubscribe from this group, send email to

> [16]nodejs+un...@googlegroups.com

> For more options, visit this group at

> [17]http://groups.google.com/group/nodejs?hl=en?hl=en
>
> --
> Job Board: [18]http://jobs.nodejs.org/
> Posting guidelines:
> [19]https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines

> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to nod...@googlegroups.com
> To unsubscribe from this group, send email to
> nodejs+un...@googlegroups.com
> For more options, visit this group at

> [20]http://groups.google.com/group/nodejs?hl=en?hl=en
>
> References
>
> Visible links
> 1. http://nodejs.org/
> 2. https://github.com/creationix/nvm
> 3. mailto:in...@bnoordhuis.nl
> 4. mailto:hol...@gmail.com
> 5. http://jobs.nodejs.org/
> 6. https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> 7. mailto:nod...@googlegroups.com
> 8. mailto:nodejs%2Bunsu...@googlegroups.com
> 9. http://groups.google.com/group/nodejs?hl=en?hl=en
> 10. http://twitter.com/arunoda
> 11. https://github.com/arunoda
> 12. http://www.linkedin.com/in/arunoda
> 13. http://jobs.nodejs.org/
> 14. https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> 15. mailto:nod...@googlegroups.com
> 16. mailto:nodejs+un...@googlegroups.com
> 17. http://groups.google.com/group/nodejs?hl=en?hl=en
> 18. http://jobs.nodejs.org/
> 19. https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> 20. http://groups.google.com/group/nodejs?hl=en?hl=en
> WARNING: gnome-keyring:: couldn't connect to: /run/user/tag/keyring-pGYP3G/pkcs11: No such file or directory

--
.''`. Paul Tagliamonte <pau...@debian.org>
: :' : Proud Debian Developer
`. `'` 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87
`- http://people.debian.org/~paultag

[klr...@gmail.com]

takes about 10 minutes including a quick test run on debian wheezy, doesn't make much sense waiting for a package update with a fast moving young item like node, stable node releases are great. You can't roll a complex deb package just like that. Otherwise hats off to Debian folks for a super stable platform, Karl

[Chad Engler]

Just to clarify I wasn't knocking any distro; I was giving props to nvm for being awesome. I agree with you Paul, which is why I use nvm for all my node needs.

-Chad

[klr...@gmail.com]

+1

>    8. mailto:nodejs%2Bu...@googlegroups.com

[Wil Moore]

So, to directly address this; that is expected. Developers can't be expected to be happy with the default version of Python or Node or Ruby 

in *any* production-worthy distro, because it's going to be (by virtue of being tested) out of date.

FWIW, I believe this is the right way to think and this is exactly what version managers are built to address from the developer's perspective. As a developer, I am typically not interesting in the shipped version of LanguageX is shipping with OperatingSystemY. For example, the system ruby in OSX...don't screw with it. It should be left in-tact for system-level work or shelling out from some cocoa app or what-have-you.

Develop with a version manager, deploy with a CM (Chef, Puppet, CFEngine, etc.), rinse, repeat.

[Mikeal Rogers]

There seems to be a slight miss-match between Debian process and node process that I'd like to flush out.

First off, node is unstable until it hits 1.0, period. All node releases, especially old ones, are unstable.

Node is not Ruby or Python and shouldn't be treated as such in Debian. Debian should not allow packages to be added that "depend" on node, ever. This is a big departure from what you're probably used to with Ruby and Python but this is "how things work" w/ node and it would be better for Debian to accept that rather than compete with it.

Node 0.8 is more stable than 0.6 by any definition of "stable." The definition of stability you are citing, which is based Ruby/Python/Perl, that packages which depend on a particular version can't be updated frivolously, should not exist because Debian should not allow a program to be added to the package manager that depends on node.

It is node and npm's responsibility to install node programs, resolve dependencies, and not allow you to upgrade or install packages against versions of node that won't work. This is **our** job, and we're pretty good at it, so please don't try to create a parallel system with differing semantics that solves the same problem.

I understand the sentiment from some of the Debian maintainers that we're throwing work at them. We can stop doing that if you give the node project responsibility for a task we've already accepted and are actually quite good at (managing dependencies and programs related to different versions of node) and it would be even better if you could take "stable" and "experimental" releases that *we* define as experimental and stable.

Thanks
-Mikeal

[Paul Tagliamonte]

On Wed, Jan 16, 2013 at 12:42:32PM -0800, Mikeal Rogers wrote:
> There seems to be a slight miss-match between Debian process and node process that I'd like to flush out.
>
> First off, node is unstable until it hits 1.0, period. All node releases, especially old ones, are unstable.
>
> Node is not Ruby or Python and shouldn't be treated as such in Debian. Debian should not allow packages to be added that "depend" on node, ever. This is a big departure from what you're probably used to with Ruby and Python but this is "how things work" w/ node and it would be better for Debian to accept that rather than compete with it.

So, you're saying we shouldn't allow apps like TileMill onto end users
computers? Why?

>
> Node 0.8 is more stable than 0.6 by any definition of "stable." The definition of stability you are citing, which is based Ruby/Python/Perl, that packages which depend on a particular version can't be updated frivolously, should not exist because Debian should not allow a program to be added to the package manager that depends on node.
>
> It is node and npm's responsibility to install node programs, resolve dependencies, and not allow you to upgrade or install packages against versions of node that won't work. This is **our** job, and we're pretty good at it, so please don't try to create a parallel system with differing semantics that solves the same problem.

I'd say the same thing about NPM with regards to dpkg. We were here
first, why didn't you integrate? (You see, it's a silly argument)

in fact, most casual users won't even know NPM exists, all their software
is handled by dpkg, and fiddling around with something like that isn't
fun if all they want is something, like, say, tilemill.

>
> I understand the sentiment from some of the Debian maintainers that we're throwing work at them. We can stop doing that if you give the node project responsibility for a task we've already accepted and are actually quite good at (managing dependencies and programs related to different versions of node) and it would be even better if you could take "stable" and "experimental" releases that *we* define as experimental and stable.

Letting another package manager install files into the filesystem
globally outside the archive is a bit insane. Not to mention NPM is
insecure (anyone can upload, no review), and has no means to run
post/pre install hook to aid in configuring software.

The idea behind an archive is that you can install whatever you want and
it won't break your machine.

Annyway, this is going to lead to a flame-war. I don't really want to
deal with another one of these chats.

Fondly,
Paul

> --
> Job Board: http://jobs.nodejs.org/

> Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines

> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to nod...@googlegroups.com
> To unsubscribe from this group, send email to
> nodejs+un...@googlegroups.com
> For more options, visit this group at

> http://groups.google.com/group/nodejs?hl=en?hl=en

[Mikeal Rogers]

On Jan 16, 2013, at January 16, 201312:48 PM, Paul Tagliamonte <pau...@debian.org> wrote:

> On Wed, Jan 16, 2013 at 12:42:32PM -0800, Mikeal Rogers wrote:
>> There seems to be a slight miss-match between Debian process and node process that I'd like to flush out.
>>
>> First off, node is unstable until it hits 1.0, period. All node releases, especially old ones, are unstable.
>>
>> Node is not Ruby or Python and shouldn't be treated as such in Debian. Debian should not allow packages to be added that "depend" on node, ever. This is a big departure from what you're probably used to with Ruby and Python but this is "how things work" w/ node and it would be better for Debian to accept that rather than compete with it.
>
> So, you're saying we shouldn't allow apps like TileMill onto end users
> computers? Why?

I should clarify, Debian should not allow *node* packages to be added that depend on node.

TileMill requires MapBox which requires Node 0.6 or greater. It then uses npm to install all the dependent npm modules. TileMill has the ability to require a particular version of node via whatever build system it's targetted for, including Debian, but notice that it does *not* using any of those system to install node packages, it uses npm. TileMill is using the OS package manager to get node, and that's it.

By requiring an older "stable" version of node you're incentivizing people to target old versions of node, which are unstable and no longer supported. I'll tell you right now, any package that you say is "stable" in the Debian package manager that needs 0.6 and fails on 0.8 is an immensely unstable piece of software and shouldn't be included in your Debian "stable" branch :)

>
>>
>> Node 0.8 is more stable than 0.6 by any definition of "stable." The definition of stability you are citing, which is based Ruby/Python/Perl, that packages which depend on a particular version can't be updated frivolously, should not exist because Debian should not allow a program to be added to the package manager that depends on node.
>>
>> It is node and npm's responsibility to install node programs, resolve dependencies, and not allow you to upgrade or install packages against versions of node that won't work. This is **our** job, and we're pretty good at it, so please don't try to create a parallel system with differing semantics that solves the same problem.
>
> I'd say the same thing about NPM with regards to dpkg. We were here
> first, why didn't you integrate? (You see, it's a silly argument)
>
> in fact, most casual users won't even know NPM exists, all their software
> is handled by dpkg, and fiddling around with something like that isn't
> fun if all they want is something, like, say, tilemill.

I think I covered this misunderstanding above but if i did not I can elaborate.

>
>>
>> I understand the sentiment from some of the Debian maintainers that we're throwing work at them. We can stop doing that if you give the node project responsibility for a task we've already accepted and are actually quite good at (managing dependencies and programs related to different versions of node) and it would be even better if you could take "stable" and "experimental" releases that *we* define as experimental and stable.
>
> Letting another package manager install files into the filesystem
> globally outside the archive is a bit insane. Not to mention NPM is
> insecure (anyone can upload, no review), and has no means to run
> post/pre install hook to aid in configuring software.

npm doesn't install packages globally, we do everything locally.

and yes, everyone can upload, because we give the maintainers of packages authority over them instead of having a handful of people determining the stability of over 20K modules.

we have post/pre install hooks.

>
> The idea behind an archive is that you can install whatever you want and
> it won't break your machine.
> Annyway, this is going to lead to a flame-war. I don't really want to
> deal with another one of these chats.

It's not my intention to be incendiary. My point is this:

- The node community has taken full responsibility for package management within node.
- The node community is who should define the standards for node packages, node releases, and varying notions of "stability" and not operating system maintainers. If this doesn't match what a user thinks is appropriate then they should not use node, they cannot resolve this by relying on Debian.

I'm asking that you transfer this responsibility to us within Debian. If you don't then you're basically forking the project because this is a central part of the node project. That's fine, people fork all the time, but we'll have to acknowledge it as such and reduce the level of involvement and support we're trying to push in to Debian.

[kapouer]

No (bad) sentiment at all towards Node's developers here.

Eventually Node will stabilize and debian packages will catch up,

it's a common pattern with distributions.

By the way, "nodejs" package won't be in next debian release,

meaning the 0.6 version will fade out gracefully. Same goes for npm,

and all other modules.

Jérémy.

>>   8. mailto:nodejs%2Bu...@googlegroups.com

[Paul Tagliamonte]

On Wed, Jan 16, 2013 at 01:09:03PM -0800, Mikeal Rogers wrote:
>
> On Jan 16, 2013, at January 16, 201312:48 PM, Paul Tagliamonte <pau...@debian.org> wrote:
>
> > On Wed, Jan 16, 2013 at 12:42:32PM -0800, Mikeal Rogers wrote:
> >> There seems to be a slight miss-match between Debian process and node process that I'd like to flush out.
> >>
> >> First off, node is unstable until it hits 1.0, period. All node releases, especially old ones, are unstable.
> >>
> >> Node is not Ruby or Python and shouldn't be treated as such in Debian. Debian should not allow packages to be added that "depend" on node, ever. This is a big departure from what you're probably used to with Ruby and Python but this is "how things work" w/ node and it would be better for Debian to accept that rather than compete with it.
> >
> > So, you're saying we shouldn't allow apps like TileMill onto end users
> > computers? Why?
>
> I should clarify, Debian should not allow *node* packages to be added that depend on node.

How can we fill the deps without them being tracked too?

>
> TileMill requires MapBox which requires Node 0.6 or greater. It then uses npm to install all the dependent npm modules. TileMill has the ability to require a particular version of node via whatever build system it's targetted for, including Debian, but notice that it does *not* using any of those system to install node packages, it uses npm. TileMill is using the OS package manager to get node, and that's it.
>
> By requiring an older "stable" version of node you're incentivizing people to target old versions of node, which are unstable and no longer supported. I'll tell you right now, any package that you say is "stable" in the Debian package manager that needs 0.6 and fails on 0.8 is an immensely unstable piece of software and shouldn't be included in your Debian "stable" branch :)

While I agree totally (I was the one who wanted to see this changed in
the first place, I think you and I agree very much) with regards to what
we aught to be shipping in stable, the issue is, 0.6 was released in our
freeze, far too late for a breaking upstream.

The idea here is that our packages are *stable*. If we upgrade node, we
have to upgrade all our apps and libs, which leads to big changes, which
leads to instability, which leads to bugs.

As you are no doubt aware, Debian releases when bugs hit 0, not on a
timer.

>
> >
> >>
> >> Node 0.8 is more stable than 0.6 by any definition of "stable." The definition of stability you are citing, which is based Ruby/Python/Perl, that packages which depend on a particular version can't be updated frivolously, should not exist because Debian should not allow a program to be added to the package manager that depends on node.
> >>
> >> It is node and npm's responsibility to install node programs, resolve dependencies, and not allow you to upgrade or install packages against versions of node that won't work. This is **our** job, and we're pretty good at it, so please don't try to create a parallel system with differing semantics that solves the same problem.
> >
> > I'd say the same thing about NPM with regards to dpkg. We were here
> > first, why didn't you integrate? (You see, it's a silly argument)
> >
> > in fact, most casual users won't even know NPM exists, all their software
> > is handled by dpkg, and fiddling around with something like that isn't
> > fun if all they want is something, like, say, tilemill.
>
> I think I covered this misunderstanding above but if i did not I can elaborate.
>
> >
> >>
> >> I understand the sentiment from some of the Debian maintainers that we're throwing work at them. We can stop doing that if you give the node project responsibility for a task we've already accepted and are actually quite good at (managing dependencies and programs related to different versions of node) and it would be even better if you could take "stable" and "experimental" releases that *we* define as experimental and stable.
> >
> > Letting another package manager install files into the filesystem
> > globally outside the archive is a bit insane. Not to mention NPM is
> > insecure (anyone can upload, no review), and has no means to run
> > post/pre install hook to aid in configuring software.
>
> npm doesn't install packages globally, we do everything locally.

I'm aware of this -- but it's not very easy to do that when an app is
installed globally. Users need not be aware of the workings, or even
that it's a node app.

>
> and yes, everyone can upload, because we give the maintainers of packages authority over them instead of having a handful of people determining the stability of over 20K modules.

We review incoming packages for code quality (find big issues, security
issues, etc), licensing (for instance, we don't allow CC-BY-NC or other
non-free licenses in Debian main), so people running Debian can be sure
there are no serious problems. Lacking this is a deal-breaker for a lot
of people.

>
> we have post/pre install hooks.

Ah, I didn't know that. I'd be a bit skeeved if random code was running
on my server in my SQL DB to set up tables. I take back what I said, but
still assert the point above.

>
> >
> > The idea behind an archive is that you can install whatever you want and
> > it won't break your machine.
> > Annyway, this is going to lead to a flame-war. I don't really want to
> > deal with another one of these chats.
>
> It's not my intention to be incendiary. My point is this:

I hoped not. I saw you work on gather.at. I'm a fan, and I'd have hated
to see bad blood.

Most certenly because your server runs Debian Squeeze.

>
> - The node community has taken full responsibility for package management within node.
> - The node community is who should define the standards for node packages, node releases, and varying notions of "stability" and not operating system maintainers. If this doesn't match what a user thinks is appropriate then they should not use node, they cannot resolve this by relying on Debian.

The standards are a legal risk (and security risk) to Debian standards
in some cases. For instance the "JSON" license (do no evil) is
considered non-free and we don't ship it.

Having code depend on non-free software doens't help much.

>
> I'm asking that you transfer this responsibility to us within Debian. If you don't then you're basically forking the project because this is a central part of the node project. That's fine, people fork all the time, but we'll have to acknowledge it as such and reduce the level of involvement and support we're trying to push in to Debian.

If you're willing to contribute to Debian, please do! I'd be willing to
help you get started. I'd be nice to get Node upstream involved, just
like most of the other languages.

Heck, you'd even be making sure gather.at stays up and running :)

Cheery-bye,
Paul

[Mikeal Rogers]

On Jan 16, 2013, at January 16, 20131:20 PM, Paul Tagliamonte <pau...@debian.org> wrote:

> On Wed, Jan 16, 2013 at 01:09:03PM -0800, Mikeal Rogers wrote:
>>
>> On Jan 16, 2013, at January 16, 201312:48 PM, Paul Tagliamonte <pau...@debian.org> wrote:
>>
>>> On Wed, Jan 16, 2013 at 12:42:32PM -0800, Mikeal Rogers wrote:
>>>> There seems to be a slight miss-match between Debian process and node process that I'd like to flush out.
>>>>
>>>> First off, node is unstable until it hits 1.0, period. All node releases, especially old ones, are unstable.
>>>>
>>>> Node is not Ruby or Python and shouldn't be treated as such in Debian. Debian should not allow packages to be added that "depend" on node, ever. This is a big departure from what you're probably used to with Ruby and Python but this is "how things work" w/ node and it would be better for Debian to accept that rather than compete with it.
>>>
>>> So, you're saying we shouldn't allow apps like TileMill onto end users
>>> computers? Why?
>>
>> I should clarify, Debian should not allow *node* packages to be added that depend on node.
>
> How can we fill the deps without them being tracked too?

Don't :)

This is my point, and it's actually how TileMill/MapBox works currently.

>
>>
>> TileMill requires MapBox which requires Node 0.6 or greater. It then uses npm to install all the dependent npm modules. TileMill has the ability to require a particular version of node via whatever build system it's targetted for, including Debian, but notice that it does *not* using any of those system to install node packages, it uses npm. TileMill is using the OS package manager to get node, and that's it.
>>
>> By requiring an older "stable" version of node you're incentivizing people to target old versions of node, which are unstable and no longer supported. I'll tell you right now, any package that you say is "stable" in the Debian package manager that needs 0.6 and fails on 0.8 is an immensely unstable piece of software and shouldn't be included in your Debian "stable" branch :)
>
> While I agree totally (I was the one who wanted to see this changed in
> the first place, I think you and I agree very much) with regards to what
> we aught to be shipping in stable, the issue is, 0.6 was released in our
> freeze, far too late for a breaking upstream.
>
> The idea here is that our packages are *stable*. If we upgrade node, we
> have to upgrade all our apps and libs, which leads to big changes, which
> leads to instability, which leads to bugs.
>
> As you are no doubt aware, Debian releases when bugs hit 0, not on a
> timer.

IMO, any node packages that requires pre-0.8 (before we guaranteed much compatibility between releases) is not stable software because node was not stable and you shouldn't include in a Debian release. Even 0.8 might is ify. I'm saying this as a node diehard: if you really mean stable then node programs 0.6 and before *aren't*.

Honestly, the thing I'm worried about more than these 0.6 -> 0.8 -> 0.10 issues are what happens when we get to 1.0. After the node.js 1.0 release we will not break compatibility again until 2.0, and probably won't even then. We won't change or add *any* API in that time and we'll be even more serious about testing each release than we are now (and we're pretty serious now). At that point Debian should take all even 1.x releases because they will solely be stability, security, performance, and bug fixes and will not break any programs that relied on earlier 1.x releases.

>
>>
>>>
>>>>
>>>> Node 0.8 is more stable than 0.6 by any definition of "stable." The definition of stability you are citing, which is based Ruby/Python/Perl, that packages which depend on a particular version can't be updated frivolously, should not exist because Debian should not allow a program to be added to the package manager that depends on node.
>>>>
>>>> It is node and npm's responsibility to install node programs, resolve dependencies, and not allow you to upgrade or install packages against versions of node that won't work. This is **our** job, and we're pretty good at it, so please don't try to create a parallel system with differing semantics that solves the same problem.
>>>
>>> I'd say the same thing about NPM with regards to dpkg. We were here
>>> first, why didn't you integrate? (You see, it's a silly argument)
>>>
>>> in fact, most casual users won't even know NPM exists, all their software
>>> is handled by dpkg, and fiddling around with something like that isn't
>>> fun if all they want is something, like, say, tilemill.
>>
>> I think I covered this misunderstanding above but if i did not I can elaborate.
>>
>>>
>>>>
>>>> I understand the sentiment from some of the Debian maintainers that we're throwing work at them. We can stop doing that if you give the node project responsibility for a task we've already accepted and are actually quite good at (managing dependencies and programs related to different versions of node) and it would be even better if you could take "stable" and "experimental" releases that *we* define as experimental and stable.
>>>
>>> Letting another package manager install files into the filesystem
>>> globally outside the archive is a bit insane. Not to mention NPM is
>>> insecure (anyone can upload, no review), and has no means to run
>>> post/pre install hook to aid in configuring software.
>>
>> npm doesn't install packages globally, we do everything locally.
>
> I'm aware of this -- but it's not very easy to do that when an app is
> installed globally. Users need not be aware of the workings, or even
> that it's a node app.

If the app is installed globally then we'll install "local" to the directory it is in and we won't break out of it, as you probably know. The risk that we will effect any other software is closer to zero than the risk that package might effect other software when you run it.

>
>>
>> and yes, everyone can upload, because we give the maintainers of packages authority over them instead of having a handful of people determining the stability of over 20K modules.
>
> We review incoming packages for code quality (find big issues, security
> issues, etc), licensing (for instance, we don't allow CC-BY-NC or other
> non-free licenses in Debian main), so people running Debian can be sure
> there are no serious problems. Lacking this is a deal-breaker for a lot
> of people.

If those things are deal-breakers then they really shouldn't use node programs. As you can see, people are already using and will continue to use npm after Debian installs them to pull in node packages so in the case of node programs you're giving them a false assurance

>
>>
>> we have post/pre install hooks.
>
> Ah, I didn't know that. I'd be a bit skeeved if random code was running
> on my server in my SQL DB to set up tables. I take back what I said, but
> still assert the point above.

we're still iterating on these, they were mostly used for compiled deps but now we have better support for that and it's unclear if we should still have these or not. this is a question for isaacs for sure.

>
>>
>>>
>>> The idea behind an archive is that you can install whatever you want and
>>> it won't break your machine.
>>> Annyway, this is going to lead to a flame-war. I don't really want to
>>> deal with another one of these chats.
>>
>> It's not my intention to be incendiary. My point is this:
>
> I hoped not. I saw you work on gather.at. I'm a fan, and I'd have hated
> to see bad blood.
>
> Most certenly because your server runs Debian Squeeze.

This might interest you then:

This is our system setup and deploy process:

- new server is provisioned by softlayer
- we do a pkg install for openssl git and upstart
- we install node from source
- we git checkout our product
- we add a few upstart scripts

All of gather, including the deployment stuff, is all node and we manage that with npm. We check our dependencies in to git in order to lock them more thoroughly and for ease of deployment we don't use any compiled dependencies (you'll notice our server setup doesn't require an npm install because all the packages are already locally checked in to git and don't need to being "installed", but we do use npm to update and install locally and then we test before checkin)

As far as our application is concerned, we're responsible for the stability of our product and all of it's dependencies, not the operating system. We use the OS package manager to keep the OS secure and up to date and we don't consider node part of that equation.

If we could create a package that included the node binary and all of our app code to push for deployment like Go can do, we would.

>
>>
>> - The node community has taken full responsibility for package management within node.
>> - The node community is who should define the standards for node packages, node releases, and varying notions of "stability" and not operating system maintainers. If this doesn't match what a user thinks is appropriate then they should not use node, they cannot resolve this by relying on Debian.
>
> The standards are a legal risk (and security risk) to Debian standards
> in some cases. For instance the "JSON" license (do no evil) is
> considered non-free and we don't ship it.
>
> Having code depend on non-free software doens't help much.

I think i covered this above, but so long as people use npm to install their deps after they do a Debian package install of their application your legal guarantees are invalidated. This leaves you with two options I can think of:

1) don't give these legal guarantees to node programs
2) fork and maintain 20K and counting npm packages.

TileMill uses npm to pull in its deps, those dependencies aren't tracked by Debian and could include proprietary software and you wouldn't know it.

>
>>
>> I'm asking that you transfer this responsibility to us within Debian. If you don't then you're basically forking the project because this is a central part of the node project. That's fine, people fork all the time, but we'll have to acknowledge it as such and reduce the level of involvement and support we're trying to push in to Debian.
>
> If you're willing to contribute to Debian, please do! I'd be willing to
> help you get started. I'd be nice to get Node upstream involved, just
> like most of the other languages.

I think that myself and a lot of other people are open to that but you need to keep in mind that we have our own community and that community has its own set of common standards. It would be unreasonable for us to change the community standards of node to fit another, whether it's Debian or RHEL or Ubuntu or Microsoft.

Being that there are some mismatches between these community standards (licensing being a central one) I think it's more productive for Debian to acknowledge them and surface that to Debian users rather than to think that node programs will ever be able to fit within the standards you're trying to uphold.

>
> Heck, you'd even be making sure gather.at stays up and running :)

Thanks, and I'm glad you like our product :)

[Paul Tagliamonte]

http://wiki.debian.org/Javascript/Policy

http://wiki.debian.org/Javascript

http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel

You're welcome to help contribute!

> --
> Job Board: http://jobs.nodejs.org/

> Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines

> You received this message because you are subscribed to the Google
> Groups "nodejs" group.

> To post to this group, send email to nod...@googlegroups.com

> To unsubscribe from this group, send email to

> nodejs+un...@googlegroups.com
> For more options, visit this group at

> http://groups.google.com/group/nodejs?hl=en?hl=en

[Arunoda Susiripala]

Hi,

What we should realize is node is not stable yet. And what we say stable is not the stable meant by other systems (like python, ruby)

Its is the 100 responsibility of the developer/maintainers of the app to take care about the node version they need and get it installed on the system. 

This is not a big problem in any server side app since developers and dev ops guys have the full control. 

If we talk about desktop apps, we have to ship an app runs on thousands of computers. And those users are not aware of node and npm. And they never need to know about them.

Then the developer/maintainer must ensure when his app gets the correct node version rather depend on the underline system. This is true for at least we hit 1.0

If I were asked to ship any app to debian this is what I do

1. I may ship node binaries with your app (and it should not crash the system's node too)

2. If I feel it is too big (~5MB), then I will download node in the first run of the app

Cheers.

> >>>> It is node and npm's responsibility to install node programs, resolve dependencies, and not allhttp://wiki.debian.org/Javascript/Policy

[Isaac Schlueter]

On Wed, Jan 16, 2013 at 1:49 PM, Mikeal Rogers <mikeal...@gmail.com> wrote:
> After the node.js 1.0 release we will not break compatibility again until 2.0, and probably won't even then. We won't change or add *any* API in that time and we'll be even more serious about testing each release than we are now (and we're pretty serious now). At that point Debian should take all even 1.x releases because they will solely be stability, security, performance, and bug fixes and will not break any programs that relied on earlier 1.x releases.

That's not strictly true. What will happen is that the stability
indexes in the documentation will become somewhat more binding, and
we'll have gotten to a higher degree of stability across the board by
then.

We may break APIs marked as "Deprecated". We may change the API
surface (and perhaps even the semantics) of APIs marked as
"Experimental". APIs marked as "Unstable" are unlikely to change.
APIs marked as "Stable" will not change if unless absolutely necessary
to fix serious bugs. APIs marked as "API Frozen" or "Frozen" will not
change.

The ABI will be consistent within even-numbered minor releases, just
as it is now, but might change when you jump to a new minor release
family.

Node itself (ie, the JavaScript and binding layers) is effectively at
a "1.0" level of stability with version 0.10. However, libuv is not
there yet. It's much younger than Node, and is still changing.
Changes in libuv involve changes in Node, so as much as we'd like to
keep things stable, we can't really promise that yet.

When libuv hits roughly the level of stability that Node is at now,
then that'll be Node 1.0. It's sort of a fuzzy goal, but I expect
that to be later this year. My best guess is that either 0.12 will be
1.0, or it'll be the next one after 0.12.