Re: [gentoo-project] Call for agenda items - Council meeting 2013-09-10

[Tom Wijsman <TomWij@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 4728 bytes --]

On Thu, 29 Aug 2013 19:17:32 +0200
Pacho Ramos <pacho@gentoo.org> wrote:

> El jue, 29-08-2013 a las 08:22 -0700, Jack Morgan escribió:
> [...]
> > This is a confusing. What is the real problem you are trying to
> > solve here? Stable @system but not having to worry about keywording
> > anything else.. like a desktop (gnome, KDE)?
> > 
> 
> At least from a gnome perspective, we are having some important delays
> with some arches:
>
> ...
>
> But this is only my impression, maybe some of this arches are more
> active in other Gentoo areas.

Let's run it across the whole Portage tree; I'm searching for bugs with
STABLEREQ keyword, that are still open, have an empty "Depends On" field
and have the arch CC-ed:

alpha: 54 bugs.
arm: 28 bugs.
amd64: 61 bugs.
hppa: 2 bugs.
ia64: 61 bugs.
m68k: No bugs.
ppc64: 58 bugs.
ppc: 36 bugs.
s390: 47 bugs.
sh: 86 bugs.
sparc: 78 bugs.
x86: 75 bugs.

Surprisingly, nothing really stands out; but those are absolute
numbers, let's see what happens if we make them proportional. For this
I am going to base myself on http://www.akhuettel.de/gentoo-bugs/kw.php
where I simply take the amount of thousands and divide above numbers by
it, which gives us:

alpha: 54 / 10   = 5.4
arm:   28 / 10   = 2.8
amd64: 61 / 34   = 1.8
hppa:   2 / 9    = 0.2
ia64:  61 / 9.5  = 6.4
m68k:  91 / 2.4  = 37.9
ppc64: 58 / 12.5 = 4.6
ppc:   36 / 19   = 1.9
s390:  47 / 5.4  = 8.7
sh:    86 / 6    = 14.3
sparc: 78 / 12   = 6.5
x86:   75 / 34   = 2.2

So, what we get here now actually shows us how well the arch does
stabilization compared to the amount of ebuilds that the particular arch
has; of course, this doesn't take into account bugs that list resolved
"depends on" and also doesn't take into account when ebuilds are punted
although I don't really feel that those should matter.

People that want to see better statistics are free to improve the search
results to take into account bugs with solely resolved "depends on" bugs
as well as to exclude recent bugs if they feel like; as for the amount
of ebuilds you could opt to use the amount of packages.

So, lower numbers are better; so, let's sort them according to that.

hppa  0.2
ppc   1.9
amd64 2
x86   2.2
arm   2.8
alpha 5.4
ia64  6.4
ppc64 6.4
sparc 6.5
s390  8.7
sh    14.3
m68k  37.9

So, first we see hppa; I often see that stabilized quite fast if I CC
them, kudos to them! Nice to see the statistics here reflect this.

Then we have the major arches ppc, amd64, x86, arm; yup, seems right.
The difference between ppc, amd64 and x86 seems quite small even.

And then, we see all the arches that people here consider minor as a
big group follow up; there's a group around 6 (ia64, ppc64, sparc,
s390) and a group that's somewhat behind around 25 (sh and m68k).

These last arches are the ones listed, except for ppc64; there was the
"(maybe ppc and ppc64?)" question; well, I would say that ppc at least
doesn't seem like a minor arch to me. ppc64 looks to be among them.

So, based on these results I think we should somehow split it up and
turn it into two votes, kinda like this:

Vote 1: Do we drop stable keywords for m68k, sh and s390?

Rationality: These fall under the original reasoning of this thread.

Vote 2: Do we drop stable keywords for alpha, ia64, ppc64 and sparc?

Rationality: Do we (as Gentoo) want to focus on more major arches in a
way that we don't have minor arches block them? What do we want to
pursue? Broader support? Or rather making just the major arches perfect?

I think it would be nice to discuss this last bit as well as see the
Council clarify what we really want to pursue here. This isn't so much
a question about whether to take work away from people doing a bad job;
this is actually more a question of what we want to see people do.

Also, is dropping stable keywords really the right choice? Can we take
other measures perhaps? Make a canonical resource for arch testing?
Make the process easier to become one? ... (see prev ML thread for more)

We're talking too much about the problem (problematic arches); I think
we should talk more about possible solutions (reviving arches), and
perhaps we need to create even more resources (eg. an archmanual)
and easier and faster scripts and tools. Although CPU cycles are free...

(Please assume good faith; I don't want to call a particular arch or
what a particular arch does bad, I just want to see a sane solution)

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]