nodejs May 2016

nodejs@lists.fedoraproject.org

4 participants
3 discussions

Source0 for nodejs modules
by Piotr Popieluch 03 Dec '18

03 Dec '18

The the Node.js guidelines say about Source0 [1]: "The canonical method for shipping most node modules is tarballs from the npm registry" and "This method [PP: tarbals from npm] should be preferred to using checkouts from git or automatically generated tarballs from GitHub." But I think that in following cases it would be better to use sources from the upstream project: 1) When the license is not included in NPM but is in upstream project. o Because we are not supposed to ship the license separate from the sources. 2) When the tests are not included. o In this case we need to download the sources from NPM and from upstream project, which seems redundant and a waste of work. 3) When NPM content is generated and source files are not in NPM. o This would mean to download sources from NPM and upstream project, delete the NPM sources in prep and generate the files again. Are there good reason to enforce the use of NPM sources which I am missing? What is your opinion? I would like to suggest to ad those three exceptions to the guidelines. Piotr [1]: https://fedoraproject.org/wiki/Packaging:Node.js?rd=Node.js/Packagers#Using…

4 5

Plans for Node.js 6.x
by Stephen Gallagher 18 Jul '16

18 Jul '16

OK folks, it's Bad Decision Time. Today, Node.js 6.0 was released. This is a significant ABI-breaking release, which means there is no guarantee that existing modules will work with it at all.[1] Better still, Node.js 5.x is only going to be supported until sometime this summer, because they're aiming for the 6.x branch to become the new LTS in October[2]. This puts us in quite a bind. Fedora disallows major ABI changes in a stable release, so if Fedora 24 Final ships with Node.js 5.x, we will be stuck with maintaining it until Fedora 24 EOL (which is probably going to mean until approximately June 2017, or almost a full year after upstream drops support). This means manually backporting any security issues that come up without the benefit of a new version to rebase to and with an increasing likelihood of the patches diverging from upstream. On the flip side, the major ABI break is hitting us post-Beta Freeze for Fedora 24, which is a really terrible time to be switching to a new major version of a language runtime (particularly since we don't actually know if any of the other packages on the system will work with it at all). We don't have any particularly good options here. A downgrade back to 4.x (which will be supported until at least April 2018, well past F24 EOL) would be very difficult at this point, since node modules may have updated to newer, incompatible versions. Furthermore, this came at a time where I was planning to write to the nodejs list and let people know that due to my changing work responsibilities, I'm not going to be able to be the primary maintainer of the main package any longer. (I'd be able to swing the occasional minor- or point-release update, but wrangling a major release won't be possible.) I realize this is inopportune, but it's best if we figure out *immediately* how we're going to handle this. Options: 1) Downgrade back to 4.x, downgrading or dropping any modules in the collection that don't run on that LTS version. 2) Stick with 5.x for the life of Fedora 24, handling security backports ourselves once it hits EOL this summer. 3) Upgrade to 6.x, fixing or dropping any modules in the collection that don't run on it yet. I'll stick around to help with this major effort (since it's partly my fault we're in this mess; I didn't realize that the release schedule for 5.x was so poorly aligned with Fedora 24), but after that I'm going to need someone else to step up and handle the primary maintenance. I don't like any of the choices, but I'm going to suggest that option 3) may be our best choice if we can manage it; we will want to be doing the same work for Fedora 25/Rawhide anyway, so it's not wasted effort. Also, a lot of the node modules in Fedora are only there because originally we needed them as dependencies for npm. Since we recently switched to carrying the embedded npm (and its rat's-nest of dependencies) inside the main nodejs package, we can probably get away with breakage in a lot of the modules in the collection. We may only need to focus in the short term on those packages that are required by other parts of the Fedora Project (like nodejs-less, which is consumed in the build process for many web apps). Option 2) is the path of least resistance in the immediate short-term, but once we run up against the upstream EOL, the maintenance burden could be prohibitive. In theory, we could petition FESCo for permission to break ABI in the stable release, but I wouldn't recommend it (and would probably be voting against it were it to come from anywhere else; I'd abstain in this case due to conflict of interest). Given that we know about the potential risk in advance, I doubt we'd see much sympathy either. So we should realistically assume that if we choose this option, someone is going to need to maintain the security backports (and it will not be me, sorry). As for Option 1)? I think someone with more knowledge of the individual modules in Fedora (Tom Hughes? Jared Smith?) would need to figure out how many modules would be broken if we downgraded. If it's sufficiently small, I suppose we could epoch-bump nodejs and its virtual npm Provides: and go that route. I don't love that we will effectively been playing yo-yo with the version in F24, but it would be a solution... Thoughts, other ideas? Please skip the rotten fruit; I'm on a diet. [1] https://github.com/nodejs/node/blob/master/CHANGELOG.md#2016-04-26-version-… [2] https://github.com/nodejs/LTS#lts_schedule

3 13

Intent to orphan nodejs
by Stephen Gallagher 16 Jun '16

16 Jun '16

As indicated in previous emails, my new $DAYJOB responsibilities are leaving little time to spend on Node.js maintenance work. I'm happy to hang around and serve as a comaintainer, but primary maintainership in Fedora should really be picked up by someone who can dedicate more time to it. Volunteers? As an aside, Patches (T.C. Hollingsworth) is still listed as the primary maintainer, but he's been non-responsive for over a year now; we should probably request that FESCo orphan it so we can invest group::nodejs-sig as the official owner.

7 15

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

nodejs May 2016