Re: opentmpfiles & opensysusers, and its use in the Debian policy
Thomas Goirand <zigo@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 (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: