Re: Removing more packages from unstable
Helmut Grohne:
Hi fellow developers,
(modified resend, as first attempt didn't arrive)
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.
Hi,
I agree with the idea.
On the bias disclaimer side: I was a very vocal proponent for the
testing auto-removal. I see it as our greatest success of the early
2010s for reducing mental load of the RT during freezes.
Another bias: For me, implementing a automation on this front is higher
than getting out the "optimal degree of conservatism" correct. The
testing auto-remover did not start out with its current criteria either.
What does a package cost?
There are various QA-related teams looking at packages from other
maintainers. When it trips a check, that often incurs time from some QA
person investigating a report or failure. Examples:
* [...]
You can add to that any "archive-wide" change we have done or will do.
Other cases where we have or probably did run into such packages also
include:
* build-arch (now done)
* compiler hardening flags (now done)
* The C++ transition many years ago and the t64 transition (now done)
* Removing our implicit dependency on `fakeroot`
By virtue of being part of Debian, a package receives attention by a
significant number of developers. Assigning a number is non-trivial, but
we can say for sure that it is significant. Especially developers doing
/usr-move NMUS (e.g. Chris Hofstaedler and Michael Biebl) now wonder
how much effort to put into the remaining packages. Removing more
packages would reduce the number of NMUs required there.
As a data point, I am (also?) personally a lot less motivated to
implement changes or do NMUs when I have to deal with broken FTBFS
packages in sid. It is one of several roadblocks that make me reconsider
whether I want to implement a change on a larger level.
It does not make sense for me to change such packages since I cannot (or
is not motivated to) fix the other problems. But I still need to track
them in case someone actually fixes the bugs but does not implement the
change I want to see in it.
> [...]
>
When to remove a package?
I looked at UDD and came up with a suggested query.
https://udd.debian.org/bugs/?release=sid¬bookworm=only¬trixie=only&merged=ign&keypackages=ign&flastmod=ign&flastmodval=366&rc=1&sortby=id&sorto=asc&format=html#results
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
I think this is a good starting point.
On the exception list, I know Josch suggested a popcon limit.
Personally, I was thinking usertagging RC bugs that are "keep out of
testing/package is not for stable" bugs and use usertag as filter to
replace the exceptions.
But either of those or even the hardcoded exception list (including
tweaks thereof) would be fine for me to get started. All of them gets us
started and we can refine the exact details over time.
[...]
What do you think about the proposed criteria and suggested set of
source packages? Is it reasonable to remove these packages from
unstable? In a sense, it is extending the idea of the testing auto
remover to unstable. Similarly, a package can be temporarily saved by
mailing the respective bug.
I agree with the proposed criteria as a starting point. Like with the
testing auto-removal, we should expect some refinements to happen once
the proposal is implemented.
The code would have to deal with reverse dependencies somehow (which
both you and Andrey pointed out).
The testing auto-remover has a solution for reverse dependencies that
could work. It has the advantage (in the eyes of *this* beholder) that
it is aggressive.
Though I would be fine with a any version really. This include
starting with "all reverse dependencies must be eligible for automatic
removal on their own (or removed manually first)". From there, we can
always refine the algorithm and its aggressiveness for removal of
reverse dependencies.
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?
I would say that at least one warning should be given for consistency
with the testing auto-remover. I am open to "how" and the timelines.
For me, the most important thing is that the process can be automated
end to end and that the tool is anchored somewhere to keep it
maintained. Therefore, I am a bit skeptical on the ITR bug concept on
the automation front, but I suppose it would have the advantage of
"living off the land" for bug notifications. That is one of the
complaints we have for the testing auto-remover.
The ITR bug concept would also lower the barrier to agreeing to a
"reassign the bug" rather than filing a new one. We could literally
include the BTS instructions in the bug so you could just copy-paste and
hit send. As long as this can be automated in practice (I am not an
expert in automation involved the BTS), then the ITR bug concept has
merit for me.
A concrete proposal could be to give a warning one month before
triggering the removal / filing the RM bug. In the timescale we are
working with, I am not invested in whether that is 11 + 1 months or 12 +
1 months.
What would be important is that you are guaranteed a minimum time to
act on the warning. This can be relevant if our selection criteria or
the dependency relation change and that should not lead to any immediate
surprise removals[1]. It also acts as a safe-guard against bugs (there
will always be another bug).
Note: Requiring a warning first would also give all the packages on your
list an automatic grace period. I would see that as an excellent way of
testing the system and the process in practice to weed out "childhood
diseases". :)
My personal motivation for looking into this actually is the /usr-move
work and the cross build support work. Please do consider me biased.
Helmut
[...]
On the "Where do we anchor this"-front, where do you see this live long
term? We have tons of QA tools that live and die with their interest of
their creator. I appreciate your are quite a persistent individual even
for Debian standards when it comes to archive-wide QA. However,
eventually everyone gets hit by a proverbial bus.
Organizationally, I think this would fit in the FTP master sphere of
influence in the long term (not saying the prototyping must happen
there), since they official decide the criteria for what is in the
archive. This would also parallel the testing auto-remover living under
the release team.
I know I said the FTP master team was resource constrained and that is
part of why I would say the prototype would happen outside the team. But
since they are in the receiving end of these RM bugs, it also makes
sense they have authority and is empowered to fix the tooling if it is
sub-optimal for them in the long run.
Nevertheless, it would not be a blocker for me that the long term
maintenance strategy for this tool would be unclear when we implement
it. But I feel we should start that discussion, so we are clear on it
and also who is the authoritative source for future changes.
In my book, debian-devel consensus gathering is slow and can be quite
draining, so we should not use it for "day-to-day" operational matters.
To me, that implies having a team with authority to manage that.
Leveraging a delegated team would checks some boxes for me on that
front, but it is certainly not a necessity.
Best regards,
Niels
PS: As much as I want automation, I do not mind the prototype starting
as a semi-automatic process if that is what it takes to get started.
[1]: A concrete example could be that a package with a 2-year old RC bug
was kept around because it had a reverse dependency and we start with
"no automatic reverse dependency removal". If that reverse dependency
was updated to drop that dependency then the RC buggy package should get
its warning and a grace timer of one month (in my proposal) rather than
immediately getting removed.
Reply to: