Bug#1101532: systemd: unable to migrate to Testing because of removed packages

[Josh Triplett]

On Tue, 1 Apr 2025 23:42:26 +0000 Stefano Rivera <stefanor at 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.