On Wed, Mar 10, 2004 at 11:32:25PM -0800, Thomas Bushnell, BSG wrote: > Anthony Towns <aj@azure.humbug.org.au> writes: > > You've got a bad habit of missing the point made in an email, then > > trimming it so that no one else can see the point either. > If so, it's not intentional, and please correct it.
I have no idea what you mean by "please correct it". Do you mean "Thankyou for pointing this out, now and in the future"? > My complaint was specifically that you (and Sven, partially) had given > up on what I see as the crucial compromise behind section five of the > SC. As should be clear by now, I never made that compromise in the first place. I don't think mangling language for marketing purposes, or agreeing not to talk about things is a good idea. > Rather, it was an explanation of > a mistake that I believe you made, and that if someone with the > awareness and visibility as yourself makes that mistake so frequently > and so persistently, ..then it's likely other people are making the same mistake, and there's no point making it about me, personally. If you really think it's important for me to stop making this "mistake", then you need to convince me that is a mistake -- and the only thing that your thread did was convince me that you're a crank who isn't worth taking seriously. > It therefore was necessarily about whether someone with your > visibility had gotten it wrong--as I still believe you have-- There are two possible claims you could be making. One is that I've broken a promise I made in the past, and am therefore a fundamentally dishonest person. Maybe this could be weakened by assuming that I wasn't aware of the importance, and simply forgot I'd made the commitment in the first place, but either way, it leaves it as a flaw in me. The other is that I never made the promise in the first place, but was expected to do so by the rest of the project. That'd mean that the new-maintainer process at the time wasn't appropriately strict, which is entirely plausible. But since I am a member of the project now, you'll need to either point to some historical documentation that makes it clear that this is a promise every member of Debian needed to have made, or you'll need to convince people that it's an important one to make now whether it was meant to be made in the past or not. I don't believe you'll find any indication that I did make the promise your claiming about. I also don't think you'll find any explicit indication that such a promise was ever expected, and I'm doubtful you'll find the idea even considered outside of arguments that non-free should be dropped. I could be wrong on both counts, of course. You certainly haven't made any convincing arguments about why it's a good thing to be unable to say "Debian includes a non-free component" or similar remarks. And you sure seem a lot more interested in using that as an excuse to drop non-free, than explaining why it's a good compromise and convincing people that it's the thing to do: > as a > necessary link in an argument that paragraph five has ceased to be a > compromise between two different parties, and has become the slogan of > only one party, which no longer feels bound to the other half of the > compromise. There's a few examples which are entirely plausible examples of a breakdown in the split between main and non-free. One occurred when we moved contrib/ and non-free/ under the release codename on the ftp site during hamm -- that made it very difficult to find terms to talk about "main" that emphasise how much more fundamental it is than "non-free" or "contrib". Last time we had this debate, I thought it'd be a good idea to make it clear that those sections were "add-ons", by putting them in a subdirectory, and having other possible add-on collections (such as backports) in with them. Unfortunately, I don't think that makes sense anymore (what happens when you've got non-free backports?), and I can't see any other way of emphasising the difference between main and contrib/non-free, and going back to the way we were pre-hamm will simply make non-free and contrib packages unusable. Another problem is when packages in main refer to packages outside non-free -- this tends to upset people. We've patched dselect in the past to fix this (in particular by making it ignore suggestions for unavailable packages), and we should probably patch apt and other tools if it comes up again. Working out whether we want to distribute non-free software _at all_ is also a valid question. There are costs to maintaining it, and if it's not maintained well, it probably does detract from the overall experience of using Debian more than if it weren't provided at all. I don't think that's the case, but it's a valid question, that affects real users. The other recent example of continuing to distribute non-free documentation after having come to the consensus that there's no good justification for different rules for programs and documentation can also be claimed to be worrisome from that standpoint. These are valid issues; but they're all about actual software, and about finding the best way of communicating what actually is the case. main is more important than contrib or non-free -- you can use main without contrib or non-free, but you can't do the opposite. Suggesting packages that aren't available is a waste of time no matter the reason their not available. Whether we should include documentation in main affects actual packages. By contrast, forbidding the use of the phrase "Debian contains non-free" as shorthand for "The Debian project provides infrastructure for non-free software and distributes it via its mirror network" makes communication more difficult and confusing, and doesn't do anything to benefit anyone. I can't imagine why you think it's an "important compromise" that's been made. In any event, I'd be interested in exactly how *you'd* spell out the terms of that particular clause. What's allowed, and what's not, exactly? At the moment, the rule might as well be "Anything that's found offensive by someone who dislikes non-free has to be rephrased." > And, if that is the case, as I believe it is, then paragraph five > needs to go, and if necessary, a new compromise needs to be reached. Normally the compromise is worked out first. Cheers, aj -- Anthony Towns <[EMAIL PROTECTED]> <http://azure.humbug.org.au/~aj/> I don't speak for anyone save myself. GPG signed mail preferred. Linux.conf.au 2004 -- Because we could. http://conf.linux.org.au/ -- Jan 12-17, 2004
signature.asc
Description: Digital signature