On Thu, 2014-10-16 at 16:05 +0100, Ian Jackson wrote: > 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 ** > -- > > Seconded.
Description: This is a digitally signed message part