On Wed, 2 Apr 2025 20:01:19 +0000 stefa...@debian.org wrote: > 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.
Not disagreeing with that, and I am not in any way endorsing the communication style or patterns; far from it. I can, however, sympathize with how people can *end up* in entrenched positions. > >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. I'm not suggesting that it is. But at the same time, it's often healthy if there are concrete proposed changes by the time the TC is deliberating, and *again*, it's not on the maintainer to implement things they disagree with. By way of example, it should have been detected much earlier in the process that the right way to "turn off mDNS in the default installation" is to install a configuration file, not to change the compile-time default. > 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. Sure, but in this case, the changes *weren't* particularly large. Most of the approaches to addressing the mDNS issue could be implemented in a few lines. > >> 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. Sure, the TC *can* make any arbitrary decision, including overriding package maintenance policies. That doesn't mean they *should*, if those policies aren't *directly* in the way of solving the problem. On balance, I would venture that TC should make the narrowest ruling that directs the problem to be solved and un-sticks a dispute, rather than over-prescribing implementation details. (The TC ruling partially did that and partially didn't.) In any case, the point of my comment was that you implied the policy was *new*, and I was observing that it wasn't new, so it wasn't a reaction to this incident. > >> 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. Having not been privy to those private conversations, I'm not in a position to comment on or judge that. I was going solely off of observations of the public communication. > 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. Honestly, I think that there was an utter failure of that on *two* sides, not just *one*. Obviously, engaging would have helped lead to better solutions. At the same time, I don't particularly have an impression that the underlying motivations or values behind systemd's policies were particularly taken seriously or empathized with; none of the alternatives that are *now* coming up were generated previously despite them being reasonably obvious. > >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. That is not at all obvious. It's certainly not an *ideal* solution, but I don't have the impression it was being presented as one; I have the impression it was presented as "do the simplest thing that meets the TC's ruling so that there is no longer external pressure and ongoing escalation". And to use the /lib64 issue as an example, it would not be the first or hundredth time in Debian that a problem gets solved by *first* adding a `Conflicts:` and *later* figuring out a better solution and removing or versioning the `Conflicts:`. That doesn't mean the `Conflicts:` are the ideal solution, but sometimes you solve an RC bug by introducing a `Severity: normal` bug and then later fixing the `Severity: normal` bug. The ruling was "base-files should own all top-level filesystem aliases, and packages that conflict with this must be patched in Debian to avoid creating any aliases that conflict with base-files". systemd was patched (and is continuing to be patched) to add `Conflicts` such that no combination of packages that can be installed together will result in the creation of any aliases that conflict with base-files. This obviously introduces a new problem, that people may wish to use packages together that now conflict, and may wish to use systemd-nspawn on arm64. To be clear, I'm not naive here, and I expect that the implemented solution had some basis in spite-driven development (SDD). I don't particularly like the solution either; I use systemd-nspawn sometimes, and would like to be able to rely on it on arm64. I hope that a better solution arises. But that future solution can be iterated upon at leisure, and was not something the TC ruled on.
