Thomas Goirand <z...@debian.org> writes: > I think you and many others should be extremely careful when talking > about proposal B just as if it was a clear winner of the poll. If you > are then discarding the opinion of everyone else who didn't want it as > the winning option, and not consider the GR result as a whole, then you > are clearly dismissing the opinion of a large amount of DDs (even though > they were not the majority).
I'm sorry to push a little bit on this, because I understand that many people are upset and frustrated by the outcome of the vote, but I am also concerned about the project falling into a different one of its very long-standing problems: being unwilling to make a decision. We have a constitutional mechanism to make a decision. That mechanism produced a decision. We should move forward with that decision. We don't need to do so in a rush, and we should do so respectfully and carefully, but as important as it is to the project to be welcoming and respectful of the people who are unhappy with the outcome of a decision, it's also important for the project to be able to *make decisions* and then follow through on them. Otherwise, we're going to still be having the same discussion in another year, and by that point we'll be having it with fewer people because there are very few things as demotivating and draining as being endlessly trapped in the same cycle of argument. For me at least, that's even worse than losing an argument. (Option B was my fourth pick in the vote, for the record.) > What I'm trying to do here, is to enable a middle ground where we have a > common interface everywhere, with the possibility to implement things > differently. Just saying "systemd systemd systemd" many times, imposing > it as the only reference and winner, where it should be enabled > everywhere, and for absolutely all of its interfaces, will lead to > nowhere. And that's *not* what the proposal B was about. The guidance of option B is that we are committing to reviewing and working collaboratively with anyone who wants to support alternate init systems, but that implementation strategy is subject to technical review. I think Sam is providing that technical review by pointing out the drawbacks of using multiple competing implementations. That's a valid point of technical discussion; you may disagree with him, but I think that discussion is explicitly enabled by the GR result. There were two options on the ballot that called for standardizing interfaces of systemd facilities that we were going to adopt so that other implementations could implement only the Policy-defined functionality and not other features. For better or worse, those options did not win. That's a lot of work, and with my Policy hat on, I'm not committing to doing that work because I see the GR as asking me to spend my limited resources on other things, and also asking that we move a little bit more decisively in the direction of adopting systemd facilities than that (albeit not as decisively as option F). Therefore, I think it's a reasonable question to ask whether we want, as a project, to commit to supporting the least common denominator between several competing implementations of these facilities, or instead ask that people arrange to run the systemd implementation so that we have the same features everywhere. Support for kFreeBSD and Hurd is obviously a valid argument in favor of some level of support for non-systemd implementations. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
