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

[Josh Triplett]

On Wed, Apr 02, 2025 at 06:38:25PM +0000, Stefano Rivera wrote:
> 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.

I think it's important to distinguish between "communication problem"
and "obstruction". "obstruction" is a problem that goes to DAM;
"communication problem" can potentially look like that, but once it's
resolved as *not* being that, it should ideally be rapidly de-escalated.

> 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."

I saw the message I think you're referrring to, and my interpretation of
that was about the *technical implementation* of the design, as opposed
to the *semantic change*. Broadly speaking it might have been ideal to
have engaged earlier, but I don't think it's obstruction to attempt to
*iterate* on implementation.

One could alternatively observe that an MR could have been provided
earlier in the process, and the iteration could have started then. I
don't think it's *entirely* on the maintainer to have started earlier in
the process.

> 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.

That has been the policy of the package for a long time, and the only
new thing was *documenting* it. It's not a new policy.

> 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.

The impression I have was that this was option 2, and the thing missing
was the "by $date". In other words, I think this was a communication
issue, not obstruction. (Though, sufficiently advanced communication
issues are indistinguishable from obstruction.)

> > 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.

I've read the discussions on the MRs, and I stand by what I said above.
I see multiple explicit mentions, in the MR discussions, referencing and
acknowledging the TC decision, and attempting to implement something
that does not contradict that ruling. Going back and forth on figuring
out *whether* something satisfies the TC ruling is not *ignoring* the TC
ruling.

I certainly don't think the TC or anyone else expected "remove the
packages" as the solution, but at the same time, I can also *understand*
how someone would land on that: "well, the response to attempting to
iterate on an implementation of the ruling is to treat it as defying the
ruling and escalate, so here's something that should definitely meet the
requirement so that things stop escalating".