[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Re-Proposal - preserve freedom of choice of init systems



On Thu, Oct 16, 2014 at 04:05:41PM +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.

Seconded.

 - Jonas

--
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

Attachment: signature.asc
Description: Digital signature


Reply to: