On Wed, Jan 16, 2013 at 01:49:04PM -0800, Mikeal Rogers wrote: > > On Jan 16, 2013, at January 16, 20131:20 PM, Paul Tagliamonte > <[email protected]> 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 > >> <[email protected]> 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.
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! > > 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 :) > > > > >> > >>> > >>> Fondly, > >>> Paul > >>> > >>>> > >>>> Thanks > >>>> -Mikeal > >>>> > >>>> On Jan 15, 2013, at January 15, 20138:57 AM, Paul Tagliamonte > >>>> <[email protected]> wrote: > >>>> > >>>>> 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: [email protected] [mailto:[email protected]] On > >>>>>> Behalf > >>>>>> Of Arunoda Susiripala > >>>>>> Sent: Monday, January 14, 2013 10:49 PM > >>>>>> To: [email protected] > >>>>>> 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][email protected]> > >>>>>> wrote: > >>>>>> > >>>>>> On Mon, Jan 14, 2013 at 10:56 PM, kapouer <[4][email protected]> 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][email protected] > >>>>>> To unsubscribe from this group, send email to > >>>>>> [8][email protected] > >>>>>> For more options, visit this group at > >>>>>> [9]http://groups.google.com/group/nodejs?hl=en?hl=en > >>>>>> > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> Arunoda Susiripala > >>>>>> > >>>>>> > >>>>>> > >>>>>> [10]@arunoda > >>>>>> > > > > Cheery-bye, > > Paul > > > > -- > > .''`. Paul Tagliamonte <[email protected]> > > : :' : Proud Debian Developer > > `. `'` 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 > > `- http://people.debian.org/~paultag > > -- > 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 [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/nodejs?hl=en?hl=en -- .''`. Paul Tagliamonte <[email protected]> : :' : Proud Debian Developer `. `'` 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `- http://people.debian.org/~paultag
signature.asc
Description: Digital signature
