Your behavior on Debian mailing lists
Hi Craig, Craig Sanders c...@taz.net.au writes: dishonest debating like this (i.e. petty ego-wankers like you point-scoring by malicious twisting of words and selective misquoting), is why i haven't bothered for years. i should have remembered that i have better things to do with my time. If you just come back from doing nothing to start insulting people who actually *do* a lot of work, please consider using your time for something more useful. Maybe you should also just consider to just leave offically... Please also at least read [1]. Ansgar [1] https://www.debian.org/code_of_conduct -- 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/87vbnhc23o@deep-thought.43-1.org
Re: Alternative proposal: support for alternative init systems is desirable but not mandatory
On 18/10/14 at 04:14 +0200, Jonas Smedegaard wrote: Thanks a lot for your analysis, Lucas. I find it _very_ helpful! Quoting Lucas Nussbaum (2014-10-17 22:23:14) Q2: support for alternative init systems as PID 1 = A2.1: packages MUST work with all alternative init systems as PID 1. (that's Ian's proposal) I disagree with your interpretation that _all_ alternative init systems are mandatory to support. Remove the all in the sentence, and it fits my interpretation of the proposal. @Ian: Probably wise to rephrase to avoid ambiguity here! [ Disclaimer: I put forward another proposal, but I don't care which one wins in the end provided it is what is best for Debian; I also disagree with the use of 'freedom' to characterize the technical ability to switch between init systems, but for clarity, I'm using 'freedom' in this email ] Given the motivations for the original proposal: 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. I don't think that it's useful to change this rule to: packages MUST work with at least one alternative init system as PID 1 or packages MUST work with some alternative init systems as PID 1 We could end up with different packages choosing different alternative init systems, or with a systemd-fork-with-the-same-interfaces-and-formats init system that makes it possible to satisfy the rule, while still effectively removing the 'freedom' to choose an init system that isn't looking like systemd. So I think that we are down to two solutions that really preserve the 'freedom' to choose an init system: 1) packages MUST work with all alternative init systems as PID 1. That's difficult. It means that if someone introduces a new init system with incompatible interfaces, it requires all maintainers to adjust their packages. So that rule would only make sense with many additional restrictions. 2) packages MUST work with a specific interface, which is basic enough to enable all alternative init systems to support it. The most natural such interface is currently sysvinit: if a package works with sysvinit as PID 1, it currently also works with upstart, openrc, etc. If we agree with the mostly uncontroversial answers: - packages MUST work with the default init system on Linux (Q1) - maintainers should be encouraged to accept patches that add or improve support for alternative init systems (Q4), especially when that alternative init system is the default on a non-Linux port (Q5) Then I think that the central question in this GR could be reduced to the following options: a) we say nothing about alternative init systems. wheezy-jessie upgrades might require switching to systemd, rebooting, and then upgrading other packages to keep a functional system b.1) sysvinit must be supported in jessie by packages that were in wheezy (that is what is closest to my original proposal) b.2) sysvinit must be supported in jessie by all packages; we don't say anything for jessie+1 (that is the minimum proposal that preserves freedom to choose init system in jessie) b.3) sysvinit must be supported by all packages (in jessie, but also in the future) (that is the minimum proposal that preserves freedom to choose init system on the longer term, which I understand is Ian's motivation for having that vote now, according to 21569.19669.726247.130...@chiark.greenend.org.uk) c.1) all init systems must be supported by all packages in jessie (nothing said about jessie+1) c.2) all init systems must be supported by all packages (in jessie, but also in the future) I believe that if we voted with those options, it would give us a good idea of how much we value the 'freedom' to choose an alternative init system, compared to the additional work required for supporting them. Options (a), (b.1), (b.2), (c.1) would not incur any additional work, given that they are limited to jessie, and the current state of jessie is fine AFAIK. An additional option, addressing answer A1.2 to Q1, could be required: @) support for the default init system is not mandatory But I suspect that it is so controversial that it's not worth putting on the ballot. Ian, do you agree that this correctly captures your opinion and the set of available options? What do you think of withdrawing both your and my proposal, and designing a ballot based on the above set of options (re-adding all the small details
Re: Proposed amendement: be more careful when proposing a GR.
Le Fri, Oct 17, 2014 at 12:37:19PM +0200, Matthias Urlichs a écrit : Charles Plessy: --- 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. --- Slightly reworded: The Debian project asks its members to be considerate when proposing General Resolutions, as the GR process may be disruptive regardless of the outcome of the vote. In particular, a proposed GR should have an actual chance of being accepted. Thanks Matthias, for the rewording. Are there people willing to second this reworded version ? Whichever the result of this GR, the people who did not want it will lose: at the very minimum, we lose our time. And to reject the initial proposal, we will have to either vote for “further discussion” while not being interested in disussing further, or for a status quo proposal that can be twisted and misused if it is not worded perfectly. This is why I am proposing this amendement, to say: “this GR was a bad idea, please do not do it again”. Have a nice week-end, -- Charles Plessy Tsurumi, Kanagawa, Japan signature.asc Description: Digital signature
Re: Re-Proposal - preserve freedom of choice of init systems
On Fri, Oct 17, 2014 at 09:14:06PM +0200, Kurt Roeckx wrote: So let's just assume for now that I would come to the same conclusion. When do you think you'll do an authoritative assessment of this matter? Thanks, -- 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: Alternative proposal: support for alternative init systems is desirable but not mandatory
On Fri, October 17, 2014 19:42, Kurt Roeckx wrote: On Fri, Oct 17, 2014 at 01:44:06PM +0100, Neil McGovern wrote: On Fri, Oct 17, 2014 at 09:44:16AM +0200, Lucas Nussbaum wrote: I am therefore bringing forward an alternative proposal Recieved, and verified. Note, this has been proposed by the current Project Leader, and thus does not require seconds, but will record those seconding anyway. I don't see him doing it with his DPL hat on, so Lucas can you clarify that you do this as DPL or not? (But there seem to be enough seconds, so it doesn't seem to matter.) Does the constituion has a concept of hats? You're either the DPL or you're not. It seems Lucas is the DPL. If Lucas proposes an amendment, the DPL has proposed an amendment, right? Thijs -- 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/d08288dcef825ddc6f2d2b5c88850600.squir...@aphrodite.kinkhorst.nl
Alternative proposal: reaffirm maintainers technical competence over the software they maintain
Dear fellow Developers, I would like to propose the following amendment proposal, and I hereby call for seconds. ** Begin Alternative 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 reaffirms the Debian Social Contract #4, in such a way that Debian acknowledges the choices made by both the software developers (also known as upstream developers) and the Debian package maintainers to provide the best free software to our users. Upstream developers considering specific free software (including, but not limited to, a particular init system executed as PID 1) fundamental to deliver the best software releases, are fully entitled to require, link, or depend on that software, or portions of it. Debian maintainers' work is aiming to respect the Debian Social Contract, in such a way to provide our users the best free software available. Debian maintainers are fully entitled to provide modifications to the free software packages they maintain as per DFSG #3, if they judge this necessary to provide the best software releases. On the other hand, Debian maintainers are fully entitled to adhere to upstream's decisions to require, link, or depend on specific free software (including, but no limited to, particular init system executed as PID 1), if they consider it necessary to prevent delivering broken, buggy, or otherwise incomplete software packages. The Debian Project states that: 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. Specific init systems as PID 1 Debian packages may require a specific init system to be executed as PID 1 if their maintainers consider this a requisite for its proper operation by clearly mark this in package descriptions and/or by adding dependencies in order to enforce this; and no patches or other derived works exist in order to support other init systems in such a way to render software usable to the same extent. 3. Evidence of defects (bugs) We strongly reaffirm Debian maintainers are not deliberately hiding problems (Social Contract #3). No technical decisions shall be overruled if no proper evidence of defects, issued in the Debian Bug Tracking system, is found. Fear, uncertainty, and doubt are not considered as evidence of defects. 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 above in sections #1, #2 and #3. ** End Proposal ** Thank you for reading so far. Cheers, Luca signature.asc Description: Digital signature
Re: Re-Proposal - preserve freedom of choice of init systems
On Sat, Oct 18, 2014 at 11:40:49AM +0200, Stefano Zacchiroli wrote: On Fri, Oct 17, 2014 at 09:14:06PM +0200, Kurt Roeckx wrote: So let's just assume for now that I would come to the same conclusion. When do you think you'll do an authoritative assessment of this matter? I did have to come to the same conclusion. 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/20141018103515.ga16...@roeckx.be
Re: Alternative proposal: reaffirm maintainers technical competence over the software they maintain
Hi, On Samstag, 18. Oktober 2014, Luca Falavigna wrote: ** Begin Alternative 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 reaffirms the Debian Social Contract #4, in such a way that Debian acknowledges the choices made by both the software developers (also known as upstream developers) and the Debian package maintainers to provide the best free software to our users. Upstream developers considering specific free software (including, but not limited to, a particular init system executed as PID 1) fundamental to deliver the best software releases, are fully entitled to require, link, or depend on that software, or portions of it. Debian maintainers' work is aiming to respect the Debian Social Contract, in such a way to provide our users the best free software available. Debian maintainers are fully entitled to provide modifications to the free software packages they maintain as per DFSG #3, if they judge this necessary to provide the best software releases. On the other hand, Debian maintainers are fully entitled to adhere to upstream's decisions to require, link, or depend on specific free software (including, but no limited to, particular init system executed as PID 1), if they consider it necessary to prevent delivering broken, buggy, or otherwise incomplete software packages. The Debian Project states that: 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. Specific init systems as PID 1 Debian packages may require a specific init system to be executed as PID 1 if their maintainers consider this a requisite for its proper operation by clearly mark this in package descriptions and/or by adding dependencies in order to enforce this; and no patches or other derived works exist in order to support other init systems in such a way to render software usable to the same extent. 3. Evidence of defects (bugs) We strongly reaffirm Debian maintainers are not deliberately hiding problems (Social Contract #3). No technical decisions shall be overruled if no proper evidence of defects, issued in the Debian Bug Tracking system, is found. Fear, uncertainty, and doubt are not considered as evidence of defects. 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 above in sections #1, #2 and #3. ** End Proposal ** seconded. Thank you for reading so far. Thanks for writing! cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: Alternative proposal: reaffirm maintainers technical competence over the software they maintain
* Luca Falavigna dktrkr...@debian.org [2014-10-18 12:21:18 +0200]: Dear fellow Developers, I would like to propose the following amendment proposal, and I hereby call for seconds. ** Begin Alternative Proposal ** [snip] 2. Specific init systems as PID 1 Debian packages may require a specific init system to be executed as PID 1 if their maintainers consider this a requisite for its proper operation by clearly mark this in package descriptions and/or ^- missing an ing by adding dependencies in order to enforce this; and no patches or other derived works exist in order to support other init systems in such a way to render software usable to the same extent. [snip] ** End Proposal ** Thank you for bringing this proposal up. Seconded. Cheers, -- Nicolas Dandrimont BOFH excuse #404: Sysadmin accidentally destroyed pager with a large hammer. signature.asc Description: Digital signature
Re: Alternative proposal: reaffirm maintainers technical competence over the software they maintain
On Sat, Oct 18, 2014 at 12:21:18PM +0200, Luca Falavigna wrote: ** Begin Alternative 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 reaffirms the Debian Social Contract #4, in such a way that Debian acknowledges the choices made by both the software developers (also known as upstream developers) and the Debian package maintainers to provide the best free software to our users. Upstream developers considering specific free software (including, but not limited to, a particular init system executed as PID 1) fundamental to deliver the best software releases, are fully entitled to require, link, or depend on that software, or portions of it. Debian maintainers' work is aiming to respect the Debian Social Contract, in such a way to provide our users the best free software available. Debian maintainers are fully entitled to provide modifications to the free software packages they maintain as per DFSG #3, if they judge this necessary to provide the best software releases. On the other hand, Debian maintainers are fully entitled to adhere to upstream's decisions to require, link, or depend on specific free software (including, but no limited to, particular init system executed as PID 1), if they consider it necessary to prevent delivering broken, buggy, or otherwise incomplete software packages. The Debian Project states that: 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. Specific init systems as PID 1 Debian packages may require a specific init system to be executed as PID 1 if their maintainers consider this a requisite for its proper operation by clearly mark this in package descriptions and/or by adding dependencies in order to enforce this; and no patches or other derived works exist in order to support other init systems in such a way to render software usable to the same extent. 3. Evidence of defects (bugs) We strongly reaffirm Debian maintainers are not deliberately hiding problems (Social Contract #3). No technical decisions shall be overruled if no proper evidence of defects, issued in the Debian Bug Tracking system, is found. Fear, uncertainty, and doubt are not considered as evidence of defects. 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 above in sections #1, #2 and #3. ** End Proposal ** Seconded. -- WBR, wRAR signature.asc Description: Digital signature
Re: Alternative proposal: reaffirm maintainers technical competence over the software they maintain
On 10/18/2014 at 06:21 AM, Luca Falavigna wrote: Dear fellow Developers, I would like to propose the following amendment proposal, and I hereby call for seconds. ** Begin Alternative Proposal ** 2. Specific init systems as PID 1 Debian packages may require a specific init system to be executed as PID 1 if their maintainers consider this a requisite for its proper operation by clearly mark this in package descriptions and/or by adding dependencies in order to enforce this; and no patches or other derived works exist in order to support other init systems in such a way to render software usable to the same extent. One potential problem which I see with this: Imagine a scenario in which this GR had not been raised, and jessie had been released with systemd as default init system, and so forth. Imagine that the maintainer of package foo decides, as they are entitled to do under this proposal, that 'foo requires upstart for proper operation' (choosing upstart just as an example here), and adds a dependency on a hypothetical set-upstart-as-PID-1 package. Imagine then that someone who is running happily with systemd as PID 1 decides to install package foo. This would cause their system to be switched from systemd as PID 1 to upstart as PID 1, comparably to what now happens when someone who is not running with systemd as PID 1 installs a package which depends on systemd-sysv. It seems unthinkable to me that this would not be considered a problem; as far as I can tell, the only reason that the dependency-based switch to systemd under the current arrangement is potentially not considered a problem is that systemd has been designated as the default init system for jessie, which would not be true of upstart in this hypothetical case. Yet under this proposal, the package maintainers would be fully entitled to do exactly the things which necessarily result in this problematic scenario. According to my best assessment at present, that type of scenario seems to be exactly (or at least a significant part of) what the original GR proposal is trying to prevent - in a broader form, which is not specific to any particular pair of init systems. This proposal would not prevent that scenario, and indeed would seem to enshrine it as something which is fully allowed. The only way I can see to avoid that scenario without a rule that no package may depend on a particular init system being PID 1 would be to add functionality to apt and/or dpkg to detect (probably at dependency-resolution time) when a package install triggered via a dependency will trigger a change of init system, and *reject* the install - requiring that the user / sysadmin specify the new-init-system package explicitly, rather than as a dependency, in order to trigger the actual init-system change. I don't know how difficult that would be to implement, but I imagine that it would be at least mildly controversial as well, although probably much less so than either systemd has been or this GR is proving to be. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Alternative proposal: reaffirm maintainers technical competence over the software they maintain
Hi, Thank you for your feedback! 2014-10-18 13:50 GMT+02:00 The Wanderer wande...@fastmail.fm: Imagine that the maintainer of package foo decides, as they are entitled to do under this proposal, that 'foo requires upstart for proper operation' (choosing upstart just as an example here), and adds a dependency on a hypothetical set-upstart-as-PID-1 package. Imagine then that someone who is running happily with systemd as PID 1 decides to install package foo. This would cause their system to be switched from systemd as PID 1 to upstart as PID 1, comparably to what now happens when someone who is not running with systemd as PID 1 installs a package which depends on systemd-sysv. I consider out of scope for this proposal to discuss a method to prevent an accidental change of default init system, even though I'd welcome such a technical feature to be designed sooner than later. Yet under this proposal, the package maintainers would be fully entitled to do exactly the things which necessarily result in this problematic scenario. I will emphasize a couple of sentences in my proposal: Debian packages *may* require a specific init system [...] [...] if their maintainers consider this a *requisite* [...] [...] *and* no patches or other derived works exist [...] [...] to support other init systems. I consider requiring a specific init system as a last resort when every possible technical solution failed, and nobody stepped in to provide alternative solutions not considered before. Note that I didn't use should, but may, as I don't consider this proposal a suggestion to avoid providing valid technical solutions to support other init systems, especially if this may turn to be a quite trivial exercise. Cheers, Luca -- 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/CADk7b0Mr3CVDchfCTQ9Md-F8KSUDXS7a+VrVdY74R=bhfyw...@mail.gmail.com
Re: Alternative proposal: reaffirm maintainers technical competence over the software they maintain
Hi Lucas, Thank you for your feedback! 2014-10-18 14:13 GMT+02:00 Lucas Nussbaum lu...@debian.org: 1) packages may require the default init system if: - their maintainer consider this a prerequisite for its proper operation - no patches or other derived works exist in order to support other init systems 2) packages may require an init system other than the default init system if: - their maintainer consider this a prerequisite for its proper operation - no patches or other derived works exist in order to support other init systems, including the default init system These two cases are very different. I agree. I consider the first case the actual policy (or best practice, as worst), and I'm still in favour of it. The second case tries to address the cases where some packages will become immediately RC buggy because of a change in the default init system. The following scenarios could happen if a change in the default init system occurs anytime in Debian: The workflow without this proposal would be something like this. * Maintainer is notified her software no longer works with the default init * Maintainer looks how to support the default init (asking advice upstream, welcoming patches from other contributors, writing patches herself, etc.) * If nothing can be done, the package becomes unsuitable for a release, and maintainer could be probably advised to ask for the removal of the software. The workflow after this proposal would be something like this: * Maintainer is notified her software no longer works with the default init * Maintainer looks how to support the default init (asking advice upstream, welcoming patches from other contributors, writing patches herself, etc.) * If nothing can be done, maintainer can inform users about the requirement of a specific init system as PID 1, leaving users the freedom to switch the default init system. This can be done by explicitly add a dependency to a package which switches the default init system. (Note that I consider out of scope for this proposal to discuss a method to prevent an accidental change of default init system). (2) could lead to fragmentation in the services/init systems available in Debian, because it would no longer be the maintainers' responsibility to ensure that all packages work with the same init system. I still consider maintainers' responsibility to aim for maximum standardization, including, but not limited to, the default init system the software they package and distribute will run upon. As I stated in the Rationale paragraph: if [maintainers] consider [requiring a specific init system to run as PID 1] necessary to prevent delivering broken, buggy, or otherwise incomplete software maintainers could decide to strictly depend on a specific init system if there is no possible way to avoid that (key word: *necessary*). On the other hand, if solutions exist (#2), they could consider applying such solutions, or being overruled by fellow developers (#3). Cheers, Luca -- 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/CADk7b0PWg4Q5hywg--oq=+fz0oz3+rpoflkeajxboxvblhd...@mail.gmail.com
Re: Proposed amendement: be more careful when proposing a GR.
Hi, Charles Plessy: This is why I am proposing this amendement, to say: “this GR was a bad idea, please do not do it again”. I would not regard it as an amendment, but as a separate alternative option on the ballot. If I were you, I'd add another paragraph, like Regarding the subject of this ballot, the Project affirms that the question has already been resolved and thus does not require a General Resolution. and then formally ask for seconds. -- -- Matthias Urlichs -- 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/20141018153127.ga24...@smurf.noris.de
Re: Alternative proposal: reaffirm maintainers technical competence over the software they maintain
Hi Luca, On 18/10/14 at 15:53 +0200, Luca Falavigna wrote: Hi Lucas, Thank you for your feedback! 2014-10-18 14:13 GMT+02:00 Lucas Nussbaum lu...@debian.org: 1) packages may require the default init system if: - their maintainer consider this a prerequisite for its proper operation - no patches or other derived works exist in order to support other init systems 2) packages may require an init system other than the default init system if: - their maintainer consider this a prerequisite for its proper operation - no patches or other derived works exist in order to support other init systems, including the default init system These two cases are very different. I agree. I consider the first case the actual policy (or best practice, as worst), and I'm still in favour of it. The second case tries to address the cases where some packages will become immediately RC buggy because of a change in the default init system. The following scenarios could happen if a change in the default init system occurs anytime in Debian: The workflow without this proposal would be something like this. * Maintainer is notified her software no longer works with the default init * Maintainer looks how to support the default init (asking advice upstream, welcoming patches from other contributors, writing patches herself, etc.) * If nothing can be done, the package becomes unsuitable for a release, and maintainer could be probably advised to ask for the removal of the software. The workflow after this proposal would be something like this: * Maintainer is notified her software no longer works with the default init * Maintainer looks how to support the default init (asking advice upstream, welcoming patches from other contributors, writing patches herself, etc.) * If nothing can be done, maintainer can inform users about the requirement of a specific init system as PID 1, leaving users the freedom to switch the default init system. This can be done by explicitly add a dependency to a package which switches the default init system. (Note that I consider out of scope for this proposal to discuss a method to prevent an accidental change of default init system). While I understand your concerns, I think that it is highly unlikely that we will decide to change the default init system to something that would break existing packages without a known reasonable way to fix them. (2) could lead to fragmentation in the services/init systems available in Debian, because it would no longer be the maintainers' responsibility to ensure that all packages work with the same init system. I still consider maintainers' responsibility to aim for maximum standardization, including, but not limited to, the default init system the software they package and distribute will run upon. As I stated in the Rationale paragraph: if [maintainers] consider [requiring a specific init system to run as PID 1] necessary to prevent delivering broken, buggy, or otherwise incomplete software maintainers could decide to strictly depend on a specific init system if there is no possible way to avoid that (key word: *necessary*). On the other hand, if solutions exist (#2), they could consider applying such solutions, or being overruled by fellow developers (#3). Both: [...] if they consider it necessary to prevent delivering broken, buggy, or otherwise incomplete software packages and: to render software usable to the same extent are quite far-reaching criteria to allow maintainers to break standardization. I value standardization and integration very highly, and would be more comfortable (more likely to vote this above FD) with e.g.: On the other hand, Debian maintainers are fully entitled [...], if they consider it necessary to prevent delivering broken software packages, or software packages that would be unsuitable for a Debian release. and: ; and no patches or other derived works exist in order to support other init systems in such a way to render software basically usable. However, we can agree to disagree on the above. Thanks for the clarifications! Lucas -- 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/20141018154825.ga32...@xanadu.blop.info
Re: Alternative proposal: reaffirm maintainers technical competence over the software they maintain
Hi, Lucas Nussbaum: While I understand your concerns, I think that it is highly unlikely that we will decide to change the default init system to something that would break existing packages without a known reasonable way to fix them. Exactly. We decided to change our (default) init system. Work to make sure that everything works both with the new and the old (or rather, pretty much any other) init system is ongoing. This work started before this GR came to be, and it will cwcontinuehappen afterwards, regardless of how this vote turns out. The whole thing is therefore, essentially, a waste of time. IMHO. -- -- Matthias Urlichs signature.asc Description: Digital signature
Re: Alternative proposal: reaffirm maintainers technical competence over the software they maintain
On Sat, Oct 18, 2014 at 12:21:18PM +0200, Luca Falavigna wrote: ** Begin Alternative 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 reaffirms the Debian Social Contract #4, in such a way that Debian acknowledges the choices made by both the software developers (also known as upstream developers) and the Debian package maintainers to provide the best free software to our users. Upstream developers considering specific free software (including, but not limited to, a particular init system executed as PID 1) fundamental to deliver the best software releases, are fully entitled to require, link, or depend on that software, or portions of it. Debian maintainers' work is aiming to respect the Debian Social Contract, in such a way to provide our users the best free software available. Debian maintainers are fully entitled to provide modifications to the free software packages they maintain as per DFSG #3, if they judge this necessary to provide the best software releases. On the other hand, Debian maintainers are fully entitled to adhere to upstream's decisions to require, link, or depend on specific free software (including, but no limited to, particular init system executed as PID 1), if they consider it necessary to prevent delivering broken, buggy, or otherwise incomplete software packages. The Debian Project states that: 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. Specific init systems as PID 1 Debian packages may require a specific init system to be executed as PID 1 if their maintainers consider this a requisite for its proper operation by clearly mark this in package descriptions and/or by adding dependencies in order to enforce this; and no patches or other derived works exist in order to support other init systems in such a way to render software usable to the same extent. 3. Evidence of defects (bugs) We strongly reaffirm Debian maintainers are not deliberately hiding problems (Social Contract #3). No technical decisions shall be overruled if no proper evidence of defects, issued in the Debian Bug Tracking system, is found. Fear, uncertainty, and doubt are not considered as evidence of defects. 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 above in sections #1, #2 and #3. ** End Proposal ** Seconded. -- Antonio Terceiro terce...@debian.org signature.asc Description: Digital signature
Re: Alternative proposal: reaffirm maintainers technical competence over the software they maintain
Hi Luca, On 18.10.2014 12:21, Luca Falavigna wrote: ** Begin Alternative 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 reaffirms the Debian Social Contract #4, in such a way that Debian acknowledges the choices made by both the software developers (also known as upstream developers) and the Debian package maintainers to provide the best free software to our users. Upstream developers considering specific free software (including, but not limited to, a particular init system executed as PID 1) fundamental to deliver the best software releases, are fully entitled to require, link, or depend on that software, or portions of it. Debian maintainers' work is aiming to respect the Debian Social Contract, in such a way to provide our users the best free software available. Debian maintainers are fully entitled to provide modifications to the free software packages they maintain as per DFSG #3, if they judge this necessary to provide the best software releases. On the other hand, Debian maintainers are fully entitled to adhere to upstream's decisions to require, link, or depend on specific free software (including, but no limited to, particular init system executed as PID 1), if they consider it necessary to prevent delivering broken, buggy, or otherwise incomplete software packages. The Debian Project states that: 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. Specific init systems as PID 1 Debian packages may require a specific init system to be executed as PID 1 if their maintainers consider this a requisite for its proper operation by clearly mark this in package descriptions and/or by adding dependencies in order to enforce this; and no patches or other derived works exist in order to support other init systems in such a way to render software usable to the same extent. 3. Evidence of defects (bugs) We strongly reaffirm Debian maintainers are not deliberately hiding problems (Social Contract #3). No technical decisions shall be overruled if no proper evidence of defects, issued in the Debian Bug Tracking system, is found. Fear, uncertainty, and doubt are not considered as evidence of defects. 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 above in sections #1, #2 and #3. ** End Proposal ** I do hereby second your proposal. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Re: Alternative proposal: reaffirm maintainers technical competence over the software they maintain
Hi. On Sat, Oct 18, 2014 at 12:21:18PM +0200, Luca Falavigna wrote: ** Begin Alternative 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 reaffirms the Debian Social Contract #4, in such a way that Debian acknowledges the choices made by both the software developers (also known as upstream developers) and the Debian package maintainers to provide the best free software to our users. Upstream developers considering specific free software (including, but not limited to, a particular init system executed as PID 1) fundamental to deliver the best software releases, are fully entitled to require, link, or depend on that software, or portions of it. Debian maintainers' work is aiming to respect the Debian Social Contract, in such a way to provide our users the best free software available. Debian maintainers are fully entitled to provide modifications to the free software packages they maintain as per DFSG #3, if they judge this necessary to provide the best software releases. On the other hand, Debian maintainers are fully entitled to adhere to upstream's decisions to require, link, or depend on specific free software (including, but no limited to, particular init system executed as PID 1), if they consider it necessary to prevent delivering broken, buggy, or otherwise incomplete software packages. The Debian Project states that: 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. Specific init systems as PID 1 Debian packages may require a specific init system to be executed as PID 1 if their maintainers consider this a requisite for its proper operation by clearly mark this in package descriptions and/or by adding dependencies in order to enforce this; and no patches or other derived works exist in order to support other init systems in such a way to render software usable to the same extent. 3. Evidence of defects (bugs) We strongly reaffirm Debian maintainers are not deliberately hiding problems (Social Contract #3). No technical decisions shall be overruled if no proper evidence of defects, issued in the Debian Bug Tracking system, is found. Fear, uncertainty, and doubt are not considered as evidence of defects. 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 above in sections #1, #2 and #3. ** End Proposal ** Seconded. Kind regards and thanks Philipp Kern signature.asc Description: Digital signature
Re: Alternative proposal: reaffirm maintainers technical competence over the software they maintain
❦ 18 octobre 2014 12:21 +0200, Luca Falavigna dktrkr...@debian.org : Dear fellow Developers, I would like to propose the following amendment proposal, and I hereby call for seconds. ** Begin Alternative Proposal ** [...] Seconded. -- Format a program to help the reader understand it. - The Elements of Programming Style (Kernighan Plauger) signature.asc Description: PGP signature
Re: Alternative proposal: reaffirm maintainers technical competence over the software they maintain
Luca Falavigna dktrkr...@debian.org writes: 2. Specific init systems as PID 1 Debian packages may require a specific init system to be executed as PID 1 if their maintainers consider this a requisite for its proper operation by clearly mark this in package descriptions and/or by adding dependencies in order to enforce this; and no patches or other derived works exist in order to support other init systems in such a way to render software usable to the same extent. Weird grammar here. marking and the software would be better, but it still sounds awkward. 3. Evidence of defects (bugs) We strongly reaffirm Debian maintainers are not deliberately hiding problems (Social Contract #3). No technical decisions shall be overruled if no proper evidence of defects, issued in the Debian Bug Tracking system, is found. Fear, uncertainty, and doubt are not considered as evidence of defects. (Not a Debian Developer, but still curious) What's the motivatior and intention of this paragraph? I don't see how it connects to the rest of the proposal. Especially the last sentence sounds unneccessary. No one would dispute that FUD is not evidence of defects, the dispute is always what is FUD and what are hard facts (and the statement doesn't help with making that distinction at all). Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« -- 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/87bnp980vk@vostro.rath.org
Re: Re-Proposal - preserve freedom of choice of init systems
On Sat, Oct 18, 2014 at 4:00 AM, Simon Richter wrote: The technical shortcomings of systemd are the smaller problem here. The way I've been treated (stopping short of directly accusing me to actively look for problems to complain about) whenever I was raising a technical issue suggests to me that this is not a healthy ecosystem that can handle different viewpoints from members of the community. I have only gotten helpful hand-holding when reporting issues in #debian-systemd, even though usually those issues were the result of misconfigurations of my system. -- bye, pabs https://wiki.debian.org/PaulWise -- 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/CAKTje6ENPPNve7af9wiCsJMhVK78733TGQKtZq6fngNM7ut=b...@mail.gmail.com
