Le 6 janvier 2016 16:55:19 GMT+01:00, Ximin Luo <infini...@debian.org> a écrit : >On 06/01/16 15:26, Paul Wise wrote: >> On Wed, 2016-01-06 at 14:02 +0100, Ximin Luo wrote: >> >>> Grunt is going to take a while to package, due to the wider JS >>> ecosystem being generally stupid, over-bloated and self-important >far >>> beyond its worth. >> >> I spoke to someone on IRC who was working on it the other day, it >> sounded like they were close, just packaging another 1KB JS file. >> > >Do you have a more solid lead that we can chase down? > >>> (For example, I very much doubt someone is going to maintain a >debian >>> package for a JS npm package whose only purpose and ability is to >>> check if number-is-nan. Also, lol @ the meow -> indent-string -> >>> repeating -> meow cyclic dependency.) >> >> Uh, #797455 >> > >"maintain" is more than filing an ITP and uploading the initial >package, it means making sure that other things continually work well >with it across multiple versions, and when it is finally obsolete to >see it get removed cleanly. Cost is important too. I would take good >bets that the person intending to do this upload will go AWOL and drop >the whole deal in 1-2 years, because the cost of maintaining npm >bullshit is simply not worth the benefits. > >>> Could we just make an exception at this time for this OTR.js >embedded >>> copy? We can add very loud notices to debian/TODO and debian/rules >>> saying that this should be fixed whenever otr.js is packaged >>> properly, hopefully once we convince upstream to move away from >>> Grunt. >> >> I don't think the DFSG has exceptions :) >> > >I don't see why you think this as a DFSG issue? This is an embedding >issue, and there have been exceptions made before for this. If we can >package Grunt soon, then ok we can wait, but my previous experience >working with JS packages makes me strongly want to avoid this road. > >>> [1] Seriously, WHO THE FUCK WRITES THIS SHIT??? >> >> It is a different world from a different age, completely disconnected >> with the world of Linux distros. Unfortunately those people are the >new >> Open Source ecosystem and abhor the distros and how we do things. >> > >I wouldn't say they're the "new ecosystem" just yet, and "new" does not >imply "better". In particular, that ecosystem does not understand the >concept of long-term maintenance cost. Not discouraging packages whose >metadata is larger in size than the data, not supporting forked version >trees to backport bugfixes, etc, wastes massive amounts of time and >effort in the end, which may be a good deal for the developers getting >paid to waste this effort, but is not good for users and developers >that want to see the overall FOSS ecosystem progress technologically. > >>> Also, in terms of lintian and this bug report, *it is still a bug in >>> lintian*. It would still give a false positive even if otr.js is >>> packaged correctly. This is also triggered by some other JS stuff I >>> have been packaging. >> >> Agreed, but it is a bit much to expect lintian to be false-positive >free. >> > >Of course not for all warnings; but the warning for this specifically >tells people to file bugs against lintian: > >https://lintian.debian.org/tags/source-is-missing.html > >>> I would suggest that lintian be amended, so that if the file is >20- >>> 50 lines, and there are only 1-2 of these "long lines", then no >>> error/warning is emitted. >> >> IIRC it already has been toned down. >> > >Well, it is still emitting this warning for that file (1 long line out >of 2600 short lines [1]) currently. If any pending versions of lintian >in git would not do this, then please add a pending tag and close this >bug of course. > >X > >[1] >https://anonscm.debian.org/cgit/pkg-mozext/cryptocat.git/tree/chrome/content/data/js/lib/otr.js
Does this line is one of the prime compromises but thé nsa? -- Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.
