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
