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 <aj@humbug.org.au> <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
Attachment:
signature.asc
Description: Digital signature