Re: Alternative proposal: reaffirm maintainers technical competence over the software they maintain
On Mon, Oct 20, 2014 at 11:55:30PM +0200, Lucas Nussbaum wrote: On 20/10/14 at 22:26 +0200, Arno T?ll wrote: That's - I think - a good default and affirms Debian's point of view that the respective maintainers can judge best what's a good requirement for their packages. Finally I encourage everyone to focus on the connotation in Luca's amendment. It allows maintainers to tie their software to a particular init system only as a last resort when absolutely necessary - not by pure choice, or by laziness. I disagree with this interpretation. We have processes in place in Debian to deal with such last resort situations: - someone opens an RC bug against the package, stating why it is unsuitable for release - the release team reviews the bug, and might (or not) mark it with the jessie-ignore tag This seems mistaken to me -- issues shouldn't have to be release critical to be reviewed, or go through the release team. I would have said the process should be: - discussion happens on -policy or -devel about what the best approach on some issue is - someone opens a bug against the package that takes a less effective approach - the maintainer reviews the bug and takes whatever action they consider appropriate - further discussion happens on the bug, -policy or -devel or similar - as a last resort, the matter is escalated to the tech ctte for review I don't think there's a need for that process to involve blocking a package from release, or any necessity to distract the release team from coordination issues to participate in resolving technical conflicts. I think that this would be a significant step backward in the way we promote consistent technical practices in all Debian packages. Promoting consistent technical practices is policy's purpose, not the release team's, surely? From what I can see, policy currently (version 3.9.6.0) covers init.d scripts and upstart, but doesn't mention systemd or unit files. That seems suboptimal to me...? Cheers, aj -- 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/20141021082155.ga11...@master.debian.org
Re: Alternative proposal: reaffirm maintainers technical competence over the software they maintain
Matthias Urlichs writes (Re: Alternative proposal: reaffirm maintainers technical competence over the software they maintain): Really? To me, For the record, the TC expects does not introduce a ruling. Precisely. It seems to be, rather, a strongly-worded but informal declaration how the TC is likely to rule, should a maintainer fail to meet this particular expectation. Indeed. 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/21574.15224.347405.22...@chiark.greenend.org.uk
Re: Alternative proposal: reaffirm maintainers technical competence over the software they maintain
Luca Falavigna dktrkr...@debian.org writes: 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 ** Seconded. -- |8] pgpVgi48kMiV7.pgp Description: PGP signature
Re: Alternative proposal: reaffirm maintainers technical competence over the software they maintain
Luca Falavigna dktrkr...@debian.org (2014-10-18): ** 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. KiBi. 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: 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 ** Seconded. -- .''`. 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: Alternative proposal: reaffirm maintainers technical competence over the software they maintain
On Sat, Oct 18, 2014 at 12:21:18PM +0200, Luca Falavigna wrote: Dear fellow Developers, I would like to propose the following amendment proposal, and I hereby call for seconds. All received and valid. Thanks, Neil -- signature.asc Description: Digital signature
Re: Alternative proposal: reaffirm maintainers technical competence over the software they maintain
Luca Falavigna wrote: 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. The tech committe made a separate ruling on this question, and decided: For the record, the TC expects maintainers to continue to support the multiple available init systems in Debian. That includes merging reasonable contributions, and not reverting existing support without a compelling reason. http://bugs.debian.org/746715 So, your proposal actually overrules this decision of the tech committe. IIRC, the TC decided to let their decision on https://bugs.debian.org/727708 be overridden by a simple majority. But not their decision on #746715. So wouldn't this amendment need a 2:1 majority to pass? -- see shy jo signature.asc Description: Digital signature
Re: Alternative proposal: reaffirm maintainers technical competence over the software they maintain
Le lundi, 20 octobre 2014, 14.14:58 Joey Hess a écrit : The tech committe made a separate ruling on this question, and decided: For the record, the TC expects maintainers to continue to support the multiple available init systems in Debian. That includes merging reasonable contributions, and not reverting existing support without a compelling reason. http://bugs.debian.org/746715 I didn't understand this as a technically binding ruling, rather as a forewarning to maintainers, from the TC; this is underlined by the the TC expects rather than explicitly using one of the TC powers (§6.1). So, your proposal actually overrules this decision of the tech committee. I don't see it that way; the developers' body would be exercising one TC power without overriding a previous decision. Let's see what the secretary@ (CC'ed) thinks… Cheers, OdyX -- 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/11496916.5mCyfBQSlK@gyllingar
Re: Alternative proposal: reaffirm maintainers technical competence over the software they maintain
Hi, Joey Hess: Luca Falavigna wrote: 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. The tech committe made a separate ruling on this question, and decided: For the record, the TC expects maintainers to continue to support the multiple available init systems in Debian. That includes merging reasonable contributions, and not reverting existing support without a compelling reason. http://bugs.debian.org/746715 So, your proposal actually overrules this decision of the tech committe. Really? To me, For the record, the TC expects does not introduce a ruling. It seems to be, rather, a strongly-worded but informal declaration how the TC is likely to rule, should a maintainer fail to meet this particular expectation. -- -- Matthias Urlichs signature.asc Description: Digital signature
Re: Alternative proposal: reaffirm maintainers technical competence over the software they maintain
Didier 'OdyX' Raboud o...@debian.org writes: Le lundi, 20 octobre 2014, 14.14:58 Joey Hess a écrit : The tech committe made a separate ruling on this question, and decided: For the record, the TC expects maintainers to continue to support the multiple available init systems in Debian. That includes merging reasonable contributions, and not reverting existing support without a compelling reason. http://bugs.debian.org/746715 I didn't understand this as a technically binding ruling, rather as a forewarning to maintainers, from the TC; this is underlined by the the TC expects rather than explicitly using one of the TC powers (§6.1). When voting on this, I understood it to fall under the TC's authority to issue technical advice to the project, not under any of the TC decision-making powers. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87fvei8t2z@hope.eyrie.org
Re: Alternative proposal: reaffirm maintainers technical competence over the software they maintain
On 20 October 2014 21:14, Joey Hess jo...@debian.org wrote: Luca Falavigna wrote: 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. The tech committe made a separate ruling on this question, and decided: For the record, the TC expects maintainers to continue to support the multiple available init systems in Debian. That includes merging reasonable contributions, and not reverting existing support without a compelling reason. http://bugs.debian.org/746715 That is actually a slightly different issue. In bug #746715 supporting an init system meant providing an init script to launch your service with that init system (or changing some return codes in the existing init script). It is assumed, that with a proper init script any service would work with any init system. In the context of this GR supporting an init system means being able to start the service at all if this init system is running as PID 1. This is a completely new problem created upstream. The fact that upstream created the problem also provides a compelling reason not to support any other init systems. And that is coupling - an actual, real dependency on an init system not just being installed, but also running as PID 1. Even if TC decision were expressed as binding, it would not ban/prevent such coupling. Ians proposal, however, would explicitly make such coupling a bug and would directly determine severity of that bug to grave if the package is completely unusable for users of alternative init systems. -- 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/CABpYwDWNV5-xZ20N6XcWqVm4S-m5fPis=gbjcd+sswl+w3t...@mail.gmail.com
Re: Alternative proposal: reaffirm maintainers technical competence over the software they maintain
On Mon, Oct 20, 2014 at 08:46:19PM +0200, Didier 'OdyX' Raboud wrote: Le lundi, 20 octobre 2014, 14.14:58 Joey Hess a écrit : The tech committe made a separate ruling on this question, and decided: For the record, the TC expects maintainers to continue to support the multiple available init systems in Debian. That includes merging reasonable contributions, and not reverting existing support without a compelling reason. http://bugs.debian.org/746715 I didn't understand this as a technically binding ruling, rather as a forewarning to maintainers, from the TC; this is underlined by the the TC expects rather than explicitly using one of the TC powers (§6.1). So, your proposal actually overrules this decision of the tech committee. I don't see it that way; the developers' body would be exercising one TC power without overriding a previous decision. Let's see what the secretary@ (CC'ed) thinks... Either it's a position statement, or we're making position statement (4.1.5), or using the TC's power (4.1.4). In #727708 it says that a position statement will replace this TC resolution. In #746715 there is no such text. So the question is going to be if this options overrides #746715 or not. I didn't look into it yet, so I might be turning 1 or more of the options into overrding the TC and put them under 4.1.4. 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/20141020193329.ga5...@roeckx.be
Re: Alternative proposal: reaffirm maintainers technical competence over the software they maintain
Hi Kurt, On 20.10.2014 21:33, Kurt Roeckx wrote: So the question is going to be if this options overrides #746715 or not. I didn't look into it yet, so I might be turning 1 or more of the options into overrding the TC and put them under 4.1.4. I do not follow you on this argumentation. The amendment text does not disagree with, or overrule, the resolution #746715 in any way. It does not endorse maintainers to drop support for a particular init system. Quite in contrary, it emphasizes to focus on the best user experience (Debian package maintainers [shall] provide the best free software to our users) which, of course, also includes users of non-default init systems. That being said, this amendment would also allow a stronger coupling to a particular init system, when the packaged software requires it in a fundamental way, at risk of delivering broken, buggy, or otherwise incomplete software packages otherwise. So in summary, this amendment let's people continue to use whatever init system they prefer, including, but not limited to the project-wide chosen default system, and it does in no way suggest to drop any alternative init system support unless absolutely necessary without shifting the burden of upstream's design decisions to the Debian package maintainers. That's - I think - a good default and affirms Debian's point of view that the respective maintainers can judge best what's a good requirement for their packages. Finally I encourage everyone to focus on the connotation in Luca's amendment. It allows maintainers to tie their software to a particular init system only as a last resort when absolutely necessary - not by pure choice, or by laziness. -- 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
On Mon, Oct 20, 2014 at 10:26:08PM +0200, Arno Töll wrote: Hi Kurt, On 20.10.2014 21:33, Kurt Roeckx wrote: So the question is going to be if this options overrides #746715 or not. I didn't look into it yet, so I might be turning 1 or more of the options into overrding the TC and put them under 4.1.4. I do not follow you on this argumentation. The amendment text does not disagree with, or overrule, the resolution #746715 in any way. Please note that I said: I didn't look into it yet. As in, I don't know yet if it overrules that or not. 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/20141020203206.ga8...@roeckx.be
Re: Alternative proposal: reaffirm maintainers technical competence over the software they maintain
Arno == Arno Töll a...@debian.org writes: Arno Hi Kurt, Arno On 20.10.2014 21:33, Kurt Roeckx wrote: So the question is going to be if this options overrides #746715 or not. I didn't look into it yet, so I might be turning 1 or more of the options into overrding the TC and put them under 4.1.4. Arno I do not follow you on this argumentation. The amendment text Arno does not disagree with, or overrule, the resolution #746715 in Arno any way. It does not endorse maintainers to drop support for a Arno particular init system. Quite in contrary, it emphasizes to Arno focus on the best user experience (Debian package maintainers Arno [shall] provide the best free software to our users) which, Arno of course, also includes users of non-default init systems. I actually think the amendment text does provide a different emphasis than the TC ruling. The TC ruling expects that maintainers will generally support multiple init systems. The amendment text focuses on user experience. I might well decide (I happen to believe) that systemd provides a better user experience for enough users that if I were judging based only on user experience I would drop sysvinit support. so, I think the amendment text shifts the emphasis of our decisions and as such overrules the TC. --Sam -- 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/01492f43f887-4e73d266-d1cf-4821-b3d8-2efa98b0e880-000...@email.amazonses.com
Re: Alternative proposal: reaffirm maintainers technical competence over the software they maintain
Kurt Roeckx wrote: Either it's a position statement, or we're making position statement (4.1.5), or using the TC's power (4.1.4). In #727708 it says that a position statement will replace this TC resolution. In #746715 there is no such text. So the question is going to be if this options overrides #746715 or not. I didn't look into it yet, so I might be turning 1 or more of the options into overrding the TC and put them under 4.1.4. So if the project makes a position statement about issues of the day, it's not actually making a technical decision, but just a (nonbinding) statement. A statement that the TC has decided will override their (binding) decision. Well, at least I've found yet another reason to perfer to not vote on this GR: It's too darn complicated to understand the procedural hacking that's going on. -- see shy jo, srsly, you could learn what monads are in the time you'll waste making an informed vote on this GR. signature.asc Description: Digital signature
Re: Alternative proposal: reaffirm maintainers technical competence over the software they maintain
On 20/10/14 at 22:26 +0200, Arno Töll wrote: That's - I think - a good default and affirms Debian's point of view that the respective maintainers can judge best what's a good requirement for their packages. Finally I encourage everyone to focus on the connotation in Luca's amendment. It allows maintainers to tie their software to a particular init system only as a last resort when absolutely necessary - not by pure choice, or by laziness. I disagree with this interpretation. We have processes in place in Debian to deal with such last resort situations: - someone opens an RC bug against the package, stating why it is unsuitable for release - the release team reviews the bug, and might (or not) mark it with the jessie-ignore tag That process works well: someone (the maintainer) is in charge of doing their best to fix the bug, while someone else (the release team) is in charge of evaluating whether, in a last resort situation, it's better to use a dirty work-around (= require another init system) or just remove the package. With Luca's proposal, the maintainer is now in charge of doing a self-evaluation of whether a given bug is unfixable enough to justify being worked-around. Also, the maintainer does not even need to try to fix the problem: showing that there are no patches or other derived works to fix it is a sufficient condition to consider the bug unfixable. I think that this would be a significant step backward in the way we promote consistent technical practices in all Debian packages. Lucas signature.asc Description: Digital signature
Re: Alternative proposal: reaffirm maintainers technical competence over the software they maintain
On Mon, Oct 20, 2014 at 04:03:49PM -0400, Joey Hess wrote: Well, at least I've found yet another reason to perfer to not vote on this GR: It's too darn complicated to understand the procedural hacking that's going on. Hear, hear. My dayjob is doing PMO[1][2] style work tracking and modeling Legislative bodies, and I'm having a hard time keeping up with what's going on. *And this is what I do for work* I mean, when the US Legislative bodies (state federal) are more straightforward in procedure than your distro's, something's gone very wrong. transparency.debian.org anyone?[3] [1]: parliamentary monitoring organization [2]: http://sunlightfoundation.com/ [3]: campaign contributions and lobbying data might do some good to try to disspell all the evil redhat is apparently buying us all off -- .''`. 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: Alternative proposal: reaffirm maintainers technical competence over the software they maintain
Hi, Joey Hess: Well, at least I've found yet another reason to perfer to not vote on this GR: It's too darn complicated to understand the procedural hacking that's going on. Well, vote them below FD then. Except for the nice two-paragraph we don't need no stinkin' GR amendment that's going to be one of the options, of course ;-) -- -- Matthias Urlichs signature.asc Description: Digital signature
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: 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: 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
