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.

As others have shared theirs, and given this is a non-secret vote (choices will be spelt out once the vote is done), I am doing so as well.

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.