<div dir="ltr">Hi,<br><div class="gmail_extra"><br><div class="gmail_quote">2016-07-12 11:06 GMT+02:00 Moritz Muehlenhoff <span dir="ltr"><<a href="mailto:jmm@debian.org" target="_blank">jmm@debian.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">On Tue, Apr 26, 2016 at 11:32:54PM +0200, Jérémy Lal wrote:<br>
> Update:<br>
> <a href="https://nodejs.org/en/blog/announcements/v6-release" rel="noreferrer" target="_blank">https://nodejs.org/en/blog/announcements/v6-release</a><br>
> """<br>
> In October 2016, Node.js v6 will become the LTS release and the LTS release<br>
> line (version 4)<br>
> will go under maintenance mode in April 2017, meaning only critical bugs,<br>
> critical security<br>
> fixes and documentation updates will be permitted.<br>
> Users should begin transitioning from v4 to v6 in October when v6 goes into<br>
> LTS.<br>
> """<br>
><br>
> I guess it will be too late for next debian release - still, it's good to<br>
> know.<br>
<br>
With the delayed freeze for jessie that would be doable again, right?<br>
The nodejs LTS is more volatile than a traditional LTS (also including<br>
bugfixes etc), but that seems ok (and is in line with e.g. security<br>
support for Firefox ESR).<br>
<br>
If we include nodejs 6 with security support in jessie we would limit<br>
it to the lifetime of that LTS branch. Is is already known how long<br>
that will be?<br></blockquote><div><br></div><div>The schedule [here](<a href="https://github.com/nodejs/LTS">https://github.com/nodejs/LTS</a>) states 2019-04-01</div><div>for the end of LTS 6 branch.</div><div><br></div><div>I can testify, being a heavy Node.js developer / user, that nodejs 6 can</div><div>already replace nodejs 4. There are no huge breaking changes and all</div><div>mainstream modules are now compatible with both versions.</div><div>The situation with v8 api is also much better - it shows deprecations</div><div>warnings now (can you believe that ?).</div><div>If time allows it, it will be best to do it.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
I'm also slightly concerned about you being the single maintainer of<br>
nodejs. Your updates in unstable have been really quick, but you'll<br>
be on vacation/sick/busy, so I'd be really great to have a fallback<br>
(not a blocker, though). Maybe a RFH on debian-devel would help?<br></blockquote><div><br></div><div>Well, Jonas is also helping when i can't do the job, and more help is welcome.</div><div><br></div><div>(For example I would very much like to use the source code of v8 shipped in</div><div>Node.js as *the* source for a libv8 package, thus taking advantage of the long</div><div>term support of nodejs, but i didn't find the time to do it.)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
While I'm fine with nodejs in stretch, I have strong concerns about the<br>
various node-* packages in the archive. It appears to me that the node<br>
modules ecosystem is very volatile and I have doubts that the various<br>
module upstreams will be able/willing to support the LTS branch of<br>
nodejs (or security backports in general). As of today we have<br>
already ten modules with unfixed security issues in unstable :-/</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
I think we can provide nodejs as a solid for server applications,<br>
but herding lots of poorly maintained node modules in a stable release<br>
is stretching our resources too thin. Also, I suppose everyone is<br>
used to npm anyway.<br></blockquote><div><br></div><div>It does indeed requires a lot of man power and we're obviously short of it.</div><div>I will happily ask to remove from testing many of the ones i uploaded myself;</div><div>however (besides other obvious precautions):</div><div>- some modules are very important to keep around (npm, node-gyp, node-nan,</div><div>node-uglify and their dependencies to name a few)</div><div>- debian is very good at packaging Node.js c++ addons (and many authors</div><div>of c++ addons do terrible things on install like distributing precompiled binaries,</div><div>downloading precompiled libraries...)</div><div><br></div><div> Jérémy</div><div><br></div></div></div></div>