Sorry for the late reply, going through some backlog.
On Tue, Jul 12, 2016 at 10:17:23PM +0200, Jérémy Lal wrote:
> 2016-07-12 11:06 GMT+02:00 Moritz Muehlenhoff <j...@debian.org>:
> > On Tue, Apr 26, 2016 at 11:32:54PM +0200, Jérémy Lal wrote:
> > > Update:
> > > https://nodejs.org/en/blog/announcements/v6-release
> > > """
> > > In October 2016, Node.js v6 will become the LTS release and the LTS
> > release
> > > line (version 4)
> > > will go under maintenance mode in April 2017, meaning only critical bugs,
> > > critical security
> > > fixes and documentation updates will be permitted.
> > > Users should begin transitioning from v4 to v6 in October when v6 goes
> > into
> > > LTS.
> > > """
> > >
> > > I guess it will be too late for next debian release - still, it's good to
> > > know.
> > With the delayed freeze for jessie that would be doable again, right?
> > The nodejs LTS is more volatile than a traditional LTS (also including
> > bugfixes etc), but that seems ok (and is in line with e.g. security
> > support for Firefox ESR).
> > If we include nodejs 6 with security support in jessie we would limit
> > it to the lifetime of that LTS branch. Is is already known how long
> > that will be?
> The schedule [here](https://github.com/nodejs/LTS) states 2019-04-01
> for the end of LTS 6 branch.
Ok, we should limit the security support to that timeframe, then (or
maybe slightly longer until the next release with a little overlap to
stretch+1, but not to the full lifetime of a stable release.
What are your plans for making the switch in sid/testing?
> (For example I would very much like to use the source code of v8 shipped in
> Node.js as *the* source for a libv8 package, thus taking advantage of the
> term support of nodejs, but i didn't find the time to do it.)
Ok, otherwise the standalone copy in the archive will remain uncovered
by security support as in jessie.
> > While I'm fine with nodejs in stretch, I have strong concerns about the
> > various node-* packages in the archive. It appears to me that the node
> > modules ecosystem is very volatile and I have doubts that the various
> > module upstreams will be able/willing to support the LTS branch of
> > nodejs (or security backports in general). As of today we have
> > already ten modules with unfixed security issues in unstable :-/
> > I think we can provide nodejs as a solid for server applications,
> > but herding lots of poorly maintained node modules in a stable release
> > is stretching our resources too thin. Also, I suppose everyone is
> > used to npm anyway.
> It does indeed requires a lot of man power and we're obviously short of it.
> I will happily ask to remove from testing many of the ones i uploaded
> however (besides other obvious precautions):
> - some modules are very important to keep around (npm, node-gyp, node-nan,
> node-uglify and their dependencies to name a few)
> - debian is very good at packaging Node.js c++ addons (and many authors
> of c++ addons do terrible things on install like distributing precompiled
> downloading precompiled libraries...)
Can you (or anyone else from the nodejs team) compile a list of packages
to keep in stretch, so that the remainders can be dropped when we get
closer to the freeze?