Hi Josh (2025.04.02_17:56:48_+0000)
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.)
That may have been what was happening here, but it was *not*
communicated to the TC as being what was happening.
The impression I got was: "I can't even consider any proposals unless
there's a merge request. Then we can discuss the details in there."
In the merge request (mirroring the NMU), there was some technical
nitpicking (which is OK, to a degree, but also obstructive). And a
general refusal to implement the changes that were decided by the TC.
Instead other options (some on the TC ballot, some not) were being
offered. That was a conversation that should have happened *before* the
TC vote, at this point it's just obstructive.
While the TC was debating these issues, the Debian systemd package added
a policy to not carry patches that were not upstream. That probably tied
the maintainers hands quite a bit.
If I were in the shoes of a maintainer that got overridden, and I wanted
to handle the issue myself, I think it would be reasonable to do one of:
1. Implement the changes myself before the NMU's deferral delay.
2. Reply to the NMUer (and TC) saying: "I'll handle this by $date".
Only then cancel the NMU. And, of course, follow through with the
implementation.
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.
Read the discussion in the MR. I don't see anything to the contrary in
there.
Stefano
--
Stefano Rivera
http://tumbleweed.org.za/
+1 415 683 3272
