General Resolution: init system coupling

Time Line

Proposal and amendment Thursday, 16th October 2014
Discussion Period: Sunday, 19th October 2014 Sunday, 2nd November, 2014
Voting Period: Wednesday, November 5th, 00:00:00 UTC, 2014 Tuesday, November 18th, 23:59:59 UTC, 2014

Proposer

Ian Jackson [[email protected]] [text of proposal] [proposing and accepting amendement] [Call for vote]

Seconds

  1. Simon Richter [[email protected]] [mail]
  2. Alessio Treglia [[email protected]] [mail]
  3. Iustin Pop [[email protected]] [mail]
  4. Florian Lohoff [[email protected]] [mail]
  5. Ritesh Raj Sarraf [[email protected]] [mail]
  6. Bernhard R. Link [[email protected]] [mail]
  7. Dimitri John Ledkov [[email protected]] [mail]
  8. Jonas Smedegaard [[email protected]] [mail]
  9. Craig Sanders [[email protected]] [mail]
  10. Thorsten Glaser [[email protected]] [mail]
  11. Tobias Frost [[email protected]] [mail]

Text

Choice 1: Packages may not (in general) require a specific init system

0. Rationale

  Debian has decided (via the technical committee) to change its
  default init system for the next release. The technical committee
  decided not to decide about the question of "coupling" i.e. whether
  other packages in Debian may depend on a particular init system.

  This GR seeks to preserve the freedom of our users now to select an
  init system of their choice, and the project's freedom to select a
  different init system in the future. It will avoid Debian becoming
  accidentally locked in to a particular init system (for example,
  because so much unrelated software has ended up depending on a
  particular init system that the burden of effort required to change
  init system becomes too great). A number of init systems exist, and
  it is clear that there is not yet broad consensus as to what the
  best init system might look like.

  This GR does not make any comment on the relative merits of
  different init systems; the technical committee has decided upon the
  default init system for Linux for jessie.

1. Exercise of the TC's power to set policy

  For jessie and later releases, the TC's power to set technical
  policy (Constitution 6.1.1) is exercised as follows:

2. Loose coupling of init systems

  In general, software may not require one specific init system to be
  pid 1.  The exceptions to this are as follows:

   * alternative init system implementations
   * special-use packages such as managers for init systems
   * cooperating groups of packages intended for use with specific init
     systems

  provided that these are not themselves required by other software
  whose main purpose is not the operation of a specific init system.

  Degraded operation with some init systems is tolerable, so long as
  the degradation is no worse than what the Debian project would
  consider a tolerable (non-RC) bug even if it were affecting all
  users.  So the lack of support for a particular init system does not
  excuse a bug nor reduce its severity; but conversely, nor is a bug
  more serious simply because it is an incompatibility of some software
  with some init system(s).

  Maintainers are encouraged to accept technically sound patches
  to enable improved interoperation with various init systems.

