On Tue, 1 Apr 2025 23:42:26 +0000 Stefano Rivera <stefa...@debian.org> wrote: > Hi Luca (2025.04.01_22:32:45_+0000) > When you think about the TC rulings in that context, a refusal to accept > an NMU to implement the TC ruling reads as an unwillingness to allow the > TC to overrule the maintainer. > > How else are we going to get a TC ruling implemented, when overriding a > maintainer. We can't expect them to do the work themselves, and we can't > expect them to approve of the changes in code review.
I don't think this is the right interpretation, and I think that interpretation leads to bad outcomes like what happened here. As you said, the TC or the project cannot *require* that a maintainer do work they've objected to. However, I think it's reasonable for a maintainer to say "OK, fine, this isn't the outcome I would prefer, but I'll implement it, and I'd prefer to implement it myself rather than have someone NMU it". (As long as that happens in a timely and cooperative fashion, which seems like what *was* happening here.) If a maintainer *refuses* to implement a TC change, then an NMU (preserved by the maintainer in subsequent uploads) is reasonable and the maintainer would need to maintain that going forward, *or* the maintainer would need to accept a PR, which seems roughly equivalent. (In both cases, the maintainer has to preserve the change going forward, but is free to rewrite or reimplement that change as long as they don't ignore the TC ruling.) And even in that case, it is reasonable for a maintainer to ensure that reasonable package process is followed; for instance, a PR that breaks a package's testsuite shouldn't be accepted, and neither should an NMU that breaks a package's testsuite. The maintainer still has discretion to *maintain the package* and *determine how to implement the change*, they just no longer have the option of *deciding whether to implement the change*, or *delaying the change unduly*. Obviously, this requires human judgement. And if a maintainer were *actually* being obstructive to the point of using package process to effectively reject or unduly delay a ruling, that'd be actionable, just as reverting the NMU *with no functional replacement* would be. But just as a maintainer is free to replace an NMU with a different implementation that still satisfies the ruling, a maintainer is *also* free to decline an NMU and implement the ruling themselves instead, *as long as that happens in a timely and good-faith fashion*. I don't see any signs that the maintainer's rejection of the NMU here was in bad faith or gave any indication of *refusing* to implement the TC ruling.
