2017-01-28 17:46 GMT+01:00 Ross Gammon <[email protected]>: > On 01/28/2017 10:52 AM, Paolo Greppi wrote: >> This is a good idea ! There is a lot of cruft, especially packages created >> for some obscure reason 2-3 years ago and since then abandoned both by the >> maintainer and by upstream, and superseded by the next cool thing in the >> nodejs ecosystem. >> >> I propose to extract from UDD a list of candidate packages to be removed: >> those not fulfilling the criteria proposed by Jérémy, plus some more like: >> >> - popcon > 20 >> .. >> >> The list would be published for scrutiny here in this mailing list or on the >> wiki for say 2 weeks. >> >> To address the point raised by Ben (i.e. to make sure we don't remove a >> library needed at some point in the future for some other package not yet >> uploaded), I would leave it to the owner of the high-level package IPTs: for >> each of those there is a Task in the wiki or a non-disclosed WIP list - in >> any case the ITP owner knows best and she should manually remove from the >> list the packages she thinks she'll need, providing a rationale (i.e. >> "needed for yarnpkg"). >> >> Once the 2 weeks are over we can proceed mass filing those "candidate for >> removal" bugreports. >> >> Once the additional 2 weeks are over the bugreports can be reassigned to >> ftpmaster. >> >> Paolo >> >> On 28/01/2017 10:17, Jonas Smedegaard wrote: >>> Quoting Ben Finney (2017-01-28 03:07:01) >>>> Jérémy Lal <[email protected]> writes: >>>> >>>>> - or having a reverse (build-)dependency, or what's the point ? >>>> I am very much in favour of this: node libraries should be in Debian >>>> to provide a library that is needed for some actual program of benefit >>>> to Debian users. >>> Agreed. >>> >>> >>>> But my eagerness to remove useless packages makes me worry that some >>>> useful ones could be swept up also. >>>> >>>> One use case I don't see addressed: How will we ensure that a library >>>> is not needed for some other package not yet uploaded to Debian? >>> Removal from testing involves filing a bugreport to ftpmaster. I guess >>> it makes sense if at all uncertain to first file bugreport against the >>> package and cc this list - of not-to-high severity - suggesting the >>> intent (removal from stretch or removal from Debian completely) some >>> time (2 weeks?) before reasigning to ftpmaster. >>> >>> Discussing only here is not adequate: Being part of this team and >>> subscribing to this mailinglist is voluntary. >>> >>> >>> - Jonas >> > > I agree. But....... > > It might be a good idea to keep the alioth repo for a while though. > Upstreams can sometimes get going again when some need is identified and > someone willing steps up to maintain it. Then we can at least quickly > resurrect the package if required. > > Can we be a little less aggressive on the timescales? It should be a > Buster goal. It can take me most of a release cycle to get all the other > dependencies in shape in order for the final reverse dependency to get > uploaded (I failed with several things this release cycle). Trying to > re-remember what package I don't want to get "dropped out" (which could > be maintained by someone else) and then adjusting bug severities does > take up valuable time which could be spent getting the other > dependencies ready. > > Also, as we enable more and more autopkgtests & buildtime testsuites, > packages in bad shape will naturally fall out of testing anyway - > without us doing any work. Periodically looking at the packages that > have not been in testing for a long time could be another metric to use. > I know I have a couple of those that weren't worth working on until a > series of other dependencies were ready.
My proposal was not to remove the debian package entirely, it was more about not letting a bunch of under-maintained node packages go to next stable, so the time-scale would be crucial here. In a second move, of course some packages need to be entirely removed, but that's something that can be done much more slowly. Jérémy -- Pkg-javascript-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