3. As far as we are aware there are currently (17th of October) no
   bugs in jessie which would be declared RC by this GR.

   Given the late passage of this resolution, we expect that any
   intractable bugs which are RC by virtue only of this resolution
   would be tagged by the release team as `jessie-ignore'.

   So this proposal is not thought to add blockers to the jessie
   release.

4. Notes and rubric

  This resolution is a Position Statement about Issues of the Day
  (Constitution 4.1.5), triggering the General Resolution override
  clause in the TC's resolution of the 11th of February.

  The TC's decision on the default init system for Linux in jessie
  stands undisturbed.

  However, the TC resolution is altered to add the additional text
  in sections (1) and (2) above.

Amendment Proposer A

Lucas Nussbaum [[email protected]] [text of original amendement] [update of amendment]

Amendment Seconds A

  1. Andrey Rahmatullin [[email protected]] [mail]
  2. Holger Levsen [[email protected]] [mail]
  3. Vincent Cheng [[email protected]] [mail]
  4. Matthias Urlichs [[email protected]] [mail]
  5. Marco d'Itri [[email protected]] [mail]

Amendment Text A

Choice 2: Support for other init systems is recommended, but not mandatory

Debian has decided (via the technical committee) to change its default
init system for the next release. The technical committee decided not to
decide about the question of "coupling" i.e. whether other packages in
Debian may depend on a particular init system.  However, the technical
committee stated in #746715 that "[it] expects maintainers to continue to
support the multiple available init systems in Debian.  That includes
merging reasonable contributions, and not reverting existing support
without a compelling reason."

The Debian Project states that:

   Software should support as many architectures as reasonably possible,
   and it should normally support the default init system on all
   architectures for which it is built.  There are some exceptional cases
   where lack of support for the default init system may be appropriate,
   such as alternative init system implementations, special-use packages
   such as managers for non-default init systems, and cooperating
   groups of packages intended for use with non-default init systems.
   However, package maintainers should be aware that a requirement for a
   non-default init system will mean the software will be unusable for
   most Debian users and should normally be avoided.

   Package maintainers are strongly encouraged to merge any contributions
   for support of any init system, and to add that support themselves if
   they're willing and capable of doing so.  In particular, package
   maintainers should put a high priority on merging changes to support
   any init system which is the default on one of Debian's non-Linux
   ports.

   
   For the jessie release, all software available in Debian 'wheezy'
   that supports being run under sysvinit should continue to support
   sysvinit unless there is no technically feasible way to do so.
   Reasonable changes to preserve or improve sysvinit support should be
   accepted through the jessie release.  There may be some loss of
   functionality under sysvinit if that loss is considered acceptable by
   the package maintainer and the package is still basically functional,
   but Debian's standard requirement to support smooth upgrades from
   wheezy to jessie still applies, even when the system is booted with
   sysvinit.

The Debian Project makes no statement at this time on sysvinit support
beyond the jessie release.


This resolution is a Position Statement about Issues of the Day
(Constitution 4.1.5), triggering the General Resolution override clause
in the TC's resolution of the 11th of February.

The TC's decision on the default init system for Linux in jessie stands
undisturbed.

However, the TC resolution is altered to add the additional text above.

Amendment Proposer B

Luca Falavigna [[email protected]] [text of amendment]

Amendment Seconds B

  1. Holger Levsen [[email protected]] [mail]
  2. Nicolas Dandrimont [[email protected]] [mail]
  3. Andrey Rahmatullin [[email protected]] [mail]
  4. Antonio Terceiro [[email protected]] [mail]
  5. Arno Töll [[email protected]] [mail]
  6. Philipp Kern [[email protected]] [mail]
  7. Vincent Bernat [[email protected]] [mail]
  8. Gergely Nagy [[email protected]] [mail]
  9. Cyril Brulebois [[email protected]] [mail]
  10. Paul Tagliamonte [[email protected]] [mail]
  11. Ansgar Burchardt [[email protected]] [mail]

Amendment Text B

Choice 3: Packages may require specific init systems if maintainers decide

0. Rationale

  Debian has decided (via the Technical Committee) to change its
  default init system for the next release. The Technical Committee
  decided not to decide about the question of "coupling" i.e. whether
  other packages in Debian may depend on a particular init system.

  This GR reaffirms the Debian Social Contract #4, in such a way
  that Debian acknowledges the choices made by both the software
  developers (also known as upstream developers) and the Debian
  package maintainers to provide the best free software to our users.

  Upstream developers considering specific free software (including,
  but not limited to, a particular init system executed as PID 1)
  fundamental to deliver the best software releases, are fully entitled
  to require, link, or depend on that software, or portions of it.

  Debian maintainers' work is aiming to respect the Debian Social
  Contract, in such a way to provide our users the best free software
  available.

  Debian maintainers are fully entitled to provide modifications to
  the free software packages they maintain as per DFSG #3, if they
  judge this necessary to provide the best software releases.
  On the other hand, Debian maintainers are fully entitled to adhere
  to upstream's decisions to require, link, or depend on specific free
  software (including, but no limited to, particular init system executed
  as PID 1), if they consider it necessary to prevent delivering broken,
  buggy, or otherwise incomplete software packages.

The Debian Project states that:

1. Exercise of the TC's power to set policy

  For jessie and later releases, the TC's power to set technical
  policy (Constitution 6.1.1) is exercised as follows:

2. Specific init systems as PID 1

  Debian packages may require a specific init system to be executed
  as PID 1 if their maintainers consider this a requisite for its proper
  operation by clearly mark this in package descriptions and/or
  by adding dependencies in order to enforce this; and no patches
  or other derived works exist in order to support other init systems
  in such a way to render software usable to the same extent.

3. Evidence of defects (bugs)

  We strongly reaffirm Debian maintainers are not deliberately hiding
  problems (Social Contract #3). No technical decisions shall be
  overruled if no proper evidence of defects, issued in the Debian Bug
  Tracking system, is found. Fear, uncertainty, and doubt are not
  considered as evidence of defects.

This resolution is a Position Statement about Issues of the Day
(Constitution 4.1.5), triggering the General Resolution override clause
in the TC's resolution of the 11th of February.

The TC's decision on the default init system for Linux in jessie stands
undisturbed.

However, the TC resolution is altered to add the additional text above
in sections #1, #2 and #3.

Amendment Proposer C

Charles Plessy [[email protected]] [text of original amendement] [update of amendment]

Amendment Seconds C

  1. Matthias Urlichs [[email protected]] [mail]
  2. Holger Levsen [[email protected]] [mail]
  3. Didier 'OdyX' Raboud [[email protected]] [mail]
  4. Raphael Hertzog [[email protected]] [mail]
  5. Cyril Brulebois [[email protected]] [mail]
  6. Gergely Nagy [[email protected]] [mail]
  7. Paul Tagliamonte [[email protected]] [mail]
  8. Lucas Nussbaum [[email protected]] [mail]
  9. Joey Hess [[email protected]] [mail]
  10. Philipp Kern [[email protected]] [mail]
  11. Anthony Towns [[email protected]] [mail]
  12. Sam Hartman [[email protected]] [mail]
  13. Philip Hands [[email protected]] [mail]

Amendment Text C

Choice 4: General Resolution is not required

The Debian project asks its members to be considerate when proposing General
Resolutions, as the GR process may be disruptive regardless of the outcome of
the vote.

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.

Quorum

With the current list of voting developers, we have: 

 Current Developer Count = 1006
 Q ( sqrt(#devel) / 2 ) = 15.8587515271537
 K min(5, Q )           = 5
 Quorum  (3 x Q )       = 47.5762545814611

Quorum

Data and Statistics

For this GR, like always, statistics will be gathered about ballots received and acknowledgements sent periodically during the voting period. Additionally, the list of voters will be recorded. Also, the tally sheet will also be made available to be viewed.

Majority Requirement

The proposal needs simple majority

Majority

Outcome

Graphical rendering of the results

In the graph above, any pink colored nodes imply that the option did not pass majority, the Blue is the winner. The Octagon is used for the options that did not beat the default.

In the following table, tally[row x][col y] represents the votes that option x received over option y. A more detailed explanation of the beat matrix may help in understanding the table. For understanding the Condorcet method, the Wikipedia entry is fairly informative.

The Beat Matrix
 Option
  1 2 3 4 5
Option 1   133 183 147 241
Option 2 313   251 180 366
Option 3 263 172   135 286
Option 4 323 280 308   358
Option 5 212 99 166 95  

Looking at row 2, column 1, Support for other init systems is recommended, but not mandatory
received 313 votes over Packages may not (in general) require a specific init system

Looking at row 1, column 2, Packages may not (in general) require a specific init system
received 133 votes over Support for other init systems is recommended, but not mandatory.

Pair-wise defeats

The Schwartz Set contains

The winners

Debian uses the Condorcet method for voting. Simplistically, plain Condorcets method can be stated like so :
Consider all possible two-way races between candidates. The Condorcet winner, if there is one, is the one candidate who can beat each other candidate in a two-way race with that candidate. The problem is that in complex elections, there may well be a circular relationship in which A beats B, B beats C, and C beats A. Most of the variations on Condorcet use various means of resolving the tie. See Cloneproof Schwartz Sequential Dropping for details. Debian's variation is spelled out in the constitution, specifically, A.6.

Debian Project Secretary