*To*: Debian Developers List <debian-devel@lists.debian.org>*Subject*: Re: gimp1.2: gimp package suggest non-free software*From*: Anthony Towns <aj@azure.humbug.org.au>*Date*: Thu, 13 Nov 2003 13:48:25 +1000*Message-id*: <20031113034825.GA560@azure.humbug.org.au>*Mail-followup-to*: Debian Developers List <debian-devel@lists.debian.org>*In-reply-to*: <20031112162815.GC24634@tennyson.netexpress.net>*References*: <m365hqxe8z.fsf@coleumes.org> <20031112080201.GA3555@azure.humbug.org.au> <m34qxakn7w.fsf@coleumes.org> <20031112093606.GA4686@azure.humbug.org.au> <m3islpj111.fsf@coleumes.org> <20031112114110.GA13083@alfa21.com> <20031112162815.GC24634@tennyson.netexpress.net>

On Wed, Nov 12, 2003 at 10:28:15AM -0600, Steve Langasek wrote: > On Wed, Nov 12, 2003 at 12:41:10PM +0100, Roberto Suarez Soto wrote: > > > Sure, keep lowering the quality of Debian in matter of freedom, > > > there's no matter discussing that. > > I don't see how making more packages available to our users is > > "lowering the quality of Debian in matter of freedom". > Oh, you think there's a positive correlation between quality and > quantity, do you? ;) Holding the average component quality constant, and increasing the quantity should increase the overall quality, yes. If you take the overall quality of Debian to be the chance it'll solve your problem, then and if the probability of any given package addressing your problem is "p", and each package's quality (ie, the probability of solving the problems it addresses) is q_i, then your probability of a given package addressing your problem is p * q_i, so the probability of a given package in Debian not solving your problem is (1 - p * q_i), so if Q, the overall quality, is the probability of Debian solving your problem, we have: n 1 - Q = prod( 1 - p * q_i ) i=1 n or Q = 1 - prod( 1 - p * q_i ) i=1 If we assume q_i is approximately constant, that's about: n Q ~= 1 - prod( 1 - pq ) i=1 Q ~= 1 - (1-pq)^n The relationship between quantity (n) and quality (q, and Q) is reasonably clear here. But note that we're treating "Q" as "probability some package in Debian can solve your problem". We really should be talking about "probability that you can use Debian to solve your problem", which is slightly more complicated, and should consider at least the following factors: (a) How much effort does it take to find and use the package? (b) Maybe I can't solve my problem with one package, but perhaps I can put two or three or more packages together to solve it? (b) is far too hard to worry about -- it reminds me of those horrible problems in Physics where you have to worry about every possible path particles could take to get from point A to point B. Yuck. (a) is easier, though. It depends on two factors: how good our descriptions and categorisations are, and how many packages we have. With things like apt-cache search, and remotely respectable descriptions, I'm inclined to think that we can pretty much treat this as a constant effort to find the packages that address the problem; followed by a linear effort to look through those packages to weed out the broken ones. Hrm, my stats is too weak to work that out from first principles. Man, do I suck. Oh well. The expected number of packages is that address the problem is: n c = sum( i * p^i * (1-p)^(n-i) ) i=0 There are two approaches we could take then: one is to say "well, sure, you get 100 possible packages, but if the first one you look at solves your problem, then you'll stop", and factor in q_i calculations. I tend to look through all the packages anyway to find the one that _best_ solves the problem for me, though, so the effort is proportional to n for me, and the probability of success is 1-(1-q)^c. So, the work that goes into it is: n sum( i * p^i * (1-p)^(n-i) ) i=0 and the expected payoff is: ~ 1 - (1-pq)^n or 1-(1-q)^c Hopefully this analysis will be helpful in evaluating future ITPs. 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. Australian DMCA (the Digital Agenda Amendments) Under Review! -- http://azure.humbug.org.au/~aj/blog/copyright/digitalagenda

**Attachment:
pgplrMVTYyz85.pgp**

**References**:**gimp1.2: gimp package suggest non-free software***From:*Mathieu Roy <yeupou@gnu.org>

**Re: gimp1.2: gimp package suggest non-free software***From:*Mathieu Roy <yeupou@gnu.org>

**Re: gimp1.2: gimp package suggest non-free software***From:*Anthony Towns <aj@azure.humbug.org.au>

**Re: gimp1.2: gimp package suggest non-free software***From:*Mathieu Roy <yeupou@gnu.org>

**Re: gimp1.2: gimp package suggest non-free software***From:*Roberto Suarez Soto <robe@alfa21.com>

**Re: gimp1.2: gimp package suggest non-free software***From:*Steve Langasek <vorlon@netexpress.net>

- Prev by Date:
**Re: radiusd-freeradius history and future** - Next by Date:
**Re: radiusd-freeradius history and future** - Previous by thread:
**Re: gimp1.2: gimp package suggest non-free software** - Next by thread:
**Re: gimp1.2: gimp package suggest non-free software** - Index(es):