On Thu, Jun 18, 2020 at 12:51 PM Ben Rosser rosser.bjr@gmail.com wrote:
On Wed, Jun 17, 2020 at 12:50 PM Fabio Valentini decathorpe@gmail.com wrote:
On Wed, Jun 17, 2020 at 6:30 PM Ben Rosser rosser.bjr@gmail.com wrote:
On Tue, Jun 16, 2020 at 5:38 PM Jared K. Smith jsmith@fedoraproject.org wrote:
On Tue, Jun 16, 2020 at 3:41 PM Ben Rosser rosser.bjr@gmail.com wrote:
So... this is a lot of node.js packages, and I haven't really seen any discussion of this on the lists. And at least some of these are possibly important for other nodejs packages-- notably "mocha", which I suspect is used in at least some packages to run unit tests (at the very least, several of my nodejs packages use it to run unit tests...).
Indeed... I'd hate to see mocha disappear. That being said, there's a bunch of these other packages that can probably safely be retired -- I pulled in a couple hundred NodeJS packages in my hard-headed attempt to get NodeRED into Fedora for the IoT team a couple of years ago, but got bogged down in dependency nightmares and ultimately gave up. Since then, I've been busy with my job and grad school to really spend a lot of time worrying about NodeJS packages in Fedora, since I'm not a NodeJS developer. That being said, if there are packages like mocha that really need to be maintained to keep the NodeJS ecosystem working in Fedora, I could probably be persuaded to pick up a few more packages.
-Jared
Hi Jared,
That makes sense to me. Maybe the priority should be trying to keep mocha alive, and eventually figuring out how to update it? The current dependencies, according to repoqery, are as follows:
(npm(commander) >= 2.2.0 with npm(commander) < 3) (npm(debug) >= 2.2.0 with npm(debug) < 3) (npm(diff) >= 1.0.8 with npm(diff) < 2) (npm(escape-string-regexp) >= 1.0.2 with npm(escape-string-regexp) < 2) (npm(glob) >= 6.0.3 with npm(glob) < 7) (npm(growl) >= 1.7.0 with npm(growl) < 2) (npm(jade) >= 1.3.1 with npm(jade) < 2) (npm(mkdirp) >= 0.5.0 with npm(mkdirp) < 0.6) /usr/bin/env nodejs(engine) >= 0.8.0 npm(supports-color)
I haven't looked further to see what the dependency tree is like for each of these, but commander, debug, diff, glob, and growl are all currently orphaned.
Hi,
Stewardship SIG guy speaking :)
If you have a limited set of packages that you want to keep working, e.g. to keep a minimal environment available to build other NodeJS rpm packages in fedora, then that's exactly what the Stewardship SIG was originally intended to to, albeit for a limited time only. We also have some tooling to check leaf package status and analyze dependency trees, which would also help here.
However! I've tried to shepherd our Java packages into the "refounded" Java SIG for a few weeks, but so far, I haven't had any success, with no contributions from people other than me in the past 2-3 weeks ... and I'd rather not try to start adding new packages into the Stewardship SIG umbrella without also getting help from packagers (both packagers familiar with NodeJS to look after the NodeJS stack, and packagers familiar with Java to finalize the move of Java packages into the new Java SIG).
Hi Fabio,
I'm not sure how much time I'll be able to put in, but I'd be very happy to (help) work on this, either as part of the Stewardship or Nodejs SIGs, or both. Hopefully others interested in the nodejs ecosystem (Sérgio and Jared, perhaps?) would be willing to consider helping too.
The Nodejs SIG does have ACLs on (almost?) all of these packages, and I know there are at least a few active packagers there, so hopefully they would be willing to help as well. I think the immediate problem is figuring out what in this large stack of nodejs packages is actually useful (and stopping them from being retired in a week and a half), so being able to use the tooling you mentioned would be very helpful, I think. Then we'd need to ultimately find new points-of-contact for the useful ones (while allowing the non-useful ones to be retired); in the long term, I'd be willing to pick up some of those (hopefully not all, but who knows).
How does one go about joining the Stewardship SIG?
The Node.js SIG is very loosely organized. If you are a packager and write to the SIG to ask to be added to the FAS group gitnodejs-packaging, I'll go ahead and add you.
Zuzanna Svetlikova and I maintain the Node.js interpreter and NPM package tool in modular and non-modular Fedora releases. This is not going away. The packaging for these critical packages includes bundled NPM content from upstream rather than consuming packages in Fedora because the Node.js packaging ecosystem makes it realistically impossible to package every individual dependency into RPMs (NPM alone has 402 dependencies and it changes constantly).
I've been meaning to bring up this topic on the Node.js SIG mailing list for a while: I think Fedora should largely get out of the game of delivering NPM modules and only concern itself with delivering tools that provide applications or support for other software in Fedora. So things like ycssmin and lessc would make sense to keep alive, but probably we would build them with their NPM dependencies bundled to match their upstream releases rather than waste time building dozens or hundreds of dependent packages in Fedora.
I have some thoughts on how this could be made easier, but I'll open a different thread on that on nodejs@lists.fedoraproject.org to discuss those.
On Thu, 18 Jun 2020, Stephen Gallagher wrote:
Stewardship SIG guy speaking :)
If you have a limited set of packages that you want to keep working, e.g. to keep a minimal environment available to build other NodeJS rpm packages in fedora, then that's exactly what the Stewardship SIG was originally intended to to, albeit for a limited time only. We also have some tooling to check leaf package status and analyze dependency trees, which would also help here.
I have some packages depending on indirectly on nodejs things being retired. How do I find out which ones I need to save?
On Thu, Jun 18, 2020 at 3:09 PM Stephen Gallagher sgallagh@redhat.com wrote:
The Node.js SIG is very loosely organized. If you are a packager and write to the SIG to ask to be added to the FAS group gitnodejs-packaging, I'll go ahead and add you.
Hi Stephen,
Thanks. I'll send an email to the SIG mailing list.
Zuzanna Svetlikova and I maintain the Node.js interpreter and NPM package tool in modular and non-modular Fedora releases. This is not going away. The packaging for these critical packages includes bundled NPM content from upstream rather than consuming packages in Fedora because the Node.js packaging ecosystem makes it realistically impossible to package every individual dependency into RPMs (NPM alone has 402 dependencies and it changes constantly).
Sure, to be clear I wasn't worried about the interpreter and npm itself-- thanks for the work you do maintaining that! I'm primarily worried about the npm module ecosystem.
I've been meaning to bring up this topic on the Node.js SIG mailing list for a while: I think Fedora should largely get out of the game of delivering NPM modules and only concern itself with delivering tools that provide applications or support for other software in Fedora. So things like ycssmin and lessc would make sense to keep alive, but probably we would build them with their NPM dependencies bundled to match their upstream releases rather than waste time building dozens or hundreds of dependent packages in Fedora.
I have some thoughts on how this could be made easier, but I'll open a different thread on that on nodejs@lists.fedoraproject.org to discuss those.
This seems sad, but probably inevitable given the mess that is the npm module ecosystem. My experience trying to package nodejs software has been that the upstream version requirements on modules are usually overly strict and can sometimes (but not always, of course) be considerably softened or worked around-- but in order to package every dependency we'd wind up needing to maintain hundreds if not thousands of packages, and it is a lot of work to keep them updated. So I suppose I'd be cautiously in favor, provided there was some kind of automation to help write/maintain this part of the spec.
However... what should we do in the meantime to stop further nodejs software from being orphaned and retired? I imagine it will take some time to put together some tooling and/or guidelines for this, and these packages are set to be retired imminently. Can we temporarily allow the nodejs SIG fas group to become the POC of these packages to stop their retirement?
I've gone ahead and taken mocha (running tests will be useful regardless of whether or not we start bundling NPM modules). I haven't yet figured out what I need to take to keep it + my other node packages alive for now, but I'll work through that this evening if no one suggests doing anything else.
Ben Rosser
On Mon, Jun 22, 2020 at 11:29 AM Ben Rosser rosser.bjr@gmail.com wrote:
However... what should we do in the meantime to stop further nodejs software from being orphaned and retired?
From my standpoint, the answer to this is around tooling to built/test/audit NodeJS applications with bundled dependencies. Easier said than done, unfortunately :-/
I've gone ahead and taken mocha (running tests will be useful
regardless of whether or not we start bundling NPM modules). I haven't yet figured out what I need to take to keep it + my other node packages alive for now, but I'll work through that this evening if no one suggests doing anything else.
Thank you! I'm happy to help where I can, but can't quite guarantee right now that I have the time to be the primary maintainer of the mocha package. That being said, if you get stuck, feel free to ping me on IRC or drop me an email, and I'll try to help.
-Jared
nodejs@lists.fedoraproject.org
-
Ben Rosser -
Jared K. Smith -
Stephen Gallagher -
Stuart D Gathman