Re: First call for votes for the Lenny release GR
On Tue, 16 Dec 2008, Russ Allbery wrote: Steve Langasek vor...@debian.org writes: On Tue, Dec 16, 2008 at 04:27:22PM -0800, Russ Allbery wrote: This is where I have a strong disagreement with Manoj and apparently with you. I don't think there's any justification in the constitution for requiring a developer statement about the project's sense of the meaning of the SC and the DFSG to have a 3:1 majority, or to make a developer override to enforce that sense of the meaning. Both the override and the statement about the meaning of the documents should require 1:1. 3:1 should only be required when the documents are explicitly superseded or changed, not just for making a project statement about their interpretation. With the corollary, I think, that such 1:1 position statements are non-binding; you can compel developers to a particular course of action with a specific 1:1 vote, but you can't force developers to accept your *interpretation* of the foundation documents that led to the override, short of modifying the foundation document to include that interpretation. But such modifications definitely shouldn't happen without the express intent of the proposer. Yup, I agree with that. Not sure it's needed but I also share this opinion/interpretation of the constitution. I'm glad that I'm not alone here and that we might have some basis to avoid a constitutional crisis. How do we get back to a saner situation now ? Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bundled votes and the secretary
On Sun, Dec 14 2008, Josselin Mouette wrote: Le samedi 13 décembre 2008 à 22:09 +0100, Robert Millan a écrit : For the record, I think the Secretary's interpretation of the Constitution is perfectly correct. Whether it is correct or not is irrelevant here. The Secretary is deciding this without justification, in an inconsistent way (similar options get a different treatment), and without any thought for following the constitution itself. I think I can honestly reject every one of these statements. Message-ID: 87vdunwp65@anzu.internal.golden-gryphon.com Message-ID: 87skq0y4i5@anzu.internal.golden-gryphon.com Message-ID: 871vxjy7cm@anzu.internal.golden-gryphon.com Message-ID: 87prl2xrla@anzu.internal.golden-gryphon.com Message-ID: 87wsf9veei@anzu.internal.golden-gryphon.com Message-ID: 87myg0zrwu@anzu.internal.golden-gryphon.com Message-ID: 87iqqozrrh@anzu.internal.golden-gryphon.com Message-ID: 87abc0zhin@anzu.internal.golden-gryphon.com Message-ID: 87fxlrwfkd@anzu.internal.golden-gryphon.com Message-ID: 87y6ziv0m6@anzu.internal.golden-gryphon.com Message-ID: 87ljviuzv8@anzu.internal.golden-gryphon.com For example, the Secretary explained that option 6 permanently modifies the foundation documents, but it doesn’t specify how. If it does modify them, where are the modifications? If it doesn’t, why does it require 3:1 majority? If it is not acceptable as is, the Secretary should have *refused to conduct the vote on it* so that a workable proposal could have been issued. If this option wins, how will we manage the situation? Message-ID: 87fxltk5yz@anzu.internal.golden-gryphon.com Message-ID: 87vdtq564m@anzu.internal.golden-gryphon.com For the GFDL GR, this was even worse: the Secretary decided that “GFDL is free” required 3:1 while “GFDL without invariant sections is free” did not. The only reason is that he couldn’t stand the latter proposal and decided to make it impossible to pass. Note that I was strongly against that proposal – but even while agreeing with Manoj on the topic, I cannot approve such a manipulation of the vote. You do not think that the former being incompatible with the DFSG had something to do with the difference? manoj -- It's amazing how much mature wisdom resembles being too tired. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bundled votes and the secretary
On Sun, Dec 14 2008, Steve Langasek wrote: On Sun, Dec 14, 2008 at 12:08:01PM +0200, Antti-Juhani Kaijanaho wrote: On Thu, Dec 11, 2008 at 10:38:34AM -0800, Steve Langasek wrote: if he saw this mail and chose not to acknowledge the arguments, then he is behaving in a wholly improper manner with regard to this vote, and frankly I see no reason that we as a project should even honor the outcome of a vote on this ballot as presented. These two statements I find most alarming. As long as there is no clear and unambiguous violation of the constitution in the Secretary's actions, As a matter of fact, there's that too. This ballot has been assembled in contravention of the Standard Resolution Procedure, which requires that new ballot options be proposed as formal *amendments* to an outstanding GR proposal in order to appear on the same ballot. Manoj has overstepped his authority in order to group separately proposed resolutions about orthogonal questions on a single ballot, over the explicit objections of the proposer/seconders. This is not a power granted to the secretary under A.2. All related options are placed on the ballot, no? I am working on the basis that any proposal, and all related proposals that may affect the action to be taken, must be on the ballot. None of the amendments in recent votes take the formal form (I amend foo, and replace all the words in the proposal with the words below). Amendments (made formal by seconds) just propose what the alternate handling being proposed, and related proposals go on the ballot. This is how the related amendment has been handled in practice over the last several years. and absent a valid GR stating otherwise, the vote must be presumed to be constitutionally valid. Ah, and how are we meant to get a valid GR when the secretary is actively tampering with the GR process? Recognizing the validity of the vote is not a must. The alternative is that we end up in a state of constitutional crisis. That's unfortunate, but it's also unfortunate that our Secretary is failing to act in a manner that safeguards the integrity of that office. In the interest of keeping the discussion civil, I shall not respond to this. manoj -- All great ideas are controversial, or have been at one time. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
On Sun, Dec 14 2008, Pierre Habouzit wrote: On Sun, Dec 14, 2008 at 03:02:17AM +, Debian Project Secretary wrote: -- Choice 2: Allow Lenny to release with proprietary firmware [3:1] == == = = == === === = Why on earth does it needs [3:1] whereas it wasn't needed for: http://www.debian.org/vote/2006/vote_007 Asked and answered, it has to do with removing the wording about requiring the firmware to be under a dfsg free license. -- Choice 3: Allow Lenny to release with DFSG violations [3:1] == == = = == === == = Same question somehow applies here. You do not think asking to release with known violations of a foundation document needs a 3:1? Again, asked and answered. -- Choice 4: Empower the release team to decide about allowing DFSG violations [3:1] == == === === === == == = == Unless I'm mistaken this shouldn't be [3:1] as it's specifically allowed by the § about delegates in the constitution. Delegates shall take decision they see fit. What should be [3:1] is to dis-empower them from having such rights. Actuallu, nothing delegated to the delegates allows them to change the foundation docs. Or should the packager fo the constitution document, or the web team, under their daily tasks, just change the constitution as they see fit? And FWIW I still believe this vote is an horrible mix-up of really different things, is completely confusing, and I've no clue how to vote. I would be surprised other people don't think the same. E.g. How can I decide 2 _and_ 4 ? Does the rule change ? Does any resolution that wins overs Further Discussion will be validated ? Because unless I'm mistaken, 2 doesn't imply 4, so if 2 wins, 4 is invalidated. No one seems to have seen it desirable to put a 2 4 option on the ballotl; despite the months we took to discuss this. The web page with the options was also up for several weeks, and a draft ballot went up earlier. Seems liek there was plenty of time to change things, and add some of the power set options on to the ballot. If I had added options willy-nilly, you would have screamed again of abuse of power. manoj -- God gives us relatives; thank goodness we can chose our friends. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
Manoj Srivastava wrote: On Sun, Dec 14 2008, Pierre Habouzit wrote: On Sun, Dec 14, 2008 at 03:02:17AM +, Debian Project Secretary wrote: And FWIW I still believe this vote is an horrible mix-up of really different things, is completely confusing, and I've no clue how to vote. I would be surprised other people don't think the same. E.g. How can I decide 2 _and_ 4 ? Does the rule change ? Does any resolution that wins overs Further Discussion will be validated ? Because unless I'm mistaken, 2 doesn't imply 4, so if 2 wins, 4 is invalidated. No one seems to have seen it desirable to put a 2 4 option on the ballotl; despite the months we took to discuss this. The web page with the options was also up for several weeks, and a draft ballot went up earlier. It's you who decided to put all the proposals on the same ballot. I don't think it's fair to request from people who disagree with that to invest time in proposing more options. It's you who decided to make it a mess, you could as an experienced vote taker have suggested quite some different things which could have made it cleaner instead IMHO. Seems liek there was plenty of time to change things, and add some of the power set options on to the ballot. If I had added options willy-nilly, you would have screamed again of abuse of power. Sure, though you could have followed the procedure or hinted people in an even saner direction IMHO. Cheers Luk -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
* Ean Schuessler (e...@brainfood.com) [081217 14:53]: - Steve Langasek vor...@debian.org wrote: With the corollary, I think, that such 1:1 position statements are non-binding; you can compel developers to a particular course of action with a specific 1:1 vote, but you can't force developers to accept your *interpretation* of the foundation documents that led to the override, short of modifying the foundation document to include that interpretation. But such modifications definitely shouldn't happen without the express intent of the proposer. Don't we need to take into consideration that the release managers' interpretation of the DFSG is the most binding one in the project? Not necessarily. If ftp-masters' interpretation would be more strict, they could remove software. Also, of course you are free to ask the DPL to replace the release team, and/or to run an GR with the same effect. However, AFAICS, we even don't have enough qualified candidates for that post when we ask for volunteers. Which does indicate to me that the amount of work to be done is more than the amount of power. If you want to change our release goals, that's ok. Please contact the release team at the known role account (though I cannot remember off-hand a mail to the effect from you). If you want to change the decision making process, that's fine either. Make a new proposal, and if you get enough supporters, than I (and I hope everybody) else accepts it (or leaves the project). However: Until a new decision making process is decided by the developers at large, the current one is the binding one. The consitution defines a way how decisions are made in Debian currently. According to the constitution, the decisions are done the way Steve explained. If you can't accept the current constitution including the way how decisions are made, and are unable to get the developers to agree on a new one (within the current rules, i.e. 3:1-majority), then I'm afraid your only way is to leave the project. (This part isn't meant personally at anyone, but - that's the way projects are governed.) Cheers, Andi -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Why the gr_lenny ballot is the way it is
Hi, This whole set of discussions and proposals started a couple of months ago, when concerns were raised about firmware blobs, dfsg violations, and the release. This, after a round of disuccion, led to three proposals on how the release should be conducted, in view of firmware blobs currently in the linux kernel packages. The proposals led tyo a great deal of heated responses, and whole slew of related proposals were produced -- related, as in all of them dealt with firmware blobs and difsg violations, and dealt with the release process, and some of them were for handling just the current release, others sought to solve the issue of firmwarfe for this and all future release4s, either directly, or delegating the decisions to a group of developers, and away from the general resolution mechanism of resolving this for future releases. All of these related proposals would handle, one way or the other, the issue of this release and firmware. Some of them would grant dispensation to more than just firmware, and some of them solve this problem for future reelases as well, but all would resolve the release _now_. Also, some of the proposals are indeed orthogonal, or, at least, mutually incompatible; and in some cases, selecting one option makes the others moot. Yes, some of the options on this ballot have long term impact, but they are also equally capable of solving our What to do about Lenny problems. Since they all solve the Lenny issue, they are relevant, and related, solutions for the issue. I do not think throwing options out because they are not of a narrow and limited scope is right. The proposer and sponsors can withdraw them, if they think the scope is too broad for the problem at hand. No one else should be removing them from consideration as a solution to the Lenny issue. Now, we have been fairly non-anal about differing options on out ballots being formally proposed as amendments (I amend proposal foo, and replace all the words in that proposal by these below ), I did not see any reason to change being anal retentive for just this vote. The ballot is a mess. While I think the related proposals should be placed on the same ballot overrides ere, the prooposals are not truly all orthogoanl. We could, for example, do the allow the delegation of DFSG violatio decisions to the release team, _and_ also rulke that firmware should be granted special dispensation in the DFSG. So, while the power set of the options is not feasible, we could have a slew of options combining the various proposed options, if people wanted to vote on a compatible set of options. This was discussed a month ago, in early november, giving people who wanted to vote on a combination of optiosn plenty of time to propose favourite combinations. Message-ID: 87ej1cd11m@mid.deneb.enyo.de Message-ID: 871vxczbww@anzu.internal.golden-gryphon.com No one seemed to want such combinations enough to follow up on that. Also, splitting a vote into multiple ballots, with related proposals affecting the same action (lenny release, for instance) , is a horrendously bad idea -- since the massive amounts of strategic voting possibilities will taint the final result. Given that these proposals are strongly related, they should be on the ballot together. The permanent solution proposals, if they fail to pass, may be discussed, modified, and brought to the table again. manoj -- Those who will be able to conquer software will be able to conquer the world.-- Tadahiro Sekimoto, president, NEC Corp. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
- Steve Langasek vor...@debian.org wrote: With the corollary, I think, that such 1:1 position statements are non-binding; you can compel developers to a particular course of action with a specific 1:1 vote, but you can't force developers to accept your *interpretation* of the foundation documents that led to the override, short of modifying the foundation document to include that interpretation. But such modifications definitely shouldn't happen without the express intent of the proposer. Don't we need to take into consideration that the release managers' interpretation of the DFSG is the most binding one in the project? I understand that there is a motivation by the release manager's to insure that the release is both technologically stable and timely but shouldn't the release managers be equally concerned with the legal stability of the release? Putting on the corporate user hat, I would hope that running stable would give me the highest level of protection against inadvertently running software that is violating its license. A serious license problem could potentially be every bit as disruptive and expensive to our users as a technical problem. I think this factor is really what the discussion is about and why release continues to be a sticking point year after year. -- Ean Schuessler, CTO Brainfood.com e...@brainfood.com - http://www.brainfood.com - 214-720-0700 x 315 -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bundled votes and the secretary
On Tue, Dec 16 2008, Pierre Habouzit wrote: On Mon, Dec 15, 2008 at 08:28:19PM +, Kurt Roeckx wrote: On Mon, Dec 15, 2008 at 09:58:09AM +0100, Pierre Habouzit wrote: from http://www.debian.org/vote/2006/vote_007#majorityreq 4. We give priority to the timely release of Etch over sorting every bit out; for this reason, we will treat removal of sourceless firmware as a best-effort process, and deliver firmware in udebs as long as it is necessary for installation (like all udebs), and firmware included in the kernel itself as part of Debian Etch, as long as we are legally allowed to do so, and the firmware is distributed upstream under a license that complies with the DFSG. and from the current vote: 4. We give priority to the timely release of Lenny over sorting every bit out; for this reason, we will treat removal of sourceless firmware as a best-effort process, and deliver firmware as part of Debian Lenny as long as we are legally allowed to do so. Now explain to me how a genuine interpretation of the Constitution let the former need simple majority and the latter super majority. The biggest difference is the under a license that complies with the DFSG part. There is also the udeb part that's different. Note that we also have the an option (choice 5) with the under a license that complies with the DFSG part and that doesn't have the 3:1 majority requirement. We could have worded it like in '06 and achieve the same then (IOW there is no gain in the wording difference that you believe - and I still do not believe it - warrants the 3:1 majority wrt what this option tries to achieve). Does the proposal choice 5 not achive exactly what you seem to want? Itr is worded like 2006, and has a 1:1 majority. I do think the under a license that complies with the DFSG part is significant; without it one may say that any binary blob under whatever license may be included in the release; without needing to comply with the DFSG. The not needing to comply with the DFSG bit is what makes the super majority come in, and which is why we have a choice 5 on the ballot. manoj -- We secure our friends not by accepting favors but by doing them. Thucydides Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
On Mon, Dec 15 2008, Russ Allbery wrote: Thomas Weber thomas.weber.m...@gmail.com writes: Am Montag, den 15.12.2008, 10:06 + schrieb Steve McIntyre: I've been talking with Manoj already, in private to try and avoid flaming. I specifically asked him to delay this vote until the numerous problems with it were fixed, and it was started anyway. I'm *really* not happy with that, and I'm following through now. Uh, I don't quite get this: you shortened the discussion period, but at the same time asked the secretary to delay the vote? Where did Steve shorten the discussion period? He did so for the *other* vote, but I haven't seen a thread where he did for this one. (I may have just missed it.) I mis remembered. Steve shortened the discussion period for this vote, and the discussion and voting period for the _other_ vote, but I missed that the vote period for the gr_lenny vote was not shortened. I'll send out a new CFV. Sorry about that. manoj -- Happiness adds and multiplies as we divide it with others. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
On Sun, Dec 14 2008, Loïc Minier wrote: This ballot is nonsense: a) I want to decide on requirements of source of firmwares AND allow lenny to release with DFSG violations AND proprietary firmware AND empower the release team to release with DFSG violations The way that we achive such combinations using condorcet is to propose such combinations as options intheir own right; and then have people vote on the combination option along with simple options. There was no such proposal during the discussion period. manoj -- Classical music is the kind we keep thinking will turn into a tune. Kin Hubbard, Abe Martin's Sayings Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
On Wed, Dec 17 2008, Luk Claes wrote: Manoj Srivastava wrote: On Sun, Dec 14 2008, Pierre Habouzit wrote: On Sun, Dec 14, 2008 at 03:02:17AM +, Debian Project Secretary wrote: And FWIW I still believe this vote is an horrible mix-up of really different things, is completely confusing, and I've no clue how to vote. I would be surprised other people don't think the same. E.g. How can I decide 2 _and_ 4 ? Does the rule change ? Does any resolution that wins overs Further Discussion will be validated ? Because unless I'm mistaken, 2 doesn't imply 4, so if 2 wins, 4 is invalidated. No one seems to have seen it desirable to put a 2 4 option on the ballotl; despite the months we took to discuss this. The web page with the options was also up for several weeks, and a draft ballot went up earlier. It's you who decided to put all the proposals on the same ballot. I don't think it's fair to request from people who disagree with that to invest time in proposing more options. Well, I put all related proposals on the same ballot, yes, but it is because I think we need to do so in order to not let strategic voting skew the results. It's you who decided to make it a mess, you could as an experienced vote taker have suggested quite some different things which could have made it cleaner instead IMHO. I do not know how to take this kind of a complex issue, and cleanly compress it into somewthing that would be both fair and clean. I opted for fairness, in that we do not have serial votes with subsets of options leading to a run-off, which would make strategic voting harder. Seems liek there was plenty of time to change things, and add some of the power set options on to the ballot. If I had added options willy-nilly, you would have screamed again of abuse of power. Sure, though you could have followed the procedure or hinted people in an even saner direction IMHO. I followed the procedure that I think we have followed in the past. We do ont make people jump through and replace all the words in the proposal by these words hoops, and we put related proposals on the same ballot. Unfortunately, some of the proposals are not mutually exclusive, so combinations are possible; and I did not want to increase the size of the ballot with combinations; I think had I done that, there would still have been accusations of the ballot being too complex. manoj -- The 11 is for people with the pride of a 10 and the pocketbook of an 8. R.B. Greenberg [referring to PDPs?] Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
On Wed, Dec 17, 2008, Manoj Srivastava wrote: The way that we achive such combinations using condorcet is to propose such combinations as options intheir own right; and then have people vote on the combination option along with simple options. Or do separate votes... There was no such proposal during the discussion period. It was your decision to make a single ballot out of these orthogonal issues, do not present the situation as being the proposers' fault. -- Loïc Minier -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
On Sun, Dec 14 2008, Russ Allbery wrote: Bas Wijnen wij...@debian.org writes: On Sun, Dec 14, 2008 at 12:59:12PM -0800, Russ Allbery wrote: It's a shame that the vote was handled in the way that it was, Actually, I think the secretary has done a very good job in preparing the ballot. I would like to feel that, but unfortunately, I don't think the facts support that feeling. The 3:1 majority part I can understand. That's his job, and whether I agree or not, I can't get upset at him for doing his job. However, there are several other serious irregularities in this vote: * Why does releasing despite DFSG violations require a 3:1 majority now when it didn't for etch? It's the same secretary in both cases. What changed? I didn't find any of the explanations offered for this very satisfying. The proposal we used before is choice 5 in the current ballot, and that does indeed have a 1:1 majority like we did before. The devil lies in the details (and I have explained the details before too) -- which is that we state that the fiormware blob be released under a DFSG free licence. This means we explictly conform to the DFSG, Without that clause, in choice 2, we are just accepting any firmware blob, with any license, which means that we are allowing for the DFSG to be violated I do not think we released before with known violations. We released with things we strongly suspected as being violations; since we strongly suspect the blob was not the preferred form of modification, but we do not know for a fact. * Bundling the vote against the open opposition of a fairly significant number of people, including some of the people whose amendments were grouped together, is within his power but comes across poorly. There wasn't much attempt to compromise or discuss this, and I came away from that with a bad taste in my mouth. Have we not been discussing this for weeks now? Related options belong on the same ballot. Not doing so allows for strategic voting to game the issue. This is not really an opinion piece, this is a known flaw of splitting votes where condorcet is used. I am sorry about the bad taste in your mouth, but unless you can argue how we can guard against gaming the system when we split votes, I don't see where we are going with this. * One role of the secretary is to interpret the constitution. The constitution states fairly clearly the process of decision-making for decisions of this type, such as whether a given package violates the DFSG, or how to weigh the implications of the Social Contract. Yet that decision-making process is not reflected in the ballot or in the presentation of the options. Option 1 is either meaningless or an override of a delegate decision, but the ballot doesn't reflect this. While the options are not written by the secretary, and people would consider it a gross abuse of power if I wrote things up as I felt thy should be written; the proposer could have made the overriding the decision of a delegate explicit. The decision to override would not need a supermajority, so the ballot would not need to be changed. Usually, the ballot form is created by the proposer, it contains the title of the proposal, as the proposer set it, and any majority requirements. The ordering is something the secretary decodes, it was done chronologically this time around. Option 4 looks equivalent to FD if you look at the decision-making process in the constitution, but the ballot doesn't reflect that. I think some additional clarity around that would have been very helpful. Again, the proposers or seconds could have improved the proposal. What does this have to do with the secretary. So, no, I think in this case Manoj did a poor job of preparing this ballot. (That doesn't mean that I have any problems with him personally, nor do I believe that he did so out of any ulterior motives. I think he made the decisions that he thought were correct. I just don't think they were good decisions.) Point 1 has been answered; and again today, point 2 is related to not splitting of related proposals or candidates for resolving the release into spearate vote while we use condorcet, and point 3 is unrelated to decisions I took; heck, I'd love to rewrite proposals other people come up with as secretary, and make them sane; I can just see hows of protest were I to rectify: or apply editorial changes to the proposals. manoj -- Goodbye, cool world. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
PARDOSELI PVC FORBO =??Q?=95TARKETT?= PARDOSEALA TEHNICA FLOTANTA (suprainaltata)
WESTFLOOR Stirbei Voda 53-55, 010103 Bucuresti; TEL 021 3182125; FAX 021 3111456; Mobil: 0740.001.101 PARDOSELI PVC FORBO TARKETT Oferta covor pvc SafeS Pardoseala trafic intens, antibicrobiana si antiaderapanta Pret covor pvc SafeS8.7 euro/mp + tva Domenii de utilizare: spitale, scoli, gradinite, productie farmaceutice, productie alimente, birouri, spatii comerciale, restaurante... Caracteristici: Safe Protection Stratul de uzura al pardoseli pvc SafeS contine oxid de aluminiu. Aceasta insertie produce o crestere a rezistentei la alunecare dar cel mai important produce o crestere a rezistentei la uzura mult mai mare decat a celorlalte pardoseli pvc. Extra PU Guard Ultra rezistent si stabil stratul de poliuretan de la suprafata asigura durabilitate si rezistenta la uzura. Tratamentul Extra PU Guard asigura protectia pardoseli la umezeala, solventi, mizerie, pete. Acest tratament face ca pardoseala SafeS estrem de usor de intretinut si mentine aspectul pardoseli in toti anii de folosinta. Antimicrobal Protection Pardoseala SafeS contine tratament antimicrobian ce ofera protectie impotriva bacteriilor si ciupercilor. SafeS este o pardoseala potrivita mediilor unde igiena este absolut necesara: spitale, sali asteptare, birouri administrative, gradinite, scoli, productie farmaceutica, productie alimente... Sistemul functioneaza permanent si distruge bacteriile daunatoare. Grosime 2mm Strat uzura 0.7mm Latime rola 2m Clasa trafic34/43 (trafic intens comercial si industrial) Rezistenta foc B1 Garantie7ani PARDOSEALA TEHNICA FLOTANTA (suprainaltata) PANOURI: PANOU 600X600mm prefinisaj aluminiu 24.8 eur/mp PANOU 600X600 mm acoperit cu laminat36.4 eur/mp PANOU 600x600 mm acoperit covor pvc 39.7 eur/mp PANOU 600x600 mm acoperit mocheta 42.98 eur/mp STRUCTURA(otel): H30mm 7.91 eur/mp, tf020g1 H85mm 9.23 eur/mp, tf050g1 H105mm 7.93 eur/mp, ts070g1 H215mm 9.10 eur/mp, ts170g1 H500mm 7.91 eur/mp, tt120g1 H1000mm 21.23 eur/mp, tt200g1 Preturile nu includ TVA. Livrare din stoc in toata tara. -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
On Tue, Dec 16 2008, Richard Hartmann wrote: I think he had the implied accussation from the GR's text in mind. Option 1 is to 'Reaffirm the Social Contract', which means that dissenting votes weaken and/or break the SC. No idea if that is on purpose or a honest mistake, but I am assuming good faith with Manoj as with everyone else. The title for ballot lines are proposed by the proposer when titling their proposals. Ask the proposer. manoj -- What soon grows old? Gratitude. Aristotle Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
On Tue, Dec 16 2008, Steve McIntyre wrote: On Tue, Dec 16, 2008 at 04:27:22PM -0800, Russ Allbery wrote: This is where I have a strong disagreement with Manoj and apparently with you. I don't think there's any justification in the constitution for requiring a developer statement about the project's sense of the meaning of the SC and the DFSG to have a 3:1 majority, or to make a developer override to enforce that sense of the meaning. Both the override and the statement about the meaning of the documents should require 1:1. 3:1 should only be required when the documents are explicitly superseded or changed, not just for making a project statement about their interpretation. And that's my interpretation too. I think the constitution is quite clear here. Frankly, if you want a non-binding position statement you should make that explicit; the developers resove via a general resolution actions that go against a foundation document need the supermajority, in my opinion. manoj -- In order to form an immaculate member of a flock of sheep one must, above all, be a sheep. Albert Einstein : Understanding the world Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
Manoj Srivastava wrote: On Wed, Dec 17 2008, Luk Claes wrote: Manoj Srivastava wrote: On Sun, Dec 14 2008, Pierre Habouzit wrote: On Sun, Dec 14, 2008 at 03:02:17AM +, Debian Project Secretary wrote: Seems liek there was plenty of time to change things, and add some of the power set options on to the ballot. If I had added options willy-nilly, you would have screamed again of abuse of power. Sure, though you could have followed the procedure or hinted people in an even saner direction IMHO. I followed the procedure that I think we have followed in the past. We do ont make people jump through and replace all the words in the proposal by these words hoops, and we put related proposals on the same ballot. Unfortunately, some of the proposals are not mutually exclusive, so combinations are possible; and I did not want to increase the size of the ballot with combinations; I think had I done that, there would still have been accusations of the ballot being too complex. Right, this kind of makes your above point moot IMHO. Cheers Luk -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
Manoj Srivastava wrote: On Sun, Dec 14 2008, Russ Allbery wrote: Bas Wijnen wij...@debian.org writes: On Sun, Dec 14, 2008 at 12:59:12PM -0800, Russ Allbery wrote: It's a shame that the vote was handled in the way that it was, Actually, I think the secretary has done a very good job in preparing the ballot. I would like to feel that, but unfortunately, I don't think the facts support that feeling. The 3:1 majority part I can understand. That's his job, and whether I agree or not, I can't get upset at him for doing his job. However, there are several other serious irregularities in this vote: * Why does releasing despite DFSG violations require a 3:1 majority now when it didn't for etch? It's the same secretary in both cases. What changed? I didn't find any of the explanations offered for this very satisfying. The proposal we used before is choice 5 in the current ballot, and that does indeed have a 1:1 majority like we did before. The devil lies in the details (and I have explained the details before too) -- which is that we state that the fiormware blob be released under a DFSG free licence. This means we explictly conform to the DFSG, Without that clause, in choice 2, we are just accepting any firmware blob, with any license, which means that we are allowing for the DFSG to be violated I do not think we released before with known violations. We released with things we strongly suspected as being violations; since we strongly suspect the blob was not the preferred form of modification, but we do not know for a fact. How is this different now btw? * Bundling the vote against the open opposition of a fairly significant number of people, including some of the people whose amendments were grouped together, is within his power but comes across poorly. There wasn't much attempt to compromise or discuss this, and I came away from that with a bad taste in my mouth. Have we not been discussing this for weeks now? Related options belong on the same ballot. Not doing so allows for strategic voting to game the issue. This is not really an opinion piece, this is a known flaw of splitting votes where condorcet is used. Because you seem to only have considered splitting the vote with the existing options and have no where suggested it would be better to split the options by topic and ask if the proposers and seconders would feel that was more appropriate... I am sorry about the bad taste in your mouth, but unless you can argue how we can guard against gaming the system when we split votes, I don't see where we are going with this. See above. * One role of the secretary is to interpret the constitution. The constitution states fairly clearly the process of decision-making for decisions of this type, such as whether a given package violates the DFSG, or how to weigh the implications of the Social Contract. Yet that decision-making process is not reflected in the ballot or in the presentation of the options. Option 1 is either meaningless or an override of a delegate decision, but the ballot doesn't reflect this. While the options are not written by the secretary, and people would consider it a gross abuse of power if I wrote things up as I felt thy should be written; the proposer could have made the overriding the decision of a delegate explicit. You could have made it clear that's how you interpret things and offered the proposers and seconders to think about changing it? Usually, the ballot form is created by the proposer, it contains the title of the proposal, as the proposer set it, and any majority requirements. Unless the proposer does not set it, then it *seems* to me at least that you try to come up with something without actually consulting the proposer and seconders. Option 4 looks equivalent to FD if you look at the decision-making process in the constitution, but the ballot doesn't reflect that. I think some additional clarity around that would have been very helpful. Again, the proposers or seconds could have improved the proposal. What does this have to do with the secretary. The secretary is supposed to have experience in taking votes and could suggest improving the proposal to the proposer and seconders? So, no, I think in this case Manoj did a poor job of preparing this ballot. (That doesn't mean that I have any problems with him personally, nor do I believe that he did so out of any ulterior motives. I think he made the decisions that he thought were correct. I just don't think they were good decisions.) Point 1 has been answered; and again today, point 2 is related to not splitting of related proposals or candidates for resolving the release into spearate vote while we use condorcet, and point 3 is unrelated to decisions I took; heck, I'd love to rewrite proposals other
Re: First call for votes for the Lenny release GR
Manoj Srivastava wrote: On Tue, Dec 16 2008, Steve McIntyre wrote: On Tue, Dec 16, 2008 at 04:27:22PM -0800, Russ Allbery wrote: This is where I have a strong disagreement with Manoj and apparently with you. I don't think there's any justification in the constitution for requiring a developer statement about the project's sense of the meaning of the SC and the DFSG to have a 3:1 majority, or to make a developer override to enforce that sense of the meaning. Both the override and the statement about the meaning of the documents should require 1:1. 3:1 should only be required when the documents are explicitly superseded or changed, not just for making a project statement about their interpretation. And that's my interpretation too. I think the constitution is quite clear here. Frankly, if you want a non-binding position statement you should make that explicit; the developers resove via a general resolution actions that go against a foundation document need the supermajority, in my opinion. Well, apparently not all DDs concur with that interpretation, though you have the explicit power to interpete the constitution, so be it (these DDs should probably explicitely propose something to maybe change the constitution). Cheers Luk -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
Manoj Srivastava sriva...@debian.org writes: On Sun, Dec 14 2008, Russ Allbery wrote: * Why does releasing despite DFSG violations require a 3:1 majority now when it didn't for etch? It's the same secretary in both cases. What changed? I didn't find any of the explanations offered for this very satisfying. The proposal we used before is choice 5 in the current ballot, and that does indeed have a 1:1 majority like we did before. Yes, I withdraw this. I found the title of that choice very confusing, but the text is the same as the previous proposition and has the same majority requirement. * Bundling the vote against the open opposition of a fairly significant number of people, including some of the people whose amendments were grouped together, is within his power but comes across poorly. There wasn't much attempt to compromise or discuss this, and I came away from that with a bad taste in my mouth. Have we not been discussing this for weeks now? Related options belong on the same ballot. Not doing so allows for strategic voting to game the issue. This is not really an opinion piece, this is a known flaw of splitting votes where condorcet is used. Yes, you've said this, and I understand your point and I understand that you feel this is very important, but clearly a lot of people don't agree with you and are willing to live with potential strategic voting in favor of having separate ballots. I don't think your concerns, while valid, were a good justification for turning something into an amendment that wasn't proposed as one. I see why you made the decision. I just don't think it's a good one. (But it's someplace where I can see where reasonable people can disagree.) * One role of the secretary is to interpret the constitution. The constitution states fairly clearly the process of decision-making for decisions of this type, such as whether a given package violates the DFSG, or how to weigh the implications of the Social Contract. Yet that decision-making process is not reflected in the ballot or in the presentation of the options. Option 1 is either meaningless or an override of a delegate decision, but the ballot doesn't reflect this. While the options are not written by the secretary, and people would consider it a gross abuse of power if I wrote things up as I felt thy should be written; the proposer could have made the overriding the decision of a delegate explicit. Yes, sorry, that's a very good point. Option 4 looks equivalent to FD if you look at the decision-making process in the constitution, but the ballot doesn't reflect that. I think some additional clarity around that would have been very helpful. Again, the proposers or seconds could have improved the proposal. What does this have to do with the secretary. The 3:1 majority here is what has to do with the secretary. Given that this option is functionally the same as FD, and FD doesn't require a 3:1 majority, I think this is rather odd. But this was discussed in more depth in another message. Basically, to declare this option as requiring a 3:1 majority assumes an answer to precisely the question that's being disputed, and I don't think that falls under the purview of the secretary. The secretary interprets the constitution, but not the DFSG or the SC. It's one of those difficult balancing acts: you do have to decide whether to require a 3:1 majority, which partly requires interpretation, but interpretation may be the matter under dispute. In this particular case, I think the best approach would be to take the word of the amendment proposers on whether they intend to supersede a foundation document or whether they are only proposing a non-binding resolution on the sense of the project (or possibly a delegate decision override that doesn't change the foundation document). To reiterate, I'm expressing disagreement with specific decisions, but not with you personally, with your motives, or with your intentions. I do not agree with a lot of what's been said in these threads. I personally think you've done consistently solid work as secretary and have always been willing to present a detailed rationale for your decisions. I don't think it's the end of the world if we don't find agreement on what should have been done in this particular case -- I think we've at least gotten out of it some clear ideas for how to handle similar votes in the future. My personal hope continues to be that we manage to vote by a 3:1 majority on one direction or another about this underlying issue so that we can stop living in the ambiguous middle zone in our decision-making. Also, after this message, I'm going to stop discussing what I think we could have done with this ballot, since at this point it's rather late to change it and I don't think withdrawing it and reissuing it would really accomplish anything that useful. So this
Re: First call for votes for the Lenny release GR
On Sun, Dec 14 2008, Russ Allbery wrote: Option 4 looks equivalent to FD if you look at the decision-making process in the constitution, but the ballot doesn't reflect that. I think some additional clarity around that would have been very helpful. Not really. I think that the power to decide to violate the DFSG is not given to _anyone_ in the constitution. Option 4 explicitly adds this power. So, currently, the RT can not violate the DFSG (and I think they have been stating all along that they are not, in their opinion, violating the DFSG); with option 4 they can. This I think is the distinction between option 4 and FD. Why were these clarifying questions not asked of the proposers in the discussion period? manoj -- When a man is tired of London, he is tired of life. Samuel Johnson Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
On Tue, Dec 16 2008, Matthew Woodcraft wrote: Russ Allbery r...@debian.org wrote: If there were something in the constitution detailing decision-making process around foundation documents and their interpretation, it would have made this whole conflict easier to resolve. But so far as I can tell, there isn't, apart from application to voting specifically. There isn't anything in the constitution about the application of foundation documents to voting either, other than the rule about superseding them. If the proposer of vote/2003/vote_0003 had intended it to give the Secretary power to impose supermajority requirements on the grounds that an option conflicts with a foundation document, one would have expected him to have said so explicitly. So, in your opinion, which decision making entity is empowered by the constitution to make decisions about super majority requirements? What are the constraints on their ability to decide on this? What should they be looking at, apart from the constitution, to decide whether a super majority rule should apply? manoj -- The man on tops walks a lonely street; the chain of command is often a noose. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
On Sun, Dec 14 2008, Russ Allbery wrote: Russ Allbery r...@debian.org writes: * Bundling the vote against the open opposition of a fairly significant number of people, including some of the people whose amendments were grouped together, is within his power but comes across poorly. There wasn't much attempt to compromise or discuss this, and I came away from that with a bad taste in my mouth. Or perhaps *not* within his power given that one of the proposals was not offered as an amendment. Which makes it come across even more poorly. We have not been making people do formal amendments at all (replace all the words of the amendment foo with these words). I also think that placing all related proposals on a single ballot is relevant, it prevents an easy exploit of the voting system by simply setting up a series of votes that can be gamed, and setting up all kinds of related proposals to be set up on different ballots. Frankly, I think that kind of gaming of the voting system that is being proposed now, and I am not comfortable letting that happen. manoj -- If you stop to think about it, you're already dead. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
Manoj Srivastava wrote: On Tue, Dec 16 2008, Matthew Woodcraft wrote: Russ Allbery r...@debian.org wrote: If there were something in the constitution detailing decision-making process around foundation documents and their interpretation, it would have made this whole conflict easier to resolve. But so far as I can tell, there isn't, apart from application to voting specifically. There isn't anything in the constitution about the application of foundation documents to voting either, other than the rule about superseding them. If the proposer of vote/2003/vote_0003 had intended it to give the Secretary power to impose supermajority requirements on the grounds that an option conflicts with a foundation document, one would have expected him to have said so explicitly. So, in your opinion, which decision making entity is empowered by the constitution to make decisions about super majority requirements? What are the constraints on their ability to decide on this? What should they be looking at, apart from the constitution, to decide whether a super majority rule should apply? I would think the explicit overriding or removal of parts of foundation documents aka changing them as I read it in the constitution (but apparently my interpretation differs from yours). Cheers Luk -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
On Wed, Dec 17 2008, Loïc Minier wrote: On Wed, Dec 17, 2008, Manoj Srivastava wrote: The way that we achive such combinations using condorcet is to propose such combinations as options intheir own right; and then have people vote on the combination option along with simple options. Or do separate votes... Separate votes on related proposals are widely open to gaming the system. There was no such proposal during the discussion period. It was your decision to make a single ballot out of these orthogonal issues, do not present the situation as being the proposers' fault. It is not the proposers fault in any case; it is, if anything, the responsibiulity of folks who wanted to vote on more than one option at a time, even when it was clear that the ballot was the way it is now. Secondly, I have presented my arguments why these proposals are all strongly related, and thus deserve to be on the same ballot for a fair vote. I do not see any counter arguments here. manoj -- Suicide is the sincerest form of self-criticism. Donald Kaul Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
On Wed, Dec 17 2008, Luk Claes wrote: Manoj Srivastava wrote: On Tue, Dec 16 2008, Steve McIntyre wrote: On Tue, Dec 16, 2008 at 04:27:22PM -0800, Russ Allbery wrote: This is where I have a strong disagreement with Manoj and apparently with you. I don't think there's any justification in the constitution for requiring a developer statement about the project's sense of the meaning of the SC and the DFSG to have a 3:1 majority, or to make a developer override to enforce that sense of the meaning. Both the override and the statement about the meaning of the documents should require 1:1. 3:1 should only be required when the documents are explicitly superseded or changed, not just for making a project statement about their interpretation. And that's my interpretation too. I think the constitution is quite clear here. Frankly, if you want a non-binding position statement you should make that explicit; the developers resove via a general resolution actions that go against a foundation document need the supermajority, in my opinion. Well, apparently not all DDs concur with that interpretation, though you have the explicit power to interpete the constitution, so be it (these DDs should probably explicitely propose something to maybe change the constitution). I would be happy if the constitution was changed, to clarify the issue, or to explicitly add another entity (foundation doc interpretation ctte) to handle intepretations, in which case the whole issue could just be referred to them. As it stands, however, I can only do what I think is right, after listening to what other people say. And I have. I just have ont been convinced of the arguments to change what I think is the right thing to do. manoj -- The world is all the richer for having the devil in it, so long as we keep our foot on his neck. --anonymous Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
On Wed, Dec 17, 2008 at 01:54:40PM -0600, Manoj Srivastava wrote: On Mon, Dec 15 2008, Russ Allbery wrote: Thomas Weber thomas.weber.m...@gmail.com writes: Am Montag, den 15.12.2008, 10:06 + schrieb Steve McIntyre: I've been talking with Manoj already, in private to try and avoid flaming. I specifically asked him to delay this vote until the numerous problems with it were fixed, and it was started anyway. I'm *really* not happy with that, and I'm following through now. Uh, I don't quite get this: you shortened the discussion period, but at the same time asked the secretary to delay the vote? Where did Steve shorten the discussion period? He did so for the *other* vote, but I haven't seen a thread where he did for this one. (I may have just missed it.) I mis remembered. Steve shortened the discussion period for this vote, and the discussion and voting period for the _other_ vote, but I missed that the vote period for the gr_lenny vote was not shortened. I'll send out a new CFV. OK, does this mean that everyone who already cast their vote will need to do so again, or will the voting period simply be extended another week? Regards: David -- /) David Weinehall t...@debian.org /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
Manoj Srivastava wrote: On Tue, Dec 16 2008, Steve McIntyre wrote: On Tue, Dec 16, 2008 at 04:27:22PM -0800, Russ Allbery wrote: This is where I have a strong disagreement with Manoj and apparently with you. I don't think there's any justification in the constitution for requiring a developer statement about the project's sense of the meaning of the SC and the DFSG to have a 3:1 majority, or to make a developer override to enforce that sense of the meaning. Both the override and the statement about the meaning of the documents should require 1:1. 3:1 should only be required when the documents are explicitly superseded or changed, not just for making a project statement about their interpretation. And that's my interpretation too. I think the constitution is quite clear here. Frankly, if you want a non-binding position statement you should make that explicit; the developers resove via a general resolution actions that go against a foundation document need the supermajority, in my opinion. AIUI, the issue here is not wether you need supermajority to act against a foundation document, but rather wether said actions are contrary to that document. In other words, the issue is that it's not clear that releasing with DFSG violations is a violation of the constitution by the release team. Some people argue that they are infringing the constitution by explicitly allowing said DFSG violations into lenny. Others argue that Debian is main, not stable main, so the DFSG should not be applied more strictly for stable than testing/unstable, and thus allowing certain DFSG violations into the next stable is not a infringement of the constitution by the release team. I don't see anywhere that stable should be considered differently DFSG-wise to testing/unstable or even experimental. -- Felipe Sateler -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
On Wed, Dec 17 2008, Russ Allbery wrote: Manoj Srivastava sriva...@debian.org writes: Have we not been discussing this for weeks now? Related options belong on the same ballot. Not doing so allows for strategic voting to game the issue. This is not really an opinion piece, this is a known flaw of splitting votes where condorcet is used. Yes, you've said this, and I understand your point and I understand that you feel this is very important, but clearly a lot of people don't agree with you and are willing to live with potential strategic voting in favor of having separate ballots. I don't think your concerns, while valid, were a good justification for turning something into an amendment that wasn't proposed as one. I see why you made the decision. I just don't think it's a good one. (But it's someplace where I can see where reasonable people can disagree.) I am sorry that you do not agree, but I am failing to see the rationale for preferring a route that allows our votes to be gamed (and thus, arguably, tainting the process _anyway_) to an omnibus vote. And there is no reason we can't still have multiple votes; just because a proposal does not win this round is no reason it can't be brought up again. The 3:1 majority here is what has to do with the secretary. Given that this option is functionally the same as FD, and FD doesn't require a 3:1 majority, I think this is rather odd. But this was discussed in more depth in another message. I do not think that FD means release lenny, I think FD means delay until we are sure we meet the DFSG. But again, what I think of the FD does not carry weight; but it does explain why I do not think the FD needed a 3:1 majority. Basically, to declare this option as requiring a 3:1 majority assumes an answer to precisely the question that's being disputed, and I don't think that falls under the purview of the secretary. The secretary interprets the constitution, but not the DFSG or the SC. It's one of those difficult balancing acts: you do have to decide whether to require a 3:1 majority, which partly requires interpretation, but interpretation may be the matter under dispute. In this particular So who interprets the DFSG and the SC in regular day to day activities? Do we not interpret it as best? Isn't your argument that the release team should be interpreting the DFSG and SC in their work? If the release team is not allowed to interpret the DFSG and SC in order to release who is? case, I think the best approach would be to take the word of the amendment proposers on whether they intend to supersede a foundation document or whether they are only proposing a non-binding resolution on the sense of the project (or possibly a delegate decision override that doesn't change the foundation document). Well, if the proposers wanted a non-binding resolution, why is that not clear in the proposal itself? If it had been explicitly stated that this is not what the developers decided by the means of a general resolution as a course of actrion, but just as a non-binding resolution, then there might have been some justification to let it stand alone (though I would have refused to run that vote, since I do not feel comforable aiding and abetting creation of a position statement that contradicts, in my view, a foundation document. However, I would let the asst. secretary run that wvote, if they were amenable). But lacking an explicit statement that it is a non-binding resolution and should be treated like one, I must treat is as something the project resolves to do via a general resolution, whether or not the foundation documents are against that. Also, after this message, I'm going to stop discussing what I think we could have done with this ballot, since at this point it's rather late to change it and I don't think withdrawing it and reissuing it would really accomplish anything that useful. So this becomes rehashing of decisions already made, which can be done forever to quickly diminishing returns. If there is sufficient support for scrapping and restarting the vote, despite the fact it has been started, I would not be in opposition. But I am not going to stick my necj out and propose it; however, if people think the ballot needs more options, and that this ballot is a mess, and they can't vote on it, and enough people stand up to support that view, it might be better for the project to allow the ballot to be amended, and reopen the discussion period. manoj -- Pournelle must die! Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
Manoj Srivastava sriva...@debian.org writes: On Wed, Dec 17 2008, Russ Allbery wrote: Basically, to declare this option as requiring a 3:1 majority assumes an answer to precisely the question that's being disputed, and I don't think that falls under the purview of the secretary. The secretary interprets the constitution, but not the DFSG or the SC. It's one of those difficult balancing acts: you do have to decide whether to require a 3:1 majority, which partly requires interpretation, but interpretation may be the matter under dispute. So who interprets the DFSG and the SC in regular day to day activities? Do we not interpret it as best? Isn't your argument that the release team should be interpreting the DFSG and SC in their work? Yes. And they seem to have already done this and arrived at a conclusion, and this GR is being proposed to override that decision. Since option four effectively supports the existing delegate decision about how the SC and DFSG should be applied, deciding whether or not it requires a 3:1 supermajority is basically equivalent to deciding whether or not you think the release team is following the DFSG and SC now. Which reduces to the same problem that's the subject of the vote in the first place. To some extent, as secretary, you're basically screwed here. Every decision that you can make about majority is arguably begging the question. I think the best way out of that trap is to take a step back and defer to the decision-making process: there's a conflict over the DFSG and SC, currently who decides? is the delegate, and they've decided that it means the lenny release can go forward. Therefore, in this area, that's the prevailing interpretation unless the project overturns that decision via GR. Of course, the other argument that can be made here is that option four is intended to be more sweeping than the existing delegate decision by making that decision binding on the rest of the project or making it permanent or some other material change. I can sort of see that if I squint at it, but I don't think that was the intention. (The if necessary we authorize those decisions adds some ambiguity, since it's not really clear to me which power of the developers acting via GR that's referring to. I, of course, didn't say anything about that at any point when it would have been useful to do so, and your points about how you're not responsible for any of the wording are very well-taken.) If the release team is not allowed to interpret the DFSG and SC in order to release who is? Yeah, that's exactly the problem. My reading of the constitution is that in the absence of a GR, the release team has that power. In other words, my reading of option four is that what it proposes is the same as the current state, modulo details of wording. -- 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
Re: First call for votes for the Lenny release GR
On Wed, Dec 17 2008, Loïc Minier wrote: On Wed, Dec 17, 2008, Manoj Srivastava wrote: I also think that placing all related proposals on a single ballot is relevant, it prevents an easy exploit of the voting system by simply setting up a series of votes that can be gamed, and setting up all kinds of related proposals to be set up on different ballots. Frankly, I think that kind of gaming of the voting system that is being proposed now, and I am not comfortable letting that happen. BS. People still need to find enough seconds; if you think we need more seconds for GRs, propose a GR. I do not think I meant proposed as in formal proposals to be voted upon. I meant splitting up votes for the same issue which leads to the results being gamed. Say, for example, we do split up the votes. And the winning options of different votes contradict. Which takes precedence? If it is the latest vote, which vote is voted upon last? Can I withsraw an option, and put it to vote at the very end, to get an edge? Why is having an omnibus vote now, and a vote on option #4 and option #6 in January any worse than arbitarily splitting votes? (We could stipulate that actions on the january votes apply only after lenny releases, to prevent people trying to game the lenny release). manoj -- The truth is rarely pure, and never simple. Oscar Wilde Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
On Wed, Dec 17 2008, David Weinehall wrote: On Wed, Dec 17, 2008 at 01:54:40PM -0600, Manoj Srivastava wrote: On Mon, Dec 15 2008, Russ Allbery wrote: Thomas Weber thomas.weber.m...@gmail.com writes: Am Montag, den 15.12.2008, 10:06 + schrieb Steve McIntyre: I've been talking with Manoj already, in private to try and avoid flaming. I specifically asked him to delay this vote until the numerous problems with it were fixed, and it was started anyway. I'm *really* not happy with that, and I'm following through now. Uh, I don't quite get this: you shortened the discussion period, but at the same time asked the secretary to delay the vote? Where did Steve shorten the discussion period? He did so for the *other* vote, but I haven't seen a thread where he did for this one. (I may have just missed it.) I mis remembered. Steve shortened the discussion period for this vote, and the discussion and voting period for the _other_ vote, but I missed that the vote period for the gr_lenny vote was not shortened. I'll send out a new CFV. OK, does this mean that everyone who already cast their vote will need to do so again, or will the voting period simply be extended another week? I was just thinking of postposing the end-of-vote cron job, so no re-voting would be needed. If there is sufficient support, we could also scrap the current vote, change our ballot, add options to it, or something, and restart the vote, but that would need a strong grass roots support (I do not think the secretary has the power to do so). manoj -- today, n.: A nice place to visit, but you can't stay here for long. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
On Wed, Dec 17 2008, Luk Claes wrote: Manoj Srivastava wrote: On Tue, Dec 16 2008, Matthew Woodcraft wrote: If the proposer of vote/2003/vote_0003 had intended it to give the Secretary power to impose supermajority requirements on the grounds that an option conflicts with a foundation document, one would have expected him to have said so explicitly. So, in your opinion, which decision making entity is empowered by the constitution to make decisions about super majority requirements? What are the constraints on their ability to decide on this? What should they be looking at, apart from the constitution, to decide whether a super majority rule should apply? I would think the explicit overriding or removal of parts of foundation documents aka changing them as I read it in the constitution (but apparently my interpretation differs from yours). Parse error. Which entity did you mean? Or are you just answering the last question? Does that mean we can just not follow the foundation documents by doing something different, but just not saying explicitly we are over riding them? So, as long as we do not make the faux-paux of explicitly amending a foundation document, we can change bits and pieces of it, as much as we want? Seems like saying that we need a super majoruty to change foundation documents is silly, since all we actually need is to never say so explicitly. I am not sure I am confortable with this wink, wink, nudge nudge approach. manoj -- Lockwood's Long Shot: The chances of getting eaten up by a lion on Main Street aren't one in a million, but once would be enough. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
On Wed, Dec 17, 2008 at 05:12:03PM -0600, Manoj Srivastava wrote: On Wed, Dec 17 2008, Luk Claes wrote: I would think the explicit overriding or removal of parts of foundation documents aka changing them as I read it in the constitution (but apparently my interpretation differs from yours). Parse error. Which entity did you mean? Or are you just answering the last question? Does that mean we can just not follow the foundation documents by doing something different, but just not saying explicitly we are over riding them? So, as long as we do not make the faux-paux of explicitly amending a foundation document, we can change bits and pieces of it, as much as we want? Seems like saying that we need a super majoruty to change foundation documents is silly, since all we actually need is to never say so explicitly. I am not sure I am confortable with this wink, wink, nudge nudge approach. And other people are not comfortable with you claiming a power that is not grounded in the constitution: namely, the power to declare that a ballot option needs supermajority, even if it is not a motion to directly amend or supersede a foundation document. That's the problem here. Whether you think you *should* have that power is a different question, but many people are convinced you do not have it now. -- Steve McIntyre, Cambridge, UK.st...@einval.com ...In the UNIX world, people tend to interpret `non-technical user' as meaning someone who's only ever written one device driver. -- Daniel Pead -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
On Wed, Dec 17 2008, Russ Allbery wrote: Manoj Srivastava sriva...@debian.org writes: On Wed, Dec 17 2008, Russ Allbery wrote: Basically, to declare this option as requiring a 3:1 majority assumes an answer to precisely the question that's being disputed, and I don't think that falls under the purview of the secretary. The secretary interprets the constitution, but not the DFSG or the SC. It's one of those difficult balancing acts: you do have to decide whether to require a 3:1 majority, which partly requires interpretation, but interpretation may be the matter under dispute. So who interprets the DFSG and the SC in regular day to day activities? Do we not interpret it as best? Isn't your argument that the release team should be interpreting the DFSG and SC in their work? Yes. And they seem to have already done this and arrived at a conclusion, and this GR is being proposed to override that decision. Since option four effectively supports the existing delegate decision about how the SC and DFSG should be applied, deciding whether or not it requires a 3:1 supermajority is basically equivalent to deciding whether or not you think the release team is following the DFSG and SC now. Which reduces to the same problem that's the subject of the vote in the first place. I am not sure how even choice 1 is over riding that decision. Do you believe that the release team, despite their protestations, is bundling DFSG violatons into main? If the release team is releasing only free stuff, then option 1 is being followed. I do not see where you get this over ride a delegate bit from, unless you are accusing the release team of violating the 100 % free debian system bit. Can you clarify? To some extent, as secretary, you're basically screwed here. Every decision that you can make about majority is arguably begging the question. Hmm. So, in my role as a vote taker, I have to decide on the majority requirement of every option, and so my daily tasks require interpretation of the SC/DFSG to see if they are being overridden or changed. Now, who gets to interpret that SC/DFSG? perhaps what follows may shed some light. I think the best way out of that trap is to take a step back and defer to the decision-making process: there's a conflict over the DFSG and SC, currently who decides? is the delegate, and they've decided that it means the lenny release can go forward. Therefore, in this area, that's the prevailing interpretation unless the project overturns that decision via GR. Wonderful. The delegate, or the role in charge, decodes how to interpret the DFSG and the SC in their day to day work. All we have to do is decide who the role in charge is that decodes how the DFSG and SC is to be interpreted when deciding of the procedures and form of the ballot in a vote. Right? Of course, the other argument that can be made here is that option four is intended to be more sweeping than the existing delegate decision by making that decision binding on the rest of the project or making it permanent or some other material change. I can sort of see It defines what the Debian system is, since our OS is what I think the SC is referring to. So, any decisions about the Debian system does impact the social contract, which is something I do considere binding on the developers -- we all agreed to it, right? Now, we are saying that we are giving away the decisions to decide about violations of the social contract with respect to the Debian system to a handful of developers. that if I squint at it, but I don't think that was the intention. (The if necessary we authorize those decisions adds some ambiguity, since it's not really clear to me which power of the developers acting via GR that's referring to. I, of course, didn't say anything about that at any point when it would have been useful to do so, and your points about how you're not responsible for any of the wording are very well-taken.) If the release team is not allowed to interpret the DFSG and SC in order to release who is? Yeah, that's exactly the problem. My reading of the constitution is that in the absence of a GR, the release team has that power. So, who gets to decide how to interpret the DFSG and the SC when it comes to voting procedures and the final form of the ballot? In other words, my reading of option four is that what it proposes is the same as the current state, modulo details of wording. Why is option 1 different from option 4, unless the release team is deciding to violate the social contract (which they have repeatedly said they are not)? manoj -- I'd put my money where my mouth is, but my mouth keeps moving. Larry Wall in 199704051723.jaa28...@wall.org Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493
Re: First call for votes for the Lenny release GR
Manoj Srivastava sriva...@debian.org writes: I am not sure how even choice 1 is over riding that decision. Do you believe that the release team, despite their protestations, is bundling DFSG violatons into main? If the release team is releasing only free stuff, then option 1 is being followed. I do not see where you get this over ride a delegate bit from, unless you are accusing the release team of violating the 100 % free debian system bit. Can you clarify? If you go back to my original message on this, you'll see that I said that *either* option 1 is a delegate override *or* it's meaningless. It sounds like you're arguing (probably just for the sake of discussion) that it's meaningless and we should continue on to release lenny even if it passes. Is that correct? *This* is exactly why I think that the ballot is poorly worded and could have used additional assistance, not in the form of rewriting it, but in the form of someone saying uh, this makes no sense -- if you want to override a decision, be explicit. I agree that any of us could have offered that assistance, and therefore this is something of a collective failure. There are multiple different ways by which to arrive at the conclusion that releasing lenny as-is doesn't violate the SC. One of them is that points 1 and 4 of the SC are in conflict and we steer a course between the two of them. Another is that the DFSG doesn't apply to firmware now. Another is that the SC is a goal that we don't need to meet in full immediately. Another is that given that the software is already in the archive, whatever problems there are aren't the release team's problem. There are probably others. I've seen all of the above put forward by different people as part of this discussion. I intend to extent to all of my fellow developers the assumption that they hold their opinions sincerely and not deceptively. I can't tell you which interpretation is correct, if any of them -- that's exactly the point under dispute. I can tell you what I personally believe, but that doesn't really mean anything. Other people can arrive at similar conclusions for entirely different reasons. I don't agree with all of those opinions, but that doesn't matter -- that just means that we don't have consensus, and we knew that already. The question now is how do we decide what to do given the lack of consensus. I think it was manifestly clear from the way in which Robert Millan made his proposal and the discussion leading up to it that he intended it to be a delegate decision override, and I think that even in the absence of better wording to make that explicit, the project should treat it accordingly anyway, since that was obviously the intent. To some extent, as secretary, you're basically screwed here. Every decision that you can make about majority is arguably begging the question. Hmm. So, in my role as a vote taker, I have to decide on the majority requirement of every option, and so my daily tasks require interpretation of the SC/DFSG to see if they are being overridden or changed. Now, who gets to interpret that SC/DFSG? perhaps what follows may shed some light. Except that then you end up in the situation we're in now, where an option that is functionally equivalent to further discussion gets a 3:1 majority requirement because you don't agree with the delegate decision, and I don't think that's a good place to be. That's why I'm trying to offer a proposal for how the secretary can decide a majority requirement when the question of a majority requirement is exactly what is under dispute. I think that would be worthwhile because I think it gets us a more workable decision-making process that's still consistent with the constitution. Otherwise, we can get into a situation where a strong disagreement between a delegate and the secretary on an issue where the project does not have a 3:1 majority either way results in a ballot that cannot decide the topic, because no one agrees about whether a majority vote sufficiently decides a question. Wonderful. The delegate, or the role in charge, decodes how to interpret the DFSG and the SC in their day to day work. All we have to do is decide who the role in charge is that decodes how the DFSG and SC is to be interpreted when deciding of the procedures and form of the ballot in a vote. Right? No, I think this is too simplistic. A vote is not solely your work as secretary. It also has a direct effect on other people's work. It's effectively part of multiple decision-making processes at the same time. Now, we are saying that we are giving away the decisions to decide about violations of the social contract with respect to the Debian system to a handful of developers. The constitution says that, by not creating any special status or separate decision-making process for disputes over interpretations and application of
Re: First call for votes for the Lenny release GR
On Wed, Dec 17 2008, Steve McIntyre wrote: And other people are not comfortable with you claiming a power that is not grounded in the constitution: namely, the power to declare that a ballot option needs supermajority, even if it is not a motion to directly amend or supersede a foundation document. That's the problem here. Whether you think you *should* have that power is a different question, but many people are convinced you do not have it now. A: the final form of the ballot, including the supermajority requirements, is specified in the conbstitution. Also, resolving to do something that overrides a foundation document, in whole or in part, is equivalent to creating a ew version of the foundation document, and adhereing to that. So any resolution, not explicitly stated to be a non-binding position statement, which contravenes a foundation document, is committing us to a course that requires us to override a foundation document. I think the intent of the constitution would be issue a new version, instead of allowing a 1:1 majority end run around foundation documents. I am fairly comfortable in the grounding in the constitution powers bit. manoj -- Any given program, when running, is obsolete. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bundled votes and the secretary
On Wed, Dec 17, 2008 at 12:25:14PM -0600, Manoj Srivastava wrote: As a matter of fact, there's that too. This ballot has been assembled in contravention of the Standard Resolution Procedure, which requires that new ballot options be proposed as formal *amendments* to an outstanding GR proposal in order to appear on the same ballot. Manoj has overstepped his authority in order to group separately proposed resolutions about orthogonal questions on a single ballot, over the explicit objections of the proposer/seconders. This is not a power granted to the secretary under A.2. All related options are placed on the ballot, no? I am working on the basis that any proposal, and all related proposals that may affect the action to be taken, must be on the ballot. What A.3.1. actually says is: Each resolution and its related amendments is voted on in a single ballot that includes an option for the original resolution, each amendment, and the default option (where applicable). That doesn't give the secretary the power to group separate proposals on a single ballot merely because they touch on the same subject matter; it says only that related *amendments* belong on the same ballot. None of the amendments in recent votes take the formal form (I amend foo, and replace all the words in the proposal with the words below). Amendments (made formal by seconds) just propose what the alternate handling being proposed, and related proposals go on the ballot. This is how the related amendment has been handled in practice over the last several years. Where there's ambiguity about whether a proposer intended an amendment vs. a stand-alone proposal, I think it's perfectly reasonable to allow the secretary latitude in determining intent so as to not get bogged down in proceduralism. I don't think that was the case here for 20081114201224.ga11...@intrepid.palfrader.org - though I'm having a hard time coming up with references at the moment, I believe there were objections from some of the seconders of this proposal that it was meant to be a stand-alone proposal rather than an amendment. When I wrote my earlier message, I believed this was much more clear-cut; on review, I see that the original proposer left the question rather open by referring to his GR as a GR (option). So there are still two possibilities here: - enough of the 17 seconders expressed no opinion on the question of whether this shoud be a separate GR, as would allow interpreting their intent in favor of treating it as an amendment and putting it on a ballot with the original proposal - more than 12 of the formal seconders objected to placing this proposal on the same ballot with the original due to the orthogonal issues, in which case it's not constitutionally valid to override their stated intent by treating it as an amendment. So chances are, there's enough ambiguity here that it's constitutionally valid to put it on the same ballot as a related amendment. There's a separate issue here, however; namely, that the secretary is the *only* line of defense against gaming of the GR process by a small group of developers who propose an uncontroversial but orthogonal amendment that will always win over the alternatives, in the process preventing the will of the project from being formally enacted: http://lists.debian.org/debian-vote/2003/10/msg00168.html http://lists.debian.org/debian-vote/2003/11/msg00052.html http://lists.debian.org/debian-vote/2003/11/msg00095.html http://lists.debian.org/debian-vote/2003/11/msg00101.html http://lists.debian.org/debian-vote/2003/11/msg00105.html It's not unconstitutional for the secretary to keep orthogonal amendments on the same ballot, and it is the secretary's prerogative to keep amendments grouped on a single ballot if he believes they are related. But when there are multiple orthogonal issues being considered on a single ballot, choosing to not split those ballots means disenfranchising the proposers of the less-popular-but-popular-enough-to-pass option. Given that developers already have the power to propose as many serial GRs as needed in order to reconcile incompatibilities between ratified resolutions, the disenfranchisement is a much worse exploit of our voting system than anything that could be achieved by forcing partially-orthogonal options onto separate ballots. -- 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 -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
On Wed, Dec 17, 2008, Manoj Srivastava wrote: I do not think I meant proposed as in formal proposals to be voted upon. I meant splitting up votes for the same issue which leads to the results being gamed. This is an hypothetical case you're making; most people think the issues are orthogonal. We can discuss various ways our voting system can be gamed; I'm concerned by the way it just was. Say, for example, we do split up the votes. And the winning options of different votes contradict. Which takes precedence? If it is the latest vote, which vote is voted upon last? Can I withsraw an option, and put it to vote at the very end, to get an edge? People can try gaming each vote or a group of votes or the voting system; we'll see on a case by case basis. Why is having an omnibus vote now, and a vote on option #4 and option #6 in January any worse than arbitarily splitting votes? (We could stipulate that actions on the january votes apply only after lenny releases, to prevent people trying to game the lenny release). I don't think proposing a change to the proposed resolutions (that they'd apply after lenny) has anything to do with the fact that we vote on them separately or on a single ballot. One reason it's worse is that we will effectively take only one decision instead of at least 3 or 4. -- Loïc Minier -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
On Wed, Dec 17, 2008 at 04:58:26PM -0600, Manoj Srivastava wrote: Why is having an omnibus vote now, and a vote on option #4 and option #6 in January any worse than arbitarily splitting votes? (We could stipulate that actions on the january votes apply only after lenny releases, to prevent people trying to game the lenny release). I would venture that this proposed solution is not worse than a split vote, but that heretofore it was by no means clear that you would allow such votes to take place without being subject to reintroduction of again-orthogonal amendments. -- 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 -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
On Wed, Dec 17 2008, Russ Allbery wrote: Manoj Srivastava sriva...@debian.org writes: I am not sure how even choice 1 is over riding that decision. Do you believe that the release team, despite their protestations, is bundling DFSG violatons into main? If the release team is releasing only free stuff, then option 1 is being followed. I do not see where you get this over ride a delegate bit from, unless you are accusing the release team of violating the 100 % free debian system bit. Can you clarify? If you go back to my original message on this, you'll see that I said that *either* option 1 is a delegate override *or* it's meaningless. It sounds like you're arguing (probably just for the sake of discussion) that it's meaningless and we should continue on to release lenny even if it passes. Is that correct? Actually, no. I was saying that option 1 says: , | Given that we have known for two previous releases that we have non-free | bits in various parts of Debian, and a lot of progress has been made, | and we are almost to the point where we can provide a free version of | the Debian operating system, we will delay the release of Lenny until | such point that the work to free the operating system is complete (to | the best of our knowledge as of 1 November 2008). ` Now, the only way this overrides a delegate is if the delegates and decide that we are not shipping a free operating system. I did not understand that that was the case. *This* is exactly why I think that the ballot is poorly worded and could have used additional assistance, not in the form of rewriting it, but in the form of someone saying uh, this makes no sense -- if you want to override a decision, be explicit. I agree that any of us could have offered that assistance, and therefore this is something of a collective failure. Actuall, given the pwer that the secretary has voer the process, the secretary shoul *NOT* be saying things like uh, this makes no sense -- if you want to override a decision, be explicit. The secretary should *NOT* be deciding if the contents of the proposal are sane. There are multiple different ways by which to arrive at the conclusion that releasing lenny as-is doesn't violate the SC. One of them is that points 1 and 4 of the SC are in conflict and we steer a course between the two of them. Did you read SC #5? SC #5, in my eyes, is what tells us how we reconcile SC #1 abd SC #4. Another is that the DFSG doesn't apply to firmware now. I do not see this in my reading of the SC. Another is that the SC is a goal that we don't need to meet in full immediately. While I do not agree for releases, I think that is true for Sid, and I can see how reasonable people might disagree. Another is that given that the software is already in the archive, whatever problems there are aren't the release team's problem. There are probably others. I've seen all of the above put forward by different people as part of this discussion. I intend to extent to all of my fellow developers the assumption that they hold their opinions sincerely and not deceptively. I can't tell you which interpretation is correct, if any of them -- that's exactly the point under dispute. I can tell you what I personally believe, but that doesn't really mean anything. Other people can arrive at similar conclusions for entirely different reasons. I don't agree with all of those opinions, but that doesn't matter -- that just means that we don't have consensus, and we knew that already. The question now is how do we decide what to do given the lack of consensus. I think it was manifestly clear from the way in which Robert Millan made his proposal and the discussion leading up to it that he intended it to be a delegate decision override, and I think that even in the absence of better wording to make that explicit, the project should treat it accordingly anyway, since that was obviously the intent. Well, I don't see how we can interpret another person's proposal -- but these clarifying questions should have been long resolved now, since asking these questions is why we have a discussion period. No, I think this is too simplistic. A vote is not solely your work as secretary. It also has a direct effect on other people's work. It's effectively part of multiple decision-making processes at the same time. Any developer in a core role has the same impact. The FTP masters, and the release team, have similar impats on the project as a whole. I till think that if a 3:1 majority requirement needs the SC to be interpreted, I am unclear what your suggestion is. My take on it has been that I do as the other delegates do: I interpret the SC for myself, as best I can, and act in goodfaith. I see this situation as no different from that of the FTP master/RM
Re: First call for votes for the Lenny release GR
Margarita Manterola wrote: If we do all this, we would be voting: A) If we trust or not the release team on making the right choices of which bugs to ignore and which not (regardless of this being firmware issues or what have you). This is from now on, not just for Lenny. B) If we want to allow sourceless firmware in Debian, defining firmware in a way that doesn't give a waiver to anything else without source. This is also from now on, not just for Lenny. But it's only for firmware, not for everything with licensing problems. C) If we want to allow stuff with some problems into Lenny, as we already did for Sarge and Etch. These three issues are obviously related, but are NOT the same issue, a positive result in one does not determine what happens to the others. And creating one mega ballot with all the different possibilities, only creates confusion and frustration. So, this should be three independent ballots. I think the concern is, what if the results conflict? e.g. if we get a No for (C) but Yes for (A). We trust the release team to make the right choices but we don't trust them to make the right choices for Lenny? My suggestion would be to vote for (C) first, and then decide the wording on (A) and (B) depending on the outcome of (C). In which case, even if there is a conflict, the wording can clarify if the second vote overrides or doesn't override the first result. -- Brian May br...@microcomaustralia.com.au -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
All of these issues should have been resolved in the discussion period. Sadly, they were not. Is there any constitutional way to do it over and resolve the issues at the appropriate time? For example, could the secretary cancel the vote if either (a) the GR alone, or (b) the GR and all amendments were withdrawn at this late stage? In case (b) the withdrawals could optionally be conditioned on other elements of the vote being withdrawn. --Mike Bird, non DD -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Why the gr_lenny ballot is the way it is
Le Wed, Dec 17, 2008 at 12:15:22PM -0600, Manoj Srivastava a écrit : So, while the power set of the options is not feasible, we could have a slew of options combining the various proposed options, if people wanted to vote on a compatible set of options. Hi Manoj, I am affraid I have not not understood much of your explanations. Furthermore, I have deleted all of today's thread on -vote: I just do not have time to read it. I hope that the most important things you wrote today were in this email anyway. I will vote further discussion because I think that this vote should not have been started, and then option 5 because it is the only way to release Lenny that you did not flag 3:1. I wish the vote has been diffrerent, and hope you will consider taking a break for next secretarial term, so that the Project can try to explore functionning with a non-interventionnist secretary. Best, -- Charles Plessy -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
On Wed, Dec 17, 2008 at 07:45:51AM -0600, Ean Schuessler wrote: A serious license problem could potentially be every bit as disruptive and expensive to our users as a technical problem. I think this factor is really what the discussion is about and why release continues to be a sticking point year after year. No, I'm pretty sure you're the only one harping on /that/ point. None of the GR proposals mandate a particular interpretation of the legality of any component of the archive, the release team has never indicated that they intended to ignore legal problems when releasing, and popular vote is a stupid way to decide questions of law. -- 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 -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
On Wed, 17 Dec 2008 21:45:54 -0200, Margarita Manterola wrote:
On Wed, Dec 17, 2008 at 9:02 PM, Manoj Srivastava sriva...@debian.org wrote:
If there is sufficient support, we could also scrap the current
vote, change our ballot, add options to it, or something, and restart
the vote, but that would need a strong grass roots support (I do not
think the secretary has the power to do so).
I support stopping this GR and starting all over, if this is
possible.
I won't repeat all the reasons why this GR is seen as problematic;
they have been named at great length already. I just want to add that
even if we finish this GR we won't have the questions solved since we
will continue to discuss what the winning Choice #n actually means,
and this won't do the project any good.
As far as I understand from reading the immense threads, most people
(me included) don't want more options in the ballot. We want separate
ballots for separate subjects.
I agree on this point, and I think your proposal is a good starting
point for a new start in general - thanks!
[..]
I hope that you can take that into consideration.
+1
Cheers,
gregor
--
.''`. Home: http://info.comodo.priv.at/{,blog/} / GPG Key ID: 0x00F3CFE4
: :' : Debian GNU/Linux user, admin, developer - http://www.debian.org/
`. `' Member of VIBE!AT, SPI Inc., fellow of FSFE | http://got.to/quote/
`-NP: Leonard Cohen: You Have Loved Enough
signature.asc
Description: Digital signature
Re: Bundled votes and the secretary
On Wed, Dec 17 2008, Steve Langasek wrote: BTW, thanks for not flaming here; it was pleasantly surprising to see civil discussion on this topic. Where there's ambiguity about whether a proposer intended an amendment vs. a stand-alone proposal, I think it's perfectly reasonable to allow the secretary latitude in determining intent so as to not get bogged down in proceduralism. I don't think that was the case here for 20081114201224.ga11...@intrepid.palfrader.org - though I'm having a hard time coming up with references at the moment, I believe there were objections from some of the seconders of this proposal that it was meant to be a stand-alone proposal rather than an amendment. When I wrote my earlier message, I believed this was much more clear-cut; on review, I see that the original proposer left the question rather open by referring to his GR as a GR (option). So there are still two possibilities here: - enough of the 17 seconders expressed no opinion on the question of whether this shoud be a separate GR, as would allow interpreting their intent in favor of treating it as an amendment and putting it on a ballot with the original proposal - more than 12 of the formal seconders objected to placing this proposal on the same ballot with the original due to the orthogonal issues, in which case it's not constitutionally valid to override their stated intent by treating it as an amendment. So chances are, there's enough ambiguity here that it's constitutionally valid to put it on the same ballot as a related amendment. There's a separate issue here, however; namely, that the secretary is the *only* line of defense against gaming of the GR process by a small group of developers who propose an uncontroversial but orthogonal amendment that will always win over the alternatives, in the process preventing the will of the project from being formally enacted: http://lists.debian.org/debian-vote/2003/10/msg00168.html http://lists.debian.org/debian-vote/2003/11/msg00052.html http://lists.debian.org/debian-vote/2003/11/msg00095.html http://lists.debian.org/debian-vote/2003/11/msg00101.html http://lists.debian.org/debian-vote/2003/11/msg00105.html It's not unconstitutional for the secretary to keep orthogonal amendments on the same ballot, and it is the secretary's prerogative to keep amendments grouped on a single ballot if he believes they are related. But when there are multiple orthogonal issues being considered on a single ballot, choosing to not split those ballots means disenfranchising the proposers of the less-popular-but-popular-enough-to-pass option. Given that developers already have the power to propose as many serial GRs as needed in order to reconcile incompatibilities between ratified resolutions, the disenfranchisement is a much worse exploit of our voting system than anything that could be achieved by forcing partially-orthogonal options onto separate ballots. OK. I'll buy this line of reasoning. I do agree that beig able to split off unrelated options from the ballot is more useful than keeping related options together. I have been going over my notes and doing some research, but every option I came up with for tactical voting seems only valid for one-shot elections; where people could not propose the same vote over and over. This is not the case here. So it boils down to this: are the issue orthogonal, or are they just different solutions to the same issue? I have presented my argument for why I think they are the same; can you explain why those arguments do not hold, and these are not just different solutions to the same issue? manoj -- The documentation is in Japanese. Good luck. Rich $alz Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
On Wed, Dec 17 2008, Loïc Minier wrote: On Wed, Dec 17, 2008, Manoj Srivastava wrote: I do not think I meant proposed as in formal proposals to be voted upon. I meant splitting up votes for the same issue which leads to the results being gamed. This is an hypothetical case you're making; most people think the issues are orthogonal. Can these people explain why they think so? ANd it would help if they could say why the arguments I present to say it is a single issue are incorrect. Just opinions do not lead to consensus. manoj -- I will always love the false image I had of you. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
On Thursday 18 December 2008 11:45, Brian May br...@microcomaustralia.com.au wrote: Margarita Manterola wrote: If we do all this, we would be voting: A) If we trust or not the release team on making the right choices of which bugs to ignore and which not (regardless of this being firmware issues or what have you). This is from now on, not just for Lenny. B) If we want to allow sourceless firmware in Debian, defining firmware in a way that doesn't give a waiver to anything else without source. This is also from now on, not just for Lenny. But it's only for firmware, not for everything with licensing problems. C) If we want to allow stuff with some problems into Lenny, as we already did for Sarge and Etch. My suggestion would be to vote for (C) first, and then decide the wording on (A) and (B) depending on the outcome of (C). In which case, even if there is a conflict, the wording can clarify if the second vote overrides or doesn't override the first result. This makes sense to me. I would like to see the current vote abandoned. Manoj said that this will be done if there is sufficient grass-roots support. We have had a series of blog posts on Planet Debian from people who don't like the current vote. I like Brian's idea (or something similar). It seems that the grass-roots support for doing something quite different to the current vote includes me, Brian, and quite a few bloggers on Planet Debian. -- russ...@coker.com.au http://etbe.coker.com.au/ My Main Blog http://doc.coker.com.au/ My Documents Blog -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bundled votes and the secretary
On Wed, 17 Dec 2008, Manoj Srivastava wrote: So it boils down to this: are the issue orthogonal, or are they just different solutions to the same issue? I have presented my argument for why I think they are the same; can you explain why those arguments do not hold, and these are not just different solutions to the same issue? You consider that all options are only answers to how do we release Lenny? but that's absurd because the resolutions concern several different problems/questions that all have a role in the release process: - do we allow the release team to use lenny-ignore tags on the firmware issue given the previous GR on the topic ? - do we allow sourceless firmware that otherwise comply with the DFSG ? - do we want yet another exception for non-free firmwares for lenny ? If you boil down each option to an answer of can we release lenny, we do not respond to the above questions but we just choose a single excuse to give to people. But all the developers that have to make the release happen have no idea how they have to act because the separate open questions have not been answered in a satisfactory way. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
