Re-Proposal - preserve freedom of choice of init systems
-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/msg0.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- -- -- 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/21567.57029.724173.958...@chiark.greenend.org.uk
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. Your proposal has been received and is signed correctly. Neil -- signature.asc Description: Digital signature
Re: Re-Proposal - preserve freedom of choice of init systems
Hi, On 16.10.2014 17:05, Ian Jackson wrote: I wish to propose the following general resolution, and hereby call for seconds. [...] ** 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. Simon signature.asc Description: OpenPGP digital signature
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
Re: Re-Proposal - preserve freedom of choice of init systems
On Thu, Oct 16, 2014 at 04:05:41PM +0100, Ian Jackson wrote: 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. Speaking of which, before deciding anything (including seconding it or not) about this proposal, I'd like to know what impact a positive outcome of this GR would have on the work load of teams whose efforts we badly need to put the Jessie release in shape. Specifically: have you, or anyone else involved in this GR, asked the GNOME team and the release team, whether a positive outcome of this GR is going to disrupt their work (plans) or not? [ Those teams are just the first two I could think of. Please speak up if you are aware of teams that might be heavily impacted, one way or another, by the outcome of this GR. ] I've sympathy for the motives behind this GR, but discovering that those teams might have their Jessie plans disrupted---on a very short notice---by this GR will make me think twice or thrice before helping in making it happen. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
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/msg0.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. iustin signature.asc Description: Digital signature
Re: Re-Proposal - preserve freedom of choice of init systems
** 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 ** I second this proposal. -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System signature.asc Description: OpenPGP digital signature
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/msg0.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. -- Florian Lohoff f...@zz.de signature.asc Description: Digital signature
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/msg0.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 signature.asc Description: Digital signature
Re: Re-Proposal - preserve freedom of choice of init systems
Stefano Zacchiroli writes (Re: Re-Proposal - preserve freedom of choice of init systems): Specifically: have you, or anyone else involved in this GR, asked the GNOME team and the release team, whether a positive outcome of this GR is going to disrupt their work (plans) or not? No, I have not. I am not aware of any underlying bugs in (say) gnome-without-systemd that would be RC. But the sentiment behind this GR is that any such bugs should be considered indeed RC for the whole project. I've sympathy for the motives behind this GR, but discovering that those teams might have their Jessie plans disrupted---on a very short notice---by this GR will make me think twice or thrice before helping in making it happen. I think that if necessary we might have to delay the release. That would be a matter for the release team. I would be very unhappy if we ditched the ability of people to choose a different init system simply to maintain our release schedule. It is very regrettable that this identical resolution didn't get enough seconds in March. At least I can say `I foresaw the neeed for this'. Ian. -- 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/21568.2030.594087.481...@chiark.greenend.org.uk
Re: Re-Proposal - preserve freedom of choice of init systems
On Thu, Oct 16, 2014 at 07:57:06PM +0200, Jonas Smedegaard wrote: Seconded. I'm getting a bad signature from you, can you try again, perhaps with a clearsigned mail? Thanks, Neil -- signature.asc Description: Digital signature
Re: Re-Proposal - preserve freedom of choice of init systems
Ian Jackson ijack...@chiark.greenend.org.uk writes: I think that if necessary we might have to delay the release. That would be a matter for the release team. I would be very unhappy if we ditched the ability of people to choose a different init system simply to maintain our release schedule. Hurray, what a great idea to delay everything *now*. And all because some people believe in conspiracy theories about Red Hat... Anyone around for the alternative choice of just one init system? In the same spirit of just one libc? (Yeah, choice of course does not include the C library or the kernel if it's just anti-evil-Red-Hat...) Ansgar -- 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/8738anyipe@deep-thought.43-1.org
Re: Re-Proposal - preserve freedom of choice of init systems
On Thu, 2014-10-16 at 19:01 +0100, Ian Jackson wrote: Stefano Zacchiroli writes (Re: Re-Proposal - preserve freedom of choice of init systems): I've sympathy for the motives behind this GR, but discovering that those teams might have their Jessie plans disrupted---on a very short notice---by this GR will make me think twice or thrice before helping in making it happen. I think that if necessary we might have to delay the release. That would be a matter for the release team. I would be very unhappy if we ditched the ability of people to choose a different init system simply to maintain our release schedule. Speaking for no-one other than myself, I _am_ very unhappy that given how long the discussion has been rumbling on for, and how much opportunity there has been, that anyone thought that two weeks before the freeze (which has had a fixed date for nearly a year now) was the right time to raise this. Regards, Adam -- 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/1413484103.2260.10.ca...@adam-barratt.org.uk
Re: Re-Proposal - preserve freedom of choice of init systems
On Thu, Oct 16, 2014 at 08:26:21PM +0200, Ansgar Burchardt wrote: Ian Jackson ijack...@chiark.greenend.org.uk writes: I think that if necessary we might have to delay the release. That would be a matter for the release team. I would be very unhappy if we ditched the ability of people to choose a different init system simply to maintain our release schedule. Hurray, what a great idea to delay everything *now*. And all because some people believe in conspiracy theories about Red Hat... This response is uncalled for. The /existence/ of conspiracy nuts is no reason to insult the members of the Debian community who are unhappy with the increasingly monolithic approach to system design that is being advocated in some quarters. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Re-Proposal - preserve freedom of choice of init systems
Hi, On Donnerstag, 16. Oktober 2014, Adam D. Barratt wrote: Speaking for no-one other than myself, I _am_ very unhappy that given how long the discussion has been rumbling on for, and how much opportunity there has been, that anyone thought that two weeks before the freeze (which has had a fixed date for nearly a year now) was the right time to raise this. Exactly. And for what exactly? Gnome right now is installable with systemd-shim + sysvinit, why can't this GR wait until after release when the dust has settled? This is a GR based on rumors, which is very sad. And even sadder, what the GR states: we think this software is not we like it to be. And/but we force *you* to change it - whether *you* think it's sensible or not. That's childish, to say at best :( If you don't like upstreams choices, *you* should write patches. Not GRs telling other people to do so. cheers, Holger, thinking about how a sensible GR to counter this one could be written signature.asc Description: This is a digitally signed message part.
Re: Re-Proposal - preserve freedom of choice of init systems
On 16 October 2014 21:41, Holger Levsen hol...@layer-acht.org wrote: And for what exactly? Gnome right now is installable with systemd-shim + sysvinit, why can't this GR wait until after release when the dust has settled? That is great! And is exactly what the GR is supposed make sure keeps happening. Debian would simply make a public commitment to keep supporting use of all Debian-packaged software with any init system. Does this also mean that such a GR is not actually a blocker for jessie release? If you don't like upstreams choices, *you* should write patches. Not GRs telling other people to do so. We have all kinds of policies about what is fine in a package and what is a Release Critical bug. That is a big part of what makes a distribution. This simply adds - must be able to work with any init system running at PID 1 to those requirements. -- Best regards, Aigars Mahinovsmailto:aigar...@debian.org #--# | .''`.Debian GNU/Linux (http://www.debian.org)| | : :' : Latvian Open Source Assoc. (http://www.laka.lv) | | `. `'Linux Administration and Free Software Consulting | | `- (http://www.aiteki.com) | #--# -- 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/cabpywdubv0ymv3b63msizthe9gfn1xkoasgchgvtmcr4nnf...@mail.gmail.com
Unidentified subject!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I second the proposal 'preserve freedom of choice of init systems' -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQJ8BAEBCgBmBQJUQBJfXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ5RkUzRTlDMzY2OTFBNjlGRjUzQ0M2ODQy QzdDMzE0NkMxQTAwMTIxAAoJECx8MUbBoAEhnWYP/1KmdCivLQ8EYDAzvQktiV3G KcOdfRRxuCe8hc2hr9NCMTTp74qn85jmfjBw8KMmvG8WTKP+OkQIiTDNcrujsLkU U/7et49Gbkz6qFRrde3vT1X7FeUmWbD4uSuq/iG47p3qXKo8WkcxrHHl3dx+elQx dCNVDtBqv/89cNS6BbE3e3wUiLt5Co54jPuwT2Ue2MAt8orfrlz70NFAAOpCg1yX O4wU9kUPLIsPllwpNJqJGEfWh9kYC++MbyDRWaMLzLeDBAgsa/vA34TwFtaOZ2Eo UUtGvYEGb7asZfYtIz6zfdBCrorqknS86eNqQSsUUvdMAyOKZPaHZ3VVS8J9sTzr GOCyttwGr03N153+W3hJbSkfS1NDsqN8U47U83/bTCT6bP556NaUANtc8TXQWulB anntUyyxqtDKFx0sUzEpcb2dx/yBPrUQEtIUffTwztZ8ICABfoW7eQ7iKcyFIkb4 RNxM06uL5L6Sbl6iBy10KSVmoYdszKmoQDnjq4SD+fXK7JrFG7ng5U4zXFeus1DK +TOhkcppBy01JSsEoDdfGcdLTwUGxd3Xkr7LqhOnxNvADPxp2Pg4MHeKPrZukMvq TAnVR/s7YmXwZie7qfWsGaMsnb1wMZqyuczD98ReHPEVNcew84ITIjx9ofOUJMYh HMVuEvoVE86K2x61KTqn =+SHi -END PGP SIGNATURE- -- 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/1413485155.304428.16433.nullmai...@jones.dk
Re: Re-Proposal - preserve freedom of choice of init systems
On Thu, 2014-10-16 at 22:00 +0300, Aigars Mahinovs wrote: We have all kinds of policies about what is fine in a package and what is a Release Critical bug. That is a big part of what makes a distribution. This simply adds - must be able to work with any init system running at PID 1 to those requirements. Strictly speaking, what is a Release Critical bug is the release team's purview, as per their delegation. (Of course, subject to being overriden by the project as with any other delegate.) Regards, Adam -- 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/1413486565.2260.15.ca...@adam-barratt.org.uk
Re: Re-Proposal - preserve freedom of choice of init systems
Aigars Mahinovs aigar...@debian.org writes: We have all kinds of policies about what is fine in a package and what is a Release Critical bug. That is a big part of what makes a distribution. This simply adds - must be able to work with any init system running at PID 1 to those requirements. No, it does not mean packages have to work with *any* init system. It's specifically aimed against a specific init replacement, see [1]. Ansgar [1] https://lists.debian.org/debian-vote/2014/03/msg00103.html -- 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/87zjcvrfnu@deep-thought.43-1.org
Re: Re-Proposal - preserve freedom of choice of init systems
Quoting Ansgar Burchardt (2014-10-16 20:50:31) Steve Langasek vor...@debian.org writes: On Thu, Oct 16, 2014 at 08:26:21PM +0200, Ansgar Burchardt wrote: Hurray, what a great idea to delay everything *now*. And all because some people believe in conspiracy theories about Red Hat... This response is uncalled for. The /existence/ of conspiracy nuts is no reason to insult the members of the Debian community who are unhappy with the increasingly monolithic approach to system design that is being advocated in some quarters. 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. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Re-Proposal - preserve freedom of choice of init systems
On Thu, 16 Oct 2014 19:24:52 +0200, Stefano Zacchiroli wrote: 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. Speaking of which, before deciding anything (including seconding it or not) about this proposal, I'd like to know what impact a positive outcome of this GR would have on the work load of teams whose efforts we badly need to put the Jessie release in shape. Secon^WAgreed. And let me add a question: What does this GR actually mean in practice? Is it about specific problems? If yes, which ones (bug numbers)? If not, what else? Cheers, gregor -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - http://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of the Free Software Foundation Europe `- NP: Beatles: Rocky Raccoon signature.asc Description: Digital Signature
Re: Re-Proposal - preserve freedom of choice of init systems
Adam D. Barratt wrote: Speaking for no-one other than myself, I _am_ very unhappy that given how long the discussion has been rumbling on for, and how much opportunity there has been, that anyone thought that two weeks before the freeze (which has had a fixed date for nearly a year now) was the right time to raise this. +1 million (Seriously considering going on VAC until the release now, however long that will turn out to be.) -- see shy jo signature.asc Description: Digital signature
Re: Re-Proposal - preserve freedom of choice of init systems
gregor herrmann gre...@debian.org (2014-10-16): On Thu, 16 Oct 2014 19:24:52 +0200, Stefano Zacchiroli wrote: 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. Speaking of which, before deciding anything (including seconding it or not) about this proposal, I'd like to know what impact a positive outcome of this GR would have on the work load of teams whose efforts we badly need to put the Jessie release in shape. Secon^WAgreed. And let me add a question: What does this GR actually mean in practice? Is it about specific problems? If yes, which ones (bug numbers)? If not, what else? My personal hunch would be: https://lists.debian.org/debian-devel/2014/10/msg00308.html Mraw, KiBi. signature.asc Description: Digital signature
Re: Re-Proposal - preserve freedom of choice of init systems
On 16 October 2014 22:13, Ansgar Burchardt ans...@debian.org wrote: Aigars Mahinovs aigar...@debian.org writes: We have all kinds of policies about what is fine in a package and what is a Release Critical bug. That is a big part of what makes a distribution. This simply adds - must be able to work with any init system running at PID 1 to those requirements. No, it does not mean packages have to work with *any* init system. It's specifically aimed against a specific init replacement, see [1]. See, there is a clear difference: * if your software works the same regardless of what process started it up - that is fine. (Even if you just provide a convenience start-up script just for one init system.) * if your software only works if started by this one init system - that is a problem. The requirement is that software should be able to work regardless of how it is started - by systemd, by sysvinit, by other init system or by a plain shell script called from the init= kernel parameter. If there are any dependant services, those should be also able to be simply startable by anything. All software in previous Debian releases satisfied this requirement, so there wasn't even any need to consider adding such requirement to the policy. -- Best regards, Aigars Mahinovsmailto:aigar...@debian.org #--# | .''`.Debian GNU/Linux (http://www.debian.org)| | : :' : Latvian Open Source Assoc. (http://www.laka.lv) | | `. `'Linux Administration and Free Software Consulting | | `- (http://www.aiteki.com) | #--# -- 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/CABpYwDXLb9vm_xR=cux2rhkz5ei4bbfarss7wfrtqvvnr3v...@mail.gmail.com
Re: Re-Proposal - preserve freedom of choice of init systems
On Thu, Oct 16, 2014 at 11:03:49PM +0300, Aigars Mahinovs wrote: See, there is a clear difference: [snip] * if your software only works if started by this one init system - that is a problem. I don't quite understand this - what if you depend on something that's only provided / supported on one init system? Take for example the case of logind before we had the shim? The requirement is that software should be able to work regardless of how it is started - by systemd, by sysvinit, by other init system or by a plain shell script called from the init= kernel parameter. If there are any dependant services, those should be also able to be simply startable by anything. So we can't rely on a new library until that library is supported on all init systems? (e.g. logind before shim, etc) All software in previous Debian releases satisfied this requirement, so there wasn't even any need to consider adding such requirement to the policy. Getting tired of these threads :( Paul -- .''`. Paul Tagliamonte paul...@debian.org | Proud Debian Developer : :' : 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `. `'` http://people.debian.org/~paultag `- http://people.debian.org/~paultag/conduct-statement.txt signature.asc Description: Digital signature
Re: Re-Proposal - preserve freedom of choice of init systems
On 16 October 2014 23:07, Paul Tagliamonte paul...@debian.org wrote: * if your software only works if started by this one init system - that is a problem. I don't quite understand this - what if you depend on something that's only provided / supported on one init system? Take for example the case of logind before we had the shim? According to my reading of the proposal - either logind gets an RC bug for not being able to work with other init systems (here logind is considered a separate piece of software) or apps who have a hard dependency on logind (without fallbacks for cases when it does not exist or is not running) get a RC bug for that (here logind is considered to be an integral part of systemd). The requirement is that software should be able to work regardless of how it is started - by systemd, by sysvinit, by other init system or by a plain shell script called from the init= kernel parameter. If there are any dependant services, those should be also able to be simply startable by anything. So we can't rely on a new library until that library is supported on all init systems? (e.g. logind before shim, etc) I'd see it as - new library can't get into Debian [stable release] until is capable of working with installations being managed by any init system or even no init system at all (like inside a Docker container ;)). All software in previous Debian releases satisfied this requirement, so there wasn't even any need to consider adding such requirement to the policy. Getting tired of these threads :( True that. But at least this is about an actual point. (IMHO) -- Best regards, Aigars Mahinovsmailto:aigar...@debian.org #--# | .''`.Debian GNU/Linux (http://www.debian.org)| | : :' : Latvian Open Source Assoc. (http://www.laka.lv) | | `. `'Linux Administration and Free Software Consulting | | `- (http://www.aiteki.com) | #--# -- 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/CABpYwDURez_V93MCaG-JrJ0mZCFsT1C_wRwQ6Wozb=2zl6z...@mail.gmail.com
Re: Re-Proposal - preserve freedom of choice of init systems
On Thu, Oct 16, 2014 at 11:20:13PM +0300, Aigars Mahinovs wrote: According to my reading of the proposal - either logind gets an RC bug for not being able to work with other init systems To be clear, this would be a bug against src:systemd about it not working with non-systemd. Do we expect the systemd maintainers to fix this? (here logind is considered a separate piece of software) or apps who have a hard dependency on logind (without fallbacks for cases when it does not exist or is not running) get a RC bug for that (here logind is considered to be an integral part of systemd). Here, we will likely do invasive forks of major upstream software (GNOME) to get around a local requirement; do we expect the GNOME team to do this? So we can't rely on a new library until that library is supported on all init systems? (e.g. logind before shim, etc) I'd see it as - new library can't get into Debian [stable release] until is capable of working with installations being managed by any init system or even no init system at all (like inside a Docker container ;)). I don't think it's unfair that things don't work in Docker if they need some userland stuff that isn't around. Getting tired of these threads :( True that. But at least this is about an actual point. (IMHO) Word. Still on VAC-ly yours, Paul -- .''`. Paul Tagliamonte paul...@debian.org | Proud Debian Developer : :' : 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `. `'` http://people.debian.org/~paultag `- http://people.debian.org/~paultag/conduct-statement.txt signature.asc Description: Digital signature
second
I second Ian Jackson's proposal 'preserve freedom of choice of init systems' craig signature.asc Description: Digital signature
Re: Re-Proposal - preserve freedom of choice of init systems
On 16 October 2014 23:26, Paul Tagliamonte paul...@debian.org wrote: On Thu, Oct 16, 2014 at 11:20:13PM +0300, Aigars Mahinovs wrote: According to my reading of the proposal - either logind gets an RC bug for not being able to work with other init systems To be clear, this would be a bug against src:systemd about it not working with non-systemd. Do we expect the systemd maintainers to fix this? To be frank, in cases like logind I would expect the logind binary package to be split out and its source patched in such a way to allow it to work without systemd running (however badly) and moving the main systemd package from Dependencies to Recommended. This would be no different if, for example, some upstream decided that they need to copy some common library, modify it and statically compile that modified version into their software - we would expect the maintainer to either convince upstream not to do that or to make and maintain a patch that would make the software work with the system shared version of the library. The proposal does explicitly allow for the software to have degraded functionality if an unsupported init system is used, so such shim is a valid option. [snip] I don't think it's unfair that things don't work in Docker if they need some userland stuff that isn't around. Well, if you want it around, you should be able to start it inside that container (or a chroot), without having to start up an init system there. And ideally have a way of connecting to that userland stuff running in host or other container by simply sharing some socket (file or network). Having such policy clearly stated should also motivate upstreams to consider what would and should happen when another init system is used when designing new software features, so that our maintainers (or users) don't actually have to face this issue too often. -- Best regards, Aigars Mahinovsmailto:aigar...@debian.org #--# | .''`.Debian GNU/Linux (http://www.debian.org)| | : :' : Latvian Open Source Assoc. (http://www.laka.lv) | | `. `'Linux Administration and Free Software Consulting | | `- (http://www.aiteki.com) | #--# -- 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/cabpywdxmg+cjqpqkh8fbgx33zyk8qo0j8s47x5rbwebif4+...@mail.gmail.com
Re: Re-Proposal - preserve freedom of choice of init systems
* Ian Jackson ijack...@chiark.greenend.org.uk [141016 17:05]: -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/msg0.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- I hearby seconded this proposal, Bernhard R. Link signature.asc Description: Digital signature
Re: Re-Proposal - preserve freedom of choice of init systems
Can I ask people to move discussion that is not relevant to the vote to some other place? Kurt -- 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/20141016210738.ga21...@roeckx.be
Re: Re-Proposal - preserve freedom of choice of init systems
On 10/16/2014 11:07 PM, Kurt Roeckx wrote: Can I ask people to move discussion that is not relevant to the vote to some other place? Do you really think anyone will feel that their contribution was not relevant for the vote? Anyway, is someone willing to propose an option that would postpone preserving the freedom of choice of init systems till after the release? Kind regards Luk -- 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/544036c3.8050...@debian.org
Re: Re-Proposal - preserve freedom of choice of init systems
❦ 16 octobre 2014 16:26 -0400, Paul Tagliamonte paul...@debian.org : Here, we will likely do invasive forks of major upstream software (GNOME) to get around a local requirement; do we expect the GNOME team to do this? By turning such bugs into RC bugs, the proponents are exactly advocating this position: they put the burden on an under-staffed team. -- Localise input and output in subroutines. - The Elements of Programming Style (Kernighan Plauger) signature.asc Description: PGP signature
Re: Re-Proposal - preserve freedom of choice of init systems
On 2014-10-16 17:23, Ian Jackson wrote: Ian Jackson writes (Re-Proposal - preserve freedom of choice of init systems): 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/msg0.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. I'm sorry to drag you into this now, but I don't want to end up perhaps passing a GR and then have an argument about its meaning. Hi Ian, While I appreciate that this is a very important issue for a lot of people, I am deeply concerned by the point in time it is revived. _*We have less than 3 weeks till the Jessie freeze starts!*_ Even if you got the DPL shorting the GR by 2 weeks[1], it is still highly unlikely that the GR will be completed /prior/ to the freeze. 2. Loose coupling of init systems [...] To make this a concrete example, the intent of this text is: The GR says that it would be a bug for GNOME not to be installable without systemd, even on Linux. Uninstallability would normally be an RC bug. The GR says that this uninstallability bug is not less severe just because it is limited to non-systemd setups. Therefore, GNOME depending on systemd is an RC bug. Is that how the release team would interpret these paragraphs of the GR ? If not, can you please suggest a clarification ? One option would be to include this clarification in the GR text as an example. Ian. Honestly, I am interpreting this as a ticking time bomb under the freeze. Who exactly is volunteering to implement this GR if it goes through? Taking GNOME as a hypothetical example[2], suppose it was uninstallable without systemd and the GNOME maintainers say We do not want to implement this GR[3]. Then you leave us with a per GR-defined RC buggy default desktop from day one of the freeze and no one to clean it up. Be advised that I would very much be inclined to jessie-ignore such issues, if such stalemates end up as blockers for the release. Beyond that, I would /very much/ like to see guidelines for just how much degradation is tolerable. Honestly, I think this should be a part of the GR text. I do not want to end up as the bad guy having to enforce this GR during the freeze, when I most at all really do not want this GR to affect Jessie at all. ~Niels [1] Which he can per §4.2.3 and §4.2.4. [2] And a somewhat bad one since GNOME is actually is installable without systemd per https://lists.debian.org/debian-devel/2014/10/msg00412.html [3] Which is their right per §2.1.1: [...] A person who does not want to do a task which has been delegated or assigned to them does not need to do it. [...] -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54402ee7.4020...@thykier.net -- 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/54402ee7.4020...@thykier.net
Re: Re-Proposal - preserve freedom of choice of init systems
On 17 October 2014 08:25, Vincent Bernat ber...@debian.org wrote: By turning such bugs into RC bugs, the proponents are exactly advocating this position: they put the burden on an under-staffed team. If people feel strongly that init system XYZ should be supported, then presumably somebody will do the work to make sure it is supported, and it does work. As I believe is the case now. e.g. my understanding is Gnome is not dependant on systemd, and it didn't need any GR for this to happen. People didn't do this work only to have it reverted tomorrow. If nobody is willing to do the work to ensure it does work, maybe that suggests nobody really wants to support XYZ any more. The result of this GR is not going to change any of the above. It could build up resentment. Especially if maintainers get bug reports for initd systems they don't use, can't test, and can't find anybody willing to offer help to fix the problems. On another topic, I think we need a GR stating that all software should work 100% with any window manager, especially my favourite window manager, Awesome. Awesome is the only window manager that does X, Y, and Z properly (insert highly controversial/disputed and subjective criteria for X, Y Z, e.g. Unix philosophy, CLI support, keyboard support, single purpose non-integrated non-monolithic design, text configuration files, text log files, etc). If not supported, it prevents me exercising my choice in deciding what window manager I want to use. Never mind that this isn't a big issue; only a GR can guarantee it won't be an issue tomorrow. Anyone want to help me with my proposal? :-) -- Brian May br...@microcomaustralia.com.au
Re: Re-Proposal - preserve freedom of choice of init systems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I second Ian's Re-Proposal - preserve freedom of choice of init systems. https://lists.debian.org/debian-vote/2014/10/msg1.html Regards, Dimitri. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJUQFF9AAoJEIh7YGGLPBaucx0P/AvSlSGY4WTURHC1dSdt+bQ4 nRsEBtmZan636C8+2llHJwxJABezauPqa/YkkPfzxXYBB2EjHAyVKLKHFw3XWitB d+va2tKV4I9O+TX4h5SCimycz435/F3xtLay6UThoxDBSoYb/FXoA0NZvtkp6XX2 A/DVhkqiMVlyHftA5L+1UHULsSILckgCSCQH5HCAjNwXhqAQOtUawZIH2pnUNwR9 26PFaFgnRd1cm5kaNllJ+p5E6Pau5O/q3lBVqXnlw+bH3lTIc0H8SD5LPRMzAJPT 374x6zORUuSLfRADsFUvhM4TNHt6TID6rlvLpWrdT/KN0RXUVLWBxJMPfT/YZTnH RfxsuhUTK36xtFM3r6EvJ62WAt1Frhe48P92az9iS01DEt9hr4x9AkIQcq9hw2Ip zCxtny+jgZpeZJ4z79xYmv9cJW8DxjomGmTRxvt4k4AP4bjDuiFtqmzUZ5Vcmrvu NV4LDile0tezrWY/V/t7BYE0ac/s1fHeiqFGAE+IjSmGWNsSjY7+Ts4xa22xteKf XsmRK09ek01f7JctE2Ecu8MVw8LVQ/2DMFA17kuhZAXptZVdgfOyB/4Z7TWVrUdU E9aCPhl3PyukqubLs79GOlM+DJNnuPn5RQXC9T8spPoyWnHHCi1CsencIlAXmbnM +goPpADGVVIAcX8xYzIq =+RI/ -END PGP SIGNATURE- -- 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/54405180.9010...@debian.org
Proposed amendement: be more careful when proposing a GR.
Le Thu, Oct 16, 2014 at 04:05:41PM +0100, Ian Jackson a écrit : -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/msg0.html Hi Ian, the seconders, and everybody, I think that this GR does nothing but demotivating those doing the work. It may give a warm feeling to those who oppose the curent direction taken for Jessie, because they can satisfy themselves that they tried everything they could, but what Debian gains with this ? Nobody prepared a workable alternative, and opposing a change does not go automatically with the capacity of building the alternative. In the end, I think that this GR is just a show. I do not see it winning, nor even approaching majority. And I think that GRs should not be proposed if they have no serious chances to win, given that each GR costs us time, energy, division and bitternes (and I know what I am talking about). Therefore, I propose the following amendement. Please do not take it personnaly. --- The Debian project asks its members to be more considerate when proposing General Resolutions, and in particular to take care that the proposed GR has actual chances to be accepted, considering that GRs is a disruptive process regardless the outcome of the vote. --- Enhancements of the wording are welcome. Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan signature.asc Description: Digital signature
