2017-01-28 17:46 GMT+01:00 Ross Gammon <javascr...@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
>> On 28/01/2017 10:17, Jonas Smedegaard wrote:
>>> Quoting Ben Finney (2017-01-28 03:07:01)
>>>> Jérémy Lal <kapo...@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.
>>>> 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.