On Tue, Feb 20, 2007 at 01:35:32AM +0000, Ciaran McCreesh wrote:
> It is widely perceived that Gentoo has a huge problem with slacker
> archs cluttering up the tree and making maintainers' work harder.
> Clearly, something needs to be done about this.
> 
> I think the first step is to establish what all the problem
> architectures are. We all know that mips is by far the worst offender,
> but by how much? Rather than speculating wildly, I decided to make use
> of adjutrix and wc to find out. So, here we have a table showing just
> how much mips is a slacker arch:

Lies, Damn Lies, and Statistics.

(I always wanted to use that quote in an email, finally got a chance :)

base tree stats as of 02/19 02:30:01

checked the data over; mind you, formatting crap I did by hand gluing 
from other bits, so it's possible I screwed up- doubt it, but feel 
free to verify it.

base tree stats:
150   categories
11511 packages
22965 ebuilds

lagging stats broken compared to the # of packages keyworded (in any 
form) for that arch.

Arch      'lagging' # of pkgs available % of available lagging.
========= ========= =================== =======================
m68k       37         477                7.7%
ppc-macos  56         499               11.2%
sh         84        1313                6.3%
s390       87        1183                7.3%
arm       120        1577                7.6%
sparc     155        5739                2.7%
hppa      176        2432                7.2%
ia64      221        3378                6.5%
ppc64     278        3403                8.1%
mips      292        1720               16.9%
ppc       359        8723                4.1%
alpha     361        3720                9.7%
amd64     413        9712                4.2%
x86       560       11360                4.9%


arch       % total lagging
=========  =================
mips       16.9
ppc-macos  11.2
alpha       9.7
ppc64       8.1
m68k        7.7
arm         7.6
s390        7.3
hppa        7.2
ia64        6.5
sh          6.3
x86         4.9
amd64       4.2
ppc         4.1
sparc       2.7


Since the complaint is regarding getting packages keyworded on mips in 
a timely fashion, stats above are useful, but knowing the breakdown of 
unstable only vs mixed keywords per package is useful.

In other words, above is close, but doesn't filter out the unstable; 
complaints (aside from broken depgraph) have typically been that 
getting things stabled is a pita for mips.


Arch      # of pkgs unstable only #     % stable in some form
========= ========= ============= ====  =====================
m68k        477       21          456   95.5
ppc-macos   499      324          175   35.0
sh         1313       63          1250  95.2
s390       1183       99          1084  91.6
arm        1577      147          1430  90.6
sparc      5739     1326          4413  76.8
hppa       2432      463          1969  80.9
ia64       3378      433          2945  87.1
ppc64      3403      508          2823  85.0
mips       1720      483          1237  71.9
ppc        8723     3045          5678  65.0          
alpha      3720      348          3372  90.6
amd64      9712     3406          6306  64.9
x86       11360     2780          8580  75.5


since results are relevant to stable targets only, we rebase the given 
'lagging' stats to only the mixed (at least partially stabled for that 
arch) pkg sets.

Arch        lagging stable #  % of stable visible
==========  ======= ========  ===================
ppc-macos     56     175       32.0
mips         292    1237       23.6
alpha        361    3372       10.7
ppc64        278    2823        9.8
hppa         176    1969        8.9
arm          120    1430        8.3
m68k          37     456        8.1
s390          87    1084        8.0
ia64         221    2945        7.5
sh            84    1250        6.7
x86          560    8580        6.5
ppc          359    5678        6.3
amd64        413    6306        5.7
sparc        155    4413        3.5


> As expected, supporting minority archs is leading to tree-wide bloat
> and huge initial rsync times for users. Clearly something has to be
> done to protect Gentoo from those useless minority archs! I mean, how
> many users do we *really* have using amd64 or x86?

Actually digging into the data rather then doing the "lies, damn lies, 
and statistics" approach shows a pattern of mips having a large % of 
their stable packages lagging the others.

Granted, ppc-macos has more, but mips has 7x the number of packages... 
plus ppc-macos is effectively a dead arch, they've gone on to prefix 
land for the most part.

Regarding "minority arches", look at arm, s390, hell, even hppa.  They 
all have a decent selection of stabled (in some form) packages 
available (exceeding mips), and they're in line with the rough mean 
for % unstable.  Hard to argue arm/s390/hppa are 'mainline' arches 
also.

Again; the complaints are regarding mips lagging in keywording; while 
this data doesn't include average time for getting something stabled 
with them, it is mildly damning in terms of how much they're lagging 
for their packages.

Additionally, note to eroyf; this isn't intended as a criticism of 
your work, since you've been bringing the mips percentage down.  That 
said, their *is* a disparity there compared to the other arches.

Aside from that, aparently props should be given to sparc; seem to be 
on top of things.

Either way, data to chew on.

~harring

Attachment: pgpNYyfX47rOt.pgp
Description: PGP signature

Reply via email to