The Debian init system general resolution returns

From: Ian Jackson <ijackson-AT-chiark.greenend.org.uk> To: debian-vote-AT-lists.debian.org Subject: Re-Proposal - preserve freedom of choice of init systems Date: Thu, 16 Oct 2014 16:05:41 +0100 Message-ID: <21567.57029.724173.958520@chiark.greenend.org.uk> Archive-link: Article, Thread

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I wish to propose the following general resolution, and hereby call for seconds. This GR resolution proposal is identical to that proposed by Matthew Vernon in March: https://lists.debian.org/debian-vote/2014/03/msg00000.html and the substantive text is that which was drafted for the purposes of the technical committee's vote (where they decided not to pass a resolution on the subject). IMO developments since March show that the concerns put forward then were well-founded. Following discussions elsewhere including -devel I have received enough offers of seconds by private email. As Matthew said, I don't think further lengthy discussion of the issues is likely to be productive, and therefore hope we can bring this swiftly to a vote. This is particularly true given the impact on the jessie release. Thanks, Ian. ** Begin Proposal ** 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 a 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. 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. ** End Proposal ** -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBCAAGBQJUP96EAAoJEOPjOSNItQ05JYcH/367UqEXLQ3BkWdm2nIGeNN2 rAkdFTso+H3qckCIZnltbWuV+2cZmqXAFac627GoT2hvnu4KwrsiKgyu1PInVWPh 0XUt/8eeR95v2B9JYMuOSlxOOPLwgRZLpJ7vtd1pEU+Skrml0hoHFPCqbrFFathz K92Kv6HFd5v9vgc1nJir719wZ0zZe20ChSRc8wyMCaM68kddnmRJcpyWF7A3o2jD 9M4coOVlBQRt7kAu65LHV72OcjJbWq4qGeTIxBIExk1nWKNLRYEOHveF7nSaiLxk D4t0466fknL23SYukhpRSjAdcr6/3tHp7pbZGBHQfrszyb1pQvzL1oNGgBUn4dw= =eHpN -----END PGP SIGNATURE----- --