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

[Ross Gammon]

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.

Cheers,

Ross