On Thu, Jun 18, 2020 at 12:51 PM Ben Rosser <rosser.bjr(a)gmail.com> wrote:
>
> On Wed, Jun 17, 2020 at 12:50 PM Fabio Valentini <decathorpe(a)gmail.com> wrote:
> >
> > On Wed, Jun 17, 2020 at 6:30 PM Ben Rosser <rosser.bjr(a)gmail.com> wrote:
> > >
> > > On Tue, Jun 16, 2020 at 5:38 PM Jared K. Smith <jsmith(a)fedoraproject.org> wrote:
> > > >
> > > > On Tue, Jun 16, 2020 at 3:41 PM Ben Rosser <rosser.bjr(a)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(a)lists.fedoraproject.org to discuss
those.
