blog post: thoughts on the init system coupling GR
authorStefano Zacchiroli <>
Thu, 20 Nov 2014 08:59:13 +0000 (09:59 +0100)
committerStefano Zacchiroli <>
Thu, 20 Nov 2014 08:59:13 +0000 (09:59 +0100)
blog/posts/2014/11/Thoughts_on_the_Init_System_Coupling_GR.mdwn [new file with mode: 0644]
blog/posts/2014/11/Thoughts_on_the_Init_System_Coupling_GR/results.png [new file with mode: 0644]

diff --git a/blog/posts/2014/11/Thoughts_on_the_Init_System_Coupling_GR.mdwn b/blog/posts/2014/11/Thoughts_on_the_Init_System_Coupling_GR.mdwn
new file mode 100644 (file)
index 0000000..391c404
--- /dev/null
@@ -0,0 +1,106 @@
+# on perceived hysteria and silent sanity
+As you probably already know by now, the results of the Debian
+[init system coupling general resolution (GR)](
+look like this:
+<div class="center">
+[[!img results.png
+  size="600x"
+  alt="results of the init system coupling GR"
+  caption="Init system coupling GR: results (arrow from A to B means that voters preferred A to B by that margin)"
+Some random thoughts about them:
+- The **turnout** has been the
+  [highest]( since
+  2010 DPL elections and the 2nd highest among all GRs (!= DPL elections) ever.
+  The highest among all GRs dates back to 2004 and was about
+  [dropping `non-free`]( In absolute
+  terms this vote scores even better: it is the GR with the highest number of
+  voters ever.
+  Clearly there was *a lot* of interest *within* the project about this vote.
+  The results appear to be as representative of the views of project members as
+  we have been able to get in the second half of Debian history.
+- There is a total ordering of options (which is not always the case with
+  [our voting system]( Starting
+  with the winning option, each option in the results beats every subsequent
+  option.  The winning option ("General resolution is not required") beats the
+  runner-up ("Support for other init systems is recommended, i.e., "you
+  [SHOULD NOT]( require a specific init")
+  by a **large margin**: 100 votes, ~20.7% of the voters. The winning options
+  wins over further options by increasingly large margins: 173 votes (~35.8%)
+  against "Packages may require specific init systems if maintainers decide"
+  (the MAY option); 176 (~36.4%) against "Packages may not require a specific
+  init system" (the MUST NOT option); 263 (~54.5%) against "Further discussion"
+  (the "let's keep on flaming" option).
+  While judging from Debian mailing lists and news sites you might have gotten
+  the impression that the project was evenly split on init system matters, at
+  least w.r.t. the matter on the ballot that doesn't seem to be the case.
+- The **winning option** is not as crazy as its label might imply (voting to
+  declare that the vote was not required? WTH?). What the winning option
+  actually says is more articulated than that; quoting from the
+  [ballot]( (highlight
+  mine):
+  <em>Regarding the subject of this ballot, the Project affirms that **the
+  procedures for decision making and conflict resolution are working
+  adequately** and thus a General Resolution is not required.</em>
+  With this GR the Debian Project affirms that the procedures we have used to
+  decide the default init system for Jessie and to arbitrate the ensuing
+  conflicts are *just fine*. People might flame and troll `debian-devel` as
+  much as they want (actually, I'm pretty sure we would all like them to stop,
+  but that matter wasn't on the ballot so you'll have to take my word for
+  it). People might write blog posts and make headlines corroborating the
+  impression that Debian is still being torn apart by ongoing init system
+  battles. But this vote says instead that the large majority of project
+  members thinks our decision making and conflict-arbitration procedures, which
+  most prominently include the **Debian Technical Committee**, have served use
+  "adequately" well over the past troubled months.
+  That of course doesn't mean that everyone in Debian is happy about every
+  single recent decision, otherwise we wouldn't have had this GR in the first
+  place. But it does mean that we consider our procedures good enough to (a)
+  avoid getting in their way with a project-wide vote, and (b) keep on trusting
+  them for the foreseeable future.
+- [ It is not the main focus of this post, but if you care specifically about
+  the implications of this GR on **SystemD** adoption in Debian, I
+  recommend reading
+  [this excellent GR commentary](
+  by Russ Allbery. ]
+My take home message is that we are experiencing a huge gap between the
+**public perception** of the state of Debian (both from within and from without
+the project) and the **actual beliefs** of the silent majority of people that
+make Debian with their work, day after day.
+In part this is old news. The most "senior" members of the project will
+remember that the topic of "vocal minorities vs silent majority" was a
+recurrent one in Debian 10+ years ago, when flames were periodically ravaging
+the project. Since then Debian has grown a lot though, and we are now part of a
+much larger and varied ecosystem. We are now at a scale at which there are
+plenty of FOSS "mass-media" covering daily what happens in Debian, inducing
+feedback loops with our own perception of ourselves which we do not fully grok
+yet. This is a new factor in the perception gap. This situation is
+intrinsically bad, nor there is blame to assign here: after all influential
+bloggers, news sites, etc., just do their job. And their attention also
+testifies of the huge interest that there is around Debian and our choices.
+But we still need to adapt and learn to take perceived hysteria with a pinch
+(or two) of salt. It might just be time for our decennial check-up. Time to
+remind ourselves that our ways of doing things might in fact still be much more
+sane than sometimes we tend to believe.
+We went on 10+ years ago, after monumental flames. It looks like we are now
+ready to move on again, putting The Era of the Great SystemD Histeriaâ„¢
+[behind us](
+[[!tag lang/english planet-debian debian ctte systemd]]
diff --git a/blog/posts/2014/11/Thoughts_on_the_Init_System_Coupling_GR/results.png b/blog/posts/2014/11/Thoughts_on_the_Init_System_Coupling_GR/results.png
new file mode 100644 (file)
index 0000000..de7a6c8
Binary files /dev/null and b/blog/posts/2014/11/Thoughts_on_the_Init_System_Coupling_GR/results.png differ