Re: Amendment (Re: Re-Proposal - preserve freedom of choice of init systems)
On Mon, Oct 20, 2014 at 11:55 AM, Ian Jackson ijack...@chiark.greenend.org.uk wrote: Alessio Treglia writes (Re: Amendment (Re: Re-Proposal - preserve freedom of choice of init systems)): Il giorno dom, 19/10/2014 alle 14.59 +0100, Ian Jackson ha scritto: I hereby formally propose the amendment below (Constitution A.1(1) `directly by proposer'), and, then, immediately accept it (A.1(2)). This resets the minimum discussion period (A.2(4)). ... Seconded. Just noticed that after reviewing the GR procedure once again. Honestly it was not really clear to me. Sorry about that. Thanks. -- Alessio Treglia | www.alessiotreglia.com Debian Developer | ales...@debian.org Ubuntu Core Developer| quadris...@ubuntu.com 0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAMHuwozC8h=h01-omtniwb2mgudake7iooqzpa+2ucrey82...@mail.gmail.com
Re: Amendment (Re: Re-Proposal - preserve freedom of choice of init systems)
Hi, Il giorno dom, 19/10/2014 alle 14.59 +0100, Ian Jackson ha scritto: I hereby formally propose the amendment below (Constitution A.1(1) `directly by proposer'), and, then, immediately accept it (A.1(2)). This resets the minimum discussion period (A.2(4)). For the avoidance of any doubt, I currently intend to not accept any further amendments. That means that the minimum discussion period will not be extended any further (unless the DPL intervenes). I currently intend to call for a vote when the minimum discussion period elapses, 2 weeks from now. The amendment is in two parts: I. In section 2, `Loose coupling of init systems', in the text `may not require a specific init system', replace `a' by `one': - In general, software may not require a specific init system to be + In general, software may not require one specific init system to be Explanation: Some people seem to have understood the previous text as must work with *all* init systems. I want to clarify that we just mean that software should not be tied to one specific init system. II. Insert new numbered section: + 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. And, renumber the already-existing section 3 to be section 4: - 3. Notes and rubric + 3. Notes and rubric Explanation: It has become clear from the discussion that it is necessary to explicitly explain the intended effect for jessie. Comment: The new section 3 does not need any powers of the Technical Committee - indeed, it is purely informational and advisory. So it is not part of the amendment's to the TC's resolution of the 11th of February. Seconded. Cheers. -- Alessio Treglia | www.alessiotreglia.com Debian Developer | ales...@debian.org Ubuntu Core Developer| quadris...@ubuntu.com 0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A signature.asc Description: This is a digitally signed message part
Re: Re-Proposal - preserve freedom of choice of init systems
On Thu, Oct 16, 2014 at 8:14 PM, Jonas Smedegaard d...@jones.dk wrote: Fine, conspiracy theories might be a bit too much. Let's call it strategic alliances that are a very real threat to Debian that are mediated by shared employment and might also involve corporate alliances. I don't care if monolithic system designs are caused by corporate alliances or not. And me neither. On Thu, Oct 16, 2014 at 4:05 PM, Ian Jackson ijack...@chiark.greenend.org.uk wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I wish to propose the following general resolution, and hereby call for seconds. I suspect that if the project members could have originally had the opportunity to vote on *which* init system should be the default on Jessie well, then it could have been handled much better. Cheers. -- Alessio Treglia | www.alessiotreglia.com Debian Developer | ales...@debian.org Ubuntu Core Developer| quadris...@ubuntu.com 0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/camhuwowxc5puy0h2pocdhddmmbuak0um252yilfmmbmfvrf...@mail.gmail.com
Re: Re-Proposal - preserve freedom of choice of init systems
Il giorno gio, 16/10/2014 alle 16.05 +0100, Ian Jackson ha scritto: ** 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. -- Alessio Treglia | www.alessiotreglia.com Debian Developer | ales...@debian.org Ubuntu Core Developer| quadris...@ubuntu.com 0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A signature.asc Description: This is a digitally signed message part
