GR vote: init systems

Submitted by gwolf on Mon, 12/09/2019 - 20:17

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 shoulds in A&B.

( categories: )

Post new comment

The content of this field is kept private and will not be shown publicly. If you have a Gravatar account associated with the e-mail address you provide, it will be used to display your avatar.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <br> <b> <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <blockquote> <img> <h1> <h2> <h3> <tt> <pre> <strike> <table> <tr> <th> <td>
  • Lines and paragraphs break automatically.
  • Use <bib>citekey</bib> or [bib]citekey[/bib] to insert automatically numbered references.
  • Use [fn]...[/fn] (or <fn>...</fn>) to insert automatically numbered footnotes.
  • You can enable syntax highlighting of source code with the following tags: <code>, <blockcode>. The supported tag styles are: <foo>, [foo].

More information about formatting options

CAPTCHA
This question is for testing whether you are a human visitor and to prevent automated spam submissions.
Keep in mind that all comments will also have to be administrator-moderated. Don't waste your time writing a spam that no one will read.
n
9
E
f
N
L
Enter the code without spaces and pay attention to upper/lower case.