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. 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
