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: Re: Re-Proposal - preserve freedom of choice of init systems
On Sat, Oct 18, 2014 at 03:26:57AM +0100, Jonathan de Boyne Pollard wrote: Perhaps if you picked something other than runit you'd make your point more effectively. Try using the case of someone who makes a tool that depends from System V init running as process #1. It is hardly farfetched. I've seen at least two people publicly point out in the past several months that they had something set up in /etc/inittab that broke when they switched to an alternative bootstrap system. (A lot of people conflate init with rc. It's not System V init that other bootstrap systems sometimes provide shims and compatibility mechanisms for. It's System V rc, more specifically the /etc/rc?.d/* scripts that it runs.) There's also a Debian bug or two. So the question that you should be asking to make your point is probably this: The resolution says that In general, software may not require a specific init system to be pid 1.. Does this mean that softwares that make use of /etc/inittab, which is peculiar to (in Ian Jackson's own words) a specific init system (its contents, outwith sometimes the run level line, being not processed at all by any of upstart, systemd, runit-init, s6-svscan, the nosh system or service managers, minit, jinit, or finit), are unfit for inclusion in Debian according to Ian Jackson's resolution? Yes, they almost certainly would be unfit for inclusion. Which is actually the status quo today, as inittab is a non-conffile config file with no management interface to permit additional packages to hook into it - making it a policy violation for other packages to edit this file. So I believe the requirements here are symmetric, and there's certainly no reason to think that the requirements are onerous because it would forbid integrating with /etc/inittab. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Alternative proposal: support for alternative init systems is desirable but not mandatory
Jonas Smedegaard d...@jones.dk writes: Quoting Nikolaus Rath (2014-10-19 20:21:59) Ian Jackson ijack...@chiark.greenend.org.uk writes: David Weinehall writes (Re: Alternative proposal: support for alternative init systems is desirable but not mandatory): OK, so packaging uselessd (thus providing another init system that provides -- most of -- the systemd interfaces) would solve all your worries? This resolution will be interpreted by humans, specifically individual maintainers, the TC, and the release team - not by robots. Presumably some maintainers would consider uselessd an alternate init system - and others will not. In that case the GR seems have achieved effectively nothing. If there was a secret agenda e.g. to annoy systemd then you are right that such trick that you now thought up would mean that this GR was a waste of time. I just don't understand why you consider uselessd a trick that I came up with (leaving alone the fact that David brought it up here, and that yet another guy started the project). 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/87fvejctbt@vostro.rath.org
Re: Alternative proposal: support for alternative init systems is desirable but not mandatory
Jonas Smedegaard d...@jones.dk writes: Quoting Nikolaus Rath (2014-10-19 20:16:37) Jonas Smedegaard d...@jones.dk writes: Quoting David Weinehall (2014-10-19 16:13:18) On Sun, Oct 19, 2014 at 02:28:02PM +0100, Ian Jackson wrote: [snip] The wording in my resolution comes from the TC discussion and specifies `at least one' or `some alternative'. To represent that as `all' is IMO misleading. One important difference between `all' and `at least one' is this: suppose there is some init system that does not support the common interface you suppose in your point (2). Saying `all' suggests that it is somehow the fault of the packages which deal with the common interface. This point was raised in the TC discussion. Saying `all' gives the impression that every package must do work for each init system. That is why my proposal's wording simply says that packages are forbidden from requiring `a specific' init system. OK, so packaging uselessd (thus providing another init system that provides -- most of -- the systemd interfaces) would solve all your worries? There are many ways to twist words, yes. I think this deserves a better answer. Do you consider uselessd to be the same init system as systemd? To me this looks like a legitimate fork. Or are you saying that at least one is really meant to mean at least one not-systemd derived? My concern is not systemd specifically - on the contrary I find it great if it brings more choice to Debian, which seems to be the status currently. My concern is also not the risk that Debian could be locked into only two or only three init systems - I believe we need not deal with that until the risk of such scenario eventually becomes realistic - if we then concider such scenario a concern. My concern now is to ensure that Debian supports more than a single init system. I sincerely hope that I made myself more clear this time, and that you found my response adequate and we can move on. Not really, I'm afraid (although you're of course free to move on). I am still wondering, if Debian would support only uselessd and systemd, would you consider that more than one init system or not? And if not, why not? 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/87iojfctso@vostro.rath.org
Re: [Call for seconds] The “no GR, please“ amendement.
Le Sun, Oct 19, 2014 at 05:01:02PM +0200, Lucas Nussbaum a écrit : --- 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. Regarding the subject of this ballot, the Project affirms that the question has already been resolved and thus does not require a General Resolution. --- I think that it would be very helpful to describe how the question has already been resolved. My understanding is that the various proposals add policy on something that isn't currently covered by the Debian Policy or by TC decisions. Alternatively, your resolution could state that the current de-facto policy of supporting both systemd and sysvinit (sometimes through systemd-shim) should be kept for Debian jessie, and that deciding on policy beyond jessie is premature at this point. Hi Lucas, being more precise would somehow defeat the point of stating that no GR is needed, because the way the solution would be expressed, with its imperfections, would then become binding. This said, let me clarify my understanding of the current situation. - Pepole running GNOME and desktops needing features not found in other init systems will be migrated to systemd during update. - Whether other people will be migrated or invited to migrate is in the hands of the release team, who decides which packages are part of Jessie or not. The techincal commttee has already given the general direction: we change the default init system. In my opinion, this general direction is how the “question” is resolved. Current decisions on which package depend on what, etc, stem from that decision. As of today I do not think that we need the technical comittee, the Policy or a GR to further constrain the work of the release team. Replacing the init system is a major change, and obviously some people who used expert skills to set up their system may need their expertise to upgrade it. This, also, is a logical consequence of the TC's decision, and I trust the various package maintainers that they are doing their best to make the transition as easy as possible. Regarding what is proposed, it is actually unclear. The consequence of accepting the main proposal may range anywhere between “do nothing special” and “harrass the GNOME and systemd maintainers until they quit”. I am sure that this is not Ian's goal, but I am not sure he is in position to prevent this to happen. In the case of your proposal, I appreciate your effort to cool down the situation and you are definitely in your role to do so, but if the whole point is that after voting it, nothing changes except that people stop complaining, then I would like to introduce a ballot option that focuses on that point: telling people who do not have a clear and realistic action plan (that is, no wishful thinking) to stop complaining. Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20141019230628.GA4618@aqwa.igloo
Re: Amendment (Re: Re-Proposal - preserve freedom of choice of init systems)
Alessio Treglia writes (Re: Amendment (Re: Re-Proposal - preserve freedom of choice of init systems)): Il giorno dom, 19/10/2014 alle 14.59 +0100, Ian Jackson ha scritto: I hereby formally propose the amendment below (Constitution A.1(1) `directly by proposer'), and, then, immediately accept it (A.1(2)). This resets the minimum discussion period (A.2(4)). ... Seconded. Thanks, but the proposer of a GR does not need seconds for their own amendments. 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/21572.59918.752013.219...@chiark.greenend.org.uk
Re: GR option text on ballots
Nikolaus Rath writes (Re: GR option text on ballots): Ian Jackson ijack...@chiark.greenend.org.uk writes: If the Secretary feels we have to have a neutral rather than a positive phrasing I would request that we use the following summary line for my proposal: Packages may not require a specific init system Why not s/a/one/ as in your amendment? Because it's a rather clumsy phrasing. 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/21572.60072.618501.4...@chiark.greenend.org.uk
Re: Amendment (Re: Re-Proposal - preserve freedom of choice of init systems)
On Mon, Oct 20, 2014 at 11:55 AM, Ian Jackson ijack...@chiark.greenend.org.uk wrote: Alessio Treglia writes (Re: Amendment (Re: Re-Proposal - preserve freedom of choice of init systems)): Il giorno dom, 19/10/2014 alle 14.59 +0100, Ian Jackson ha scritto: I hereby formally propose the amendment below (Constitution A.1(1) `directly by proposer'), and, then, immediately accept it (A.1(2)). This resets the minimum discussion period (A.2(4)). ... Seconded. Just noticed that after reviewing the GR procedure once again. Honestly it was not really clear to me. Sorry about that. Thanks. -- Alessio Treglia | www.alessiotreglia.com Debian Developer | ales...@debian.org Ubuntu Core Developer| quadris...@ubuntu.com 0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAMHuwozC8h=h01-omtniwb2mgudake7iooqzpa+2ucrey82...@mail.gmail.com
Re: Alternative proposal: support for alternative init systems is desirable but not mandatory
Quoting Nikolaus Rath (2014-10-20 05:19:03) Jonas Smedegaard d...@jones.dk writes: Quoting Nikolaus Rath (2014-10-19 20:16:37) Do you consider uselessd to be the same init system as systemd? To me this looks like a legitimate fork. Or are you saying that at least one is really meant to mean at least one not-systemd derived? My concern is not systemd specifically - on the contrary I find it great if it brings more choice to Debian, which seems to be the status currently. My concern is also not the risk that Debian could be locked into only two or only three init systems - I believe we need not deal with that until the risk of such scenario eventually becomes realistic - if we then concider such scenario a concern. My concern now is to ensure that Debian supports more than a single init system. I sincerely hope that I made myself more clear this time, and that you found my response adequate and we can move on. Not really, I'm afraid (although you're of course free to move on). I am still wondering, if Debian would support only uselessd and systemd, would you consider that more than one init system or not? And if not, why not? I don't know: I do know from our recent experience of bugs appearing and getting fixed too!) that whoa, let's preserve more than one init system in Debian. Maybe an experience with systemd + uselessd will not make me react whoa, let's preserve more than two init systems in Debian, or maybe even whoa, let's preserve at least one conservative init system in Debian - I don't know. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: [Call for seconds] The “no GR, please“ amendement.
Hi, On Sonntag, 19. Oktober 2014, Charles Plessy wrote: --- 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. Regarding the subject of this ballot, the Project affirms that the question has already been resolved and thus does not require a General Resolution. --- seconded. (After some thinking I still think it's useful to also have this option on the ballot. I don't expect it to win, but I surely hope it will win against Ian's proposal - and by far even! ;-) cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: [Call for seconds] The “no GR, please“ amendement.
Le dimanche, 19 octobre 2014, 23.29:21 Charles Plessy a écrit : -- 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. Regarding the subject of this ballot, the Project affirms that the question has already been resolved and thus does not require a General Resolution. -- Seconded, for much the same reasons as Holger's. Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Re: [Call for seconds] The “no GR, please“ amendement.
On Sun, 19 Oct 2014, Charles Plessy wrote: --- 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. Regarding the subject of this ballot, the Project affirms that the question has already been resolved and thus does not require a General Resolution. --- Seconded. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/ signature.asc Description: Digital signature
Re: [Call for seconds] The “no GR, please“ amendement.
On Sun, Oct 19, 2014 at 11:29:21PM +0900, Charles Plessy wrote: --- 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. Regarding the subject of this ballot, the Project affirms that the question has already been resolved and thus does not require a General Resolution. --- Received and valid. I'll add it to the vote page once it receives sufficient seconds. Neil -- signature.asc Description: Digital signature
Re: [Call for seconds] The “no GR, please“ amendement.
Charles Plessy ple...@debian.org writes: Here is the text: --- 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. Regarding the subject of this ballot, the Project affirms that the question has already been resolved and thus does not require a General Resolution. --- Seconded. -- |8] pgpzyCI9JnbfH.pgp Description: PGP signature
Re: Alternative proposal: support for alternative init systems is desirable but not mandatory
Nikolaus Rath nikol...@rath.org writes: I just don't understand why you consider uselessd a trick that I came up with (leaving alone the fact that David brought it up here, and that yet another guy started the project). Indeed, I think uselessd is a very interesting project. I hope it succeeds at its goals and offers another interesting alternative implementation. At the least, even if it doesn't succeed, it can provide some practical experience with exactly what sort of coupling is and isn't present or needed, grounded in running code rather than speculation. -- 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/87zjcq93xc@hope.eyrie.org
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: [Call for seconds] The “no GR, please“ amendement.
Charles Plessy ple...@debian.org (2014-10-19): --- 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. Regarding the subject of this ballot, the Project affirms that the question has already been resolved and thus does not require a General Resolution. --- 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: [Call for seconds] The “no GR, please“ amendement.
On Sun, Oct 19, 2014 at 11:29:21PM +0900, Charles Plessy wrote: Here is the text: --- 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. Regarding the subject of this ballot, the Project affirms that the question has already been resolved and thus does not require a General Resolution. --- Seconded. Deciding technical policy via GR strikes me as awkward. I'd rather see the maintainers in question attempt to resolve this. Cheers, Paul -- .''`. Paul Tagliamonte paul...@debian.org | Proud Debian Developer : :' : 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `. `'` http://people.debian.org/~paultag `- http://people.debian.org/~paultag/conduct-statement.txt signature.asc Description: Digital signature
Re: Alternative proposal: support for alternative init systems is desirable but not mandatory
Nikolaus Rath writes (Re: Alternative proposal: support for alternative init systems is desirable but not mandatory): I just don't understand why you consider uselessd a trick that I came up with (leaving alone the fact that David brought it up here, and that yet another guy started the project). When I read someone mention uselessd before, I thought it was a hypothetical fork of systemd which was nearly identical to systemd. I think uselessd, if it is successful, deals squarely with many of the actual reasons why people don't like systemd: systemd's tendency to try to be everything. That is the real coupling threat - not the lack of ability to continue to use init scripts. So I think in practice there aren't going to be many packages that would want to couple specifically to systemd _or_ uselessd, but where support for other init systems is hard to provide. 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/21573.16685.235428.467...@chiark.greenend.org.uk
Re: Alternative proposal: support for alternative init systems is desirable but not mandatory
Quoting Nikolaus Rath (2014-10-20 05:29:10) Jonas Smedegaard d...@jones.dk writes: Quoting Nikolaus Rath (2014-10-19 20:21:59) Ian Jackson ijack...@chiark.greenend.org.uk writes: David Weinehall writes (Re: Alternative proposal: support for alternative init systems is desirable but not mandatory): OK, so packaging uselessd (thus providing another init system that provides -- most of -- the systemd interfaces) would solve all your worries? This resolution will be interpreted by humans, specifically individual maintainers, the TC, and the release team - not by robots. Presumably some maintainers would consider uselessd an alternate init system - and others will not. In that case the GR seems have achieved effectively nothing. If there was a secret agenda e.g. to annoy systemd then you are right that such trick that you now thought up would mean that this GR was a waste of time. I just don't understand why you consider uselessd a trick that I came up with (leaving alone the fact that David brought it up here, and that yet another guy started the project). For the record: I don't consider uselessd a trick¹. On the contrary, I agree with Russ that it might be a quite interesting init system. You are right that I confused you and David. Sorry about that! - Jonas ¹ What I reflected on was how a question was phrased which included this project, not the project itself. -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: [Call for seconds] The “no GR, please“ amendement.
Charles Plessy wrote: --- 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. Regarding the subject of this ballot, the Project affirms that the question has already been resolved and thus does not require a General Resolution. --- Seconded. -- see shy jo signature.asc Description: Digital signature
Re: Alternative proposal: support for alternative init systems is desirable but not mandatory
+1 keep `sysvint-core` in Debian *at a reliable level*, is a wise thing to do. For at least, 2018~2020. On 19 October 2014 18:40, Jonas Smedegaard d...@jones.dk wrote: Quoting Nikolaus Rath (2014-10-19 20:16:37) Jonas Smedegaard d...@jones.dk writes: Quoting David Weinehall (2014-10-19 16:13:18) On Sun, Oct 19, 2014 at 02:28:02PM +0100, Ian Jackson wrote: [snip] The wording in my resolution comes from the TC discussion and specifies `at least one' or `some alternative'. To represent that as `all' is IMO misleading. One important difference between `all' and `at least one' is this: suppose there is some init system that does not support the common interface you suppose in your point (2). Saying `all' suggests that it is somehow the fault of the packages which deal with the common interface. This point was raised in the TC discussion. Saying `all' gives the impression that every package must do work for each init system. That is why my proposal's wording simply says that packages are forbidden from requiring `a specific' init system. OK, so packaging uselessd (thus providing another init system that provides -- most of -- the systemd interfaces) would solve all your worries? There are many ways to twist words, yes. I think this deserves a better answer. Do you consider uselessd to be the same init system as systemd? To me this looks like a legitimate fork. Or are you saying that at least one is really meant to mean at least one not-systemd derived? My concern is not systemd specifically - on the contrary I find it great if it brings more choice to Debian, which seems to be the status currently. My concern is also not the risk that Debian could be locked into only two or only three init systems - I believe we need not deal with that until the risk of such scenario eventually becomes realistic - if we then concider such scenario a concern. My concern now is to ensure that Debian supports more than a single init system. I sincerely hope that I made myself more clear this time, and that you found my response adequate and we can move on. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
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: [Call for seconds] The “no GR, please“ amendement.
On Sun, Oct 19, 2014 at 11:29:21PM +0900, Charles Plessy wrote: Anyway, whichever the name I call for seconds (or comments: if this proposed amendment is considered harmful, let me know). Received (well, found in the middle of a mail thread, thanks for changing the subject though :P) and valid. Neil -- signature.asc Description: Digital signature
Re: Re-Proposal - preserve freedom of choice of init systems
Ian Jackson 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. What, then was #746715? 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. How can you use 4.1.5, which is Issue, supersede and withdraw **nontechnical** policy documents and statements (emphasis mine) for a technical decision like this? Why does this not come under 4.1.4, and so require a 2:1 majority? -- 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: [RFC] Alternative proposal: reaffirm upstream and maintainers technical competence over the software they maintain
Hi. I'd support a proposal that focused on reaffirming the decisions that have already been taken, and it sort of sounds like you're doing that. However, I think your proposal goes significantly further than I'd like. So, I'd rank your proposal significantly below Lucas's proposal. however, if you'd be willing to consider something that was more focused around hey, the process worked and we have a decision, let's go with it, I'd prefer that to Lucas's proposal. --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/01492edb1f3e-860a8b8c-6eaf-4dc3-bde1-dfbb68080792-000...@email.amazonses.com
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: support for alternative init systems is desirable but not mandatory
Joey == Joey Hess jo...@debian.org writes: Joey Why not just make your proposal be something along the lines Joey of reaffirming the technical decision-making process as it Joey currently stands, from the package maintainers, to the policy, Joey to the TC. It could implicitly or explicitly reaffirm both Joey recent TC decisions on init systems. I'd support very strongly something like this, no more than one or two more paragraphs like the above. -- 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/01492ee2524a-68f800f4-1794-43fe-b81a-c3f9f5d55221-000...@email.amazonses.com
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: support for alternative init systems is desirable but not mandatory
Sam Hartman wrote: Joey == Joey Hess jo...@debian.org writes: Joey Why not just make your proposal be something along the lines Joey of reaffirming the technical decision-making process as it Joey currently stands, from the package maintainers, to the policy, Joey to the TC. It could implicitly or explicitly reaffirm both Joey recent TC decisions on init systems. I'd support very strongly something like this, no more than one or two more paragraphs like the above. I consider Charles Plessy's proposal to do this, more or less. (Enough that I don't think another proposal would be worthwhile.) -- see shy jo signature.asc Description: Digital signature
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: GR option text on ballots
On Sun, Oct 19, 2014 at 03:18:52PM +0100, Ian Jackson wrote: IMO summary lines should certainly not be written by opponents of the proposed option. Please would you as Secretary confirm that you will seek to use a summary text that both I (as proponent) and you are happy with. Please see A.2.3. I would also like to point out that the webpage currently doesn't name the options. I also believe in that they should be written as neutral as possible. 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/20141020194042.ga7...@roeckx.be
Re: [Call for seconds] The “no GR, please“ amendement.
Joey == Joey Hess jo...@debian.org writes: Joey Charles Plessy wrote: --- 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. Regarding the subject of this ballot, the Project affirms that the question has already been resolved and thus does not require a General Resolution. --- Joey Seconded. Seconded!@!! thanks! pgppbTuOE7Vsm.pgp Description: PGP signature
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: GR option text on ballots
On Sun, Oct 19, 2014 at 03:18:52PM +0100, Ian Jackson wrote: Lucas Nussbaum writes (Re: GR option text on ballots): I'd like to propose: I would like to reiterate my view that these summaries should be positive, and written by the proponent of each version, so long as they are not misleading. A quick look through previous ballots seems (to me at least) to have neutral statements there, rather than positive ones, so I'd prefer these if possible. IMO summary lines should certainly not be written by opponents of the proposed option. Please would you as Secretary confirm that you will seek to use a summary text that both I (as proponent) and you are happy with. That would indeed be my aim, though I reserve my right to make a final decision should that not be possible. Obviously, with what is potentially quite a contentious vote, I'd like to avoid that, hence this mail thread :) If the Secretary feels we have to have a neutral rather than a positive phrasing I would request that we use the following summary line for my proposal: Packages may not (in general) require a specific init system That sounds fine to me. Ian's: make each package support all alternative init systems This is actively misleading in a least four ways: Yup, I wouldn't count that as neutral either. How about: Packages should continue to run under sysvinit unless technically unfeasible or Packages may require a specific init system if technically required ? I would be very displeased if the Secretary chooses to use a text for my proposal which was suggested by my opponent, and which I think contains coded criticisms of my proposal. I'm not sure why you would assume that this is a possibility to be honest. Neil -- 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/20141020111714.ga18...@halon.org.uk
Re: Re-Proposal - preserve freedom of choice of init systems
I wholeheartedly support this proposal. I would go further in this proposal and state that no software should require a specific init system in ANY pid. Of course, like many others, I would prefer Debian's default init to be almost anything other than systemd. In fleeing systemd, I have left Debian and am currently running Slackware. I won't use Debian again, unless I can do so without systemd. Kind regards, -D.M. -- 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/20141020065542.543a9...@darkstar.example.net
Re: Amendment (Re: Re-Proposal - preserve freedom of choice of init systems)
On Sun, Oct 19, 2014 at 02:59:16PM +0100, Ian Jackson wrote: (CC secretary@ to avoid this getting overlooked in the mail flood.) I hereby formally propose the amendment below (Constitution A.1(1) `directly by proposer'), and, then, immediately accept it (A.1(2)). This resets the minimum discussion period (A.2(4)). Received and valid Neil -- 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/20141020181427.gi18...@halon.org.uk
Re: Alternative proposal: support for alternative init systems is desirable but not mandatory
Ian Jackson ijack...@chiark.greenend.org.uk writes: Nikolaus Rath writes (Re: Alternative proposal: support for alternative init systems is desirable but not mandatory): I just don't understand why you consider uselessd a trick that I came up with (leaving alone the fact that David brought it up here, and that yet another guy started the project). When I read someone mention uselessd before, I thought it was a hypothetical fork of systemd which was nearly identical to systemd. I think uselessd, if it is successful, deals squarely with many of the actual reasons why people don't like systemd: systemd's tendency to try to be everything. That is the real coupling threat - not the lack of ability to continue to use init scripts. So I think in practice there aren't going to be many packages that would want to couple specifically to systemd _or_ uselessd, but where support for other init systems is hard to provide. So just to be clear: A package requiring either uselessd or systemd would be acceptable in Debian if your GR proposal passes? 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/87zjcqtftj@vostro.rath.org
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
