1 |
On Thu, 29 Aug 2013 19:17:32 +0200 |
2 |
Pacho Ramos <pacho@g.o> wrote: |
3 |
|
4 |
> El jue, 29-08-2013 a las 08:22 -0700, Jack Morgan escribió: |
5 |
> [...] |
6 |
> > This is a confusing. What is the real problem you are trying to |
7 |
> > solve here? Stable @system but not having to worry about keywording |
8 |
> > anything else.. like a desktop (gnome, KDE)? |
9 |
> > |
10 |
> |
11 |
> At least from a gnome perspective, we are having some important delays |
12 |
> with some arches: |
13 |
> |
14 |
> ... |
15 |
> |
16 |
> But this is only my impression, maybe some of this arches are more |
17 |
> active in other Gentoo areas. |
18 |
|
19 |
Let's run it across the whole Portage tree; I'm searching for bugs with |
20 |
STABLEREQ keyword, that are still open, have an empty "Depends On" field |
21 |
and have the arch CC-ed: |
22 |
|
23 |
alpha: 54 bugs. |
24 |
arm: 28 bugs. |
25 |
amd64: 61 bugs. |
26 |
hppa: 2 bugs. |
27 |
ia64: 61 bugs. |
28 |
m68k: No bugs. |
29 |
ppc64: 58 bugs. |
30 |
ppc: 36 bugs. |
31 |
s390: 47 bugs. |
32 |
sh: 86 bugs. |
33 |
sparc: 78 bugs. |
34 |
x86: 75 bugs. |
35 |
|
36 |
Surprisingly, nothing really stands out; but those are absolute |
37 |
numbers, let's see what happens if we make them proportional. For this |
38 |
I am going to base myself on http://www.akhuettel.de/gentoo-bugs/kw.php |
39 |
where I simply take the amount of thousands and divide above numbers by |
40 |
it, which gives us: |
41 |
|
42 |
alpha: 54 / 10 = 5.4 |
43 |
arm: 28 / 10 = 2.8 |
44 |
amd64: 61 / 34 = 1.8 |
45 |
hppa: 2 / 9 = 0.2 |
46 |
ia64: 61 / 9.5 = 6.4 |
47 |
m68k: 91 / 2.4 = 37.9 |
48 |
ppc64: 58 / 12.5 = 4.6 |
49 |
ppc: 36 / 19 = 1.9 |
50 |
s390: 47 / 5.4 = 8.7 |
51 |
sh: 86 / 6 = 14.3 |
52 |
sparc: 78 / 12 = 6.5 |
53 |
x86: 75 / 34 = 2.2 |
54 |
|
55 |
So, what we get here now actually shows us how well the arch does |
56 |
stabilization compared to the amount of ebuilds that the particular arch |
57 |
has; of course, this doesn't take into account bugs that list resolved |
58 |
"depends on" and also doesn't take into account when ebuilds are punted |
59 |
although I don't really feel that those should matter. |
60 |
|
61 |
People that want to see better statistics are free to improve the search |
62 |
results to take into account bugs with solely resolved "depends on" bugs |
63 |
as well as to exclude recent bugs if they feel like; as for the amount |
64 |
of ebuilds you could opt to use the amount of packages. |
65 |
|
66 |
So, lower numbers are better; so, let's sort them according to that. |
67 |
|
68 |
hppa 0.2 |
69 |
ppc 1.9 |
70 |
amd64 2 |
71 |
x86 2.2 |
72 |
arm 2.8 |
73 |
alpha 5.4 |
74 |
ia64 6.4 |
75 |
ppc64 6.4 |
76 |
sparc 6.5 |
77 |
s390 8.7 |
78 |
sh 14.3 |
79 |
m68k 37.9 |
80 |
|
81 |
So, first we see hppa; I often see that stabilized quite fast if I CC |
82 |
them, kudos to them! Nice to see the statistics here reflect this. |
83 |
|
84 |
Then we have the major arches ppc, amd64, x86, arm; yup, seems right. |
85 |
The difference between ppc, amd64 and x86 seems quite small even. |
86 |
|
87 |
And then, we see all the arches that people here consider minor as a |
88 |
big group follow up; there's a group around 6 (ia64, ppc64, sparc, |
89 |
s390) and a group that's somewhat behind around 25 (sh and m68k). |
90 |
|
91 |
These last arches are the ones listed, except for ppc64; there was the |
92 |
"(maybe ppc and ppc64?)" question; well, I would say that ppc at least |
93 |
doesn't seem like a minor arch to me. ppc64 looks to be among them. |
94 |
|
95 |
So, based on these results I think we should somehow split it up and |
96 |
turn it into two votes, kinda like this: |
97 |
|
98 |
Vote 1: Do we drop stable keywords for m68k, sh and s390? |
99 |
|
100 |
Rationality: These fall under the original reasoning of this thread. |
101 |
|
102 |
Vote 2: Do we drop stable keywords for alpha, ia64, ppc64 and sparc? |
103 |
|
104 |
Rationality: Do we (as Gentoo) want to focus on more major arches in a |
105 |
way that we don't have minor arches block them? What do we want to |
106 |
pursue? Broader support? Or rather making just the major arches perfect? |
107 |
|
108 |
I think it would be nice to discuss this last bit as well as see the |
109 |
Council clarify what we really want to pursue here. This isn't so much |
110 |
a question about whether to take work away from people doing a bad job; |
111 |
this is actually more a question of what we want to see people do. |
112 |
|
113 |
Also, is dropping stable keywords really the right choice? Can we take |
114 |
other measures perhaps? Make a canonical resource for arch testing? |
115 |
Make the process easier to become one? ... (see prev ML thread for more) |
116 |
|
117 |
We're talking too much about the problem (problematic arches); I think |
118 |
we should talk more about possible solutions (reviving arches), and |
119 |
perhaps we need to create even more resources (eg. an archmanual) |
120 |
and easier and faster scripts and tools. Although CPU cycles are free... |
121 |
|
122 |
(Please assume good faith; I don't want to call a particular arch or |
123 |
what a particular arch does bad, I just want to see a sane solution) |
124 |
|
125 |
-- |
126 |
With kind regards, |
127 |
|
128 |
Tom Wijsman (TomWij) |
129 |
Gentoo Developer |
130 |
|
131 |
E-mail address : TomWij@g.o |
132 |
GPG Public Key : 6D34E57D |
133 |
GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D |