Re: Removing more packages from unstable
On August 20, 2024 7:46:05 AM UTC, Andrey Rakhmatullin <wrar@debian.org> wrote:
>On Tue, Aug 20, 2024 at 07:28:52AM +0200, Helmut Grohne wrote:
>> please allow me to open a can of worms. Package removal from unstable.
>> Deciding when it is time to remove a package from unstable is difficult.
>> There may be users still and it is unclear whether keeping the package
>> imposes a cost. In this mail I want to argue for more aggressive package
>> removal and seek consensus on a way forward.
>
>Yes please.
>
>> What does package removal cost?
>>
>> Before a package can be removed, it needs to be reviewed for reverse
>> dependencies and if there are any, they have to be switched to something
>> else or removed as well.
>
>(leaf packages are much more straightforward to remove because of this)
>
>> Human readable explanation:
>> * Packages in sid
>> * not in bookworm or trixie
>> * not a key package
>> * affected by an RC bug that has been last modified more than a year ago
>> * not among a few selected exceptions
>
>Makes sense, though non-leaf ones can't be processed automatically and so
>I'm not sure what can be done with them.
>
>If we don't want to mass-remove all of these, there are additional
>criteria (that I sometimes use to file manual removals) that can be added,
>though not all of them are possible to determine automatically:
>
>* Leaf package
>* A "library" (something not useful by itself)
>* FTBFS - these can't be binNMUed, NMUed etc. without fixing an unrelated
> bug first so they are in a worse condition thatn others in the context
> we are discussing
>* "Doesn't work at all" - these are not useful to users.
>* Orphaned
>
>> Let us assume that we agree on there being a set of packages to be
>> removed. What is a reasonable process? Is it ok to just file a pile of
>> RoQA bugs or is more warning warranted? Should we maybe use a process
>> similar to salvaging where there is an "ITR" (intent to remove) bug that
>> is reassigned to ftp after a reasonable timeout?
>
>Removing packages that aren't formally orphaned always sounds too bold to
>me, though it should be fine if we formalize a process (any process) for
>that.
>
The process currently is file an rm but against ftp.debian.org for removal from unstable using RoQA (remember, we're all QA) explaining the rationale and an FTP Team member will assess it and remove the package if it seems reasonable (the above criteria are quite reasonable in that regard).
There are people doing this, we could use more, but it does happen. I've processed lots of these and it's virtually always fine. In the rare case of a mistake, the cost to rectify the mistake is a trip through New.
I don't think we need more process. We just need someone to do the work of finding the packages and filing the bugs.
Scott K
P.S. FTP Team member, but not speaking for the team.
Reply to: