Re: Reducing the discussion and the voting period to 1 week
Hi Lucas, 2014-10-22 17:22 GMT+02:00 Lucas Nussbaum : > Charles, Luca, can you confirm that you are also fine with shortening > the discussion period to one week? Fine for me. 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/cadk7b0myhwpcdgigdos2xsby83ggwaaifj1n-57fxornqni...@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 : > 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: 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 : > 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
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: [RFC] Alternative proposal: reaffirm upstream and maintainers technical competence over the software they maintain
2014-10-17 11:17 GMT+02:00 Thorsten Glaser : > Note that this paragraph *directly* goes against the *definition* of > a software distribution (take upstream software and integrate it with > the whole, occasionally going against upstream’s will) and towards a > unified userland.exe… Upstream could or could not consider downstream requirements while designing its own piece of software, and this is perfectly OK. As you said, it's the role of the software distribution developers to adapt a specific to the policy of the distribution, as I affirm in point 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/CADk7b0Put2ioisYuOsLb0-=x2-k-qlag9hppchanaaqaj9r...@mail.gmail.com
[RFC] Alternative proposal: reaffirm upstream and maintainers technical competence over the software they maintain
Dears, I'd like to draft an alternative proposal to the GR. Would anybody consider it a nice addition to the proposals we currently have, and eventually second it if I asked for it? Of course, improvements to the text are much more than welcome! ** Begin Alternative Proposal ** Proposal: Reaffirm upstream and maintainers technical competence over the software they maintain 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. 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. Freedom of upstream discrection Upstream Developers considering a 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. 3. Reaffirm Debian Maintainers goodwill Debian Maintainers' work is aiming to respect the Debian Social Contract, in such a way to provide our Users the best Free Software available. 4. Modifications to Upstream Software Debian Maintainers are fully entitled to provide modifications to the Free Software 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 a specific Free Software (including, but no limited to, a particular init system executed as PID 1), if they consider it necessary to prevent delivering broken, buggy, or otherwise incomplete software packages. 5. 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. ** End Proposal ** 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/CADk7b0Pow2RnOo0A1PK8i8CGAO3KyvF3iDkUDje=n52bzdl...@mail.gmail.com
Re: Reducing the discussion and the voting period to 1 week
2014-10-17 10:42 GMT+02:00 Lucas Nussbaum : > Note that our voting method is clone-proof, so one proposal cannot steal > votes from one another. That's one of the great things about Condorcet: > you can have similar proposals on the same ballot without causing the > votes to be split. Also numbers like "25%" don't really make sense with > Condorcet, unless you limit the calculation to two proposals. Yes, I'm fully aware of that. I still consider a choice between a very few options to be more direct to everybody, though (fellow developers, our users, and the vocal minority). 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/CADk7b0OuUzTjeWEUPdkO5-22woS-8=tcqnbywbnmh79s+s2...@mail.gmail.com
Re: Reducing the discussion and the voting period to 1 week
2014-10-17 10:01 GMT+02:00 Lucas Nussbaum : > So, I think that we need alternative proposal(s), [...] I agree with this point in principle, but we should avoid having too many options, leading to scattered votes. One party could "win" with less than 25% of the votes if the other ones are stealing votes one another, especially if they're aiming at the same goal, but with different statements. I see the Project is divided, and I see this like a "Black Or White" decision, so I'd welcome *two* clear, concise, and final statements to choose about how the Project wants to move forward. We left too many grey areas in the previous decisions which created too many interpretations, and these led to where we are now. This should come to an end. 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/cadk7b0mjtxrqgzx5sxvj399-nc_sbrs9gjmoykuzropae35...@mail.gmail.com
