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

[stefanor at debian.org]

Hi Josh (2025.04.02_19:27:34_+0000)
>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.

Absolutely. In abstract, at least.

We have been watching where this goes and trying to see the changes we 
decided on land. There has been a lot of communication. But I'm afraid 
things have not de-escalated, because this wasn't just a simple lack of 
communication.

I think Luca set himself in a strongly entrenched position, and was 
unwilling to give any ground. I'm afraid this is a pattern I've seen 
before.

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

I agree with that. But the reality is that it blocked the fast 
implementation of the semantic change.

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

The Debian Constitution defines how the CT is to take decisions. MRs 
are not part of the process. Yes, it could be helpful to hash out 
detailed implementation examples of all the solutions on the table, 
before the TC votes. But in practice, I don't see that happening very 
often. Changes that come to the CT are often big enough that they can't 
be completely fleshed-out pre-vote, we're making higher level decisions.

I don't think a package maintainer can say that their package will use a 
different procedure for CT decisions.

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

I assumed as much too. But again, I don't think package maintainers can 
declare that something is out of bounds for a CT decision. 

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

I had private conversations with Luca, to try to see where he was coming 
from. And I did not get the impression that he would commit to implement 
changes that he didn't agree with.

So, sorry, but it was very clearly neither 1 or 2. I think he was hoping 
to find different solutions to the problems that would satisfy the TC. 
And there is scope for doing something like that, but it requires 
communication and discussion. Most importantly it requires listening to 
the other side, and taking their position seriously.

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

Yes, that came later. But the first responses were flat nos. That's when 
the escelation happened.

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

Yes, but that isn't a serious position. It's obvious that the packages 
wouldn't be able to migrate to testing in that hobbled state, and that 
the TC would not be satisified. We're still working towards finding 
results that satisfy our decision.

And Luca is still a systemd maintainer in Debian, with only a DAM 
warning. There has been some escalation, but not nearly as much as there 
could (and may yet) be.

I'm sorry, but the response by systemed maintainers (in particular Luca) 
here has not been what I would consider acceptable for our project. I 
understand it, I can see how frustrated Luca must feel with the way 
things have gone. But I think the response we expect from that is to 
step back and accept the NMU that you disagree with.

I'm happy that we got there with the mDNS part of this bug. I'm sorry it 
went via package removal, but we got there. Thanks.

Now it remains to be seen where we get to with the /usr-merge issue.

Stefano

-- 
Stefano Rivera
   http://tumbleweed.org.za/
   +1 415 683 3272