GR vote — init systems
For Debian followers, it should not be a surprise: a new General Resolution regarding the init systems is underway, trying to finally settle the set of issues that stem from the way our project works, following the 2014-003 vote, init system coupling.
Back in 2014, I find it quite understandable the project was not in a collective mental state that would have allowed for closure after the infamously long and flamey bug #727708.
But before that — Given the complexity of this vote, please read and follow Ian’s recommendations regarding ballot formatting.
``` [ 1 ] Choice 3: A: Support for multiple init systems is Important [ 2 ] Choice 2: B: Systemd but we support exploring alternatives [ 3 ] Choice 4: D: Support non-systemd systems, without blocking progress [ 4 ] Choice 5: H: Support portability, without blocking progress [ 5 ] Choice 8: Further Discussion [ 6 ] Choice 1: F: Focus on systemd [ 7 ] Choice 7: G: Support portability and multiple implementations [ 8 ] Choice 6: E: Support for multiple init systems is Required ```
My ordering might be odd given the discussions and recommendations we have seen in the past month. I agree with Charles,
I am crushed under the number of options. Their texts are long, sometimes very similar, and do not separate clearly the normative from the preambles
So, I start by describing the options I chose under FD (that is, under my personal agreeability threshold):
- It will benefit the project having a clear slant towards systemd (so, I ranked E last). The benefits are many and deep.
- We need guiding and policy, not just good good neighbor guidelines already given by 2014-03, so G follows next-to-last
- I think it’s very important that, even being not the default options and not having tier-one support, Debian remains able to answer to specific user’s needs. Option F is too strong for my taste in dropping alternatives.
The four remaining options can be grouped in Sam’s original proposals (A&B) and Ian’s counter-proposals (D&H). While Ian has great rationales and I have learnt and understood a lot from reading him, they are just too complex. I feel they lead to too many subtleties and details.
I am not absolutely behind A and B’s words to the last comma, but they both illustrate a point I do find agreeable to adopt as a norm. Of course, I do believe the epilogue in D&H (Being excellent to each other) should apply to all of our work in Debian, no matter what option wins… And that should solve the potential ambiguities regarding the strength of _should_s in A&B.