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: 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: 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: 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: 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
Re: Bundled votes and the secretary
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). -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org pgpOskOneN1fA.pgp Description: PGP signature
Re: Bundled votes and the secretary
On Mon, Dec 15, 2008 at 12:13:23AM +, Matthew Johnson wrote: On Sun Dec 14 16:02, Ean Schuessler wrote: For gosh sakes man! Try to be polite! Any child can see that GFDL invariants violate the DFSG because they cannot be modified. Concur. GFDL + invariants clearly need to change the DFSG since the DFSG doesn't allow things which can't be modified [DFSG3]. GFDL - invariants is equally clearly possible without changing the DFSG. Ergo, 3:1 for the former and simple majority for the latter. On Sun Dec 14 16:02, Josslin wrote: 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'm sorry, how is it not relevant? The secretary interprets the constitution [7.1.3]. If the interpretation is correct then he has followed the constitution. Choice 6 says firmware in Debian does not have to come with source. DFSG2 says The program must include source code. Please tell me how you can _possibly_ reconcile those two statements without modifying the DFSG and therefore requiring a super majority. The point is, the secretary chooses interpretations that suits his own proposals to the vote. Explain to me how the release lenny options need [3:1] supermajority where the very same vote didn't need it in the past ? from http://www.debian.org/vote/2006/vote_007#majorityreq Release Etch even with kernel firmware issues 1. We affirm that our Priorities are our users and the free software community (Social Contract #4); 2. We acknowledge that there is a lot of progress in the kernel firmware issue; however, it is not yet finally sorted out; 3. We assure the community that there will be no regressions in the progress made for freedom in the kernel distributed by Debian relative to the Sarge release in Etch 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: Allow Lenny to release with proprietary firmware 1. We affirm that our Priorities are our users and the free software community (Social Contract #4); 2. We acknowledge that there is a lot of progress in the kernel firmware issue; most of the issues that were outstanding at the time of the last stable release have been sorted out. However, new issues in the kernel sources have cropped up fairly recently, and these new issues have not yet been addressed; 3. We assure the community that there will be no regressions in the progress made for freedom in the kernel distributed by Debian relative to the Etch release in Lenny (to the best of our knowledge as of 1 November 2008); 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. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org pgpVm52u21yYx.pgp Description: PGP signature
Re: Bundled votes and the secretary
- Pierre Habouzit madco...@debian.org wrote: The point is, the secretary chooses interpretations that suits his own proposals to the vote. Explain to me how the release lenny options need [3:1] supermajority where the very same vote didn't need it in the past ? From a rigorous perspective, the release Etch vote should have been 3:1. If we are worth our salt we should not be allowing DFSG violations past testing and developers should be aggressive about filing bugs on errant packages. I can understand the necessity of providing certain users non-free drivers to help them get their equipment going. Serious users should be selecting equipment that won't have install problems. Last time I checked, this was a distribution for serious users (that also happens to want to be friendly to people just getting started). I fail to understand how serious Debian Developers arrive at a point where enforcing the DFSG is an exercise for zealots. -- 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 Sun, Dec 14, 2008 at 01:54:30PM -0800, Steve Langasek wrote: 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. That's certainly a valid interpretation of the constitution (and one could make an excellent case for it). However, it is not the only possible (and reasonable) one, hence it's not an unambiguous violation - it is within the Secretary's power to reject that interpretation in favor of an alternative. One alternative (and not, in my opinion, frivolous) interpretation can be derived from the fact that the Constitution requires that amendments may be made formal by being proposed and sponsored according to the requirements for a new resolution, which arguably could mean that an amendment need not be called an amendment by its proposer. 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? Are you speaking hypothetically, or have you actually tried to get a that was not a valid GR GR past the Secretary? If the latter, I must apologise, for I have missed it. (Incidentally, I think it is clear that we are operating under different definitions of valid GR. Mine is rather formal - as long as the Secretary does not blatantly[*] disregard the Constitution, any vote the Secretary conducts is valid.) Recognizing the validity of the vote is not a must. The alternative is that we end up in a state of constitutional crisis. Well, true. I was hoping nobody else had noticed, and I didn't want to give anybody ideas :) I would be strongly disappointed if we did arrive at a constitutional crisis. Among other things, and depending on the events that lead up to it, it would be one more reason for me to reconsider my membership in this project. [*] Blatant would require, in my eyes, that there is no reasonable interpretation of the Secretary's actions that would render them constitutional. So far, I haven't noticed anything like that. -- Antti-Juhani Kaijanaho, Jyväskylä, Finland http://antti-juhani.kaijanaho.fi/newblog/ http://www.flickr.com/photos/antti-juhani/ signature.asc Description: Digital signature
Re: Bundled votes and the secretary
On Mon, Dec 15, 2008 at 03:49:14PM +, Ean Schuessler wrote: - Pierre Habouzit madco...@debian.org wrote: The point is, the secretary chooses interpretations that suits his own proposals to the vote. Explain to me how the release lenny options need [3:1] supermajority where the very same vote didn't need it in the past ? From a rigorous perspective, the release Etch vote should have been 3:1. If we are worth our salt we should not be allowing DFSG violations past testing and developers should be aggressive about filing bugs on errant packages. I can understand the necessity of providing certain users non-free drivers to help them get their equipment going. Serious users should be selecting equipment that won't have install problems. Last time I checked, this was a distribution for serious users (that also happens to want to be friendly to people just getting started). I fail to understand how serious Debian Developers arrive at a point where enforcing the DFSG is an exercise for zealots. I disagree. What would be 3:1 (to date) is to decide that such bugs aren't RC. The funding documents don't enforce the release team to release without a single known DFSG-related issue, unless I'm deeply mistaken. A $suite-ignore tag is _NOT_ the same as downgrading the severity of a bug. It's acknowledging it's a serious issue, but that we shall not wait for it to be solved to release. I don't say that DFSG freeness is a secondary issue. What I'm saying is that when: * we see DFSG freeness issue that need quite a long time to resolve properly and would else delay the release too much, * there is no sign of foul play from the maintainer (IOW those bugs have not been sneaked into testing, but have just been detected after the migration to testing), Then I fail to see why deciding to release with such bugs needs a 3:1 vote. It's merely pragmatism. What would be quite arguable, would be the Kernel Team and Release Team deciding they just don't care about DFSG issues at all. It's not the case, the firmware front is better at each release. It's just that new firmwares pop up every kernel release, and there have been new firmwares that have not been spotted. That's all. The former would be foul play, and is condemnable. The latter is just a bug, from a specific kind, but in the end just a bug. You're welcome to start a GR that we shall not release with a single known DFSG violation and write it in the constitution (which is kind of what the 1 vote is supposed to mean in the current vote). But the project has voted 3 times on similar issues, and it doesn't seem this opinion is shared by more than a few. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org pgplEtCAE04nv.pgp Description: PGP signature
Re: Bundled votes and the secretary
- Pierre Habouzit madco...@debian.org wrote: I disagree. What would be 3:1 (to date) is to decide that such bugs aren't RC. The funding documents don't enforce the release team to release without a single known DFSG-related issue, unless I'm deeply mistaken. A $suite-ignore tag is _NOT_ the same as downgrading the severity of a bug. It's acknowledging it's a serious issue, but that we shall not wait for it to be solved to release. I don't say that DFSG freeness is a secondary issue. What I'm saying is that when: * we see DFSG freeness issue that need quite a long time to resolve properly and would else delay the release too much, * there is no sign of foul play from the maintainer (IOW those bugs have not been sneaked into testing, but have just been detected after the migration to testing), Then I fail to see why deciding to release with such bugs needs a 3:1 vote. It's merely pragmatism. Well. I do agree with you here. Doing a release is essentially just bookmarking the state of the archive at a point in time where we consider it to be stable. From a DFSG violation perspective the real culprit is the uploading of the problem software, not the bookmarking of the release that includes it. Obviously, we could be distributing non-free from testing main for a year if we are waiting for a release as the event to clean it out. From this perspective, I agree with you. The release team declaring that a release state has been reached does seem orthogonal to the DFSG violation problem, especially as long as the release team is working with the rest of the project to clear problem softwares. I still disagree strongly with declaring firmware to be source but I agree on the notion that marking a release ready state is a separate matter. -- 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 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. Kurt -- 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 Thu, Dec 11, 2008 at 03:15:20PM +0100, Josselin Mouette wrote: What this position requires is the minimal level of morality to not use it to favor an opinion or another. And this is something Manoj has been repeatedly doing; first in the GFDL GR, next in the etch firmwares GR, now in the lenny one. I do not agree with the second sentence, but really, what I agree with is beside the point. The larger point I want to make is this: if the Secretary making a choice A favors a particular opinion, then surely the Secretary making the choice not-A equally favors a particular (different) opinion. You object to the Secretary's particular actions as being deterimental to your position - surely, if the Secretary had made different actions, ones you'd approve of, it would be in favor of your position. Damned if you do, damned if you don't. The correct test, therefore, is whether the choices were consistent with the constitution and established precedents (in that order of precedence). Since the Secretary adjugates disputes about interpretation of the constitution, he has a wide latitude of correct action. I do not trust anymore the Secretary, and I do not trust sufficiently the result of this vote. The Constitution does not require that the Secretary enjoy the trust of the Developers. There isn't even a possibility of a vote of no confidence! There is some wisdom in that, parallelling the concept of judicial indipendence. Once this particular issue has been settled, however, it may be a good idea to reexamine our judicial arrangements in the constitution. If the otherwise winning option is dismissed by the lack of a 3:1 majority (for which the requirements are still “Manoj said so”), or if a winning option is dismissed by a completely unrelated other option that was not proposed as an amendment, it won’t be possible to consider the vote result as the decision of the project as a whole. 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, and absent a valid GR stating otherwise, the vote must be presumed to be constitutionally valid. Ignoring the result of such a vote would, in my eyes, be an odrer of magnitude worse transgression than any misbehavior that has been alleged against the Secretary. The proper action, if you believe that the vote is procedurally flawed, is to propose (after the current vote is finished) a GR stating that the previous vote was procedurally mishandled and therefore is null and void. Since the Constitution does not recognize GRs overriding the Secretary, such a GR would probably require a 3:1 supermajority. -- Antti-Juhani Kaijanaho, Jyväskylä, Finland http://antti-juhani.kaijanaho.fi/newblog/ http://www.flickr.com/photos/antti-juhani/ signature.asc Description: Digital signature
Re: Bundled votes and the secretary
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. 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? 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. So let's go back to 2003, when this started. It seems this super-majority requirement wasn't a big problem to you at the time: http://www.debian.org/vote/2003/gr_sec415_tally.txt I don’t have a problem with the 3:1 requirement. If I were to propose any constitutional amendment on this topic, it would be to make explicit for GR proposals when they override or modify foundation documents, and only let the Secretary a power of rejection based on strong evidence the proposal doesn’t conform. But I ask you one thing: Do not blame the Secretary for your mistakes, he's just doing his job. No, he’s outrageously abusing his position. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Bundled votes and the secretary
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. 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. -- 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: Bundled votes and the secretary
- Josselin Mouette j...@debian.org wrote: 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. [snip] No, he’s outrageously abusing his position. For gosh sakes man! Try to be polite! Any child can see that GFDL invariants violate the DFSG because they cannot be modified. Saying that someone is outrageously abusing their position is a powerfully insulting statement. You had better make sure that the problem isn't your inability to grasp the details of the discussion. I certainly do not envy Manoj's position. The task of turning this firmware hoo-haw into a reasonable vote seems difficult at the very best. Thank you, Manoj, for your work. -- 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 Sun Dec 14 16:02, Ean Schuessler wrote: For gosh sakes man! Try to be polite! Any child can see that GFDL invariants violate the DFSG because they cannot be modified. Concur. GFDL + invariants clearly need to change the DFSG since the DFSG doesn't allow things which can't be modified [DFSG3]. GFDL - invariants is equally clearly possible without changing the DFSG. Ergo, 3:1 for the former and simple majority for the latter. On Sun Dec 14 16:02, Josslin wrote: 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'm sorry, how is it not relevant? The secretary interprets the constitution [7.1.3]. If the interpretation is correct then he has followed the constitution. Choice 6 says firmware in Debian does not have to come with source. DFSG2 says The program must include source code. Please tell me how you can _possibly_ reconcile those two statements without modifying the DFSG and therefore requiring a super majority. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: Bundled votes and the secretary
* Julien BLACHE: [ ] Choice 2: Allow Lenny to release with proprietary firmware [3:1] We're not changing the DFSG. So there's no need for 3:1. We're overriding it, so it requires 3:1, and it was the same for the waiver for Etch. Are we? I mean, this stuff is already in the archive, in main, and as far as I can tell, the release team can release from main at any point in time they see fit (practical considerations notwithstanding). The Social Contract does not even mention the word release. A release doesn't really change if we are in conformance or not. The release team has little control over the conformance aspect, especially if core packages are affected for which remove is not an option. In this light, requiring a 3:1 supermajority just to underscore that the release team is, in fact, the release team and can release from main is a bit out of line, isn't it? Oh, and I'm quite offended how this whole thing is used to pressure developers to do certain work, contrary to the spirit of Constition 2.1.1. -- 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 Thu, Dec 11, 2008 at 03:15:20PM +0100, Josselin Mouette wrote: I do not trust anymore the Secretary, and I do not trust sufficiently the result of this vote. If the otherwise winning option is dismissed by the lack of a 3:1 majority (for which the requirements are still “Manoj said so”), or if a winning option is dismissed by a completely unrelated other option that was not proposed as an amendment, it won’t be possible to consider the vote result as the decision of the project as a whole. I think it's obvious that the project has decayed into such a level in which we can't even agree on what override a foundation document means. This renders the 3:1 super-majority requirements in the Constitution as and endless source of contention, and there's nothing we can do about it unless the Constitution is ammended. For the record, I think the Secretary's interpretation of the Constitution is perfectly correct. Not that discussion about it is going to improve anything, of course... we already tried haven't we? So let's go back to 2003, when this started. It seems this super-majority requirement wasn't a big problem to you at the time: http://www.debian.org/vote/2003/gr_sec415_tally.txt Though, as time passes and things change, maybe it is now. We're all human and make mistakes sometimes. So why don't you propose it to be removed? I would probably support you on that. After all, I voted against it back then. But I ask you one thing: Do not blame the Secretary for your mistakes, he's just doing his job. -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. -- 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 Thu, Dec 11, 2008 at 10:38:34AM -0800, Steve Langasek wrote: [...], and frankly I see no reason that we as a project should even honor the outcome of a vote on this ballot as presented. I think you meant to say we as the Release Team. -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. -- 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
Hello DPL, I'd like to point you to the following mail by Raphaël on -vote. It is also available at [1]. 1. http://lists.debian.org/debian-vote/2008/12/msg00038.html Raphael Hertzog [EMAIL PROTECTED] (11/12/2008): Manoj, I still object to voting all at once and I'm convinced that you will manage to hurt the project by doing that. Ditto. Honestly, at this point, I would really wish that you retired as secretary because there have been too many conflicts between you and various DD while your secretarial work shouldn't be the source of any conflict. You just have to count the points on each side but you don't. You insist on deciding alone if something is a change to the DFSG (when the text doesn't modify it explicitely) while I believe that only the project at large is able to decide of something like that. That's why I'd like to put you (leader@) in the loop. You'll find Raphaël's comments below. Could you please comment on the secretary's behaviour? Is he only doing his job, and the right way? Or is there something going very wrong? Thanks for your time. Mraw, KiBi. That said, here are my comments anyway: On Wed, 10 Dec 2008, Manoj Srivastava wrote: 41b0a520-c6c1-4e7b-8c49-74ee85faf242 [ ] Choice 1: Reaffirm the Social Contract Delay Lenny until all DFSG violations known at 1. Nov 2008 are fixed At least be clear what the choice means. Otherwise it looks like you are hiding the meaning and trying to get you personal preference (yes you explained several times that you would probably vote for such an option). [ ] Choice 2: Allow Lenny to release with proprietary firmware [3:1] We're not changing the DFSG. So there's no need for 3:1. [ ] Choice 3: Allow Lenny to release with DFSG violations [3:1] I followed the discussions but I don't even know why we have this alternative which looks like the same than 2. [ ] Choice 4: Empower the release team to decide about allowing DFSG violations [3:1] The full text doesn't use the word DFSG violation. Maybe: Let the release team decide if each known freeness problems should be blockers [ ] Choice 5: Assume blobs comply with GPL unless proven otherwise The proposition doesn't speak of the GPL in any special way. Neither does it explain what is required to prove that source code exist for the blob. So this subject is not appropriate either. In fact, I would think it doesn't solve at all the problem of GPL firmwares. [ ] Choice 6: Exclude source requirements for firmware (defined) [3:1] Peter explicitely told that he doesn't want to modify the DFSG. Cheers, -- Raphaël Hertzog signature.asc Description: Digital signature
Re: Bundled votes and the secretary
Raphael Hertzog [EMAIL PROTECTED] wrote: Hi, I'll echo Raphael's feelings about that ballot; it feels strange and voting on that one is going to be a mess. There are definitely some options that should be split into another vote. [ ] Choice 2: Allow Lenny to release with proprietary firmware [3:1] We're not changing the DFSG. So there's no need for 3:1. We're overriding it, so it requires 3:1, and it was the same for the waiver for Etch. [ ] Choice 3: Allow Lenny to release with DFSG violations [3:1] I followed the discussions but I don't even know why we have this alternative which looks like the same than 2. It's not the same; it's broader. Option 2 only deals with firmware, whereas this option is a waiver for all the DFSG violations. JB. -- Julien BLACHE - Debian GNU/Linux Developer - [EMAIL PROTECTED] Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bundled votes and the secretary
On Thu Dec 11 10:55, Julien BLACHE wrote: Raphael Hertzog [EMAIL PROTECTED] wrote: Hi, I'll echo Raphael's feelings about that ballot; it feels strange and voting on that one is going to be a mess. There are definitely some options that should be split into another vote. On the other hand, I would like to say I am entirely happy with the way that Manoj has handled the vote and do not see a problem with voting on everything at once. This ballot is essentially deciding what to do with Lenny with some justification behind the choices. I think that having the 'outcomes' matrix on the website with the list of 'release/wait', 'permanent/temporary exception', 'delegate/don't delegate' for each option. As Julien has pointed out, choices 2 and 3 re not the same and that we have precedent for the overriding options requiring 3:1. However, I think retitling 5 to: Assume firmware blobs are in source form unless proven otherwise is worthwhile as is retitling 1 to: Delay Lenny release until all DFSG issues are resolved. I wouldn't say this is the secretary trying to skew anything, I just think that it makes the meaning of the choices slightly clearer. If people read the text below then it is clear. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: Bundled votes and the secretary
On Thu, Dec 11, 2008 at 08:50:20AM +0100, Raphael Hertzog wrote: Honestly, at this point, I would really wish that you retired as secretary because there have been too many conflicts between you and various DD while your secretarial work shouldn't be the source of any conflict. I honestly believe that the secretary cannot always avoid a conflict. He is charged with deciding what the correct interpretation of the Constitution is, and when there are strongly conflicting opinions among the developers as to what the correct interpretation is, the Secretary's decision will be a source of conflict, whatever it is. You just have to count the points on each side but you don't. That's not the Secretary's job. He is not a judge in an adversarial proceeding. (Perhaps such a job should be created, but that's a different matter altogether.) You insist on deciding alone if something is a change to the DFSG (when the text doesn't modify it explicitely) while I believe that only the project at large is able to decide of something like that. I believe Manoj is acting correctly in this. More strongly, I believe Manoj has repeatedly shown the sort of moral courage and sound judgment that the Secretary's job requires, and I believe it would be a grave loss if he were to step down. It would be a shame if he were to be replaced by someone who counts avoiding conflict as a major part of the job. -- Antti-Juhani Kaijanaho, Jyväskylä, Finland http://antti-juhani.kaijanaho.fi/newblog/ http://www.flickr.com/photos/antti-juhani/ signature.asc Description: Digital signature
Re: Bundled votes and the secretary
Le jeudi 11 décembre 2008 à 15:38 +0200, Antti-Juhani Kaijanaho a écrit : More strongly, I believe Manoj has repeatedly shown the sort of moral courage and sound judgment that the Secretary's job requires, and I believe it would be a grave loss if he were to step down. It would be a shame if he were to be replaced by someone who counts avoiding conflict as a major part of the job. What is asked from the Secretary is not to avoid conflict. It is not even to not participate in the conflict – there’s not reason why he couldn’t have his own opinion. What this position requires is the minimal level of morality to not use it to favor an opinion or another. And this is something Manoj has been repeatedly doing; first in the GFDL GR, next in the etch firmwares GR, now in the lenny one. I do not trust anymore the Secretary, and I do not trust sufficiently the result of this vote. If the otherwise winning option is dismissed by the lack of a 3:1 majority (for which the requirements are still “Manoj said so”), or if a winning option is dismissed by a completely unrelated other option that was not proposed as an amendment, it won’t be possible to consider the vote result as the decision of the project as a whole. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Bundled votes and the secretary
to, 2008-12-11 kello 08:50 +0100, Raphael Hertzog kirjoitti: Manoj, I still object to voting all at once and I'm convinced that you will manage to hurt the project by doing that. I, on the other hand, think Manoj has explained well why he is doing things the way he is doing with this vote, and I agree with his reasons. -- 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
Josselin Mouette wrote: What this position requires is the minimal level of morality to not use it to favor an opinion or another. And this is something Manoj has been repeatedly doing; first in the GFDL GR, next in the etch firmwares GR, now in the lenny one. I do not trust anymore the Secretary, and I do not trust sufficiently the result of this vote. I fully concur. Cheers, Moritz -- 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 Thu, Dec 11, 2008 at 12:42:20PM +, Matthew Johnson wrote: However, I think retitling 5 to: Assume firmware blobs are in source form unless proven otherwise is worthwhile as is retitling 1 to: Delay Lenny release until all DFSG issues are resolved. I wouldn't say this is the secretary trying to skew anything, I just think that it makes the meaning of the choices slightly clearer. If people read the text below then it is clear. As written in http://lists.debian.org/debian-vote/2008/12/msg3.html, this is not the case at all. It's possible that the secretary didn't notice this mail because I didn't cc: him; but 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. -- 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: Bundled votes and the secretary
On Thu, Dec 11, 2008 at 06:38:34PM +, Steve Langasek wrote: On Thu, Dec 11, 2008 at 12:42:20PM +, Matthew Johnson wrote: However, I think retitling 5 to: Assume firmware blobs are in source form unless proven otherwise is worthwhile as is retitling 1 to: Delay Lenny release until all DFSG issues are resolved. I wouldn't say this is the secretary trying to skew anything, I just think that it makes the meaning of the choices slightly clearer. If people read the text below then it is clear. As written in http://lists.debian.org/debian-vote/2008/12/msg3.html, this is not the case at all. It's possible that the secretary didn't notice this mail because I didn't cc: him; but 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. I second that. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org pgpZTqR1654UT.pgp Description: PGP signature
Re: Bundled votes and the secretary
On Thu, Dec 11 2008, Josselin Mouette wrote: Le jeudi 11 décembre 2008 à 15:38 +0200, Antti-Juhani Kaijanaho a écrit : More strongly, I believe Manoj has repeatedly shown the sort of moral courage and sound judgment that the Secretary's job requires, and I believe it would be a grave loss if he were to step down. It would be a shame if he were to be replaced by someone who counts avoiding conflict as a major part of the job. What is asked from the Secretary is not to avoid conflict. It is not even to not participate in the conflict – there’s not reason why he couldn’t have his own opinion. What this position requires is the minimal level of morality to not use it to favor an opinion or another. And this is something Manoj has been repeatedly doing; first in the GFDL GR, next in the etch firmwares GR, now in the lenny one. I do not trust anymore the Secretary, and I do not trust sufficiently the result of this vote. If the otherwise winning option is dismissed by the lack of a 3:1 majority (for which the requirements are still “Manoj said so”), or if a winning option is dismissed by a completely unrelated other option that was not proposed as an amendment, it won’t be possible to consider the vote result as the decision of the project as a whole. You are enttled to an opinion, I suppose. For the record, no matter what my personal opinions are, I decide on the final form of the ballots based on my reading of the constitution. manoj -- Toroidal carbohydrate modules? Make mine glazed! Zippy 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 Thu, Dec 11 2008, Raphael Hertzog wrote: Manoj, I still object to voting all at once and I'm convinced that you will manage to hurt the project by doing that. Honestly, at this point, I would really wish that you retired as secretary because there have been too many conflicts between you and various DD while your secretarial work shouldn't be the source of any conflict. You just have to count the points on each side but you don't. You insist on deciding alone if something is a change to the DFSG (when the text doesn't modify it explicitely) while I believe that only the project at large is able to decide of something like that. The project at largewill be doing the deciding. If they pass a resolution that contradicts the foundation document, the will of the people should not be dismissed. That said, here are my comments anyway: On Wed, 10 Dec 2008, Manoj Srivastava wrote: 41b0a520-c6c1-4e7b-8c49-74ee85faf242 [ ] Choice 1: Reaffirm the Social Contract Delay Lenny until all DFSG violations known at 1. Nov 2008 are fixed At least be clear what the choice means. Otherwise it looks like you are hiding the meaning and trying to get you personal preference (yes you explained several times that you would probably vote for such an option). The title for the resolutions are usually selected by the proposer. I d do not change it unless it is clear to me that the title is obviously incorrect. Ask the proposer to modify the title, or demonstrate the title is wrong (no clear enough is not wrong). [ ] Choice 2: Allow Lenny to release with proprietary firmware [3:1] We're not changing the DFSG. So there's no need for 3:1. The proposal is to resolve on a course of action that over rides a foundation document. [ ] Choice 3: Allow Lenny to release with DFSG violations [3:1] I followed the discussions but I don't even know why we have this alternative which looks like the same than 2. Look again. This is more general than 2. [ ] Choice 4: Empower the release team to decide about allowing DFSG violations [3:1] The full text doesn't use the word DFSG violation. Maybe: Let the release team decide if each known freeness problems should be blockers We define the DFSG to be the definition of what we consider free. So freeness problems == DFSG violations. [ ] Choice 5: Assume blobs comply with GPL unless proven otherwise The proposition doesn't speak of the GPL in any special way. Neither does it explain what is required to prove that source code exist for the blob. So this subject is not appropriate either. In fact, I would think it doesn't solve at all the problem of GPL firmwares. Well, if you can show that the GPL firmware is not in the preferred form of modification, you might have a point. I wanted to propose that a) Everything in the kernel should be a) legal for us to distribute b) released under a free license. What is excluded is verfy beyond reasonable doubt that the firmware is the preferred form of documentation. I wanted to say we'll take any upstream claim that the firmware does not violate gpl or whatever dfsg free license it is nunder; unless we have some kind of proof that the author is being deceptive. I'll take suggestions on how to word this on the ballot as long as the meaning is not distorted. [ ] Choice 6: Exclude source requirements for firmware (defined) [3:1] Peter explicitely told that he doesn't want to modify the DFSG. If peter is resolving that the project do something that contradicts the dfsg, I am not sure any unrelated staements he makes changes the fact that the resolution is to propose a course of action different from the current foundation document. manoj -- A 'full' life in my experience is usually full only of other people's demands. 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 Thu, Dec 11 2008, Steve Langasek wrote: On Thu, Dec 11, 2008 at 12:42:20PM +, Matthew Johnson wrote: However, I think retitling 5 to: Assume firmware blobs are in source form unless proven otherwise is worthwhile as is retitling 1 to: Delay Lenny release until all DFSG issues are resolved. I wouldn't say this is the secretary trying to skew anything, I just think that it makes the meaning of the choices slightly clearer. If people read the text below then it is clear. As written in http://lists.debian.org/debian-vote/2008/12/msg3.html, this is not the case at all. It's possible that the secretary didn't notice this mail because I didn't cc: him; but 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. I did read that mail. I was underwhelmed by the force of the arguments in that email. If you have definitive proof that the firmware are not the preferred form of modification, please present that eveidence, boit to us, and to upstream kernel folks. The proposal also states that a) we should be legally allowed to distribute the firmware (we can only do so if it is covered by a licesne) b) The license be dfsg free. If you know of any irmware that we are sure does not meet the criteria (as opposed to we strongly suspect might not), then proposal 5 does not allow lenny to be released with that. By the way, stating someting in an email does not immediately make a person holding an official role act that way. So not being swayed by your arguments is not, in my eyes, acting in an improper manner. 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
