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
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)