Re: [Amendment] Reaffirm current requirements for GR sponsoring
On Tue, Mar 24, 2009 at 04:10:49PM -0700, Lucas Nussbaum wrote: Hi, I am hereby proposing the amendment below to the general resolution entitled Enhance requirements for General resolutions. PROPOSAL START = General Resolutions are an important framework within the Debian Project. While over those years, some problems have arised during the discussion and/or voting of some resolutions, there is no evidence that changing the number of sponsors (seconds) for GR proposals or amendments will help solve those problems. Instead, by making it harder to propose general resolutions or amendments, it might make it harder to improve imperfect resolutions, or to add valuable options to a ballot. Therefore the Debian project reaffirms the current requirements for the sponsoring (seconding) of GR proposals or amendments, and for overruling of delegates. = PROPOSAL END I second this. -- 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. signature.asc Description: Digital signature
Re: [Amendment] Reaffirm the GR process [rescinded]
On Thu, Mar 26, 2009 at 07:07:03PM +0100, Kurt Roeckx wrote: On Thu, Mar 26, 2009 at 01:12:45AM +0100, Bill Allombert wrote: On Mon, Mar 23, 2009 at 11:42:40PM +0100, Bill Allombert wrote: Hello developers, I am hereby proposing the amendement below to the General resolution entitled Enhance requirements for General resolutions. PROPOSAL START General Resolutions are an important framework within the Debian Project, which have served us well since the first GR vote in 2003, with 804 developers, nearly has much as today slightly over 1000 developers. Therefore the Debian project reaffirms its attachement to the constitution and the current General Resolutions process. PROPOSAL END I am rescinding this amendment. Please second Lucas amendment instead, which has a cleaner wording. Robert, You're were the only one seconding that proposal, and now the proposer of this amendment. You might want to withdraw too and second Lucas's proposal instead. Thanks Kurt. I've seconded Lucas' amendment in a separate mail, and I'm hereby rescinding my second to Bill's amendment. -- 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. signature.asc Description: Digital signature
Re: [Amendment] Reaffirm the GR process
On Mon, Mar 23, 2009 at 11:42:40PM +0100, Bill Allombert wrote: Hello developers, I am hereby proposing the amendement below to the General resolution entitled Enhance requirements for General resolutions. PROPOSAL START General Resolutions are an important framework within the Debian Project, which have served us well since the first GR vote in 2003, with 804 developers, nearly has much as today slightly over 1000 developers. Therefore the Debian project reaffirms its attachement to the constitution and the current General Resolutions process. PROPOSAL END Seconded. I'd also like to complain about the title text of the initial GR. It is clearly manipulative, as it pretends to be merely describing the proposed changes when in fact it is asserting an opinion. I hope the Secretary will fix this. And if that's too much to ask, then I hope voters will read carefuly and won't fall for such an easy trick. -- 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. signature.asc Description: Digital signature
Re: [Amendment] Reaffirm the GR process
On Tue, Mar 24, 2009 at 11:52:22PM +0100, Kurt Roeckx wrote: On Tue, Mar 24, 2009 at 08:03:46PM +0100, Robert Millan wrote: I'd also like to complain about the title text of the initial GR. It is clearly manipulative, as it pretends to be merely describing the proposed changes when in fact it is asserting an opinion. I hope the Secretary will fix this. I think the title is also not the best one and just used Joerg's title. What about: General Resolution sponsorship requirements Sounds good to me. Thank you -- 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: Results of the Lenny release GR
On Sun, Jan 11, 2009 at 10:17:52AM -0600, Ean Schuessler wrote: - Robert Millan wrote: The majority of developers voted to make an exception for firmware in Lenny. They did NOT vote to empower the Release Team to make exceptions as they see fit. Results of GR 2008/003 are crystal clear about this. Unfortunately, nothing can be crystal clear about GR 2008/003 because there is simply nothing crystal clear about it. It's clear what the vote says. What the voters were thinking, I can't tell. Usually one would assume they were thinking the same thing they voted. At least, when I voted, I did. If we have reasons to believe this is not so, I think the vote should be invalidated. Playing with a flawed vote is very dangerous bussiness. Ironically, Bdale *is* warping the results of the vote and applying an editorial voice to the interpretation of the results. I say ironically because Bdale's actions go far beyond anything Manoj did with regard to imposing his desires or thoughts on the construction or result of a vote. Amusingly, those who called for Manoj's head have now fallen quite silent. Agreed. Then again, even if Manoj was rightfully appliing super-majority requirements (which I think he was), it has become clear that, in general, such requirements are not politicaly sustainable. And in practice they don't exist anymore, anyway.I think this would be a good time to propose that they are removed from the Constitution. There are some things that are clear to me: * I have a very high level of trust in Bdale, even when he starts doing peculiar things. I don't know him that well, so I can only judge him by his recent actions, which are quite questionable. I acknowledge that it may be unfair that I can't also recognize his merits, but this is how it is. OTOH, writing in a harsh tone is something that sometimes happens to me when I find something outrageous. Then again, at least I'm capable of rectifiing, which not everyone in this thread is. * We should not delay Lenny for further political discussion because people's operations depend on our release. I tend to agree with this, but I don't think this is the matter at hand. My concerns are: - Some maintainers are simply refusing to fix DFSG violations that would otherwise NOT delay Lenny, as a consequence of the RT's rather low requirements for appliing a lenny-ignore tag. A good example of that is #459705, in which the maintainer simply said I'd rather not remove this file. I think this creates a VERY dangerous precedent, which is precisely what I'm trying to stop. Yeah, it is really. It's not like one day I woke up and thought hey, it would be cool if we could delay Lenny. - Even if there's a general perception that everyone agrees not to delay Lenny at all costs, this should definitely be voted on and sanctioned. Not doing so creates a very bad precedent. * Discussion of these issues in the shadow of Lenny warps people's minds and makes sane discourse impossible. Spot on. And point taken. * We have already made several such releases in the past and do not have a soberly constructed framework for solving the problem permanently. What is wrong with the framework we've used for Sarge and Etch? With that in mind, I am inclined to go along with Bdale's release Lenny by all means possible reading of 2008/003. However, if anyone views this as a victory then they are smoking extremely powerful crack. I would rosily call this a convenient failure of democratic discipline on Debian's part. It would be VERY, VERY UNFORTUNATE if it continutes to be a permanent pattern. I think the very survival of our organization depends on us coming to a well defined solution by the next release. If we're going to go that route, at the very least I think the project should issue a position statement explaining something like: - We just screwed up. Sorry about that. - It's too late in the Lenny release process to do something about this without causing unacceptable delays. We will release Lenny ASAP out of responsibility. - We will try to find a solution. Would you be likely to support such thing? So I'm sorry Robert, your heart is absolutely in the right place but I agree that we should release Lenny. You say you're sorry? You almost read my mind! But I don't agree that doing nothing is going to solve our problem. -- 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: Results of the Lenny release GR
On Mon, Jan 12, 2009 at 01:12:24AM -0700, Bdale Garbee wrote: r...@aybabtu.com (Robert Millan) writes: So, what I think would be the honest approach to this problem, is for you to either announce that your interpretation is the way it is because the ballot was flawed ... In my preamble to the second call for votes, http://lists.debian.org/debian-vote/2008/12/msg00411.html I said: It is clear that there are flaws with the way the current ballot is constructed. I know that, but the difference between A and B and A because B is very significant here. -- 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: Results of the Lenny release GR
On Mon, Jan 12, 2009 at 07:13:57PM +0100, Michael Goetze wrote: Robert Millan wrote: - Even if there's a general perception that everyone agrees not to delay Lenny at all costs, this should definitely be voted on and sanctioned. Not doing so creates a very bad precedent. You think everyone must be voted on? Everything significant, yes. Because I believe in democracy. -- 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: Results of the Lenny release GR
On Mon, Jan 12, 2009 at 08:52:13PM +, Matthew Johnson wrote: On Mon Jan 12 19:34, Robert Millan wrote: On Mon, Jan 12, 2009 at 07:13:57PM +0100, Michael Goetze wrote: Robert Millan wrote: - Even if there's a general perception that everyone agrees not to delay Lenny at all costs, this should definitely be voted on and sanctioned. Not doing so creates a very bad precedent. You think everyone must be voted on? Everything significant, yes. Because I believe in democracy. Democracy doesn't mean voting on everything. That's why I said everything significant. Compromising on our core principles is one of the things I consider significant. In the majority of instances it means 'let the elected officials and those to whom they have delegated make the decisions we have elected them to make'. You elect someone because you trust them to act in your interests with the option of overriding or recalling them if they don't. I find this reasonable, in general, for minor issues. But it's worth noting that in this occasion, the developers didn't feel it was necessary to delegate this responsibility. If they did, they'd have voted for option 4. -- 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: Results of the Lenny release GR
On Sun, Jan 11, 2009 at 02:13:59PM +, Matthew Vernon wrote: Robert Millan r...@aybabtu.com writes: I think you mean both option 3 and 4 ranked above FD. I read that as I don't like these options, but if there's no choice, I prefer them over the ambiguity of not making any explicit decision. If one doesn't like an option, one ranks FD above it. The developers clearly preferred option 2 over option 4. You can spin it as much as you want, but in the end, it means a straight vote between option 2 and option 4 would have option 2 as the winner. If you don't believe me, try proposing one. -- 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: Results of the Lenny release GR
On Sun, Jan 11, 2009 at 09:07:12PM +0100, Frank Küster wrote: Robert Millan r...@aybabtu.com wrote: 4- Bugs which are trivial to fix, such as #459705 (just remove a text file), #483217 (only affects optional functionality that could be removed according to the maintainer) Of course it could be removed, and it's technically trivial. The question is whether it is worth the disadvantages to our users, when we still expect (or hope or something in between) that the files will be released under a DFSG-free license once we manage to attract enough attention from Donald. Isn't that why we have a non-free repository? -- 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: Results of the Lenny release GR
On Sun, Jan 11, 2009 at 04:41:51PM +, Steve McIntyre wrote: Robert, I appreciate that you believe you're doing the right thing here, but attempting to continue this discussion right now, just after the first vote that has already delayed Lenny, is not going to help you or anybody. I don't see how even option 1 would have delayed Lenny. I just see that it would have forced a few patches to be applied. But we got option 5 instead. You claim this has delayed Lenny. Please explain how. It *is* clear that a substantial majority of DDs want us to release Lenny soon rather than attempt to fix every last issue. Please drop it for now. You're writing with the assumption that fixing DFSG violations is fundamentally incompatible with releasing Lenny soon. I can see that this could be true for some cases, where critical functionality is affected, but for most of them (including firmware) I don't see any correlation. -- 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: Results of the Lenny release GR
On Sun, Jan 11, 2009 at 05:17:33PM +, Stephen Gran wrote: This one time, at band camp, Steve McIntyre said: If things go much further we'll end up with enough seconds to force a vote to hand Robert Millan a nice cup of STFU. I'm hoping that's not what anybody actually wants, but I can also understand why some people might be feeling that way. Dato didn't sign his proposal mail, so this can't be a valid GR proposal, AIUI. All I meant was that I second the feeling, rather than a formal proposal. We're having a serious discussion, and you guys are adding noise. If you want to make jokes, please at least start a separate thread. Thanks in advance -- 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: Results of the Lenny release GR
On Sun, Jan 11, 2009 at 09:25:37AM -0800, Russ Allbery wrote: Ben Finney ben+deb...@benfinney.id.au writes: Though there seem to be a number of people vocally wishing Robert would go away or the like, I have yet to see any substantive response to the questions he's raised in this thread. I made a substantive response to these points weeks ago. He just didn't like it. I don't feel the urge to constantly repeat it, but since I'm sending the mail anyway: the release team made a delegate decision. That decision was not overridden. Hence, the release continues. All else is irrelevant. If he wants to stop the release, he needs to propose a GR to override the delegate decision, and it has to pass. Neither of those things have happened. Until they do, this is all pointless noise. As I said in a separate mail, the developers just discredited this line of reasoning by ranking option 2 above option 4. -- 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: Results of the Lenny release GR
On Sun, Jan 11, 2009 at 10:00:02AM -0800, Russ Allbery wrote: [...] Robert's constitutional interpretation is not going to be adopted at present. There's nothing to be adopted. The project as a whole thinks of the Social Contract as a binding document. Having a vocal minority disagree with that doesn't change things. -- 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: Results of the Lenny release GR
On Sun, Jan 11, 2009 at 06:42:12PM +0200, Kalle Kivimaa wrote: Ean Schuessler e...@brainfood.com writes: Ironically, Bdale *is* warping the results of the vote and applying an editorial voice to the interpretation of the results. Umm, why shouldn't Bdale have his opinion about the results? Nowhere does it say that the (acting) Secretary is the authority to interprete GR results (that's not interpreting the Constitution). He's doing more than interpret the results. He claims they are ambigous, and that his interpretation is based on his speculation on what he thinks the developers want. This is far from what one would expect the Secretary to do. If results are really ambigous, or flawed in any way, what he should do is cancel the vote. -- 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: Results of the Lenny release GR
On Mon, Jan 12, 2009 at 10:30:02PM +0100, Pierre Habouzit wrote: On Mon, Jan 12, 2009 at 09:26:20PM +, Robert Millan wrote: On Sun, Jan 11, 2009 at 05:17:33PM +, Stephen Gran wrote: This one time, at band camp, Steve McIntyre said: If things go much further we'll end up with enough seconds to force a vote to hand Robert Millan a nice cup of STFU. I'm hoping that's not what anybody actually wants, but I can also understand why some people might be feeling that way. Dato didn't sign his proposal mail, so this can't be a valid GR proposal, AIUI. All I meant was that I second the feeling, rather than a formal proposal. We're having a serious discussion, and you guys are adding noise. If you want to make jokes, please at least start a separate thread. Priceless. That goes for you, too. -- 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: Results of the Lenny release GR
On Mon, Jan 12, 2009 at 05:47:00PM +, Matthew Johnson wrote: On Mon Jan 12 18:38, Robert Millan wrote: Agreed. Then again, even if Manoj was rightfully appliing super-majority requirements (which I think he was), it has become clear that, in general, such requirements are not politicaly sustainable. And in practice they don't exist anymore, anyway.I think this would be a good time to propose that they are removed from the Constitution. Immediately after Lenny is released is a better time, and when I'm intending to propose vote(s) to clarify a bunch of this stuff. Now is not the time and is only going to hurt your chances at getting people to agree with you later. If the DPL wants to release a statement to explain this all he is welcome (and encouraged) to do so, I don't think we need a GR though. This is one of the DPL's main functions and we did elect him to perform that function... So far he hasn't. Do you have reasons to believe he will? By reading the vote result announcement, it gives me the impression that he endorses it. -- 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: Results of the Lenny release GR
On Mon, Jan 12, 2009 at 09:14:27PM +, Matthew Johnson wrote: On Mon Jan 12 22:07, Robert Millan wrote: I find this reasonable, in general, for minor issues. But it's worth noting that in this occasion, the developers didn't feel it was necessary to delegate this responsibility. If they did, they'd have voted for option 4. They did vote for option 4, through the wonders of condorcet. more than half the voters were happy with that option (or it would not have beaten FD) For a very specific and convenient definition of happy. According to your definition, the developers endorsed both delegating and not delegating at the same time! I guess now you'll have a hard time explaining me what this means... -- 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: Results of the Lenny release GR
On Mon, Jan 12, 2009 at 12:42:12AM -0800, Steve Langasek wrote: On Mon, Jan 12, 2009 at 08:37:06AM +0100, Robert Millan wrote: I know you didn't explicitly request being appointed Secretary; it sort of happened by accident, but you had the opportunity to refuse all the time, so I must take it that you accept it, at least temporarily. This is not true. The constitution specifies that when there is no Secretary, the chair of the Technical Committee serves as Acting Secretary. To refuse the post of Acting Secretary, Bdale would have to step down as TC chair. This doesn't change anything. When he accepted his position as TC chair, he was accepting that he could become Acting Secretary under certain circumstances. It's not like he was blackmailed to become Secretary. -- 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: Results of the Lenny release GR
On Mon, Jan 12, 2009 at 04:12:57AM -0500, Daniel Dickinson wrote: As for trying to bully people about consitution and the social contract et al, I think you need to remember that the Debian Project is a concept not an incorporated (or otherwise formally recognized by any government as an organization) body. The 'consitution' and 'social contract' exist only insofar as the developers agree they do, either by action or inaction. Agreed. If you want to argue constutional matters in debian you have to make sure you're not just making noise but are in fact supported other developers. Indeed. If most developers think that Bdale's interpretation makes sense Nope. You only got that impression because the ones supporting this interpretation are the ones making the most noise. If you want to know for real, check the vote results. You'll see how option 2 beats option 4. And I lost count on how many times I repeated that, but will do as long as necessary. -- 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: Results of the Lenny release GR
On Mon, Jan 12, 2009 at 01:45:04PM -0800, Russ Allbery wrote: As I said in a separate mail, the developers just discredited this line of reasoning by ranking option 2 above option 4. I disagree completely. The fact that more people preferred 2 to 4 in this vote does not change the fact that the release team is currently empowered to interpret the DFSG and SC in their own work. That's what the constitution currently says. You mean what it says, or ... I understand that you disagree with this interpretation of the constitution, ... your interpretation of what it says? Attempting to read a project position about the interpretation of the constitution into this vote is stretching its implications far beyond what is supportable, given that the text of the options didn't address constitutional interpretation at all. No, but it's very clear about developers preferring the option that doesn't gives this power to the RT over the option that does. (Without a 3:1 majority, such a position statement would be non-binding anyway, Interesting to see 3:1 come back. One of the most annoying things about super-majority requirements is that they appear and disappear depending on the position one is holding. That's why I would very much like to get rid of them. So I take it you didn't agree with Manoj's decision to set super-majority requirements in the ballot? It doesn't provide any clarity at all, except that the project wants us to not spend time worrying about the licensing of firmware. Results are clear for me. You'll notice that I'm not complaining about firmware right now. But the same goes both ways: people should accept the results when it comes to non-firmware. The winning option in the vote says nothing one way or the other about the non-firmware licensing issues, which means that we're in the same position that we were in before the GR began. Technically yes, but politically the situation is much different. The developers had a number of options that explicitly granted more exceptions, and they preferred the one that didn't. This tells us something about what the majority of us wants, and you shouldn't neglect it. Of course, you can object that it wasn't an explicit assertion, etc, but from general consensus to explicit assertion there's only one small step. Keep that in mind. This is one of the reasons why the vote was flawed; Again, if the vote was flawed (I don't think it was, but if the Secretary considers it flawed), the right thing would be to cancel it. -- 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: Results of the Lenny release GR
On Mon, Jan 12, 2009 at 10:52:04PM +0100, Michael Goetze wrote: Robert Millan wrote: This is far from what one would expect the Secretary to do. If results are really ambigous, or flawed in any way, what he should do is cancel the vote. And I'm sure you would have been the first one to cry foul, there being, after all, no constitutional basis for the cancellation of a vote which has already entered the voting period - in any case not unilaterally by the (acting) secretary. I already said, that I don't consider the ballot to be flawed. Whether I'd have complained or not, I don't even know myself. But the important thing is, that although both events would have the same result, cancelling the vote is much better because it's much more sincere, and it lets the developers know that something went seriously wrong. OTOH, reinterpreting the vote into something else is much harder to notice. Take the exact wording: This result means that the Debian Lenny release can proceed as the release team has intended, with the kernel packages currently in the archive. and carefully analize this phrase. Does it say the RT intended to release with the kernel packages currently in the archive? Well, yes. Does it say anything else about what they intended? Not really. Now suppose you know first-hand what the RT intends. Does the phrase mean the vote endorses that? Well, depends a lot on what the Secretary knows about the RT intentions and doesn't tell us in this mail, doesn't it? -- 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: Results of the Lenny release GR
On Mon, Jan 12, 2009 at 09:54:43PM +, Stephen Gran wrote: This one time, at band camp, Robert Millan said: On Mon, Jan 12, 2009 at 09:14:27PM +, Matthew Johnson wrote: On Mon Jan 12 22:07, Robert Millan wrote: I find this reasonable, in general, for minor issues. But it's worth noting that in this occasion, the developers didn't feel it was necessary to delegate this responsibility. If they did, they'd have voted for option 4. They did vote for option 4, through the wonders of condorcet. more than half the voters were happy with that option (or it would not have beaten FD) For a very specific and convenient definition of happy. According to your definition, the developers endorsed both delegating and not delegating at the same time! I guess now you'll have a hard time explaining me what this means... Not at all. Option 1 was the only option that failed to meet simple majority. Every other option on the ballot beat it by somewhere between a factor of 2 and 3. That seems like a pretty clear vote that the solution you are advocating is not what the project wants. It seems as you're trying to vindicate option 4 by discrediting me by discrediting option 1. Basically: - Robert doesn't like option 4 - Robert voted for option 1 - Option 4 ranked above option 1 Therefore: - The project is endorsing option 4!! This doesn't make any sense. To begin with, my opinion is only a ridiculously small part of the vote results. so I see that you haven't accepted the outcome. Of course I have. -- 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
I give up (for the time being)
Hi It's not usual in me to give up on something when I'm completely certain that I'm right. I hope you appreciate that I'm doing a great personal sacrifice here. Ean said: Discussion of these issues in the shadow of Lenny warps people's minds and makes sane discourse impossible. I've been pondering on that statement, and I think it's the most insightful point that has been made in this thread. I've gradually confirmed to be true over the course of the discussion. There's no point in insist that people shouldn't be irrationally committed to releasing Lenny. Feelings aren't supposed to be rational, just like my course of action hasn't been completely rational either. I realize that insisting too hard precisely at this time has the opposite effect to the goals I was trying to defend. So, I'll stop now. Do not think this means the problem just got solved. I only do it because I expect we can have a healthy discussion about it after Lenny is released. Best wishes to everyone, -- 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: Results of the Lenny release GR
On Sun, Jan 11, 2009 at 10:32:10AM +0100, Joerg Jaspert wrote: So, I think you made a mistake, a very serious one, and when asked about it, your explanation is completely unsatisfactory. How do we solve this? Currently, the only solution I see is that we ask the developers what they think, and hold another vote. Do you have any other idea in mind? How about accepting that the project wants to release, and not want to have yet another vote by someone who just doesnt like the outcome of the last? Actually, I accept the outcome of the last vote. I don't like that we made an exception for firmware, but the developers chose to make one so there's no point in arguing about it. On the other hand, it appears that the Secretary, the DPL and the Release Team don't like that we made an exception ONLY for firmware. As per your reply I will assume you're also in that list. -- 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: Results of the Lenny release GR
On Sun, Jan 11, 2009 at 10:32:10AM +0100, Joerg Jaspert wrote: Do you have any other idea in mind? Btw, Joerg, that goes for you too. If you have something constructive to say, this would be a good time. -- 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: Results of the Lenny release GR
On Sun, Jan 11, 2009 at 11:03:45AM +, Matthew Johnson wrote: On Sun Jan 11 10:56, Robert Millan wrote: On the other hand, it appears that the Secretary, the DPL and the Release Team don't like that we made an exception ONLY for firmware. As per your reply I will assume you're also in that list. I will note there was a simple majority in favour of releasing Lenny with DFSG violations (take that as you will). Relative to... ? -- 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: Results of the Lenny release GR
On Sun, Jan 11, 2009 at 01:06:21PM +0100, Michael Banck wrote: On Sun, Jan 11, 2009 at 08:22:58AM +0100, Robert Millan wrote: You're the Secretary. You're supposed to give answers, not speculation. If the ballot was ambigous, or confusing, it is YOUR responsibility. It has to be said that at least I am taking YOU personally responsable for a lot of why the ballot was ambigous as well, not least to the fact you named your proposal Reaffirm the Social Contract, i.e. SC-trolling the rest of the project not in line with your opinion. I keep hearing this SC is not binding story, as if repeating it lots of times made it true, but fact is that the project already rejected option 4 which is the one that represents this line of reasoning. If you're so serious about it, I challenge you to propose it as a separate vote. -- 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: Results of the Lenny release GR
On Sun, Jan 11, 2009 at 11:35:22AM +0100, Joerg Jaspert wrote: Do you have any other idea in mind? Btw, Joerg, that goes for you too. If you have something constructive to say, this would be a good time. How about you going elsewhere until Lenny is released, then coming back as soon as that happens and start working on what is left to fix then? (Not right before a release, right after a release for a change.) We can talk about that, yes. I don't think right before a release is the best time to go through all this mess, but alas we already started, and believe it or not, it wasn't my choice. Please let me ellaborate. I think the reason this happened is that although most of these bugs were filed ages ago, nothing was done about them untill it became clear that the Release Team planned to include them in Lenny without asking for an exception (like happened for Sarge Etch). All this could have been avoided if we started talking about the bugs earlier (from a constructive POV rather than just flaming), so let's talk about the bugs shall we? The way I see it, there are 5 cathegories: 1- Firmware in Linux. We already made an exception for these. But it's not clear what the maintainers plan to do after Lenny is released, and it's not clear what the FTP team will do about it either. 2- Long-standing bugs in critical components for which a fix is expected to arrive soon. This includes things like SunRPC, GLX, and even Nvidia obfuscation (#383465). It's not unreasonable to expect the developers would support an exception. Heck, maybe even I would. But none of this _has happened yet_. 3- Non-bugs (IMHO), that'd be the trademark issue in #391935. 4- Bugs which are trivial to fix, such as #459705 (just remove a text file), #483217 (only affects optional functionality that could be removed according to the maintainer) or #509287 (just move afio to non-free). Why isn't the FTP team enforcing these? 5- Bugs which aren't easy to fix. AFAICS this includes ONLY TWO of them: #477060 and #498475 (aka #498476). Maybe it's worth making an exception for them, but again this is something that should be judged by the project as a whole. This needs proper discussion IMHO. Maybe even a vote. So, if you could tell me that there's going to be a proper solution for #1 and #4, all that's left to do is have a vote to device what we do about #2 (which almost certainly will be exempted) and #5 (which is likely to be exempted too). OTOH, if you just tell me to go elsewhere, I'm sorry but I don't want to look the other way while the project destroys its reputation for having a commitment to freedom, a democratic system and a set of principles. -- 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: Results of the Lenny release GR
On Sun, Jan 11, 2009 at 01:14:08PM +0100, Robert Millan wrote: On Sun, Jan 11, 2009 at 11:03:45AM +, Matthew Johnson wrote: On Sun Jan 11 10:56, Robert Millan wrote: On the other hand, it appears that the Secretary, the DPL and the Release Team don't like that we made an exception ONLY for firmware. As per your reply I will assume you're also in that list. I will note there was a simple majority in favour of releasing Lenny with DFSG violations (take that as you will). Relative to... ? I think you mean both option 3 and 4 ranked above FD. I read that as I don't like these options, but if there's no choice, I prefer them over the ambiguity of not making any explicit decision. This is hardly the same as simple majority in favour. -- 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: Results of the Lenny release GR
On Sun, Jan 11, 2009 at 08:22:58AM +0100, Robert Millan wrote: You're the Secretary. You're supposed to give answers, not speculation. If the ballot was ambigous, or confusing, it is YOUR responsibility. Bdale, After sleeping over this, I really think I've been unnecesarily harsh, and at the same time I failed to explain accurately what I meant here. So please bear with me, and let me rephrase it in a way that doesn't make it a less serious problem, but at least more sympathethic. I know you didn't explicitly request being appointed Secretary; it sort of happened by accident, but you had the opportunity to refuse all the time, so I must take it that you accept it, at least temporarily. When you accepted your position as Secretary, you knew this implied making tough decisions, and being responsible for them. You decided that the ballot was good enough to be voted on; you could have cancelled the vote, or you could have announced the results saying they're basically useless, but you didn't. Fair enough, it's your decision. And I don't see a problem with the ballot myself. However, when you were asked about the way you're interpreting the results, what you're essentially telling us is that the ballot was ambigous, and badly worded. You probably think this is my fault because I wrote a significant part of it, but that doesn't matter: you already decided the ballot is good enough, and (unless you want to retract that) you're bound to your own decision. So, what I think would be the honest approach to this problem, is for you to either announce that your interpretation is the way it is because the ballot was flawed, or change your interpretation to make it consistent with the ballot. I assume you won't be doing the latter, but if you choose the former instead of not doing anything, you have my support on that. -- 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: Results of the Lenny release GR
On Mon, Jan 05, 2009 at 04:54:25PM -0700, Bdale Garbee wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I've been reminded that as Acting Secretary I should officially announce the results of the recent vote. My apologies for the delay! Details of the outcome and how various options were voted are available at http://www.debian.org/vote/2008/vote_003 The winning option was number 5, Assume blobs comply with GPL unless proven otherwise, the full text of which is appended below. Since the election concluded, several developers have asked for some statement from the DPL and/or Secretary as to what this result really means. Steve and I have discussed it, and we think it's pretty clear. This result means that the Debian Lenny release can proceed as the release team has intended, with the kernel packages currently in the archive. Hi Bdale, What the release team intended (at least before the vote), as represented by lenny-ignore tags is to skip more DFSG violations than just kernel packages, see: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=211765 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=368559 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=424957 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=391935 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=459705 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=382175 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=509287 However, your announcement seems to assume these only concerned kernel packages. This leaves the message open to interpretation, it could mean any of the following: - You assume the release team no longer intends to ignore DFSG violations for these packages. - The RT gets an exception for kernel packages, as they intended, but not for the rest of Debian. - The developers are implicitly endorsing an exception for the rest of Debian packages. Please, could you send a new message clarifiing the situation, and your judgement as Secretary? Thanks! -- 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: Results of the Lenny release GR
On Sat, Jan 10, 2009 at 09:45:48AM -0700, Bdale Garbee wrote: It is my opinion that the text of the winning GR option says nothing explicit about any of the bugs currently tagged lenny-ignore except those relating to firmware blobs. However, analysis of the voting results in this and prior GRs relating to similar issues in prior releases indicates to me that Debian developers in general would prefer to release with faults than to defer release until some arbitrary level of perfection is achieved. What you describe sounds like option 3, or maybe option 4. What is your opinion on the fact that option 2 defeats both of them? -- 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: Results of the Lenny release GR
On Sat, Jan 10, 2009 at 05:48:33PM -0700, Bdale Garbee wrote: On Sun, 2009-01-11 at 01:04 +0100, Robert Millan wrote: What you describe sounds like option 3, or maybe option 4. What is your opinion on the fact that option 2 defeats both of them? I'm not sure I agree with your sense of distinction here. I think what I'm saying is a fair rationalization of picking any of 2-5 over 1. How is option 1 related to this? And, at some point I think we cross the line from drawing meaningful inferences from a limited data set to fiddling with divining rods... http://en.wikipedia.org/wiki/Divining_rod Who's drawing inferences here? I'm just reading the results: - Option 5 is the winner. - Option 2 is what the (simple) majority of developers wanted. The majority of developers voted to make an exception for firmware in Lenny. They did NOT vote to empower the Release Team to make exceptions as they see fit. Results of GR 2008/003 are crystal clear about this. Options 2 and 5 share the attribute that neither explicitly asserts that the firmware issue is a DFSG violation, while 3 and 4 both seem to. How is that relevant at all? We just made an exception for firmware. Why do you bring this into the discussion? Perhaps our community is willing to admit there's a problem, but isn't convinced or doesn't want to admit that the problem is a clear contradiction of the social contract. You're the Secretary. You're supposed to give answers, not speculation. If the ballot was ambigous, or confusing, it is YOUR responsibility. The way results stand, they say we make an exception for firmware. They don't say we empower the Release Team to make exceptions as they see fit. Up to this point, I was assuming that your reinterpretation of the results was an unintended mistake. TBH, now I think you're being coy. When called into question, you respond talking about unrelated things like option 1, and about firmware, and with speculation on what the developers might really want instead of what they voted. So, I think you made a mistake, a very serious one, and when asked about it, your explanation is completely unsatisfactory. How do we solve this? Currently, the only solution I see is that we ask the developers what they think, and hold another vote. Do you have any other idea in mind? -- 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: RFC: General resolution: Clarify the status of the social contract
On Sat, Dec 20, 2008 at 02:52:03PM +1000, Anthony Towns wrote: As far as voting for a position statement along the lines of the social contract doesn't matter, we'll upload Microsoft Word into main, yay!, I believe that would also require a simple majority (1:1) to pass, What you're saying is basicaly that a technicality can turn the 3:1 requirement in the Constitution into a simple majority requirement? I'm not sure if this is so, but if it is, I think it's unfortunate that we have such language in the Constitution. IMO it should be either removed for consistency or fixed so that it actually has the intended effect. -- 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: I hereby resign as secretary
On Thu, Dec 18, 2008 at 08:44:11AM -0600, Manoj Srivastava wrote: As to the people who emailed me that they are putting together a petition for the DAM to have me removed from the project, I hear you too. I am going to spend the next few days evaluating how important the project is to me, and whether I should save you the bother or an expulsion process. Hi Manoj, I'm not going to argue on your decision to resign as secretary, because I understand how hard it must have been to go through all this pressure just to do what is, in your judgement, your obligation in this position [1]. OTOH, triing to have you removed from the project looks a lot like a purely emotional response, which IMO cannot be justified even if we take as granted that you acted irresponsibly as secretary (which, btw, I don't). Because this response is completely unjustified, I'd like to ask that you don't vindicate them as you suggest you would. Please force them to go through it themselves. Force them to provide non-sense arguments to the DAM, and to make up silly excuses for everyone to read. In the end, they'll make fools of themselves no matter if they succeed or not, and I believe it's what they deserve. Let them make their own karma. [1] For those who believe that I'm an uncompromising zealot (you guys know who you are ;-) ), notice that I vocally disagreed with Manoj's decision not to split the votes in separate ballots. This doesn't change anything I said in this mail, nor make me feel that his decisions as secretary are somehow illegitimate. -- 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: RFC: General resolution: Clarify the status of the social contract
On Fri, Dec 19, 2008 at 01:38:33PM -0600, Manoj Srivastava wrote: ,[ The Social contract is a binding contract ] | The developers, via a general resolution, determine that the social | contract should apply to everything Debian does, now and in the future; | _AND_ the social contract should stop us from including anything that | doesn't comply with the DFSG in main ` main is just the name of an archive section. The SC says that Debian is 100% free, so I think we should go with that instead, regardless of how DAK calls it. ,[ The social contract is binding, but currently flawed ] | This amends the proposal above, and replaces the text of the proposal with: | The developers, via a general resolution, determine that the social | contract should apply to everything Debian does, now and in the future; | _AND_ it is and was a mistake to have the DFSG cover firmware because | we have not yet been able to limit Debian to only DFSG-free firmware | in a suitable way. This mistake should be corrected by amending the | social contract. ` Would probably be a good idea to define firmware here. Besides, isn't there an option in the gr_lenny vote that is basicaly equivalent to this? ,[ The social contract is binding but may be overridden by a simple GR ] | This amends the proposal above, and replaces the text of the proposal | with: The developers, via a general resolution, determine that the | social contract should apply to /almost/ everything Debian does, now | and in the future; _AND_ for the few cases where it should not apply | now, there should be an explicit GR affirming that variation (by simple | majority) ` I don't like the workaround approach to supermajority requirements. If we don't want 3:1, why don't we ammend the Constitution instead? ,[ The social contract is a goal, not a binding contract ] | This amends the proposal above, and replaces the text of the proposal | with: The developers, via a general resolution, determine that the | social contract is an aspirational document: while we aim to achieve as | much of it as feasible at all times, we don't expect to get it | completely right for some time yet. This includes DFSG-freeness of all | firmware ` Doesn't that contradict the definition of contract ? Maybe a rename would be in order. ,[ The social contract is a non-binding advisory document ] | This amends the proposal above, and replaces the text of the proposal | with: The developers, via a general resolution, determine that the | social contract is a statement of principle only, and has no particular | force on the day to day operations of Debian, except in so far as it | influences individual contributors' actions. ` How does this differ from the previous one in practice? -- 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 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
Call for vote (Re: call for seconds: on firmware)
On Thu, Dec 04, 2008 at 07:45:05PM +0100, Robert Millan wrote: On Tue, Dec 02, 2008 at 09:18:03AM +0100, Peter Palfrader wrote: Feel free to propose an amendment. I might accept it. I propose the following ammendment: [...] Since there was no further reply on this proposed ammendment, and no followup discussion for a reasonable period of time, I conclude that after discussion, the ballot in: http://www.debian.org/vote/2008/vote_003 titled General Resolution: Lenny and resolving DFSG violations, represents each of the opinions in a reasonably accurate manner, and that it is unlikely that it will be improved. Therefore I'm hereby calling for vote. -- 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. signature.asc Description: Digital signature
Re: call for seconds: on firmware
On Tue, Dec 02, 2008 at 09:18:03AM +0100, Peter Palfrader wrote: I would ask that the proposer withdraw this resolution (which in effect is a non-binding position statement, contradicting the text of the DFSG as many of us understand it) and draft a resolution in its place that disambiguates the DFSG. Peter, I too would prefer if you did, for the sake of clarity. But if you will, then please do it soon. Minimal time for discussion period has passed, and due to the urgency of the situation I don't want to wait much longer before calling for vote. Feel free to propose an amendment. I might accept it. I propose the following ammendment: --- firmware2008-12-04 19:40:22.0 +0100 +++ firmware.new2008-12-04 19:40:44.0 +0100 @@ -16,3 +16,20 @@ b) we however do require all other freedoms that the DFSG mandate from components of our operating system, and c) such firmware can and should be part of our official installation media. + d) the Debian Free Software Guidelines shall be ammended as follows: + +--- social_contract.wml22 Nov 2007 03:15:39 - 1.23 social_contract.wml4 Dec 2008 18:36:32 - +@@ -95,7 +95,11 @@ the free software community as the basis +lipstrongSource Code/strong/p + pThe program must include source code, and must allow + distribution in source code as well as compiled +- form./p/li ++ form. As a special exception, the requirement to include ++ source code does not apply to firmware (Firmware is data such ++ as microcode or lookup tables that is loaded into hardware ++ components in order to make the component function properly. It ++ is not code that is run on the host CPU)./p/li +lipstrongDerived Works/strong/p + pThe license must allow modifications and derived works, and + must allow them to be distributed under the same terms as -- 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. signature.asc Description: Digital signature
Re: Dwindling popularity
On Wed, Nov 19, 2008 at 12:54:04AM +0100, Michael Banck wrote: Hi Ean, On Tue, Nov 18, 2008 at 05:35:20PM -0600, Ean Schuessler wrote: [...] Why the heck did you post this to -vote? I think Ean thought this would be relevant to the discussion. I found his message insightful, and I appreciate his contribution. -- 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
On Sun, Nov 30, 2008 at 05:11:23PM -0800, Steve Langasek wrote: On Sat, Nov 15, 2008 at 09:45:56AM -0600, Debian Project Secretary wrote: ,[ Proposal 6: Exclude source requirements from firmware (defined) ] | Firmware is data such as microcode or lookup tables that is loaded into | hardware components in order to make the component function properly. | It is not code that is run on the host CPU. | | Unfortunately such firmware often is distributed as so-called blobs, | with no source or further documentation that lets us learn how it works | or interacts with the hardware in question. By excluding such firmware | from Debian we exclude users that require such devices from installing | our operating system, or make it unnecessarily hard for them. | | Therefore the Debian project resolves that | a) firmware in Debian does not have to come with source. While we do | prefer firmware that comes with source and documentation we will not | require it, | b) we however do require all other freedoms that the DFSG mandate from | components of our operating system, and | c) such firmware can and should be part of our official installation media. | | (Since this option overrides the SC, I believe it would require 3:1 | majority) ` This will need wording to change the SC, since this is not a temporary override, but adds a definition of firmware, and an exclusion from the 100% free promises of the SC. i Do we require source for firmware in main: No ii Do we allow the Release Team to ignore SC violation bugs: No iii What do we do for Lenny: Release iV Do we modify foundation documents: Yes v Do we override foundation documentsNo In light of the Secretary's claims that the above GR would give him the power to amend the text of the DFSG even though it says nothing of the sort, I would ask that the proposer withdraw this resolution (which in effect is a non-binding position statement, contradicting the text of the DFSG as many of us understand it) and draft a resolution in its place that disambiguates the DFSG. Peter, I too would prefer if you did, for the sake of clarity. But if you will, then please do it soon. Minimal time for discussion period has passed, and due to the urgency of the situation I don't want to wait much longer before calling for vote. -- 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Call for seconds: DFSG violations in Lenny
On Sun, Nov 16, 2008 at 09:20:13AM -0800, Steve Langasek wrote: On Sun, Nov 16, 2008 at 01:24:56PM +0100, Bernd Zeimetz wrote: The only thing you're doing is to make Lenny the release with the longest freeze time ever. Not that I disagree with the rest, but I don't think Robert has much chance of displacing sarge from that position of honor. Why would I want that? Honestly, the time wasted on this whole GR cycle is orders of magnitude more than the time it would have taken to just finish removing the sourceless firmware from the main kernel package and support loading it from the installer. Maybe, but that wouldn't have solved the actual problem. Which is, a selected group taking decisions about major issues without the endorsement of the project. Careful; given the uncompromising zealotry of the people arguing for the removal of sourceless firmware at all costs, Please would you (all) stop referring to these imaginary uncompromising zealots arguing imaginary things that I don't recall even reading in this discussion? The only zealots here are those who want to impose their view on the rest of the project. It happens they won't be able to, because a vote is already scheduled. Whatever we decide now, it will be by consensus. -- 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Call for seconds: DFSG violations in Lenny
On Sun, Nov 16, 2008 at 12:46:44PM -0800, Russ Allbery wrote: This is exactly why I'm going to be voting for one of the options that modifies the foundation documents and establishes a permanent and unambiguous decision. I think this has gone on far, far too long and wastes way too much time and energy, and it's clear that it's never going to be considered resolved short of a modification of the foundation documents, given that hardware requirements for firmware are not going to magically disappear. They probably won't, but there are no hardware requirements that prevent firmware source code from being distributed under a free license. -- 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Discussion: granting discretion to release team (was: Call for seconds: DFSG violations in Lenny)
On Mon, Nov 17, 2008 at 12:10:07AM +0100, Pierre Habouzit wrote: I would welcome a more permanent answer to the firmware question, really, I'm not really pleased with the trolls that arise on the subject prior to every release. May I ask who are those trolls you refer to? -- 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
On Mon, Nov 17, 2008 at 08:08:36AM +0100, Andreas Barth wrote: I believe that one of the arguments used is that by doing so, the RT would be overriding a foundation document, and developers cannot do so without $higher_power. Though I agree that the release team cannot put any foundation document aside, I don't think the release team is overriding the social contract, but chooses a certain interpretation (that I think is the correct one btw). Other people obviously prefer a different interpretation, and so the relevant question is: Whose interpretation is the binding one? Currently, it seems to me that unless decided otherwise by a GR, the release team has the final say (as explained by Russ). When you say chooses a certain interpretation, are you referring to the one in which SC #4 is interpreted in a way that cannot be complied with no matter what, only to use this impossibility as proof that SC #4 and SC #1 contradict each other, and in turn resolving that because the SC is inconsistent, SC #1 is meant to be read figuratively? I think we discussed this before [1]. In any case, if you think the SC is so badly broken, you should be ammending the text to disambiguigate it, like we did in GR 2004 / 003, or even in GR 2003 / 003. [1] http://lists.debian.org/debian-vote/2008/11/msg00039.html -- 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
On Sun, Nov 16, 2008 at 06:02:00PM +0100, Josselin Mouette wrote: What they are not empowered to do is to decide to release with DFSG violations in main. Sorry? The release team is empowered to release, and that includes releasing with some known RC bugs. That’s what they’ve been doing – including with DFSG-freeness RC bugs – since I have known this project. The Social Contract doesn’t say anything about stable releases, nor about the release team. The interpretation that the release team is somehow special is your own. Why would it have to? Knowingly violating the Social Contract is not allowed anywhere in the project, not just in stable releases. The fact that other participants did (either intentionally or unintentionally) is by no means an excuse for the Release Team to do the same. -- 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposed wording for the SC modification
On Mon, Nov 17, 2008 at 10:19:49PM +0900, Charles Plessy wrote: Can the Secretary clarify again what will hapen if Peter's option is voted ? - What if Peter does not think that a second vote is necessary, but the Secretary does ? - What if a second vote is organised, but not option gets a 3:1 majority ? - What if no second vote is organised ? - What if Peter's option is voted with less than a 3:1 majority ? Is this really so important? If a 3:1 majority that supports this exists, they can easily ammend the SC as they see fit, possibly with another GR to decide whether to ammend it or just override it. If a simple majority exists, but not a 3:1 one, then we're in for stormy weather. Too bad. Note that I don't like 3:1 requisites either [1], but since I had to accept it when it was against my preferred choice [2], it's only fair that others do the same now. [1] http://www.debian.org/vote/2003/gr_sec415_tally.txt [2] http://www.debian.org/vote/2004/gr_non_free_tally.txt -- 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposed wording for the SC modification
On Mon, Nov 17, 2008 at 04:50:50PM +0100, Adeodato Simó wrote: * Manoj Srivastava [Mon, 17 Nov 2008 09:32:33 -0600]: On Mon, Nov 17 2008, Adeodato Simó wrote: * Josselin Mouette [Mon, 17 Nov 2008 14:38:43 +0100]: Le lundi 17 novembre 2008 à 14:05 +0100, Peter Palfrader a écrit : This is not part of my GR as proposed and seconded. The Secretary made it clear that if your proposal wins, the SC *will* be amended. Therefore I think we should decide on a new wording before the vote instead of letting someone else decide on it. Can the SC be modified without a second vote? I don't see why we need a second 3:1 vote on a foundation document after having a 3:1 vote that supersedes part of it. And who is going to modify it if the original vote does not include a wording? Guys, I think this is not productive. If the vote wins, it won't be by chance, it will mean there's a 3:1 majority that supports this change. At that point, if the wording is contentious, you can always propose another vote to resolve that. And looking at what others (e.g. Peter) had to say about this, it seems the position among those who support sourceless firmware is not unanimous. This would have to be resolved in some way, too. Either with a new vote, or by adding a new option to this ballot. -- 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: on firmware (possible proposal)
On Sat, Nov 15, 2008 at 04:39:04PM +, Stephen Gran wrote: This one time, at band camp, Robert Millan said: If we get closer to the free side, and provide a 100% free main like we used to, When precisely was that? Yeah, it's funny. We never did. Let us say, like we used to promise we would. -- 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: on firmware (possible proposal)
On Sun, Nov 16, 2008 at 12:14:30PM +, Stephen Gran wrote: This one time, at band camp, Robert Millan said: On Sat, Nov 15, 2008 at 04:32:08PM +, Stephen Gran wrote: It often can, though. You can't really tell if the firmware for your network card is using DMA to send away your private data in unaccounted frames. Of course you can. Adding paranoid fantasies to the debate doesn't really help much. Can you? Would you explain how? (and no, I run wireshark in my gateway and dig through several GiBs of data doesn't really tell me anything) Disregarding standard diagnostic tools doesn't really add to your credibility in this. Ad hominem doesn't really work as a stock replacement for justifiing things. -- 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: on firmware (possible proposal)
On Sat, Nov 15, 2008 at 04:32:08PM +, Stephen Gran wrote: It often can, though. You can't really tell if the firmware for your network card is using DMA to send away your private data in unaccounted frames. Of course you can. Adding paranoid fantasies to the debate doesn't really help much. Can you? Would you explain how? (and no, I run wireshark in my gateway and dig through several GiBs of data doesn't really tell me anything) -- 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: on firmware (possible proposal)
On Fri, Nov 14, 2008 at 06:54:52PM +0100, Frans Pop wrote: On Friday 14 November 2008, you wrote: I believe Debian has remained important over time because, despite our various social failings, they *respect* our ideology. And I believe that Debian is becoming increasingly marginal because users are driven away to other distros. Ironicaly, it is possible that both are right. It is staying in this middle stage that harms us the most, since we're heavily criticized from both sides. Furthermore, we can't really satisfy everyone. If we get closer to the non-free side, we'll still be beaten by distributions which go further. If we include firmware, they will include Nvidious blobs. If we include Nvidious blobs, they will include Adobe Flash. Etc. This is a big part of how Ubuntu earned this reputation of being easy to setup (they used our code to betray our goals, and now somehow we're looking at them for inspiration..). If we get closer to the free side, and provide a 100% free main like we used to, we'll still be criticised for having a non-free repository, or for having unofficial non-free installers. This is why I think that worriing so much about what _others_ think is a pointless exercise. Heck, if people think our stance on freedom is wrong, they most likely have already abandoned us in favour of other options (be it e.g. Ubuntu or Gnewsense). Those who have stayed with us to this date is because they _like_ our current compromise, because they care about freedom, even if they sacrifice their beliefs for practical reasons, and install non-free software. But when they do, they want to know they did. -- 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: on firmware (possible proposal)
On Fri, Nov 14, 2008 at 12:29:20AM -0600, Manoj Srivastava wrote: - code uploaded into another cpu (a device cpu, not a SMP cpu of some kind) does not run in the same memory space, and can thus not impact the main software running on the host CPU. Impacting other software has very little to do with the desirability of freedom of software. It often can, though. You can't really tell if the firmware for your network card is using DMA to send away your private data in unaccounted frames. -- 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: For our own good: splitting the vote. Thoughts?
On Fri, Nov 14, 2008 at 09:56:06AM +, Neil McGovern wrote: On Thu, Nov 13, 2008 at 01:23:42PM +0100, Robert Millan wrote: On the contrary. It is excess of overlapping options that prompt for strategic voting. For example, if I don't care much between option A and option B, but prefer either of them to option C So, your opinion would be ABC 112 No, that would be my strategical vote. My opinion could be e.g. 123. -- 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: on firmware (possible proposal)
On Fri, Nov 14, 2008 at 04:56:38PM +0100, Peter Palfrader wrote: Firmware is data [...] Firmware is like porn, I know it when I see it. :) This isn't meant to be an exact definition, but more of a guideline. That being said, if s/data/software/ makes you happy then we can do that. Why not refer to it as microcode instead? This is far less ambigous, as microcontroller is a more specific term than processor. Also, I was asked to s/BLOB/blob/ which seems fine to me too. May I suggest so-called \blobs\ or some indication that blob is an informal term? -- 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: on firmware (possible proposal)
On Wed, Nov 12, 2008 at 04:20:33PM +0100, Martin Michlmayr wrote: * Robert Millan [EMAIL PROTECTED] [2008-11-12 15:29]: For example, if you want to install Debian on an NSLU, the only difficulty is finding the unofficial D-I images that include non-free firmware. And even that can be improved. They could be linked from the main website, and integrated with our infrastructure, much like we do for non-free, as long as we make it clear they're not officially Debian. The problem with this is that we'll end up shipping official Debian CDs that won't work on many systems and eventually we'll end up telling people take the unofficial one, you know, the one that actually works. I've been doing that for NSLU2 and there it's not such a big deal because everyone uses netboot images, but it's more of a problem with CDs/DVDs. I know people who use Debian themselves, but when asked tell take the Ubuntu one, it supports more hardware. Sure, we can try to compete with that if that's more practical than either not recommending non-free or shipping two build sets. If we go this route, expect that we will either go half-way and not actually make any difference, or push further and bundle our default setup with Nvidious blobs, a restricted devices daemon, Adobe flash, etc, etc. In the end, you can't out-Ubuntu Ubuntu. -- 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: For our own good: splitting the vote. Thoughts?
On Wed, Nov 12, 2008 at 04:17:23PM +0100, Adeodato Simó wrote: I hate complex ballots. They tend to work against the goal of a vote, which is getting a crystal clear assessment on the opinions of the Developers. This vote is at 5 options already, with 2 more underway. I want to propose, and get consensus on it, to logically split the vote in two or three simple ballots, one for each of the orthogonal issues at hand. These issues are (in the order they should be voted on): 1. Do we require source for firmware in main. I don't think we have ever had this vote, and it's about time that we do, *without bundling it with somebody else*. This is Peter Palfrader's proposal at [1]. This vote has two options in it. 2. Do we allow the Release Team to use without a GR suite-ignore tags on bugs for violations of the SC. We haven't had this vote either, and it seems now it would be good to have it. This vote also has two options on it, eg. something akin to Andreas Barth's proposal [2] on one side, and Robert's reply [3] on the other. 3. What do we do for Lenny. The necessity for this vote depends on the results of the two votes above, and I think it should have at most 3 options: delay Lenny until all firmware issues known by some date are solved: (a) allowing source-less, (b) not allowing source-less; or don't delay it. I'm a bit lost as to what I could get done in order to have this go forward, since there have been a lot of seconds for the various options. I do think it would be a Good Thing. I'm CC'ing secretary@ and leader@ to see what they think. I second this. Notice, however, that my alternate option to Andreas' proposal hasn't got enough sponsors yet: [3]: http://lists.debian.org/debian-vote/2008/11/msg00086.html -- 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. signature.asc Description: Digital signature
Re: on firmware (possible proposal)
On Wed, Nov 12, 2008 at 03:49:44PM +0100, Patrick Schoenfeld wrote: On Wed, Nov 12, 2008 at 03:29:30PM +0100, Robert Millan wrote: For example, if you want to install Debian on an NSLU, the only difficulty is finding the unofficial D-I images that include non-free firmware. And even that can be improved. They could be linked from the main website, and integrated with our infrastructure, much like we do for non-free, as long as we make it clear they're not officially Debian. well, as you say for yourself non-free is not Debian, which basically means that we provide infrastructure and such, but if in doubt the user is left alone with his problems. We don't have any rules saying that non-free users have to be left alone with their problems. Some of us aren't going to help supporting non-free, but this doesn't mean you can't do it if you like. Isn't this what we had SC #4 and SC #5 for? -- 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: For our own good: splitting the vote. Thoughts?
On Wed, Nov 12, 2008 at 11:00:29AM -0600, Manoj Srivastava wrote: Hi, Well, splitting a vote into multiple ballots, with options referring to the same outcome, is a horrendously bad idea -- since the massive amounts of strategic voting possibilities will taint the final result. On the contrary. It is excess of overlapping options that prompt for strategic voting. For example, if I don't care much between option A and option B, but prefer either of them to option C, I might give equal weight to A and B in order to prevent circular ambiguities. In fact it is only starting with the presence of a 3rd option that strategy gets into the game: http://en.wikipedia.org/wiki/Gibbard-Satterthwaite_theorem Also, note that my alternate option to Andreas' proposal [1] was carefully worded to avoid making assumptions about the order in which votes would be processed. [1] http://lists.debian.org/debian-vote/2008/11/msg00086.html -- 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Call for seconds: DFSG violations in Lenny
On Wed, Nov 12, 2008 at 08:48:44AM +0100, Raphael Hertzog wrote: No it's really not funny. I'm sick of reading ad nauseam your opinion. Then don't read it. Me, I'm sick of reading personal attacks, but I choose to read anyway out of responsibility. It smells like you have the truth and you want to impose it. The only individuals in a position to impose anything are Release Team members, and I'm not entitled to force them to comply with the Social Contract; only the project as a whole is. (And yes, I hope your resolution won't pass Which is my resolution? You mean any of the options in which the developers get to decide what we do about Lenny? My hope is that whatever we decide, it is the result of the widest consensus possible, and that it is decided by the developers as a whole, not by a few selected ones. and I'll support the RM in their difficult job…) So do I. If the project grants them an exception to release Lenny (like we did for Sarge and Etch), I'll support that too. -- 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Discussion period: GR: DFSG violations in Lenny
On Tue, Nov 11, 2008 at 04:49:06PM +0100, Adeodato Simó wrote: I'm just making a point that Robert assumed the project shared his views and proposed a GR accordingly, instead of realizing he could be wrong, and thought of having a different GR first. If I'm proposing a GR, it is obviously with the hope that the project will agree with at least one of the options (remember, I proposed 3 very different options). Of course I don't know for sure. If we could read everyone's minds we wouldn't need a voting process after all. -- 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Discussion period: GR: DFSG violations in Lenny
On Tue, Nov 11, 2008 at 11:14:28PM +0100, Luk Claes wrote: Bas Wijnen wrote: On Tue, Nov 11, 2008 at 06:30:56PM +0100, Stefano Zacchiroli wrote: Can someone explain me why all these threads smell of gratuitous RM bashing? I hope I didn't take part in that. I'm very happy with the work done by the RMs. But that doesn't mean I want to give them the power to overrule the SC without a GR. Thanks Bas. I completely share your view. It's unfortunate that it's so poorly understood :-( Hmm, it's not us that uploaded the packages that broke the SC without a GR, it's not us that accepted these packages into the archive, it's not us alone that tolerated these without searching and filing bugs for the issues till the release was near, it's not us alone that did wait to start fixing the bugs till the release was near. It's only us that wanted it to be clear that if the bugs won't be fixed in time, we would not wait for the fixes before releasing... that's all the ignore tags tells. It's not your fault! Nobody (well, at least not me) is pretending that you're the source of this problem. However, that doesn't mean that the solution you want to apply is legitimate. -- 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Discussion period: GR: DFSG violations in Lenny
On Tue, Nov 11, 2008 at 07:42:47PM +0100, Johannes Wiedersich wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robert Millan wrote: If the project as a whole determines that the Release Team is empowered to make exceptions to SC #1 as they see fit, I would accept it [1]. Please stop repeating in an endless loop that the Release Team must focus on SC #1, while you are ignoring SC #4. As you wish. Instead of repeating myself, I will refer you to the mail in which I already replied to the same argument: http://lists.debian.org/debian-vote/2008/11/msg00039.html -- 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: on firmware (possible proposal)
Hi Peter, As much as I respect the legitimacy of your proposal, I think it is overkill to use a GR for that. Let me explain... On Wed, Nov 12, 2008 at 12:14:10PM +0100, Peter Palfrader wrote: By excluding such firmware from Debian we exclude | users that require such devices from installing our operating system, or | make it unnecessarily hard for them. This is not necessarily so. I believe that not excluding those users is precisely the reason we have SC #4 and SC #5 (and it is hard to justify those sections without this reason). Though, it may be true incidentally that we're making it unnecessarily hard for them. But there's nothing in our Social Contract that requires it to be hard, and you don't need a GR to change that. For example, if you want to install Debian on an NSLU, the only difficulty is finding the unofficial D-I images that include non-free firmware. And even that can be improved. They could be linked from the main website, and integrated with our infrastructure, much like we do for non-free, as long as we make it clear they're not officially Debian. -- 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DFSG violations in Lenny: new proposal
On Mon, Nov 10, 2008 at 10:23:26PM +, Matthew Johnson wrote: And that if we release now, the glibc code which we ship will be free shortly, without having to update stable, whereas the code shipped in the kernel won't be free in Lenny, however long we wait (because the solution is to remove/replace it) Usually true, but not always so. See #494010. Which is taking surprisingly long to be fixed. Makes me wonder what best effort truly means... -- 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Discussion period: GR: DFSG violations in Lenny
On Mon, Nov 10, 2008 at 08:01:02PM +, Stephen Gran wrote: I have to admit that I'm a bit curious how you justify needing a 3:1 supermajority to update a Packages file, but not to have the software in question served in the first place. The basic difference is that in one case it is the result of an unintended mistake [1], and in the other it is the result of known, willfull infringement of the Social Contract. It is in fact so clear, that we have a state in the BTS for bugs that are known to violate the DFSG and nevertheless intentionally ignored by the Release Team (lenny-ignore tag). [1] e.g. FTP masters not finding a specific violation during routine inspection [2], or package maintainers uploading new upstream versions that introduce new violations. [2] or finding and ignoring them, in which case this *is* a serious problem, not an example that can be used to justify more of the same. -- 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Call for seconds: DFSG violations in Lenny
On Mon, Nov 10, 2008 at 05:47:59PM +0100, Johannes Wiedersich wrote: With binary blobs inside or outside of debian, my computer will run just the same. It's just that outside main it won't be supported by debian -- at least not officially. It will be harder to install, as well. I think I said this before, but I don't mind repeating it ad nauseam ;-) There's no reason a modified version of Debian that includes non-free blobs needs to be harder to install or harder to find. Take, for example, the NSLU builds which include non-free firmware. They are in fact better maintained for NSLU hardware than official builds, since almost nobody uses pure Debian on a NSLU (network requires a USB dongle). Whether it's harder to install or not, it depends on you. We don't have a foundation document saying it must be. -- 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Call for seconds: DFSG violations in Lenny
On Mon, Nov 03, 2008 at 05:57:04PM +0100, Andreas Barth wrote: To give an example, I can remember well that during release of Sarge, we noticed on Saturday (that was while already the cd images were partially done) that the upgrade of sendmail will stop delivering any mails in the queue, but due to the options we had (either skip the release for at least another week, or deliver this version of sendmail and document it in the release notes) we decided to not stop the release. Such things can happen with any part of the release policy, and I think that's the adequate behaviour. You're mixing unrelated things. We don't promise to our users that Debian is 100% bug-free. We just try and do our best. On the other hand, we _do_ promise to our users that Debian is 100% free. If you're not comfortable with keeping this promise, the appropiate procedure is seeking the approval of the project, like was done for etch. But so far you haven't. And you stated your intent to release lenny with SC violations that the project hasn't approved. That is the whole reason I care about this. I don't really feel strongly about whether we should make an exception or not, as long as it is the result of consensus and is endorsed by the majority of the project, not by a few selected ones. Yeah, I really mean what I said. If you don't believe me, check what I voted last time: http://www.debian.org/vote/2006/vote_007_tally.txt You'll see that I'm not the radical zealot some try to present me as. Proof is written. -- 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Call for seconds: DFSG violations in Lenny
On Mon, Nov 03, 2008 at 05:57:04PM +0100, Andreas Barth wrote: | Debian's priorities are our users and free software. We don't trade them | against each other. I believe this phrase invalidates SC #1. - If this is so, why is it not explicit? - If it is not, what is, in your judgement, the correct interpretation of SC #1? | We as Developers at large continue to trust our release team to follow | all these goals, and therefor encourage them to continue making | case-by-case-decisions as they consider fit, and if necessary | authorize these decisions. What does the word continue mean in this phrase? Are you trying to imply that the release team is _already_ empowered to make decisions that override SC #1? - If you are, why is it not explicit? - If you're not, then please remove the continue from that phrase. -- 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Call for seconds: post-Lenny enforceability of DFSG violations
On Wed, Oct 29, 2008 at 10:34:15PM +0100, Thomas Viehmann wrote: As you seem to have conceded (for the purposes of this resolution) to seeing the DFSG-violations fixed post-Lenny and with the linux-2.6 (with Ben's work) and hopefully also glibc and portmap (now that Sun people seem to be interested in looking for ways to help) being on a good way, maybe it would be best to bring this up again should things not be fixed, say, 2 months after the lenny release? Hi Thomas, I appreciate the conciliatory tone of your message, but I think you've missunderstood my concerns. The position I'm trying to defend is very simple: We have the Social Contract for a reason, it is our promise to the free software community. And if the Release Team (or any team) feels we can't stand to our promises, and needs to override them somehow, this _must_ be done with the endorsement of the project, not because a few, chosen ones, decide it unilaterally. Whether the project decides that we need an exception that overrides SC #1 for the Nth time or not, that's a secondary problem as far as I'm concerned. -- 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Call for seconds: DFSG violations in Lenny
On Mon, Nov 03, 2008 at 05:57:04PM +0100, Andreas Barth wrote: Perhaps replace it with delay Lenny indefinitly. This indefinitely is only so because of the technical requisites that have been decided by the Linux maintainers and by the release team. That is, that DFSG violations can't be fixed unless a working blob is packaged in non-free. There's nothing in the Social Contract or in this GR that mandates the release is post-poned for a long time. That would only be the consequence of a technical decision that is not yet taken. When you take it, it will be your own responsibility, not that of the project. Therefore, it doesn't belong in this GR to assert that Lenny will be delayed indefinitely. -- 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Consequences for the lenny release, was: Call for seconds: DFSG violations in Lenny
On Thu, Oct 30, 2008 at 12:57:49PM +0100, Reinhard Tartler wrote: AFAIUI and have if Robert's option 2 (allow Lenny to release with proprietary firmware) gets voted over option 3 (allow Lenny to release with any DFSG violations) all these issues have the potential to delay the lenny release until they are fixed. Is my understanding correct? Yes (except that option 2 is not more Robert's than option 3 is). -- 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Call for seconds: DFSG violations in Lenny
Hi, Here's a revised set of options with a number of changes relative to the first one: - Added option 1 / point 2 - Remove confusing sentence from options 2,3 / point 4 - Replaced option 2 / point 2 (written by Manoj Srivastava) - Simplify option 2 / point 4 not to assert that firmware must be in udebs (suggested by Holger Levsen) - Added to the best of our knowledge phrase to each option (suggested by Peter Samuelson and Hubert Chathi) - Typo fix (spotted by Frans Pop) I hereby propose this General Resolution: Option 1 (reaffirm the Social Contract) ~~~ 1. We affirm that our Priorities are our users and the free software community (Social Contract #4); 2. We acknowledge that we promised to deliver a 100% free operating system (Social Contract #1); 3. 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). Option 2 (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. (Since this option overrides the SC, I believe it would require 3:1 majority) Option 3 (allow Lenny to release with DFSG violations) ~~ 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 on DFSG compliance issues; however, they are not yet finally sorted out; 3. We assure the community that there will be no regressions in the progress made for freedom in the packages 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 fixing of DFSG violations as a best-effort process. (Since this option overrides the SC, I believe it would require 3:1 majority) -- 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. signature.asc Description: Digital signature
Re: Call for seconds: post-Lenny enforceability of DFSG violations
On Tue, Oct 28, 2008 at 11:27:24AM -0500, Peter Samuelson wrote: Is this intended to bypass the NEW process currently done by ftpmasters any time something is added to non-free? I suspect the ftpmasters will not be enthusiastic about complying with a GR that requires a mechanism to bypass the NEW queue. Not to say we can't pass the GR, but I would much rather see something that does not step on those toes. Hi Peter, ACK about your concerns (and the ones pointed by others, which are roughly the same). Do you have any suggestion on what would be a better approach? -- 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Call for seconds - DC concept (was: Possible amendment for Debian Contributors concept)
On Wed, Oct 29, 2008 at 09:01:51PM +0100, Peter Palfrader wrote: I hereby propose this alternate option/amendment and am asking for seconds. | The Debian Project recognizes that many contributors to the project are not | working withing established frameworks of Debian and thus are not provided by | the project with as much help as might be possible, useful or required, nor | opportunities to join the project. | | We thank Joerg Jaspert for exploring ideas on how to involve contributors more | closely with and within the project so that they can get both recognition and | the necessary tools to do their work. | | We realize that the proposal posted to the debian-devel-announce mailinglist is | not yet finalized and may not have the support of a large part of our | community. We invite the DAM and all the contributors to further develop their | ideas in close coordination with other members of the project, and to present a | new and improved proposal on the project's mailinglists in the future. | | Significant changes should only be implemented after consensus within | the project at large has been reached, or when decided by a general | resolution. Seconded. -- 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. signature.asc Description: Digital signature
Re: Call for seconds: DFSG violations in Lenny
On Mon, Oct 27, 2008 at 10:54:35PM +0200, Holger Levsen wrote: Hi, On Monday 27 October 2008 20:36, Robert Millan wrote: - 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 in udebs as long as it is necessary for installation (like all udebs) *and* - firmware included in the kernel itself as part of Debian Lenny as long as we are legally allowed to do so, and the firmware is distributed upstream under a license that complies with the DFSG. Aeh, if we'd vote on this, would that mean that we could deliver the firmware in udebs but not in debs? Not all debian installers use udebs, fai for example doesnt and I'm sure there are others... How about making it less specific, like: ... deliver firmware as part of Debian Lenny as long as ... -- 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Call for seconds: post-Lenny enforceability of DFSG violations
On Wed, Oct 29, 2008 at 05:09:58PM +0200, Kalle Kivimaa wrote: Robert Millan [EMAIL PROTECTED] writes: ACK about your concerns (and the ones pointed by others, which are roughly the same). Do you have any suggestion on what would be a better approach? How about dropping the GR and continuing with the current process, where anybody can file a RC bug against a non-DFSG package, maintainer (or during the release process, anybody) makes a new package release moving the package to contrib/non-free, and the ftpmasters do the move when they get around to it? Alternatively, you can always provide patches to dak where the priority of the semi-automatically moved packages is raised to the top of the NEW processing list and a note is shown to the ftpmaster doing the processing (meaning an almost automatic Apply override reflex) - remember to check that the source tar.gz is identical to the existing one, to make it easier to trust that there's nothing non-distributable trying to sneak in. I don't think NEW is the problem here. The question, from my POV, is that as developer I don't feel I am empowered to move a package to non-free without permission from the maintainers, even if it is obviously infringing on the Social Contract. Such kind of controversial actions are IMO sometimes necessary, but should never be done without consensus and endorsement from the project as a whole. To me, the purpose of this GR is to sanction a procedure that would otherwise have a doubtful legitimacy. And if this involves overseeing by the ftp team, so be it. I have no reason to believe they would actively obstruct a decision that has been endorsed by the majority of the project. -- 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Call for seconds: post-Lenny enforceability of DFSG violations
On Wed, Oct 29, 2008 at 12:35:36PM -0500, Peter Samuelson wrote: [me] Is this intended to bypass the NEW process currently done by ftpmasters any time something is added to non-free? [Robert Millan] ACK about your concerns (and the ones pointed by others, which are roughly the same). Do you have any suggestion on what would be a better approach? Well, unless you explicitly want to undermine the authority of ftpmaster over NEW processing, which I do not advise[*], I would say ...may be done by any developer, subject to verification by the ftpmaster role. Sounds fine. Although I would use different wording; I think the strict definition of ftpmaster doesn't match with whoever processes NEW. How about: ... may be performed by any of the developers (however, moving packages in distributions other than unstable or experimental may still require approval by the corresponding Release Team and/or by the FTP Archive 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [DRAFT] resolving DFSG violations
On Sun, Oct 26, 2008 at 07:27:24PM -0700, Jeff Carr wrote: On Sat, Oct 25, 2008 at 11:19, Robert Millan [EMAIL PROTECTED] wrote: Is there a reason why those interested in supporting blob-dependant hardware can't make a release that includes those blobs? As per SC #1 they can't refer to it as Debian, but they can use the project's resources to build and Because you are discriminating against hardware manufacturers if they chose to not put flash,cpld,etc chips onboard. You aren't helping freedom in any way. All you are doing is just pretending it doesn't exist. Pretending everything is fine by hiding anything not free in a black hole doesn't help freedom. Especially since you then banish from debian anyone that tries to expose the non-free stuff you've been trying to hide. Let me understand your position: only buy hardware where the manufacturer hides the firmware on an onboard flash otherwise you can't run debian. This has nothing to do with the core problem, which is we're telling our users that these blobs are free software (i.e. we're liing to them), and in some cases even exposing them to legal risk by having them accept the GPL when they can't comply with it (since they don't have the source code). Nevertheless, I'll give you my personal opinion. When that software is in a ROM, what prevents the user from modifiing it is not a matter of freedom, it's purely technical. Understanding how the device works (including, but not limited to, by reading firmware) is IMO a freedom issue, but it has nothing to do with Debian. You might as well consider it a freedom issue if you can't read the source code in your NAS, but just because a Debian box is connected to the same network it doesn't mean it's Debian's bussiness. When that software is in writable memory, it means the vendor retained its ability to modify it, but it didn't want others to have this ability. Therefore, although they have to ship the firmware, they rely on obfuscation to prevent end users from having those rights. This has more implications that it might seem. It turns out, that they'll tend to consider the unified firmware+driver combo a derived product, and the interface between them is blurred. They might adjust this interface anytime they want, and it's very likely they'll find it useful to restrain our freedom by moving complexity from the free side to the obfuscated one (Intel has likely done this with the iwl driver). Also, your argument assumes that vendors are uncapable of fixing the problem, and only able to move it from one way to the other. I disagree; I think pressure can push them in the right direction, which is telling users how their own devices work. -- 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Call for seconds: Suspension of the changes of the Project's membership procedures.
On Mon, Oct 27, 2008 at 03:30:02PM +0100, Joerg Jaspert wrote: On 11551 March 1977, Charles Plessy wrote: I would be more than happy if a discussion between the different poles of opinions would start, with focus on convergence. This GR effectively blocks any [motivation to have a] discussion. Hi Joerg, I read your recent blog entry on the topic, and I think you make interesting points defending your proposal. From my perspective (i.e. the perspective of someone who isn't very familiarized with the areas of Debian affected by your proposed changes), the whole thing looked confusing, and I didn't know (still don't!) whether I would support it or not. So, I totally support you in defending your proposal, but I think it could've been a lot better if those points were made _before_ the announcement. The reason I seconded this GR is because, one way or the other, I think a healthy reform is one that is endorsed by the majority of developers [1] (and if the proposed vote doesn't pass, that is a form of endorsement too). I'd like to encourage you to bring this discussion forward, and push for your proposed changes to gain acceptance. My opinion, right now, is that I have no clue about what they imply, and will most likely not vote or send a no-op ballot. [1] or members, or people with voting rights, whatever.. -- 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Call for seconds: Suspension of the changes of the Project's membership procedures.
On Mon, Oct 27, 2008 at 10:42:08AM +0100, Lucas Nussbaum wrote: Should we add something to the GR to address this problem? Or simply explain the reasoning behind the GR by different means, during the vote? I think it's perfectly reasonable to explain our respective POVs separately (and in fact I just did). -- 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Call for seconds: Revised ballot
On Mon, Oct 27, 2008 at 10:27:28AM +, MJ Ray wrote: Debian Project Secretary [EMAIL PROTECTED] wrote: This is an interesting point. It all depends on the definition of what a resolution is, and whether a resolution can have multiple options, or not. I consider a resolution to be a formal expression of the opinion or will of an official body or a public assembly, adopted by vote. See §A.1 Proposal and §A.1 Discussion and Amendment. [...] While I am tentatively ruling this so, I am still open to feedback, and I would appreciate hearing from anyone who thinks my determination on this issue is at fault, in which case we shall discuss this further. Please would you regard each option as a resolution and allow people to second all of them, or some subset of them if they wish? I understand from the Secretary's explanation that this is so, and will send a new mail with all of them, asking seconders to pick a subset if they want. -- 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Call for seconds: Revised ballot
On Sun, Oct 26, 2008 at 11:07:10AM +0100, Robert Millan wrote: On Sun, Oct 26, 2008 at 10:05:34AM +0200, Holger Levsen wrote: Moin, On Saturday 25 October 2008 20:31, Robert Millan wrote: When ever a package in Debian is found to have been violating the DFSG for 60 days or more besides that this proposal still has at least the problem of who determines how (that the DFSG has been violated) I have been thinking that I would be much more comfortable with it, if the timeline would be 120 or 180 days instead of 60. (Rationale: legalise moves much slower than code.) But probably thats a minor point too. Fine with me. What does everyone else think? In particular, would any of the people who object to this GR be less concerned if the time was increased? Since noone else replied, I'll pick 180. If someone feels strongly enough that the number should be different, they can send their own proposal, of course. -- 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Call for seconds: Revised ballot
On Mon, Oct 27, 2008 at 04:07:41PM +0100, Robert Millan wrote: On Sun, Oct 26, 2008 at 11:07:10AM +0100, Robert Millan wrote: On Sun, Oct 26, 2008 at 10:05:34AM +0200, Holger Levsen wrote: Moin, On Saturday 25 October 2008 20:31, Robert Millan wrote: When ever a package in Debian is found to have been violating the DFSG for 60 days or more besides that this proposal still has at least the problem of who determines how (that the DFSG has been violated) I have been thinking that I would be much more comfortable with it, if the timeline would be 120 or 180 days instead of 60. (Rationale: legalise moves much slower than code.) But probably thats a minor point too. Fine with me. What does everyone else think? In particular, would any of the people who object to this GR be less concerned if the time was increased? Since noone else replied, I'll pick 180. If someone feels strongly enough that the number should be different, they can send their own proposal, of course. Now that I think, this means the options that only included my proposed reform would not have the effect of preventing Lenny from releasing with non-free code. Since sorting that out would require even more complexity in the ballot, I will propose a GR that only deals with what we do about Lenny, and re-send my reform proposal later on. This also makes it easier for others to select what they want to second. -- 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Call for seconds: DFSG violations in Lenny
I propose the following General Resolution. If you wish to second only one or two of the options, please indicate which ones clearly, so the Secretary can account them separately. Option 1 (reaffirm the Social Contract) ~~~ 1. We affirm that our Priorities are our users and the free software community (Social Contract #4); 2. 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. Option 2 (allow Lenny to release with propietary 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; 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 Etch release in Lenny 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 in udebs as long as it is necessary for installation (like all udebs), and firmware included in the kernel itself as part of Debian Lenny, as long as we are legally allowed to do so, and the firmware is distributed upstream under a license that complies with the DFSG. (Since this option overrides the SC, I believe it would require 3:1 majority) Option 3 (allow Lenny to release with any DFSG violations) ~~ 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 on DFSG compliance issues; however, they are not yet finally sorted out; 3. We assure the community that there will be no regressions in the progress made for freedom in the packages distributed by Debian relative to the Etch release in Lenny 4. We give priority to the timely release of Lenny over sorting every bit out; for this reason, we will treat fixing of DFSG violations as a best-effort process. (Since this option overrides the SC, I believe it would require 3:1 majority) -- 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. signature.asc Description: Digital signature
Call for seconds: post-Lenny enforceability of DFSG violations
Hi, I propose the following General Resolution. If you wish to second only one or two of the options, please indicate which ones clearly, so the Secretary can account them separately. Note: Both options are only concerned with resolving the DFSG enforceability problem in long-term. Therefore they don't take any effect untill after Lenny has been released (I just proposed a separate GR for deciding how we deal with this problem in Lenny). Option 1 (set an upper limit) ~ The developers resolve that the following rule shall take effect inmediately after Lenny is released: When ever a package in Debian is found to have been violating the DFSG for 180 days or more, and none of the solutions that have been implemented (if any) is considered suitable by the maintainers, the package must be moved from Debian (main suite) to the Non-free repository (non-free suite). The action of moving it may be performed by any of the developers (however, moving packages in distributions other than unstable or experimental may still require approval by the corresponding Release Team). When this happens, any known DFSG violation in the package must be resolved before the package can be moved back into Debian. Option 2 (set an upper limit, make this part of the SC) ~~~ The developers resolve that, inmediately after Lenny is released, the Social Contract shall be ammended as follows: --- social_contract.wml 22 Nov 2007 03:15:39 - 1.23 +++ social_contract.wml 27 Oct 2008 15:52:14 - @@ -31,6 +31,24 @@ the free software community as the basis free and non-free works on Debian. We will never make the system require the use of a non-free component. /p + p + In order to ensure continued compliance with this promise, the + following rule is to be followed: + /p + p + When ever a package in Debian is found to have been violating the + Debian Free Software Guidelines/cite/q for 180 days or more, and + none of the solutions that have been implemented (if any) is considered + suitable by the maintainers, the package must be moved from Debian + (main suite) to the Non-free repository (non-free suite). + /p + p + The action of moving it may be performed by any of the developers (however, + moving packages in distributions other than unstable or experimental may + still require approval by the corresponding Release Team). When this happens, + any known DFSG violation in the package must be resolved before the package + can be moved back into Debian. + /p /li listrongWe will give back to the free software community/strong p (Since this option ammends the SC, I believe it would require 3:1 majority) -- 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. signature.asc Description: Digital signature
Re: Call for seconds: DFSG violations in Lenny
On Mon, Oct 27, 2008 at 10:55:56AM -0500, Manoj Srivastava wrote: On Mon, Oct 27 2008, Robert Millan wrote: Option 2 (allow Lenny to release with propietary 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; 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 Etch release in Lenny 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 in udebs as long as it is necessary for installation (like all udebs), and firmware included in the kernel itself as part of Debian Lenny, as long as we are legally allowed to do so, and the firmware is distributed upstream under a license that complies with the DFSG. (Since this option overrides the SC, I believe it would require 3:1 majority) While I have seconded this proposal, how about a change in wording: , | 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 | | 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 in udebs as | long as it is necessary for installation (like all udebs), and | firmware included in the kernel itself as part of Debian Lenny, as | long as we are legally allowed to do so, and the firmware is | distributed upstream under a license that complies with the DFSG. ` The changes are just to item 2., which is expanded to explain a little more about the progress we actually made in the kernel, and also to explain these are new issues (not something we have been ignoring for years). I would like to propose this as a formal amendment to the proposal, and hope it would be acceptable to the proposer. I accept and second it. -- 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. signature.asc Description: Digital signature
Re: Call for seconds: DFSG violations in Lenny
On Mon, Oct 27, 2008 at 08:22:57PM +0100, Peter Palfrader wrote: On Mon, 27 Oct 2008, Robert Millan wrote: 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 in udebs as long as it is necessary for installation (like all udebs), and firmware included in the kernel itself as part of Debian Lenny, as long as we are legally allowed to do so, and the firmware is distributed upstream under a license that complies with the DFSG. Sorry, I fail to parse this. You lost me somewhere around 'like all udebs'. Could you please explain this in something that does not try to compete with german sentences in length? :) It's the same from http://www.debian.org/vote/2006/vote_007 with s/Etch/Lenny/g. A decomposition would be: - 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 in udebs as long as it is necessary for installation (like all udebs) *and* - firmware included in the kernel itself as part of Debian Lenny as long as we are legally allowed to do so, and the firmware is distributed upstream under a license that complies with the DFSG. (Also, isn't we allow sourceless firmware ... as long as the license complies with the DFSG a no-op?) The license for a sourceless blob can be GPL or BSD, which are licenses that comply with the DFSG, or it could be any sort of non-free license (including lack of license). Of course, the code itself wouldn't comply with DFSG #2, but the license would. Anyway, this specific text is already tested and known to work so I think this proves it is solid :-) -- 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Call for seconds: DFSG violations in Lenny
On Mon, Oct 27, 2008 at 08:36:06PM +0100, Robert Millan wrote: (Also, isn't we allow sourceless firmware ... as long as the license complies with the DFSG a no-op?) The license for a sourceless blob can be GPL or BSD, which are licenses that comply with the DFSG, or it could be any sort of non-free license (including lack of license). Of course, the code itself wouldn't comply with DFSG #2, but the license would. Anyway, this specific text is already tested and known to work so I think this proves it is solid :-) Though, if the as long as the license complies with the DFSG doesn't really have any effect (other than what's already covered by we are legally allowed to do so), I think it is confusing and shouldn't be in the text. I propose the following alternatative to Option 2 (removes last sentence): Option 2 (allow Lenny to release with propietary 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; 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 Etch release in Lenny 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 in udebs as long as it is necessary for installation (like all udebs), and firmware included in the kernel itself as part of Debian Lenny, as long as we are legally allowed to do so. (Since this option overrides the SC, I believe it would require 3:1 majority) -- 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. signature.asc Description: Digital signature
Re: Call for seconds: DFSG violations in Lenny
On Mon, Oct 27, 2008 at 09:04:33PM +0100, Robert Millan wrote: I propose the following alternatative to Option 2 (removes last sentence): Or rather, I propose the following alternative which incorporates Manoj's rewritten #2 (in addition to removing the last sentence in #4): Option 2 (allow Lenny to release with propietary 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 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 in udebs as long as it is necessary for installation (like all udebs), and firmware included in the kernel itself as part of Debian Lenny, as long as we are legally allowed to do so. (Since this option overrides the SC, I believe it would require 3:1 majority) -- 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. signature.asc Description: Digital signature
Re: Call for seconds: Revised ballot
On Sun, Oct 26, 2008 at 10:05:34AM +0200, Holger Levsen wrote: Moin, On Saturday 25 October 2008 20:31, Robert Millan wrote: When ever a package in Debian is found to have been violating the DFSG for 60 days or more besides that this proposal still has at least the problem of who determines how (that the DFSG has been violated) I have been thinking that I would be much more comfortable with it, if the timeline would be 120 or 180 days instead of 60. (Rationale: legalise moves much slower than code.) But probably thats a minor point too. Fine with me. What does everyone else think? In particular, would any of the people who object to this GR be less concerned if the time was increased? -- 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposed amendment: Resolving DFSG violations
On Sun, Oct 26, 2008 at 11:32:52AM +0100, Josselin Mouette wrote: Le samedi 25 octobre 2008 à 20:26 +0200, Robert Millan a écrit : I'd appreciate if you don't use a GR procedure for that, though, it makes us look like a bunch of clowns. it makes us look like a bunch of clowns. look like a bunch of clowns a bunch of clowns clowns -- Robert Millan For those who didn't get Josselin's witty remark, this happens because I dared to complain that my words were being missrepresented by Steve Langasek on IRC, pretending that I said something I never did. 21:22 vorlon oh yes, that's right, *sending chocolate* makes us look like a bunch of clowns 21:34 nyu vorlon: don't put words in my mouth, thanks 21:35 vorlon nyu: what should I put in your mouth? Let this serve as a warning for anyone who dares to complain that mr Langasek is defamating him. P.S.: I never thought we'd get so low. Sad thing, really. -- 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. signature.asc Description: Digital signature
Re: Call for seconds: Resolving DFSG violations
On Sun, Oct 26, 2008 at 02:00:27PM -0500, Peter Samuelson wrote: [Robert Millan] + p + When ever a package in Debian is found to have been violating the + Debian Free Software Guidelines/cite/q for 60 days or more, and + none of the solutions that have been implemented (if any) is considered + suitable by the maintainers, the package must be moved from Debian + (main suite) to the Non-free repository (non-free suite). + /p It seems pretty impractical to allow the release of lenny, as some of the options do, yet force/authorize somebody to immediately, upon lenny's release, fix the linux-2.6 situation _in lenny_. Since of course we've known about linux-2.6 for far longer than 60 (or 180) days. For that matter, some of these options have the curious effect of allowing the lenny release while simultaneously authorizing developers to fix the etch and sarge kernels. Not that that part is enforceable, I'm pretty sure the RMs wouldn't actually allow that to happen. Now if you change the wording to exempt our published releases from this entire process, so that it applies only to unstable and testing, it would be a lot easier to support. Hi, Note that (after someone else pointed out the same concern) I included wording to avoid this: however, moving packages in the \stable\ distribution may still require approval by the Release Team for \stable\ Perhaps we should also explicitly exclude oldstable? But what about versions before oldstable then? Or we could make it inclusive and list only unstable and experimental. -- 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [DRAFT] resolving DFSG violations
On Sat, Oct 25, 2008 at 02:36:06PM +0100, Steve McIntyre wrote: we'll be more likely to be push many of them towards installing other (even less free) systems instead. Is there a reason why those interested in supporting blob-dependant hardware can't make a release that includes those blobs? As per SC #1 they can't refer to it as Debian, but they can use the project's resources to build and distribute it, and there can be healthy interaction between both codebases. What I mean to say, is that there's no need for end users to jump from one edge to the other. A middle ground can be useful too. -- 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposed amendment: Resolving DFSG violations
On Sat, Oct 25, 2008 at 02:46:47AM +0100, Steve McIntyre wrote: On Fri, Oct 24, 2008 at 06:40:14PM +0200, Thomas Viehmann wrote: Hi, I propose to amend the Robert's resolution by adding the following choice --- The Debian project, recognizing that bugs do not fix themselves, applauds Ben Hutchings's efforts to remove non-DFSG-conformant bits from the linux-2.6 package in a way that is still making users a priority. It instructs the project leader to authorize spending of Debian funds to send a box of chocolates to Ben. --- I've made a point of telling people that I think Ben is about the only one who deserves any praise for what's been happening on the kernel front. I'll happily help to push beer/chocolate/$foo at him as a thank you for that, regardless of any vote here. I belive that Robert's resolution is a waste of time Seconded. As a matter of fact, if you want to send chocolate to Ben I second that too. I'd appreciate if you don't use a GR procedure for that, though, it makes us look like a bunch of clowns. -- 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Call for seconds: Revised ballot
suite). + /p + p + The action of moving it may be performed by any of the developers (however, + moving packages in the stable distribution may still require approval by + the Release Team for stable). When this happens, any known DFSG violation + in the package must be resolved before the package can be moved back into + Debian. + /p /li listrongWe will give back to the free software community/strong p In addition: 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 on DFSG compliance issues; however, they are not yet finally sorted out; 3. We assure the community that there will be no regressions in the progress made for freedom in the packages distributed by Debian relative to the Etch release in Lenny 4. We give priority to the timely release of Lenny over sorting every bit out; for this reason, we will treat fixing of DFSG violations as a best-effort process. (Since this option ammends the SC, I believe it would require 3:1 majority) Option 7 (exception for lenny, no reform) ~ 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 Etch release in Lenny 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 in udebs as long as it is necessary for installation (like all udebs), and firmware included in the kernel itself as part of Debian Lenny, as long as we are legally allowed to do so, and the firmware is distributed upstream under a license that complies with the DFSG. (Since this option overrides the SC, I believe it would require 3:1 majority) Option 8 (reaffirm the Social Contract) ~~~ 1. We affirm that our Priorities are our users and the free software community (Social Contract #4); 2. Given that we have known for two previous releases that we have non-free bits in kernel sources, 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. -- 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. signature.asc Description: Digital signature
Re: Call for seconds: Suspension of the changes of the Project's membership procedures.
On Sat, Oct 25, 2008 at 10:10:55AM +0900, Charles Plessy wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - Following the announcement of the 22nd of October on the debian-devel-announce mailing list (Message-id: [EMAIL PROTECTED]) about Developer Status; - Given the importance of defining how the Project accepts new members; - Because of the strong opposition to the method used to prepare, discuss and decide the announced changes, and without judging their validity; - In accordance with the paragraphs 4.1(3) and 4.2(2.2) of the Constitution; The Debian Project, by way of a general resolution of its developers, decides: The changes announced the 22nd of October on the debian-devel-announce mailing list (Message-id: [EMAIL PROTECTED]) are suspended [§4.1(3)]. This suspension is effective immediately [§4.2(2.2)]. In addition, the developers make the following statement: The delegates of the Project leader are asked to not take decisions that are not consensual about the membership procedures of the Project, and to let these procedures change by way of a general resolution if no consensus can be reached. Seconded. -- 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. signature.asc Description: Digital signature
Call for seconds: Resolving DFSG violations
approval by + the Release Team for stable). When this happens, any known DFSG violation + in the package must be resolved before the package can be moved back into + Debian. + /p /li listrongWe will give back to the free software community/strong p In addition: 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 on DFSG compliance issues; however, they are not yet finally sorted out; 3. We assure the community that there will be no regressions in the progress made for freedom in the packages distributed by Debian relative to the Etch release in Lenny 4. We give priority to the timely release of Lenny over sorting every bit out; for this reason, we will treat fixing of DFSG violations as a best-effort process. (Since this option ammends the SC, I believe it would require 3:1 majority) -- 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. signature.asc Description: Digital signature
