[Pkg-javascript-devel] pre-spring cleaning, please advise

[Jérémy Lal]

2017-01-28 17:46 GMT+01:00 Ross Gammon <javascript at the-gammons.net>:
> 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 <kapouer at melix.org> 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