| 1 |
On Tue, Feb 20, 2007 at 01:35:32AM +0000, Ciaran McCreesh wrote: |
| 2 |
> It is widely perceived that Gentoo has a huge problem with slacker |
| 3 |
> archs cluttering up the tree and making maintainers' work harder. |
| 4 |
> Clearly, something needs to be done about this. |
| 5 |
> |
| 6 |
> I think the first step is to establish what all the problem |
| 7 |
> architectures are. We all know that mips is by far the worst offender, |
| 8 |
> but by how much? Rather than speculating wildly, I decided to make use |
| 9 |
> of adjutrix and wc to find out. So, here we have a table showing just |
| 10 |
> how much mips is a slacker arch: |
| 11 |
|
| 12 |
Lies, Damn Lies, and Statistics. |
| 13 |
|
| 14 |
(I always wanted to use that quote in an email, finally got a chance :) |
| 15 |
|
| 16 |
base tree stats as of 02/19 02:30:01 |
| 17 |
|
| 18 |
checked the data over; mind you, formatting crap I did by hand gluing |
| 19 |
from other bits, so it's possible I screwed up- doubt it, but feel |
| 20 |
free to verify it. |
| 21 |
|
| 22 |
base tree stats: |
| 23 |
150 categories |
| 24 |
11511 packages |
| 25 |
22965 ebuilds |
| 26 |
|
| 27 |
lagging stats broken compared to the # of packages keyworded (in any |
| 28 |
form) for that arch. |
| 29 |
|
| 30 |
Arch 'lagging' # of pkgs available % of available lagging. |
| 31 |
========= ========= =================== ======================= |
| 32 |
m68k 37 477 7.7% |
| 33 |
ppc-macos 56 499 11.2% |
| 34 |
sh 84 1313 6.3% |
| 35 |
s390 87 1183 7.3% |
| 36 |
arm 120 1577 7.6% |
| 37 |
sparc 155 5739 2.7% |
| 38 |
hppa 176 2432 7.2% |
| 39 |
ia64 221 3378 6.5% |
| 40 |
ppc64 278 3403 8.1% |
| 41 |
mips 292 1720 16.9% |
| 42 |
ppc 359 8723 4.1% |
| 43 |
alpha 361 3720 9.7% |
| 44 |
amd64 413 9712 4.2% |
| 45 |
x86 560 11360 4.9% |
| 46 |
|
| 47 |
|
| 48 |
arch % total lagging |
| 49 |
========= ================= |
| 50 |
mips 16.9 |
| 51 |
ppc-macos 11.2 |
| 52 |
alpha 9.7 |
| 53 |
ppc64 8.1 |
| 54 |
m68k 7.7 |
| 55 |
arm 7.6 |
| 56 |
s390 7.3 |
| 57 |
hppa 7.2 |
| 58 |
ia64 6.5 |
| 59 |
sh 6.3 |
| 60 |
x86 4.9 |
| 61 |
amd64 4.2 |
| 62 |
ppc 4.1 |
| 63 |
sparc 2.7 |
| 64 |
|
| 65 |
|
| 66 |
Since the complaint is regarding getting packages keyworded on mips in |
| 67 |
a timely fashion, stats above are useful, but knowing the breakdown of |
| 68 |
unstable only vs mixed keywords per package is useful. |
| 69 |
|
| 70 |
In other words, above is close, but doesn't filter out the unstable; |
| 71 |
complaints (aside from broken depgraph) have typically been that |
| 72 |
getting things stabled is a pita for mips. |
| 73 |
|
| 74 |
|
| 75 |
Arch # of pkgs unstable only # % stable in some form |
| 76 |
========= ========= ============= ==== ===================== |
| 77 |
m68k 477 21 456 95.5 |
| 78 |
ppc-macos 499 324 175 35.0 |
| 79 |
sh 1313 63 1250 95.2 |
| 80 |
s390 1183 99 1084 91.6 |
| 81 |
arm 1577 147 1430 90.6 |
| 82 |
sparc 5739 1326 4413 76.8 |
| 83 |
hppa 2432 463 1969 80.9 |
| 84 |
ia64 3378 433 2945 87.1 |
| 85 |
ppc64 3403 508 2823 85.0 |
| 86 |
mips 1720 483 1237 71.9 |
| 87 |
ppc 8723 3045 5678 65.0 |
| 88 |
alpha 3720 348 3372 90.6 |
| 89 |
amd64 9712 3406 6306 64.9 |
| 90 |
x86 11360 2780 8580 75.5 |
| 91 |
|
| 92 |
|
| 93 |
since results are relevant to stable targets only, we rebase the given |
| 94 |
'lagging' stats to only the mixed (at least partially stabled for that |
| 95 |
arch) pkg sets. |
| 96 |
|
| 97 |
Arch lagging stable # % of stable visible |
| 98 |
========== ======= ======== =================== |
| 99 |
ppc-macos 56 175 32.0 |
| 100 |
mips 292 1237 23.6 |
| 101 |
alpha 361 3372 10.7 |
| 102 |
ppc64 278 2823 9.8 |
| 103 |
hppa 176 1969 8.9 |
| 104 |
arm 120 1430 8.3 |
| 105 |
m68k 37 456 8.1 |
| 106 |
s390 87 1084 8.0 |
| 107 |
ia64 221 2945 7.5 |
| 108 |
sh 84 1250 6.7 |
| 109 |
x86 560 8580 6.5 |
| 110 |
ppc 359 5678 6.3 |
| 111 |
amd64 413 6306 5.7 |
| 112 |
sparc 155 4413 3.5 |
| 113 |
|
| 114 |
|
| 115 |
> As expected, supporting minority archs is leading to tree-wide bloat |
| 116 |
> and huge initial rsync times for users. Clearly something has to be |
| 117 |
> done to protect Gentoo from those useless minority archs! I mean, how |
| 118 |
> many users do we *really* have using amd64 or x86? |
| 119 |
|
| 120 |
Actually digging into the data rather then doing the "lies, damn lies, |
| 121 |
and statistics" approach shows a pattern of mips having a large % of |
| 122 |
their stable packages lagging the others. |
| 123 |
|
| 124 |
Granted, ppc-macos has more, but mips has 7x the number of packages... |
| 125 |
plus ppc-macos is effectively a dead arch, they've gone on to prefix |
| 126 |
land for the most part. |
| 127 |
|
| 128 |
Regarding "minority arches", look at arm, s390, hell, even hppa. They |
| 129 |
all have a decent selection of stabled (in some form) packages |
| 130 |
available (exceeding mips), and they're in line with the rough mean |
| 131 |
for % unstable. Hard to argue arm/s390/hppa are 'mainline' arches |
| 132 |
also. |
| 133 |
|
| 134 |
Again; the complaints are regarding mips lagging in keywording; while |
| 135 |
this data doesn't include average time for getting something stabled |
| 136 |
with them, it is mildly damning in terms of how much they're lagging |
| 137 |
for their packages. |
| 138 |
|
| 139 |
Additionally, note to eroyf; this isn't intended as a criticism of |
| 140 |
your work, since you've been bringing the mips percentage down. That |
| 141 |
said, their *is* a disparity there compared to the other arches. |
| 142 |
|
| 143 |
Aside from that, aparently props should be given to sparc; seem to be |
| 144 |
on top of things. |
| 145 |
|
| 146 |
Either way, data to chew on. |
| 147 |
|
| 148 |
~harring |
Archives