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

[Stefano Rivera]

Hi Luca (2025.04.01_22:32:45_+0000)

I don't think getting into the timeline nitty gritty is the most 
productive thing we can do, but let me give you the context that you're 
missing. Skip over this part of my email, if you want to get onto 
productive bits.

>- Mar 4 11:58: TC is asked to open MRs, not do NMUs

I think you mean March 14.

I know that some TC members had some personal contact with you, but I 
don't have any email from you sent on that date. I have seen a message 
you sent Matthew (our chair) on March 14, that says that you will not 
accept NMUs.

However, I don't think it's really OK for any project members to say 
that their packages are not NMUable. NMUs are always an option available 
to the project when package maintainers are MIA and something needs to 
be done. I imagine the rest of the project thinks similarly.

As a committee member, I never want to have to rule to override a 
package maintainer. That's a heavy responsibility, and not a great 
option to have to take. If the package maintainer doesn't accept the 
ruling, then the project is having to lose the maintainer. But in this 
case, the options in front of the committee were ruling to override one 
or another set of package maintainers, that's where we found ourselves.

When you think about the TC rulings in that context, a refusal to accept 
an NMU to implement the TC ruling reads as an unwillingness to allow the 
TC to overrule the maintainer.

How else are we going to get a TC ruling implemented, when overriding a 
maintainer. We can't expect them to do the work themselves, and we can't 
expect them to approve of the changes in code review. That's going to 
blow up (like this did).

I'm afraid our constitution doesn't allow leeway here. These are 
situations that get DAM involved.

>- Mar 27 22:32: TC escalates to DAM

That timestamp is when DAM contacted you, not when the matter was 
escalated to them. That had come a day and a half earlier, impressively 
quick action, if you ask me. The decision to make that escalation 
had come from discussion over the previous several days.

The discussions we were having in the MR were in parallel to this 
escalation process. Obviously, if we'd been making progress in the MR, 
DAM may have stood back, or we may have paused the escalation process a 
little longer. But the wheels were in motion as soon as the NMU was 
cancelled (and comments were posted in the MR that made it clear that 
the changes in the NMU weren't acceptable to you).

I reached out to you on IRC when I could see that this process was 
getting under way and I was looking for a way to de-escalate. It was a 
long shot, but sadly we didn't get there. I think it was interpreted as 
a threat, instead.

>- Apr 1 21:46: TC escalates to DAM

There was no second escalation. I think that was just DAM cogs turning. 
They issued a warning today.


Let's try to get back onto productive threads of discussion:

Speaking for myself, but I imagine the rest of the committee thinks 
similarly, we did not want to see the removal of systemd-resolved or 
systemd-nspawn. These options were never even on the table to vote, 
as nobody requested them. They're radical and seem reactionary, I'm 
assuming we'll be able to find a better way.

 From my PoV the patches Helmut posted still seem like the most 
reasonable solution to the issues at hand, but if there are better 
options that weren't considered, we can consider them. The constitution 
doesn't (to my reading) block us from taking a second bite at a problem, 
*but* that's going to be an exceptional process. There'd have to be some 
significant change in the problem space to make that happen.

I don't think it's OK for maintainers who have been overridden by the TC 
to blackmail the project into forcing TC decisions to be overturned (or 
DAM to remove the maintainer).

Bad TC decisions can be overridden by GR (wit ha high cost in process).

And you can work with the TC to help find a workable solution. Really, 
that should have happened before we voted, but better late than never.

We're here, and we can discuss options forward.

I think Helmut's proposed patches are worth considering seriously. I 
know you don't, but I don't know exactly why. Explaining your reasoning 
would *really* help us to understand your position.

Stefano

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