Re: Removing more packages from unstable
Hi Johannes and Bastian,
On Tue, Aug 20, 2024 at 10:35:47AM +0200, Bastian Venthur wrote:
> On 20.08.24 07:55, Johannes Schauer Marin Rodrigues wrote:
> > Hi,
> [...]
> > if I remember correctly, a package can also become a key package by having a
> > high-enough popcon value. If that is correct, maybe there should also be the
> > inverse. Looking at your list, about 85% of those packages have a popcon lower
> > than 100. Taking the popcon value into account would also kinda make your
> > hand-curated list of exceptions obsolete as your current list has popcons well
> > above 100, for example. If the popcon is taken into consideration, that would
> > also give a little bit of insurance that only very few users will be affected.
>
> That's what I thought too: we should somehow incorporate the popcon value.
I considered adding popcon to the criteria before hitting send. In the
end, I opted for not including it based on my own cost/benefit analysis.
While popcon may be a signal for the benefit-of-keeping aspect, it
provides little value for the cost-of-keeping part that feels most
important to me. As you point out, popcon is partially considered via
the key package constraint. As others (e.g. Niels) point out, the cost
of a package largely is a function of our ability to modify it and long
lasting RC bugs are a relatively high quality signal indicating that a
package is difficult to modify. Either some of those many users
(according to popcon) eventually gets interested in doing the hard work,
or we should put it onto the chopping block. Even mailing the rc bug
would reset its last modified timer.
If there ends up being consensus for adding popcon as a signal, so be
it. I've explained my reasons and am not too strongly attached to
excluding popcon.
Helmut
Reply to: