Re: GR option text on ballots
Le lundi, 20 octobre 2014, 12.17:14 Neil McGovern a écrit : 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: Your two proposals don't seem to match Ian's to which you're responding: Packages should continue to run under sysvinit unless technically unfeasible Ian's doesn't mention sysvinit at all; this would be highly misleading. Packages may require a specific init system if technically required That's not at all the core of Ian's proposal in my reading. What about In general, software may not require one specific init system to be pid 1 ? 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/3165381.DVHk3vBgWs@gyllingar
Re: Alternative proposal: support for alternative init systems is desirable but not mandatory
Quoting Nikolaus Rath (2014-10-21 02:41:12) 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? Yes. This GR is not anti-systemd, it is pro-choice-if-init-system. In case you also lack an executive summary of that: The last GR was not which-init-system, but which-system-by-default. This GR is not anti-last-GR but refining -what-else-than-default with -and-more-than-default-must-be-supported. - 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: 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: GR option text on ballots
On Tue, Oct 21, 2014 at 08:14:44AM +0200, Didier 'OdyX' Raboud wrote: Le lundi, 20 octobre 2014, 12.17:14 Neil McGovern a écrit : 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: Your two proposals don't seem to match Ian's to which you're responding: Packages should continue to run under sysvinit unless technically unfeasible Ian's doesn't mention sysvinit at all; this would be highly misleading. Packages may require a specific init system if technically required That's not at all the core of Ian's proposal in my reading. That's because they're descriptions for Lucas' amendment. Neil -- signature.asc Description: Digital signature
Re: [Call for seconds] The ???no GR, please??? amendement.
On Mon, Oct 20, 2014 at 08:06:28AM +0900, Charles Plessy wrote: Le Sun, Oct 19, 2014 at 05:01:02PM +0200, Lucas Nussbaum a ??crit : 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. 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. Maybe instead of: } Regarding the subject of this ballot, the Project affirms that the } question has already been resolved and thus does not require a General } Resolution. you could say something like: } Policy on how packages should integrate into the init system is set } by the policy team, though disputes may be escalated to the technical } committee as usual. As these procedures have not been exhausted, } this issue does not require a GR at this time. } } At the time of this GR, current policy on init system integration can } be found in Debian Policy, section 9.3, 9.4, and 9.11, and development } guidelines can be found at: }https://wiki.debian.org/systemd/Packaging (Those are all the references I could find with a quick search. Honestly, it seems remarkably inadequate... People spending too much time organising votes to actually document how secondary init systems should work?) FWIW, I think being non-specific about what the deal with systemd vs sysvinit vs runit vs upstart vs whatever is a bug (both here and in -policy too). I think that's stopping me from adding a (redundant) seconded!, though I think this is still my preferred option. 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/20141021084759.gb11...@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: Re-Proposal - preserve freedom of choice of init systems
Joey Hess writes (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? It was non-binding advice asking maintainers to accept reasonable patches. IMO it does not answer the question addressed by my GR. 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? I think that this coupling question is actually mostly a political rather than a technical problem. The TC explicitly decided to allow their init system decision to be amended or supplemented by a 1:1 GR and it would be wrong to subvert that. 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.15584.843492.552...@chiark.greenend.org.uk
Re: GR option text on ballots
Neil McGovern writes (Re: GR option text on ballots): On Sun, Oct 19, 2014 at 03:18:52PM +0100, Ian Jackson wrote: 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. Yes. I'm sorry to have overreacted. The very unpleasant atmosphere is getting to me - and me reacting to it like that isn't helping. So my apologies. 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.15749.415661.73...@chiark.greenend.org.uk
Re: Re-Proposal - preserve freedom of choice of init systems
Hi, On 16.10.2014 17:05, Ian Jackson wrote: I wish to propose the following general resolution, and hereby call for seconds. [...] ** Begin Proposal ** 0. Rationale Debian has decided (via the technical committee) to change its default init system for the next release. The technical committee decided not to decide about the question of coupling i.e. whether other packages in Debian may depend on a particular init system. This GR seeks to preserve the freedom of our users now to select an init system of their choice, and the project's freedom to select a different init system in the future. It will avoid Debian becoming accidentally locked in to a particular init system (for example, because so much unrelated software has ended up depending on a particular init system that the burden of effort required to change init system becomes too great). A number of init systems exist, and it is clear that there is not yet broad consensus as to what the best init system might look like. This GR does not make any comment on the relative merits of different init systems; the technical committee has decided upon the default init system for Linux for jessie. 1. Exercise of the TC's power to set policy For jessie and later releases, the TC's power to set technical policy (Constitution 6.1.1) is exercised as follows: 2. Loose coupling of init systems In general, software may not require a specific init system to be pid 1. The exceptions to this are as follows: * alternative init system implementations * special-use packages such as managers for init systems * cooperating groups of packages intended for use with specific init systems provided that these are not themselves required by other software whose main purpose is not the operation of a specific init system. Degraded operation with some init systems is tolerable, so long as the degradation is no worse than what the Debian project would consider a tolerable (non-RC) bug even if it were affecting all users. So the lack of support for a particular init system does not excuse a bug nor reduce its severity; but conversely, nor is a bug more serious simply because it is an incompatibility of some software with some init system(s). Maintainers are encouraged to accept technically sound patches to enable improved interoperation with various init systems. 3. Notes and rubric This resolution is a Position Statement about Issues of the Day (Constitution 4.1.5), triggering the General Resolution override clause in the TC's resolution of the 11th of February. The TC's decision on the default init system for Linux in jessie stands undisturbed. However, the TC resolution is altered to add the additional text in sections (1) and (2) above. ** End Proposal ** Seconded. I say no to systemd dependency. I want to be able to choose myself what init system to use in my Debian setup. Regads, Sergey -- 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/cabtsbtp+bxpxwf8o23r1hxdftbsu_kvhhah5m2_rkdznquq...@mail.gmail.com
Maximum term for tech ctte members
Hey, Moving from -project. Reference: https://lists.debian.org/debian-project/2014/05/threads.html#00054 Like I said, I'd rather provide a second than make a proposal, but at debconf Stefano [0] said he'd appreciate some sample wording, so here's what I came up with, based on where I was thinking when the thread on -project sputtered out. https://lists.debian.org/debian-project/2014/06/msg00026.html --- constitution.cur.wml +++ constitution.wml @@ -507,11 +507,33 @@ appointment./p /li + li +pA Developer is not eligible to be appointed to the Technical Committee +if they have been a member within the previous 12 months./p + /li + li pIf the Technical Committee and the Project Leader agree they may remove or replace an existing member of the Technical Committee./p /li + + li +pMembership of the Technical Committee is automatically reviewed +on the 1st of January of each year. At this time, any member of the +Technical Committee who was most recently appointed 54 or more months +prior will ordinarily have their term automatically expire. However, +a member's term may be extended until the next review provided +there are at least two other members, each of whom who either (a) +are a current, longer serving member of Technical Committee, or (b) +resigned from the Technical Committee, or were removed or replaced +since the previous review./p + +pciteWhen the Committee is fully populated, it is expected this +will result in a turnover of 1 or 2 members each year, whether by +resignation or term expiry, while allowing senior members to stay +on if a junior member resigns./cite/p + /li /ol h36.3. Procedure/h3 Debian's birthday came and went, so Jan 1st seems the next most obvious flag day. 54 months is 4.5 years; if you get appointed to the ctte in January after someone else resigns or expires, you term won't expire until January 4 years and 11 months away, whether the limit is 48 months or 59 months, so using the midpoint means expiries happen in the range of 4.5-5.5 years which I think works out okay. The above's as simple as I could make the phrasing. If someone else can do better, please do :) I know there's been some talk that maybe this is something the ctte should just handle themselves; my view is that it's better to have something that just takes care of it in a good enough way without having to take specific actions (which can be missed or procrastinated) or having the people involved having to think about it in detail (whether that means bikeshedding the process or weight it against oh, but I have a couple more things I just have to do while on the ctte). Cheers, aj [0] I'm pretty sure it was Stefano, my memory of that night's possibly kinda blurry... -- Anthony Towns a...@erisian.com.au -- 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/cajs_lcwberpe_tgh4uqcetpmf9wkn4mism9ao-5iqipbvyk...@mail.gmail.com
Re: [Call for seconds] The ???no GR, please??? amendement.
Thanks Anthony and Lucas for your suggestions. Even if it can be improved, I am reluctant to change the wording of the amendement, given that the whole point is a) to say that a GR is unwelcome, and b) to reduce as much as possible the “attack surface” on the voted text in case some people want to use it to continue arguing after the vote. The discussion in this GR falls short of concrete examples of a) what is wrong in Jessie, b) how it should be corrected and c), why would a GR be needed. The burden of the proof is on the side that asks for a GR, not the reverse. If there is not concrete problem to solve, there should be no vote. I consider this GR strongly anti-democratic and anti-doocratic. The different amendements require digging in long, noisy threads to assess what is the common understanding of them (and thanks Lucas for your summary, but it did not help me to have a clear picture of what would be the most likely concrete consequence (that is, not “what the rules are”, but “how the system runs“) of voting each amendement). This makes the GR anti-democratic since the safest choice becomes to vote by the names of who proposed and seconded an amendement rather than by the contents of the amendement itself. And it is anti-doocratic since it lays general principles for the Jessie + 1 release without even giving a chance for the people who will do the work to prepare this release in a brilliant way that does not require the project to constrain their choices. [I can not beleive I spent an hour writing this short text; I hope it is my last email related to this GR.] 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/20141021143145.ga21...@falafel.plessy.net
Re: Maximum term for tech ctte members
I support this proposal, and if that was intented as a formal proposal I'd probably second. I'd also support: * making this something the TC decides for themselves with your wording as an initial condition I do think rotation in bodies like the TC is really good both for the members' personal development and for the project as a whole. I have experience with this in a number of volunteer and standards organizations and I think it works out well to have this sort of rotation. --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/0149331d4496-2ab6c505-1661-47c3-979e-2a430b3f3352-000...@email.amazonses.com
Re: Maximum term for tech ctte members
On Wed, Oct 22, 2014 at 12:08:33AM +1000, Anthony Towns wrote: Moving from -project. Reference: https://lists.debian.org/debian-project/2014/05/threads.html#00054 Like I said, I'd rather provide a second than make a proposal, but at debconf Stefano [0] said he'd appreciate some sample wording, so here's what I came up with, based on where I was thinking when the thread on -project sputtered out. [0] I'm pretty sure it was Stefano, my memory of that night's possibly kinda blurry... Yeah, that was me. Thanks a lot for this draft! In general, it looks good to me and I'd be happy to second something along these lines. A few comments: + li +pMembership of the Technical Committee is automatically reviewed +on the 1st of January of each year. At this time, any member of the +Technical Committee who was most recently appointed 54 or more months +prior will ordinarily have their term automatically expire. However, +a member's term may be extended until the next review provided +there are at least two other members, each of whom who either (a) +are a current, longer serving member of Technical Committee, or (b) +resigned from the Technical Committee, or were removed or replaced +since the previous review./p FWIW, I found the original wording about this part from https://lists.debian.org/debian-project/2014/06/msg00026.html much easier to follow, but it might be a non-native speaker failure on my part. Still, I hereby AOL your call for simpler phrasing here :) +pciteWhen the Committee is fully populated, it is expected this +will result in a turnover of 1 or 2 members each year, whether by +resignation or term expiry, while allowing senior members to stay +on if a junior member resigns./cite/p Does this really belong to the constitutional text? It is good to document the underlying principle/expectation of this change, but having it in the GR text (but still not in the constitution itself) would be good enough IMO. I know there's been some talk that maybe this is something the ctte should just handle themselves; my view is that it's better to have something that just takes care of it in a good enough way without having to take specific actions (which can be missed or procrastinated) or having the people involved having to think about it in detail (whether that means bikeshedding the process or weight it against oh, but I have a couple more things I just have to do while on the ctte). Very much agreed. Nonetheless, before formally calling for seconds, it would be nice to solicit comments from current tech-ctte members on the latest and greatest draft of the GR text. Thanks again, Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: Maximum term for tech ctte members
I think rotation is a good idea. My main minor concern is that it doesn't allow reappointing members to the CTTE if there are no nominees whom the DPL and CTTE finds acceptable (or even if there are no nominees at all). Not allowing people to be reappointed if there are nominees and they're just not acceptable may be a design goal, but not allowing reappointment if there are no nominees does not. On Wed, 22 Oct 2014, Anthony Towns wrote: + li +pA Developer is not eligible to be appointed to the Technical Committee +if they have been a member within the previous 12 months./p + /li + [...] + + li +pMembership of the Technical Committee is automatically reviewed +on the 1st of January of each year. At this time, any member of the +Technical Committee who was most recently appointed 54 or more months +prior will ordinarily have their term automatically expire. However, +a member's term may be extended until the next review provided Probably should be will be extended instead of may be extended. +there are at least two other members, each of whom who either (a) +are a current, longer serving member of Technical Committee, or (b) +resigned from the Technical Committee, or were removed or replaced +since the previous review./p + +pciteWhen the Committee is fully populated, it is expected this +will result in a turnover of 1 or 2 members each year, whether by +resignation or term expiry, while allowing senior members to stay +on if a junior member resigns./cite/p + /li /ol There was also some discussion of this during the CTTE meeting too: http://meetbot.debian.net/debian-ctte/2014/debian-ctte.2014-07-31-16.58.log.html Thanks for drafting this. -- Don Armstrong http://www.donarmstrong.com Miracles had become relative common-places since the advent of entheogens; it now took very unusual circumstances to attract public attention to sightings of supernatural entities. The latest miracle had raised the ante on the supernatural: the Virgin Mary had manifested herself to two children, a dog, and a Public Telepresence Point. -- Bruce Sterling, _Holy Fire_ p228 -- 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/20141021153428.gm28...@teltox.donarmstrong.com
Re: Maximum term for tech ctte members
On Wed, Oct 22, 2014 at 12:08:33AM +1000, Anthony Towns wrote: +At this time, any member of the +Technical Committee who was most recently appointed 54 or more months +prior will ordinarily have their term automatically expire. About this, I wonder if the text should specify in which order expiries are to be processed, e.g., most recently appointed members last. It seems to me that without a pre-defined ordering you might have scenarios in which, in the absence of consensus about who should step down, more members than desired will automatically expire. (Although that might be by design.) And yes, this might be seen as procedural paranoia, but the Constitution is precisely the place where one wants to be paranoid. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: Re-Proposal - preserve freedom of choice of init systems
-- L.S.C.A. Francisco González Flores Redes y Comunicaciones CDE PRI Chihuahua
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. --- Seconded. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: Maximum term for tech ctte members
On Tue, Oct 21, 2014 at 05:21:04PM +0200, Stefano Zacchiroli wrote: FWIW, I found the original wording about this part from https://lists.debian.org/debian-project/2014/06/msg00026.html much easier to follow, but it might be a non-native speaker failure on my part. Hmm, aren't a majority of Debian devs non-native English speakers anyway? I was worried that the two or more .. members have either X or Y phrasing might be ambiguous if there was one member who matched X and a different member who matched Y. +pciteWhen the Committee is fully populated, it is expected this +will result in a turnover of 1 or 2 members each year, whether by +resignation or term expiry, while allowing senior members to stay +on if a junior member resigns./cite/p Does this really belong to the constitutional text? Text marked as a citation, such as this, is rationale and does not form part of the constitution. It may be used only to aid interpretation in cases of doubt. -- from appendix B in the constitution. It is good to document the underlying principle/expectation of this change, but having it in the GR text (but still not in the constitution itself) would be good enough IMO. Given the convoluted wording, I think it makes sense to have a bit of an explanation in the text itself, and not just in the GR. On Tue, Oct 21, 2014 at 05:43:47PM +0200, Stefano Zacchiroli wrote: On Wed, Oct 22, 2014 at 12:08:33AM +1000, Anthony Towns wrote: +At this time, any member of the +Technical Committee who was most recently appointed 54 or more months +prior will ordinarily have their term automatically expire. About this, I wonder if the text should specify in which order expiries are to be processed, e.g., most recently appointed members last. Take the current members, Ian, Bdale, Steve, Andi, Russ and Don are all over five years and are in roughly that order of seniority iirc. On Jan 1st 2015, assuming no resignations, then: - Andi: 2x current, longer serving members (Bdale and Ian) - Bdale: 1x current, longer serving member (Ian) -- expired - Colin: under 4.5 years - Don: 4x current, longer serving members (Bdale, Ian, Steve, Andi) - Ian: no longer serving members -- expired - Russ: same as Don - Steve: same as Andi ie, I guess I was thinking that were all considered simultaneously so ordering wasn't relevant. There could be a minor cascade effect though I guess. If, say, Colin resigns, you might get something like: - 2014-10-23: Colin resigns to found forkubuntu.org - 2015-01-01: Ian's term expires - 2016-01-01: Bdale, Steve, Andi's terms expire - 2017-01-01: Russ and Don's terms expire - 2018-01-01: no one expires! - 2019-01-01: Keith's term expires because while there'd be three people's terms expiring in 2016, both Andi and Steve would only have Bdale as more senior, since they were appointed at the same time. Oh, hey, since there's already math in the constitution, maybe it would work to say something like: Membership of the Technical Committee is automatically reviewed on the 1st of January of each year. At this time, the terms of the N most senior members automatically expire provided they were appointed at least 4.5 years ago. N is defined as 2-R (if R 2) or 0 (if R = 2). R is the number of former members of the Technical Committee who have resigned, or been removed or replaced within the previous twelve months. A member of the Technical Committee is said to be more senior than another if they were appointed earlier, or were appointed at the same time and have been a member of the Debian project longer. In the event that a member has been appointed more than once, only the most recent appointment is relevant. ? It's getting closer to source code than English at that point, but... (I'm not sure the second paragraph there is actually needed; could probably just rely on the secretary or the ctte itself to interpret seniority and disambiguate appointment sensibly.) (I believe the above would declare Steve senior to Andi, and Don senior to Russ) 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/20141021174128.ga18...@master.debian.org
Re: Re-Proposal - preserve freedom of choice of init systems
On Thu, 2014-10-16 at 16:05 +0100, Ian Jackson wrote: I wish to propose the following general resolution, and hereby call for seconds. This GR resolution proposal is identical to that proposed by Matthew Vernon in March: https://lists.debian.org/debian-vote/2014/03/msg0.html and the substantive text is that which was drafted for the purposes of the technical committee's vote (where they decided not to pass a resolution on the subject). IMO developments since March show that the concerns put forward then were well-founded. Following discussions elsewhere including -devel I have received enough offers of seconds by private email. As Matthew said, I don't think further lengthy discussion of the issues is likely to be productive, and therefore hope we can bring this swiftly to a vote. This is particularly true given the impact on the jessie release. Thanks, Ian. ** Begin Proposal ** 0. Rationale Debian has decided (via the technical committee) to change its default init system for the next release. The technical committee decided not to decide about the question of coupling i.e. whether other packages in Debian may depend on a particular init system. This GR seeks to preserve the freedom of our users now to select an init system of their choice, and the project's freedom to select a different init system in the future. It will avoid Debian becoming accidentally locked in to a particular init system (for example, because so much unrelated software has ended up depending on a particular init system that the burden of effort required to change init system becomes too great). A number of init systems exist, and it is clear that there is not yet broad consensus as to what the best init system might look like. This GR does not make any comment on the relative merits of different init systems; the technical committee has decided upon the default init system for Linux for jessie. 1. Exercise of the TC's power to set policy For jessie and later releases, the TC's power to set technical policy (Constitution 6.1.1) is exercised as follows: 2. Loose coupling of init systems In general, software may not require a specific init system to be pid 1. The exceptions to this are as follows: * alternative init system implementations * special-use packages such as managers for init systems * cooperating groups of packages intended for use with specific init systems provided that these are not themselves required by other software whose main purpose is not the operation of a specific init system. Degraded operation with some init systems is tolerable, so long as the degradation is no worse than what the Debian project would consider a tolerable (non-RC) bug even if it were affecting all users. So the lack of support for a particular init system does not excuse a bug nor reduce its severity; but conversely, nor is a bug more serious simply because it is an incompatibility of some software with some init system(s). Maintainers are encouraged to accept technically sound patches to enable improved interoperation with various init systems. 3. Notes and rubric This resolution is a Position Statement about Issues of the Day (Constitution 4.1.5), triggering the General Resolution override clause in the TC's resolution of the 11th of February. The TC's decision on the default init system for Linux in jessie stands undisturbed. However, the TC resolution is altered to add the additional text in sections (1) and (2) above. ** End Proposal ** -- Seconded. signature.asc Description: This is a digitally signed message part
Re: [Call for seconds] The ???no GR, please??? amendement.
Charles == Charles Plessy ple...@debian.org writes: Charles Thanks Anthony and Lucas for your suggestions. Even if it Charles can be improved, I am reluctant to change the wording of Charles the amendement, given that the whole point is a) to say Charles that a GR is unwelcome, and b) to reduce as much as Charles possible the “attack surface” on the voted text in case Charles some people want to use it to continue arguing after the Charles vote. I've already seconded this and will vote for it. I do think I'd feel slightly more comfortable with a statement that the existing processing were working adequately than a statement that the question has already been answered. See, I'm not actually sure that all the questions surrounding init systems have been answered. I think people are busy doing the work to answer them though and nothing needs project-level intervention. Lucas's analysis is correct; there are questions that would be answered by this GR that seem to be answered no where else formally yet. my response is so what? People are doing their jobs, let's not get in their way. I'd rather this amendment not push people away simply because they disagree over whether all the questions have been answered. -- 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/014933c4b6eb-dafbeaaf-d917-447f-9a2d-dd68ba85fa95-000...@email.amazonses.com
Re: Maximum term for tech ctte members
On Tue, Oct 21, 2014 at 08:34:28AM -0700, Don Armstrong wrote: I think rotation is a good idea. My main minor concern is that it doesn't allow reappointing members to the CTTE if there are no nominees whom the DPL and CTTE finds acceptable (or even if there are no nominees at all). In that event the ctte would have 6 people rather than 8 for 12 months, at which point the two expirees could be reappointed. (Though another 2 might expire then, keeping it at 6 members) Not allowing people to be reappointed if there are nominees and they're just not acceptable may be a design goal, but not allowing reappointment if there are no nominees does not. I could easily see acceptability being defined so that automatic reappointment is a matter of course (they're the most experienced candidates!, we know them and trust them!). Avoiding reappointmnet as a matter of course is a design goal. For more generous definitions of acceptability (really smart, knows lots about Debian, willing to work in a team, can deal well with disagreements), I don't think there's a shortage of potential candidates in Debian, so on that score I don't think it's likely there won't be sufficient acceptable nominees. YMMV, of course. (And maybe willing to put up with the conflict and BS that makes its way to the tech ctte would narrow the field more). 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/20141021175436.gb18...@master.debian.org
Re: [Call for seconds] The ???no GR, please??? amendement.
Hi, On Dienstag, 21. Oktober 2014, Sam Hartman wrote: my response is so what? People are doing their jobs, let's not get in their way. I'd rather this amendment not push people away simply because they disagree over whether all the questions have been answered. I agree. I've also been thinking whether I find the distinction pointed out by Lucas to be so important as to offer another amendment if Charly doesnt want to change his... I'd definitly prefer to have this statement once on the ballot than twice. So, Charles? cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: Re-Proposal - preserve freedom of choice of init systems
Andy, Thank you for the email. You can currently use Debian without systemd as long as no package you use depends on systemd. That depends on systemd hook is a primary objection for those of us who know better. Why should a non-init package depend on a particular init system? Only systemd initialization-related packages should depend on systemd. Non-systemd packages currently depend on systemd due to the direct efforts of systemd supporters. Lennart Poettering himself is pushing to get packages dependent on systemd: https://mail.gnome.org/archives/desktop-devel-list/2011-May/msg00427.html The reason why Mr. Pottering resorts to such tactics is because: 1. locking packages upstream FORCES the use of systemd by anyone wanting to use that package; 2. systemd would surely fall flat on its face, were it to attempt to advance on merit alone. Sorry, but such unscrupulous manipulation has to stop before things get out of hand. I want to install that unnecessarily systemd-dependent package on my non-systemd machine! systemd is not Essential level of priority in Debian. Debian's major (and contentious) switch to systemd indicates otherwise. There are no plans by Debian to change that fact. See http://www.vitavonni.de/blog/201410/2014102101-avoiding-systemd.html for example. Thank you for the link. I love this line from the page: ***However, notice that there are some programs such as login managers (e.g. gdm3) which have an upstream dependency on systemd. gdm3 links against libsystemd0 and depends on libpam-systemd; and the latter depends on systemd-sysv | systemd-shim SO IT IS IN FACT A SOFTWARE SUCH AS GNOME THAT IS PULLING SYSTEMD ONTO YOUR COMPUTER.*** However, the above linked post from Lennart Poettering proves that it was he who initiated Gnome's dependency on systemd. So, on the one hand, the systemd apologists are implying that it is not systemd's fault that upstream software depends on it, while, on the other hand, the systemd supporters are pushing for such upstream dependencies on systemd. That's a slimy, two-faced approach. Those of us not who are not sold on systemd can only assume that the amount of effort that the systemd camp puts into such connivances is inversely related to the amount of effort that they put into proper coding. Also, given the prevalence of such deception above, how can we trust anything that comes from the systemd supporters (including systemd itself)? In regards to steps that your linked page suggests, anything can be hacked (except, perhaps, a non-systemd package's dependency on systemd/pid 1). I can run Debian packages on Slackware, Gentoo, Arch, etc. However, I and many, many others don't want to bother with such rigmarole. I'll tell you what -- why don't we go back SysV init as the Debian default, and then, the systemd users can take steps such as those proposed on your linked site. Don't like that proposal, do you? You be the one to have to do extra work to set-up and maintain your init system. Furthermore, you would probably lose those precious upstream dependencies on systemd, as the upstream developers would have to remove them, given that the major players (Red Hat/Arch, Debian, Slackware, etc.) are using various init systems. And again, if I were to follow the instructions on your linked page, how do I run that systemd-dependent package on my non-systemd machine? Regards, -DM Hello, On Mon, Oct 20, 2014 at 06:55:42AM -0700, ss-compo...@marks.org wrote: 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. You can currently use Debian without systemd as long as no package you use depends on systemd. systemd is not Essential level of priority in Debian. There are no plans by Debian to change that fact. See http://www.vitavonni.de/blog/201410/2014102101-avoiding-systemd.html for example. Spreading the idea that Debian is forcing you to use systemd is spreading falsehoods. Cheers, Andy -- http://bitfolk.com/ -- No-nonsense VPS hosting -- 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/20141021134644.036e3...@darkstar.example.net
Re: Re-Proposal - preserve freedom of choice of init systems
Hi debian-vote, The below poster redirected their response to my off-list mail back to the list. I explicitly mailed them off-list and with a reply-to of only myself set in order to avoid further list noise, and because they seemed like they were genuinely confused. I now see that they had an agenda and that there's nothing I can say to alter it, so I'll leave it there. I am sorry that this got back onto the list. Cheers, Andy On Tue, Oct 21, 2014 at 01:46:44PM -0700, ss-compo...@marks.org wrote: Andy, Thank you for the email. You can currently use Debian without systemd as long as no package you use depends on systemd. That depends on systemd hook is a primary objection for those of us who know better. Why should a non-init package depend on a particular init system? etc. -- 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/20141021211606.gf27...@bitfolk.com
[Sorry Neil] Wording modification of the The ???no GR, please??? amendement.
Le Tue, Oct 21, 2014 at 08:13:52PM +0200, Holger Levsen a écrit : On Dienstag, 21. Oktober 2014, Sam Hartman wrote: my response is so what? People are doing their jobs, let's not get in their way. I'd rather this amendment not push people away simply because they disagree over whether all the questions have been answered. I agree. I've also been thinking whether I find the distinction pointed out by Lucas to be so important as to offer another amendment if Charly doesnt want to change his... I'd definitly prefer to have this statement once on the ballot than twice. So, Charles? Indeed, you are right: by definition, not all questions have been answered. The existing wording of the amendement is therefore logically inconsistent. I propose the following replacement as per article A.1.5 of our Contitution. 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 procedures for decision making and conflict resolution are working adequately and thus a General Resolution is not required. I avoided terms like “premature” and “at this time”, since they leave a bit of an impression that a GR will definitely be needed, but only later. This is one of the main resons for my initial reluctance to accept Antony's and Lucas' comments. If further changes are needed, please suggest a full replacement: I am reaching the limits of my writing skills in English (an again: a GR that requires near-native fluency in English because the consequence of the vote will strongly depend on how the text is interpreted is anti-democratic in Debian). Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan signature.asc Description: Digital signature
Re: Maximum term for tech ctte members
Anthony Towns a...@erisian.com.au writes: On Tue, Oct 21, 2014 at 08:34:28AM -0700, Don Armstrong wrote: I think rotation is a good idea. My main minor concern is that it doesn't allow reappointing members to the CTTE if there are no nominees whom the DPL and CTTE finds acceptable (or even if there are no nominees at all). In that event the ctte would have 6 people rather than 8 for 12 months, at which point the two expirees could be reappointed. (Though another 2 might expire then, keeping it at 6 members) While not fatal, that doesn't seem particularly desirable. I don't think there's a shortage of potential candidates in Debian, so on that score I don't think it's likely there won't be sufficient acceptable nominees. I agree. Bdale pgpRf5MYblnHy.pgp Description: PGP signature
Re: [Sorry Neil] Wording modification of the The ???no GR, please??? amendement.
Hi Charles, On Mittwoch, 22. Oktober 2014, Charles Plessy wrote: I propose the following replacement as per article A.1.5 of our Contitution. 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 procedures for decision making and conflict resolution are working adequately and thus a General Resolution is not required. I avoided terms like “premature” and “at this time”, since they leave a bit of an impression that a GR will definitely be needed, but only later. This is one of the main resons for my initial reluctance to accept Antony's and Lucas' comments. I like this changed version indeed much more, thanks a lot for your work on this! Writing short texts well is almost an art ;-) (I don't think I need to formally second this, but if I do, I hereby am. Please tell me still, I have tiny doubts :) cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: [Sorry Neil] Wording modification of the The ???no GR, please??? amendement.
I propose the following replacement as per article A.1.5 of our Contitution. 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 procedures for decision making and conflict resolution are working adequately and thus a General Resolution is not required. I'm not sure If a re-second is required. I do support this text and believe it is an improvement over the original. If it is meaningful/useful, count this message as a formal second. pgpqTifxMFVi7.pgp Description: PGP signature
Re: Tentative summary of the amendments
Lucas Nussbaum lu...@debian.org writes: Q2: support for alternative init systems as PID 1 = A2.1: packages MUST work with one alternative init system (in [iwj]) (if you are confused with “one” here, it’s basically fine to read it as “sysvinit” instead. See [10]this subthread for a discussion about this) I believe Ian's intended reading is that a package that depends on uselessd | systemd (but does not work with sysvinit) would be allowed by his proposal. 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/8738agpzq9@vostro.rath.org
Re: [Sorry Neil] Wording modification of the The ???no GR, please??? amendement.
Hi, Charles Plessy: I propose the following replacement as per article A.1.5 of our Contitution. 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 procedures for decision making and conflict resolution are working adequately and thus a General Resolution is not required. Seconded. While I disagree with the statement that not all questions have been answered. the above re-wording is less controversial, which is a Good Thing (in this case, at least). -- -- Matthias Urlichs signature.asc Description: Digital signature
