Re: call for seconds: on firmware
* Manoj Srivastava [Sat, 15 Nov 2008 17:38:56 -0600]: That does not seem to make sense. Either you have 'none of this non-free crap in the archive ever' or you have 'the release team downgrades these bugs and includes non-free crap' Not both. Which is why they are on the same ballot. How does one vote, I want the Release Team to have freedom to use suite-ignore tags, plus I want to allow firmware in main independently of what the Release Team thinks? How does one vote, I want the Release Team to have freedom to use suite-ignore tags, plus I want Lenny not to be blocked by firmware issues even if the Release teams changes their mind and remove the lenny-ignore tags? Thanks, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org The pure and simple truth is rarely pure and never simple. -- Oscar Wilde -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
This one time, at band camp, Adeodato Simó said: * Manoj Srivastava [Sat, 15 Nov 2008 17:38:56 -0600]: That does not seem to make sense. Either you have 'none of this non-free crap in the archive ever' or you have 'the release team downgrades these bugs and includes non-free crap' Not both. Which is why they are on the same ballot. How does one vote, I want the Release Team to have freedom to use suite-ignore tags, plus I want to allow firmware in main independently of what the Release Team thinks? How does one vote, I want the Release Team to have freedom to use suite-ignore tags, plus I want Lenny not to be blocked by firmware issues even if the Release teams changes their mind and remove the lenny-ignore tags? Or the vote that I suspect would be a reasonably common one if the vote allowed it: I don't want firmware in main, but I want the Release Team to have the freedom to allow it for Lenny. Which was really the starting point of this whole round of proposals. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
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)
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. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: Call for seconds: DFSG violations in Lenny
Robert Millan wrote: 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. If you're sick of personal attacks, stop this bullshit and spend your time on something useful. Like fixing RC bugs so Lenny can be released SOON. You're wasting a lot of people's time here, time which could be spent on making Lenny the best release ever. The only thing you're doing is to make Lenny the release with the longest freeze time ever. 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. To start the same bullshit again for the next release, a few days before the release? *sigh* Bernd ... who will look for a different distribution to spend his time on, if Robert's proposals will pass the GR. -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 -- 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)
This one time, at band camp, Robert Millan said: 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. Your use of 'ad hominem' seems to imply that you think that I made the argument personal at a point when it was not personal. You told me that pcap output wouldn't tell _you_ anything, at which point you made the discussion about what was relevant to you. pcap output is in fact a relevant diagnostic tool for this, just as gdb or an oscilloscope are relevant diagnostic tools in their areas. Whether or not they're useful to you isn't all that interesting or even really my problem. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Further discussion ? None of the above ?
Le Sun, Nov 16, 2008 at 01:13:25PM +0100, Robert Millan a écrit : Instead of having a long, useless discussion on what Further discussion means, would it be possible to remove that option? Correct me if I am wrong, but I think for any interpretation of what Further Discussion would mean in this vote, there's an explicit option in the ballot. Hi Robert, we probably agree that the dicussion about Further discussion must be as short as possible. I am completely uncomfortable with the idea of a GR having decisionnal consequences even if all options are rejected. If it can help to cut the story short, I can propose yet another option: None of the above. The Project decides nothing. Interpretations of this result are personal opinions and are not binding to anyone. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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 12:13:25PM +, Robert Millan wrote: On Sun, Nov 16, 2008 at 08:54:17AM +0100, Stefano Zacchiroli wrote: Let me observe that the fact that several people here think is not authoritative. That said, I disagree with point (ii) of your interpretation: i Do we require source for firmware in main: Yes ii Do we allow the Release Team to ignore SC violation bugs: No iii What do we do for Lenny: Wait iV Do we modify foundation documents: No v Do we override foundation documentsNo it should rather be Yes: Instead of having a long, useless discussion on what Further discussion means, would it be possible to remove that option? Correct me if I am wrong, but I think for any interpretation of what Further Discussion would mean in this vote, there's an explicit option in the ballot. Further discussion means none of the ballot options seems right to me, I prefer we discuss this again. IOW it's the statu quo, it solves nothing, it means please draft a new ballot. I see no problem with such a meaning, it's always what it has meant. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpHMHlZedbOU.pgp Description: PGP signature
Re: call for seconds: on firmware (was: on firmware (possible proposal))
Hi, On Fri, Nov 14, 2008 at 09:12:25PM +0100, Peter Palfrader wrote: On Wed, 12 Nov 2008, Peter Palfrader wrote: I so didn't want to get into this discussion, but here goes anyway. I'm considering formally proposing this GR (option): I'm hereby proposing the following general resolution: | 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. Looking for seconds now. I'm hereby seconding this proposal. Regards, Patrick signature.asc Description: Digital signature
Re: call for seconds: on firmware
On Sun, Nov 16 2008, Stefano Zacchiroli wrote: On Sat, Nov 15, 2008 at 04:24:18PM -0800, Russ Allbery wrote: Hm, no, the impression that I got from this discussion that at least several people here think the result of Further discussion is: Let me observe that the fact that several people here think is not authoritative. That said, I disagree with point (ii) of your interpretation: i Do we require source for firmware in main: Yes ii Do we allow the Release Team to ignore SC violation bugs: No iii What do we do for Lenny: Wait iV Do we modify foundation documents: No v Do we override foundation documentsNo it should rather be Yes: ii Do we allow the Release Team to ignore SC violation bugs: Yes Rationale: with further discussion nothing changes. Today RMs are empowered, by delegation, to decide upon transitions and lenny-ignore tags. It will be the same tomorrow if further discussion wins. What they are not empowered to do is to decide to release with DFSG violations in main. If you think there is such a powere delegated to them, you need to show that these powers are there with the DPL in the first place, or that they belong to the RM. So, sure, they can ad whatever tags they wish to the BTS. But the release Lenny woth stuff the SC says we will not have in the Debian system, sorry, no. If people disagree with that, they can overrule delegates' decision as supported by our constitution. Err, it should not come to that, since they would be exceeding their authority in the first place (releasing something that the SC says Debian shall not). BTW, this is yet another hint that separate ballots would have been better, because we are implicitly calling for another GR in some special case, but unfortunately Dato's proposal to split ballots doesn't seem to have gained enough momentum. We can have a spearate vote on what to do post lenny, if people still want that. But currently, with the issue on how to go about releasing lenny, all these proposals are related. manoj -- 'Tis true, 'tis pity, and pity 'tis 'tis true. Poloniouius, in Willie the Shake's _Hamlet, Prince of Darkness_ Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- 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, Stephen Gran wrote: Or the vote that I suspect would be a reasonably common one if the vote allowed it: I don't want firmware in main, but I want the Release Team to have the freedom to allow it for Lenny. As far as the lenny release is concerned, how is this different from letting the RM's decide option? Either the GR decides, or the RM's decide, perhaps basing on how far above the furhter discussion the no firmware in main option is? Seems like either the GR says something definitive about firmware in main, or it delegates the decision to the RMs. Which the ballot allows. manoj somewhat confused -- We don't have to protect the environment -- the Second Coming is at hand. James Watt Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- 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, Adeodato Simó wrote: * Manoj Srivastava [Sat, 15 Nov 2008 17:38:56 -0600]: That does not seem to make sense. Either you have 'none of this non-free crap in the archive ever' or you have 'the release team downgrades these bugs and includes non-free crap' Not both. Which is why they are on the same ballot. How does one vote, I want the Release Team to have freedom to use suite-ignore tags, plus I want to allow firmware in main independently of what the Release Team thinks? At this point, I think we should decide about Lenny. So the vote should be to allow firmware in main. We can then have another vote just about changing the SC to allow the rlease team to make Debian non-free when they so decide, separately. If you think such an option should be on the current ballot, please propose one, and call for seconds. So I suppose this is me saying there could be multiple votes, if sponsors so desire, but the release lenny vote has all the options on the ballot, since releasing Lenny can happen via any of these mechanisms. How does one vote, I want the Release Team to have freedom to use suite-ignore tags, plus I want Lenny not to be blocked by firmware issues even if the Release teams changes their mind and remove the lenny-ignore tags? So currently vote for what you want to happen for Lenny. We can have a different vote about changing the SC and the constitution later. I think we can be reasonably sure that the current spate of discussions is about releasing Lenny. For this action, any of the ballot options will have a distinct decision; and the ballot should have _all_ the possible courses of action for that decision. If, later, people want to try out changes to the SC/constitution, they can have their separate vote. Since we are in a hurry to release Lenny, the what to do with Lenny vote comes first. I'll be happy to run independent votes on any issue after that decision has been taken. I also think that the Lenny release hanging over our heads is tainting the discussion of the other options, but that is just my personal opinion. manoj -- It is easier to fight for principles than to live up to them. Alfred Adler Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
Le samedi 15 novembre 2008 à 19:39 -0600, Manoj Srivastava a écrit : Hm, no, the impression that I got from this discussion that at least several people here think the result of Further discussion is: i Do we require source for firmware in main: Yes ii Do we allow the Release Team to ignore SC violation bugs: No iii What do we do for Lenny: Wait iV Do we modify foundation documents: No v Do we override foundation documentsNo and that seems to be consistent with what Manoj is ruling about overrides of the SC. This is my reading, yes. As far as I see, the SC is pretty clear, and leaves us no other option. It seems very convenient to decide at the same time that further discussion equals proposition #1 and that other propositions require 3:1 majority. This means that, if proposition #1 fails to gather 1:1 majority and other propositions fail to gather 3:1 (a very likely outcome), you get to decide that proposition #1 applies anyway. It makes me feel uneasy. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Call for seconds: DFSG violations in Lenny
- Robert Millan [EMAIL PROTECTED] wrote: 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) This seems rational and pragmatic. I second this proposal. -- Ean Schuessler, CTO Brainfood.com [EMAIL PROTECTED] - http://www.brainfood.com - 214-720-0700 x 315 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Call for seconds: DFSG violations in Lenny
- Bas Wijnen [EMAIL PROTECTED] wrote: So what's the problem? We want to provide a 100% free software distribution. Appearantly we currently can't do that. We're far on the way, but not there yet. We may have thought we were there, but we were wrong. So indeed, people currently running Debian don't run a 100% free software system. The simple obvious thing to do, seems to be (to me at least) to remove non-free parts from main, and tell people the truth: currently, we can't offer a 100% free solution, please use this stuff from non-free, we're working on free solutions. Instead you seem to invent a new rule, which says the number of users of Debian must be as high as possible, and you even want to break SC#1 for this rule. I think parallels can be drawn between this situation and the recent financial crisis. Certain banks found a way to bend the rules on what they considered to be good investments. Because they took stable investments to the casino with slanted odds they started to make lots of money. Other banks saw this and began to feel uncomfortable and jealous about what they were seeing and followed suit. Soon, many banks were caving in to their greed and by the time the whistle blew the damage was very deep. As the smoke clears we see that financial institutions who followed their values are the big winners. They stood on rock while others built castles on sand. Just because something is popular doesn't mean its right. The first lesson anyone must learn in the stock market is that following the crowd is a doomed behavior. If you focus on short term results at the expense of long term strategy then, eventually, the value of your organization will disappear. Warren Buffet and his teacher Benjamin Graham say always look for value. I agree that we must be sensible about providing users with a workable product. Let's just make sure thou shalt not steal doesn't turn into steal when convenient. If we must break the rules then please lets do steal when you have no other choice and pay back with interest later. -- Ean Schuessler, CTO Brainfood.com [EMAIL PROTECTED] - http://www.brainfood.com - 214-720-0700 x 315 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
On Sunday 16 November 2008, Manoj Srivastava wrote: I think we can be reasonably sure that the current spate of discussions is about releasing Lenny. For this action, any of the ballot options will have a distinct decision; and the ballot should have _all_ the possible courses of action for that decision. If the current vote is going to be interpreted that way then any option that _modifies_ foundation documents is not relevant and does not add to the GR. The same goes for options that _structurally_ allow the RT to allow violations. Those are clearly long-term decisions, which apparently you feel should be decided separately. I therefore propose to remove Proposals 5 and 6 on your list [1] from this vote and to hold a separate vote on them later. IMO the then remaining proposals still cover all relevant scenarios for the release of Lenny (as proposal 3 basically covers 5 with a restriction to Lenny). The current ballot really is highly inconsistent and confusing with your interpretation of it. This does leave the problem whether a delay of a vote on GR proposals that have received sufficient seconds is allowed, but possibly if the proposers of 5 and 6 agree we should just do that. Cheers, FJP [1] http://lists.debian.org/debian-vote/2008/11/msg00186.html signature.asc Description: This is a digitally signed message part.
Re: call for seconds: on firmware
On Sun, Nov 16 2008, Josselin Mouette wrote: Le dimanche 16 novembre 2008 à 10:04 -0600, Manoj Srivastava a écrit : ii Do we allow the Release Team to ignore SC violation bugs: Yes Rationale: with further discussion nothing changes. Today RMs are empowered, by delegation, to decide upon transitions and lenny-ignore tags. It will be the same tomorrow if further discussion wins. 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. The social contract says that the debian system and all its components will be 100% free, free as determined by the dfsg. DFSG says that free means source code. The constitution says that superseding a foundation document needs a 3:1 majority vote, not a handful of people. Downgrading reports of SC violation to ignore and releasing that seems like a weaselly end run around promises we made just for convenience, I am sure that the RMs are not going to stoop to that. manoj -- genlock, n.: Why he stays in the bottle. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
Le dimanche 16 novembre 2008 à 11:24 -0600, Manoj Srivastava a écrit : The social contract says that the debian system and all its components will be 100% free, free as determined by the dfsg. All its components include the unstable suite as well. Why are you focusing on the release team when hundreds of other developers (yes, that includes you) ignored the DFSG violations as well by not fixing them? Downgrading reports of SC violation to ignore and releasing that seems like a weaselly end run around promises we made just for convenience, I am sure that the RMs are not going to stoop to that. I can’t wait to see you pull on your black leather uniform and whip the release managers while they stoop. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: call for seconds: on firmware
On Sun, Nov 16 2008, Frans Pop wrote: On Sunday 16 November 2008, Manoj Srivastava wrote: I think we can be reasonably sure that the current spate of discussions is about releasing Lenny. For this action, any of the ballot options will have a distinct decision; and the ballot should have _all_ the possible courses of action for that decision. If the current vote is going to be interpreted that way then any option that _modifies_ foundation documents is not relevant and does not add to the GR. The same goes for options that _structurally_ allow the RT to allow violations. Those are clearly long-term decisions, which apparently you feel should be decided separately. No, I don't really feel quite that way. Yes, some of the options on this ballot have long term impact, but they are also equally capable of solving our What to do about Lenny problems. Since they all solve the Lenny issue, they are relevant, and related, solutions for the issue. I do not think throwing options out because they are not of a narrow and limited scope is right. The proposer and sponsors can withdraw them, if they think the scope is too broad for the problem at hand. No one else should be removing them from consideration as a solution to the Lenny issue. manoj -- Tcl tends to get ported to weird places like routers. Larry Wall in [EMAIL PROTECTED] Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
First of all, please stop the obnoxious cross-posting. It makes the threads unreadable anyway. (If you could stop the condescending and pedantic tone, that would help as well, but I guess that would be asking too much of you.) Le dimanche 16 novembre 2008 à 11:34 -0600, Manoj Srivastava a écrit : So, really, we cannot release programs (firmware) in main without source code just because a few delegates think we should. So another delegate (the secretary) should make the decision instead? It’s not that your interpretation of the Social Contract is flawed; but it is only your interpretation. The secretary is not a superhuman – unless he is leading a double life chasing evil aliens at night, but that would be irrelevant to Debian – and as such it would be inappropriate to consider only his interpretation as valid. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: For our own good: splitting the vote. Thoughts?
Don Armstrong [EMAIL PROTECTED] wrote: The goal of a vote is the ranking of options; this doesn't necessarily coincide with a clear assessment of the opinions of the population. Furthermore, splitting non-disjoint options into separate votes has a myriad of other problems that Manoj has identified. Is there any issue-independent way of deciding what's a substitute proposal and what's a proper amendment to the proposal? A quick check suggests that, for example Quick Consensus and Robert's Rules place essentially no limits on the scope of amendments, while Democratic Rules of Order does not allow amendments that negate, change topics or amend amendments. Most deliberative systems seem to limit amendments by some type of resource starvation (time, support of voters), which doesn't seem probable here IMO. I wonder about a limit on the proportion of changed words, but would that work? Thanks for any help, -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Discussion period: GR: DFSG violations in Lenny
Luk Claes [EMAIL PROTECTED] wrote: Please stop this fud. As everyone knows the 'lenny-ignore' tag is not used to intentionally ignore bugs (and has nothing to do with DFSG violations or not apart from bug severities), it's used to mark bugs as not blocking the release. [...] It seems that someone doesn't know the meaning of that tag. Would a GR promoting some release manager definition of the meaning of that tag to a postition statement be a simple settlement of much of this dispute? Sorry if this looks like a personal attack, but I'm sick of all these false allegations. Yes, it did look like a personal attack and I'm sick of everyone who's making those. Advance apologies are a signal that the comment probably shouldn't be sent in that form. Regards, -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
Josselin Mouette [EMAIL PROTECTED] writes: Le dimanche 16 novembre 2008 à 11:34 -0600, Manoj Srivastava a écrit : So, really, we cannot release programs (firmware) in main without source code just because a few delegates think we should. So another delegate (the secretary) should make the decision instead? The secretary isn't a delegate. The secretary has special powers explicitly listed in the Constitution that are not available to the DPL or to a delegate and a selection process mandated by the Constitution that isn't the same as delegation. It’s not that your interpretation of the Social Contract is flawed; but it is only your interpretation. The secretary is not a superhuman – unless he is leading a double life chasing evil aliens at night, but that would be irrelevant to Debian – and as such it would be inappropriate to consider only his interpretation as valid. However, the Constitution does that, so far as I can tell. A 3:1 majority can, of course, change the Constitution, which would effectively overturn the decision of the secretary. Alternately, you could try to convince the secretary that the project membership has reached an opposite consensus under 7.3. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Call for seconds: DFSG violations in Lenny
Bernd Zeimetz [EMAIL PROTECTED] writes: Robert Millan wrote: 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. To start the same bullshit again for the next release, a few days before the release? 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. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- 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, Pierre Habouzit wrote: On Sun, Nov 16, 2008 at 06:04:32PM +, Josselin Mouette wrote: First of all, please stop the obnoxious cross-posting. It makes the threads unreadable anyway. (If you could stop the condescending and pedantic tone, that would help as well, but I guess that would be asking too much of you.) Le dimanche 16 novembre 2008 à 11:34 -0600, Manoj Srivastava a écrit : So, really, we cannot release programs (firmware) in main without source code just because a few delegates think we should. So another delegate (the secretary) should make the decision instead? I believe the sense of the vote is to clarify the DFSG and that there is no consensus on the matter. We could decide a 3:1 majority to say that firmwares are subject to the DFSG _as well_ as for saying that the firmwares are _not_ subject to the DFSG. The SC is pretty clear about everything in the Debian system (which includes image .debs) should be 100% free. Not just things in the Debian system that run on a host CPU (what is that, anyway) are free. How we define free is the DFSG. So, since everything in the Debian system is free, everything must pass the DFSG. There is no ambiguity here. manoj -- By golly, I'm beginning to think Linux really *is* the best thing since sliced bread. -- Vance Petree, Virginia Power Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
Josselin Mouette [EMAIL PROTECTED] writes: Le dimanche 16 novembre 2008 à 12:43 -0800, Russ Allbery a écrit : It’s not that your interpretation of the Social Contract is flawed; but it is only your interpretation. The secretary is not a superhuman – unless he is leading a double life chasing evil aliens at night, but that would be irrelevant to Debian – and as such it would be inappropriate to consider only his interpretation as valid. However, the Constitution does that, so far as I can tell. No. The Secretary has the power to interpret the Constitution (§7.1.3) but not the Social Contract. Hm, good point. In fact, looking at it from that angle, it looks like interpretation of the foundation documents when it comes to work in Debian follows the normal decision-making process in Debian, since it's not an issue of the Constitution. That means that the primary decision rests with individual developers doing their own work (section 3), overridable by the DPL or a delegate of the DPL (section 5 and 8), which in turn is overridable by a General Resolution (section 4). Given that no GR has been passed to specifically override the release team decision, I think it's fairly clear that a vote of further discussion would leave the decision with the previous decision-making body, in this case the release team as DPL delegates. There doesn't appear to be anything in the Constitution that would allow anyone else to override the release team's interpretation of the foundation documents. I think that for a GR to be relevant, it would need to specifically fall under point 3 of section 4.1 (although I suppose one could read an action on the foundation documents under point 5 to implicitly fall under point 3 as well). The GR we passed for etch says nothing about what we do for lenny and hence couldn't override a release team decision for lenny. Manoj, am I misinterpreting something here? The question isn't what the SC says, but rather who gets to decide what it means and how it applies to their work. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- 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 09:01:38PM +, Manoj Srivastava wrote: On Sun, Nov 16 2008, Pierre Habouzit wrote: On Sun, Nov 16, 2008 at 06:04:32PM +, Josselin Mouette wrote: First of all, please stop the obnoxious cross-posting. It makes the threads unreadable anyway. (If you could stop the condescending and pedantic tone, that would help as well, but I guess that would be asking too much of you.) Le dimanche 16 novembre 2008 à 11:34 -0600, Manoj Srivastava a écrit : So, really, we cannot release programs (firmware) in main without source code just because a few delegates think we should. So another delegate (the secretary) should make the decision instead? I believe the sense of the vote is to clarify the DFSG and that there is no consensus on the matter. We could decide a 3:1 majority to say that firmwares are subject to the DFSG _as well_ as for saying that the firmwares are _not_ subject to the DFSG. The SC is pretty clear about everything in the Debian system (which includes image .debs) should be 100% free. Not just things in the Debian system that run on a host CPU (what is that, anyway) are free. The SC speaks about software, and doesn't define it. I believe software is what is interpreted or run on the host CPU, firmware is in a gray area. All is a matter of interpretation and I believe we have to settle that, once and for all. Firmwares are not going to disappear anytime soon, and playing that game for each release is destroying us from the inside. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgp1VdzGVVoZV.pgp Description: PGP signature
Re: Call for seconds: DFSG violations in Lenny
On Sun, Nov 16, 2008 at 01:24:56PM +0100, Bernd Zeimetz wrote: Robert Millan wrote: 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. If you're sick of personal attacks, stop this bullshit and spend your time on something useful. Like fixing RC bugs so Lenny can be released SOON. You're wasting a lot of people's time here, time which could be spent on making Lenny the best release ever. 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. 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. Bernd ... who will look for a different distribution to spend his time on, if Robert's proposals will pass the GR. Careful; given the uncompromising zealotry of the people arguing for the removal of sourceless firmware at all costs, statements like this are only likely to encourage them. :P -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Discussion: granting discretion to release team (was: Call for seconds: DFSG violations in Lenny)
Given that this is supposed to be the discussion period, I'd like to share my standpoint regarding one option. Andreas Barth wrote: | 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. I am extremely hesitant when it comes to this option. In fact, I think it's going to end up below Further discussion on my ballot. The main reason for that is that IMO the main reason that we're having this discussion is that the firmware question was handled rather badly by the current release team (RT). They themselves bear a heavy responsi- bility especially for the way the discussion started (IMO things have now settled down into a fairly reasonable discussion and voting process). We've already had two releases where this was an issue and in both cases it was decided by a GR. Why should the current release team think they could handle it differently? Just compare the way this started (by someone noticing that RC bugs had been tagged lenny-ignore without _any_ prior public discussion) to the way it was handled by the previous release team. For Etch, Steve Langasek *as RM* opened the discussion on debian-vote with this mail: http://lists.debian.org/debian-vote/2006/08/msg00032.html In summary: the previous RT anticipated on the resistance against such waivers, opened a discussion with the project and proposed a resolution to allow the release to go forward. This resulted in a very controlled vote (well, except for ...) and in the end the permission of the project was obtained without any real bloodshed. It's no secret that I've not been happy with the way the current RT has handled a number of things, including for example removals from testing. They seem to think they are mandated a large degree of freedom to beat the archive into shape for the release, no matter the cost and the frustration this may cause developers. IMO this is fundamentally wrong. Important decisions regarding the release, such as waiving structural RC issues, the support of architectures and the removal of packages should be made in discussion with the project at large and *not* by a select team. However careful they are it is impossible that they can correctly weigh all arguments all by themselves, even if only because they are just not aware of all the facts (for which of course they cannot be blamed given the size and diversity of the project). It is especially wrong because the way it is done is largely silent. Only very few people will actually notice the removal of a package or the addition of a tag to a BR when those happen. Most developers will only notice later on, for example when things break. Supporting this option on the ballot would effectively grant the RT broad powers and only increase the kind of problems we've seen in this release cycle. So, although I completely disagree with Robert Milan on his viewpoints regarding firmware, I do thank him for bringing the matter to the attention of the project. Cheers, FJP signature.asc Description: This is a digitally signed message part.
Differing standards of freedom for different bitstreams (was: call for seconds: on firmware)
Ben Finney [EMAIL PROTECTED] writes: This gives no argument for why such bitstreams should be held to different standards of freedom for its recipients. The properties “not code that is run on the host CPU” is mentioned, but seems to be irrelevant to the argument. Can you re-write this so it's clear why this particular class of bitstream should not be held to the same freedom standards as everything else in Debian? I've seen quite a number of seconds for Peter Palfrader's proposal, yet have not seen an answer to my question above. If this proposal passes, it seems to me that the result is the establishment of a contradiction between: | 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, […] versus SC §1: 1. Debian will remain 100% free […] We promise that the Debian system and all its components will be free according to [the DFSG] […] We will never make the system require the use of a non-free component. Those two cannot, by my reading, be simultaneously true. Surely some significant number of those who second the proposal must have a rational way to reconcile “Debian will remain 100% free” with the differing standards of freedom proposed by Peter? -- \ “Oh, I realize it's a penny here and a penny there, but look at | `\ me: I've worked myself up from nothing to a state of extreme | _o__) poverty.” —Groucho Marx | Ben Finney -- 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 10:20:05PM +, Ben Finney wrote: Pierre Habouzit [EMAIL PROTECTED] writes: On Sun, Nov 16, 2008 at 09:01:38PM +, Manoj Srivastava wrote: The SC is pretty clear about everything in the Debian system (which includes image .debs) should be 100% free. Not just things in the Debian system that run on a host CPU (what is that, anyway) are free. The SC speaks about software, and doesn't define it. The statement that Manoj refers to, above, does *not* speak about software. 1. Debian will remain 100% free We provide the guidelines that we use to determine if a work is free in the document entitled The Debian Free Software Guidelines. We promise that the Debian system and all its components will be free according to these guidelines. We will support people who create or use both free and non-free works on Debian. We will never make the system require the use of a non-free component. There is no need to define “software” for this promise to be understood. It explicitly promises that “the Debian system and all its components will be free”. This bit doesn't require the so called source of the work to exist within Debian explicitly. It asks for any component in Debian to meet the DFSG. In turn however, the DFSG requires that in their §2. The DFSG use a mix of component, software, program words, which makes them a mess in that regard. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpbw00qNQvtU.pgp Description: PGP signature
Re: Discussion: granting discretion to release team (was: Call for seconds: DFSG violations in Lenny)
On Sun, Nov 16, 2008 at 10:29:35PM +, Frans Pop wrote: We've already had two releases where this was an issue and in both cases it was decided by a GR. Why should the current release team think they could handle it differently? Maybe because in http://www.debian.org/vote/2004/vote_004 then later in http://www.debian.org/vote/2006/vote_007 there was a large majority of people thinking that the firmwares issues should not postpone a release. Maybe also because AFAICT, all but one firmware issue that were known when etch was released have been addressed. 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. But I really think the project stated strongly and twice that firmwares issues shouldn't postpone a release, hence I think that the RT wasn't abusing its powers while tagging those bugs lenny-ignore, because it was following pre-established consensus. Note that AFAICT I've seen no release team member (myself included) being against the vote. The vote will tell if we took a decision that the project won't endorse, and if it's the case, it will be rescinded. I have absolutely no strong feelings on the subject, unlike you apparently. Unless I'm mistaken, we haven't released Lenny without asking anyone, or sent any rash mail to d-d-a saying we would accept any firmwares without discussion from now on. We've marked bugs lenny-ignore, and you can watch progress on that front on [0]. | 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. I am extremely hesitant when it comes to this option. In fact, I think it's going to end up below Further discussion on my ballot. FWIW, I believe that any delegate that sees one of his decision loose with a decent margin should just resign. I dont think this § from Andi's proposal has any real implication. If the project votes one way or the other than firmwares should not postpone the release, then it will underline that we made the right choice in the first place, and I will feel we did represent the project consensus as delegates. Constitution is clear about this (§8.3): a Delegate must make choices that follow the consensus. I genuinely believe we did, two prior votes are here to support that. If the project rescind our choices with a clear majority, so be it. It will mean that we (and in particular I) don't represent Debian well after all. As a consequence I will resign from my RT membership if that should happen. [0] http://bugs.debian.org/tag:lenny-ignore my point with this URL, is that lenny-ignore tags are highly visible and traceable. It's not an intent of the release team to rub things under the carpet. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpkNCLlCsyc3.pgp Description: PGP signature
Defining free, and the DFSG's terminological shortcomings (was: call for seconds: on firmware)
Pierre Habouzit [EMAIL PROTECTED] writes: On Sun, Nov 16, 2008 at 10:20:05PM +, Ben Finney wrote: Pierre Habouzit [EMAIL PROTECTED] writes: The SC speaks about software, and doesn't define it. The statement that Manoj refers to, [SC §1], does *not* speak about software. […] There is no need to define “software” for this promise to be understood. It explicitly promises that “the Debian system and all its components will be free”. This bit doesn't require the so called source of the work to exist within Debian explicitly. It asks for any component in Debian to meet the DFSG. Okay. So, at least, we agree that the promise that Debian will remain 100% free does not depend on the term “software”. In turn however, the DFSG requires that in their §2. The DFSG use a mix of component, software, program words, which makes them a mess in that regard. That seems to be an argument for proposing a re-wording of the DFSG, so that freedoms are defined without referring to that mess of terms. I would agree that could be a good motivation in principle. -- \“Human reason is snatching everything to itself, leaving | `\ nothing for faith.” —Saint Bernard, 1090–1153 | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Discussion: granting discretion to release team
On Monday 17 November 2008, 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. I completely agree with that. [0] http://bugs.debian.org/tag:lenny-ignore my point with this URL, is that lenny-ignore tags are highly visible and traceable. It's not an intent of the release team to rub things under the carpet. I did not say it was your intention to rub things under the carpet, and you will never hear me say so. But the fact that things can be found if you go look for them, does not mean they are visible. My point is that most people will never see such lists as they just don't go looking for them. And they should not have to. My very strong opinion is that it is part of the job of being a release manager to *actively* bring things that can be expected to be important or controversial to project members to their attention and, if needed, discuss such things _before_ they are done. And for me that includes setting ignore tags on BRs that involve DFSG violations and removals of anything other that totally obvious unmaintained fringe packages. In most cases a simple mail for the following reasons we are considering to [...] to d-devel would be more than sufficient to check if there is any real issue with a planned action. Just allow a few days or a week for reactions. Cheers, FJP signature.asc Description: This is a digitally signed message part.
Re: Defining free, and the DFSG's terminological shortcomings (was: call for seconds: on firmware)
On Sun, Nov 16, 2008 at 11:15:10PM +, Ben Finney wrote: Pierre Habouzit [EMAIL PROTECTED] writes: On Sun, Nov 16, 2008 at 10:20:05PM +, Ben Finney wrote: Pierre Habouzit [EMAIL PROTECTED] writes: The SC speaks about software, and doesn't define it. The statement that Manoj refers to, [SC §1], does *not* speak about software. […] There is no need to define “software” for this promise to be understood. It explicitly promises that “the Debian system and all its components will be free”. This bit doesn't require the so called source of the work to exist within Debian explicitly. It asks for any component in Debian to meet the DFSG. Okay. So, at least, we agree that the promise that Debian will remain 100% free does not depend on the term “software”. It depends on the DFSG which depends on term software. So yes, it doesn't depend _directly_ on the term software. In turn however, the DFSG requires that in their §2. The DFSG use a mix of component, software, program words, which makes them a mess in that regard. That seems to be an argument for proposing a re-wording of the DFSG, so that freedoms are defined without referring to that mess of terms. I would agree that could be a good motivation in principle. Yes, I believe the DFSG are clumsy when it comes to its terms. Component is clear. Firmwares are part of Debian components for sure, there is absolutely no doubt about that. But I'm honnestly not sure what programs or software mean, and in §2 that's the terms in use, and that's the sole § causing issues with them. We have had quite a few rounds of GRs to say that documentations, images, documentation, fonts... are softwares, we could continue such rounds, or make the DFSG clearer. I would be more on the latter side. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpQMCq5QBjdT.pgp Description: PGP signature
Re: call for seconds: on firmware
On Sun, Nov 16, 2008 at 01:17:08PM -0800, Russ Allbery wrote: Given that no GR has been passed to specifically override the release team decision, I think it's fairly clear that a vote of further discussion would leave the decision with the previous decision-making body, in this case the release team as DPL delegates. 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. Note: I'm not giving any opinion either way as to what a FD vote means. Personally, I think it's a 'send it back to the drawing board' item, and I'd need to further think about that that entails regarding the current position. Neil -- * Maulkin cries Maulkin NB: rm -rf /chroots/sarge while /home is mounted at /chroots/sarge/home is NOT-A-GOOD-THING(tm) signature.asc Description: Digital signature
Re: call for seconds: on firmware
Neil McGovern [EMAIL PROTECTED] writes: On Sun, Nov 16, 2008 at 01:17:08PM -0800, Russ Allbery wrote: Given that no GR has been passed to specifically override the release team decision, I think it's fairly clear that a vote of further discussion would leave the decision with the previous decision-making body, in this case the release team as DPL delegates. 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. Sure, and this is something that I always thought too, but I don't see this anywhere in the Constitution. But even more fundamentally, I think the question of whether this decision actually overrides the SC is part of the dispute. People have in this thread put forward reasons why they don't think firmware may violate the current SC (including Manoj, for that matter), so it's not like it's completely inconceivable to reconcile the RT position with the SC. Given that, someone has to decide which reading of the SC applies, and as near as I can tell from the Contitution, in the absence of a GR overriding their decision, the RT is empowered as delegates to make such decisions with regard to the release. Or if the DPL doesn't think the delegation includes making such a judgement, the individual developers uploading the packages are empowered to make that decision unless overruled by the DPL or a delegate. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Defining free, and the DFSG's terminological shortcomings
Pierre Habouzit [EMAIL PROTECTED] writes: On Sun, Nov 16, 2008 at 11:15:10PM +, Ben Finney wrote: That seems to be an argument for proposing a re-wording of the DFSG, so that freedoms are defined without referring to that mess of terms. I would agree that could be a good motivation in principle. Yes, I believe the DFSG are clumsy when it comes to its terms. Component is clear. Firmwares are part of Debian components for sure, there is absolutely no doubt about that. But I'm honnestly not sure what programs or software mean, and in §2 that's the terms in use, and that's the sole § causing issues with them. We have had quite a few rounds of GRs to say that documentations, images, documentation, fonts... are softwares I think that's a mischaracterisation of those GRs. They're not “to say that foo is software”, but rather “to determine whether foo should be exempt from the freedoms that we promise to apply to all of Debian”. Again, as earlier in this thread, I don't see such arguments necessarily requiring a definition of “software”; but, as you say, the current wording of the DFSG makes this confusion much more likely. we could continue such rounds, or make the DFSG clearer. I would be more on the latter side. Agreed, I would very much like the DFSG to be clearer as to what freedoms it defines for works in Debian. Is now a good time to propose such a GR? On the positive side, it could bring clarity to the ongoing discussions about what freedoms apply to works in Lenny; on the negative side, it could further delay the resolutions that seem to more directly impact the status of Lenny. -- \ “I have the simplest tastes. I am always satisfied with the | `\ best.” —Oscar Wilde | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Defining free, and the DFSG's terminological shortcomings
Pierre Habouzit [EMAIL PROTECTED] writes: Yes, I believe the DFSG are clumsy when it comes to its terms. Component is clear. Firmwares are part of Debian components for sure, there is absolutely no doubt about that. But I'm honnestly not sure what programs or software mean, and in §2 that's the terms in use, and that's the sole § causing issues with them. We have had quite a few rounds of GRs to say that documentations, images, documentation, fonts... are softwares, we could continue such rounds, or make the DFSG clearer. I would be more on the latter side. I think it's fairly clear that the project is split on this. Of the two clear votes that we had on this, the first, which would have unambiguously declared firmware to be software for the purposes of DFSG #2, failed: http://www.debian.org/vote/2006/vote_004 and the second, to amend the DFSG to exclude firmware from the source requirements of the DFSG, garnered more than a majority but failed due to 3:1 majority requirements: http://www.debian.org/vote/2006/vote_007 (I don't consider the editorial amendment and subsequent sarge vote to be sufficiently clear to really serve as proof of the project's position on this.) -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- 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 11:42:19AM -0600, Manoj Srivastava wrote: I do not think throwing options out because they are not of a narrow and limited scope is right. The proposer and sponsors can withdraw them, if they think the scope is too broad for the problem at hand. No one else should be removing them from consideration as a solution to the Lenny issue. The proposers and sponsors of option 5 didn't propose this as an amendment to the current GR. Why should they have to *withdraw* the proposal in order to get it considered separately at a later time? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Defining free, and the DFSG's terminological shortcomings
On Sun, Nov 16, 2008 at 11:54:25PM +, Russ Allbery wrote: Pierre Habouzit [EMAIL PROTECTED] writes: Yes, I believe the DFSG are clumsy when it comes to its terms. Component is clear. Firmwares are part of Debian components for sure, there is absolutely no doubt about that. But I'm honnestly not sure what programs or software mean, and in §2 that's the terms in use, and that's the sole § causing issues with them. We have had quite a few rounds of GRs to say that documentations, images, documentation, fonts... are softwares, we could continue such rounds, or make the DFSG clearer. I would be more on the latter side. I think it's fairly clear that the project is split on this. I know, though we really cannot afford the big flames about firmwares on each release, we should try to find a sane compromise here, but I've no clue where to start in the first place. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpGrNQYc65TE.pgp Description: PGP signature
Re: Defining free, and the DFSG's terminological shortcomings
Le Mon, Nov 17, 2008 at 10:51:54AM +1100, Ben Finney a écrit : Is now a good time to propose such a GR? I really do not think so. As you see, it creates discordance in the Project, kills the fun, sinks energy, makes people asking for each other's heads and starts a process that has many dead ends, like not having a release tea, or not agreeing on voting an amendment on the SC after accepting a 3:1 option that lets Lenny release. The supermajority madness is preparing a situation where 100 % of the developers are dissatisfied. The whole anti-debate is a big disorganised pile of emails and many questions were left unanswered. I still do not understand why it was possible to release Etch without a supermajority if it is not the case for Lenny. Can each camp, in particular the release later camp and the supermajority camp prepare a synthethic document to help people vote ? Have a nice day, if that is possible after having this thread for breakfast, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Discussion: granting discretion to release team
On Sun, Nov 16, 2008 at 11:36:32PM +, Frans Pop wrote: My very strong opinion is that it is part of the job of being a release manager to *actively* bring things that can be expected to be important or controversial to project members to their attention and, if needed, discuss such things _before_ they are done. And for me that includes setting ignore tags on BRs that involve DFSG violations I didn't expect the matter to be controversial, since there was two votes in that direction before. And to be frank, I don't think there is much discussion on the lenny-ignore bits, I really expect the project will endorse our choice. On the other hand, there have been a couple of very loud people on the subject, that don't really care about the lenny-ignore-or-not issue, but rather care about the firmware issue at large. Most of what I've seen are people using that pretext to start their favourite firmware-related flame throwers. TTBOMK #211765 or #368559 or #382175 sarge, etch and lenny-ignore tags have never been discussed publicly and are DFSG violations as well. And I've seen no one disagree with those choices yet. Oh and unlike you, I believe it's the responsibility of every QA Team Member (IOW every DD) to watch the RC bug list during a freeze. Lenny-ignore bugs are not removed from that list, they just don't count for Britney. Probably not everyone watches it. But I *know* for sure that many people _outside_ the release team watch it, and will happily trigger a discussion if we badly screw up. The bug reporters see the tags, those people see the changes, and can argue about them. That's exactly why the discussion started in the first place, and unlike you (or other people) I don't read that as a failure of the release team, but a success of our feedback mechanisms. I'm perfectly fine with Delegates taking decisions without prior consultation of everyone, if that follows consensus. I'm also fine with Delegates taking crappy decisions because they're just human and make honnest mistakes, when they realize those are mistakes and don't obstinately try to impose a decision that is after all not making consensus at all. So far, I don't believe the Release Team failed those principles, and a vote will just decide that once for all. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpGympZKlHPE.pgp Description: PGP signature
Re: Discussion: granting discretion to release team
On Monday 17 November 2008, Pierre Habouzit wrote: The bug reporters see the tags, [...] Not true by default, only if they subscribe to the BR. signature.asc Description: This is a digitally signed message part.
Re: call for seconds: on firmware
Pierre Habouzit [EMAIL PROTECTED] wrote: [...] [SC 1] doesn't require the so called source of the work to exist within Debian explicitly. It asks for any component in Debian to meet the DFSG. In turn however, the DFSG requires that in their §2. The DFSG use a mix of component, software, program words, which makes them a mess in that regard. Quite right! We need some editorial changes to fix this(!) Except we already tried that, with the social contract, not long before madcoder joined. Surely no-one joining in 2005 could be ignorant of what SC 1 applies to, given all the noise in 2004? Actually, the DFSG don't use component, software or program but some of the explanations/illustrations do. I think the DFSG could be written exactly, maybe using some system of formal symbols, and there would *still* be disagreements about the meaning. The price of freedom is eternal vigilance, sadly. Regards, -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct -- 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, Russ Allbery wrote: Josselin Mouette [EMAIL PROTECTED] writes: Le dimanche 16 novembre 2008 à 12:43 -0800, Russ Allbery a écrit : It’s not that your interpretation of the Social Contract is flawed; but it is only your interpretation. The secretary is not a superhuman – unless he is leading a double life chasing evil aliens at night, but that would be irrelevant to Debian – and as such it would be inappropriate to consider only his interpretation as valid. However, the Constitution does that, so far as I can tell. No. The Secretary has the power to interpret the Constitution (§7.1.3) but not the Social Contract. Hm, good point. In fact, looking at it from that angle, it looks like interpretation of the foundation documents when it comes to work in Debian follows the normal decision-making process in Debian, since it's not an issue of the Constitution. That means that the primary decision rests with individual developers doing their own work (section 3), overridable by the DPL or a delegate of the DPL (section 5 and 8), which in turn is overridable by a General Resolution (section 4). Manoj, am I misinterpreting something here? The question isn't what the SC says, but rather who gets to decide what it means and how it applies to their work. Sure. I, as secretary (as opposed to with other developers in a GR) can not, and ahve never said I can, decide for the release team how to interpret the SC. I have said that my personal read on this is that the firmware blobs are not source code, so unless we decide to override the DFSG, we can't release. As secretary, I can say that the foundation documents can't be superseded or overridden by the DPL or delegates. So, if the release team states that they are not violating the SC, and can defend that stance, they are within their rights -- and the people who do not like that can, via GR, override their decision. But the release team can't say they decided to bend the rules and disregard the SC, since the power to do so is not granted by the constitution. manoj -- Meekness is uncommon patience in planning a worthwhile revenge. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- 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, Pierre Habouzit wrote: On Sun, Nov 16, 2008 at 09:01:38PM +, Manoj Srivastava wrote: On Sun, Nov 16 2008, Pierre Habouzit wrote: On Sun, Nov 16, 2008 at 06:04:32PM +, Josselin Mouette wrote: First of all, please stop the obnoxious cross-posting. It makes the threads unreadable anyway. (If you could stop the condescending and pedantic tone, that would help as well, but I guess that would be asking too much of you.) Le dimanche 16 novembre 2008 à 11:34 -0600, Manoj Srivastava a écrit : So, really, we cannot release programs (firmware) in main without source code just because a few delegates think we should. So another delegate (the secretary) should make the decision instead? I believe the sense of the vote is to clarify the DFSG and that there is no consensus on the matter. We could decide a 3:1 majority to say that firmwares are subject to the DFSG _as well_ as for saying that the firmwares are _not_ subject to the DFSG. The SC is pretty clear about everything in the Debian system (which includes image .debs) should be 100% free. Not just things in the Debian system that run on a host CPU (what is that, anyway) are free. The SC speaks about software, and doesn't define it. I believe software is what is interpreted or run on the host CPU, firmware is in a gray area. All is a matter of interpretation and I believe we have to settle that, once and for all. Firmwares are not going to disappear anytime soon, and playing that game for each release is destroying us from the inside. I tend to agree with: http://en.wikipedia.org/wiki/Computer_software Back when I voted on the social contract, and now, I believe that everything computer related that is not hardware (or wetware), is software/. The article also states: Firmware which is software programmed resident to electrically programmable memory devices on board mainboards or other types of integrated hardware carriers So, there seem to be a wide spread view that firmware are indeed software. I think that an entity, like a program, can have multiple representations: * It starts life as wetware, when I think through the steps needed * It may have a stint as hardware (something tanngible), when I print it out, or write it out using pen and paper * When encoded as 0/1 and 1. it is in a software representation. I believe now, as I did then, that everything we distribute on a CD, being encoded in 0s and 1s, is software. manoj -- Every man is as God made him, ay, and often worse. Miguel de Cervantes Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- 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, Steve Langasek wrote: On Sun, Nov 16, 2008 at 11:42:19AM -0600, Manoj Srivastava wrote: I do not think throwing options out because they are not of a narrow and limited scope is right. The proposer and sponsors can withdraw them, if they think the scope is too broad for the problem at hand. No one else should be removing them from consideration as a solution to the Lenny issue. The proposers and sponsors of option 5 didn't propose this as an amendment to the current GR. Why should they have to *withdraw* the proposal in order to get it considered separately at a later time? They only need to do so to prevent it from being on the current ballot. I think it would be a pity of any of the 6 options is withdrawn, since any of them could lend us relief from the current mess wrt Lenny release. As to future votes, anyone may propose a failed option on any vote for a fresh look anytime they so desire. manoj -- Our business is run on trust. We trust you will pay in advance. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: For our own good: splitting the vote. Thoughts?
Please forward this mail to the list, as i am being censored, No, you are not being censored. -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct -- 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 01:27:26AM +, MJ Ray wrote: Quite right! We need some editorial changes to fix this(!) Except we already tried that, with the social contract, not long before madcoder joined. Surely no-one joining in 2005 could be ignorant of what SC 1 applies to, given all the noise in 2004? Actually, the DFSG don't use component, software or program but some of the explanations/illustrations do. 2. Source Code The program must include source code, and must allow distribution in source code as well as compiled form. You seem to be saying that everything after the title is merely explanation/illustration and not a binding part of the DFSG. That doesn't make any sense. Just reading the titles of each of the DFSG doesn't tell you what the guidelines are. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
* Neil McGovern ([EMAIL PROTECTED]) [081117 00:27]: On Sun, Nov 16, 2008 at 01:17:08PM -0800, Russ Allbery wrote: Given that no GR has been passed to specifically override the release team decision, I think it's fairly clear that a vote of further discussion would leave the decision with the previous decision-making body, in this case the release team as DPL delegates. 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). Cheers, Andi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
