Hi josch,[Talking mostly as a fellow DD, just a tiny bit with Release Team member hat on].
On 11-10-2023 13:31, Johannes Schauer Marin Rodrigues wrote:
There exist RC bugs that the release team deems RC even though they do not directly violate policy and vice-versa.
I would hope that this is only one direction. Policy describes practice and is always (by definition) behind. So, unless the policy needs updating for something that we (as a project) learned to accept, I would hope that all policy violations are RC by default. Indeed, the Release Team is delegated to make non-policy violations RC bugs. The RT *tries* to state them in the rc_policy [1], where non-policy issues are marked with "Ref: RT".
I'm going this route because *if* those bugs get classified as RC by the release team, then there are different mechanisms available to fix them, like NMUs in case the maintainer is unresponsive.
I claim that a bug doesn't need to be RC to be acceptable for NMU fixing. The dev ref has a chapter on it [2], nowhere it says that bugs have to be RC. It even suggests how to use the DELAYED queue for non-RC bugs.
The patch for each of these bugs is very minimal, so fixing them is usually as simple as adding the missing B-D.
I'd say, prepare NMU's for all of them, let the bug report know you've done so and upload to DELAYED 10.
I am aware that this annoys people. I do not like to annoy people. But this is a problem that annoys me (and others). So right now we are in a situation where there are two ways forward: doing nothing and changing things. For each of these two ways there are people in favour of it and people against it. So independent of what the outcome is, *somebody* will be annoyed. Who is there to choose who should be the one annoyed in the end? Quite evidently there is no way out of this that annoys nobody. What would you do?
My *expectation* is that if you follow the NMU process as outlined in the dev ref, you'll not receive as much friction as you would get with (even approved) severity serious bugs.
Paul [1] https://release.debian.org/testing/rc_policy.txt[2] https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#when-and-how-to-do-an-nmu
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature