From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id BB7991381F3 for ; Thu, 29 Aug 2013 18:33:15 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 76601E0EAB; Thu, 29 Aug 2013 18:33:10 +0000 (UTC) Received: from gerard.telenet-ops.be (gerard.telenet-ops.be [195.130.132.48]) by pigeon.gentoo.org (Postfix) with ESMTP id 89681E0EAA for ; Thu, 29 Aug 2013 18:33:09 +0000 (UTC) Received: from TOMWIJ-GENTOO ([94.226.55.127]) by gerard.telenet-ops.be with bizsmtp id JiZ81m00i2khLEN0HiZ8jQ; Thu, 29 Aug 2013 20:33:08 +0200 Date: Thu, 29 Aug 2013 20:33:01 +0200 From: Tom Wijsman To: gentoo-project@lists.gentoo.org Subject: Re: [gentoo-project] Call for agenda items - Council meeting 2013-09-10 Message-ID: <20130829203301.288a593a@TOMWIJ-GENTOO> In-Reply-To: <1377796652.5477.15.camel@localhost> References: <21020.30575.805569.383992@a1i15.kph.uni-mainz.de> <20130829152248.GA3432@shimane.bonyari.local> <1377796652.5477.15.camel@localhost> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.20; x86_64-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Project discussion list X-BeenThere: gentoo-project@lists.gentoo.org Reply-To: gentoo-project@lists.gentoo.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/cDjcuaqnR0P+vNAdvzz=xvy"; protocol="application/pgp-signature" X-Archives-Salt: 62e61377-81e0-491b-9985-24514a6e8430 X-Archives-Hash: 416eaec48c8aab57388cc134b3912838 --Sig_/cDjcuaqnR0P+vNAdvzz=xvy Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, 29 Aug 2013 19:17:32 +0200 Pacho Ramos wrote: > El jue, 29-08-2013 a las 08:22 -0700, Jack Morgan escribi=F3: > [...] > > 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)? > >=20 >=20 > 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 =3D 5.4 arm: 28 / 10 =3D 2.8 amd64: 61 / 34 =3D 1.8 hppa: 2 / 9 =3D 0.2 ia64: 61 / 9.5 =3D 6.4 m68k: 91 / 2.4 =3D 37.9 ppc64: 58 / 12.5 =3D 4.6 ppc: 36 / 19 =3D 1.9 s390: 47 / 5.4 =3D 8.7 sh: 86 / 6 =3D 14.3 sparc: 78 / 12 =3D 6.5 x86: 75 / 34 =3D 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) --=20 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 --Sig_/cDjcuaqnR0P+vNAdvzz=xvy Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (GNU/Linux) iQEcBAEBAgAGBQJSH5PhAAoJEJWyH81tNOV9NZsH/iIUk/WWH61Z9TRxrkuFNOyN wJt6a0e8mILva+EKncxfXvls4xPP3UUTmJlH+0tpL2zeLuHRdHlBWfLy0vYvPfkE cuj05LxO7BtHaHkuJ6ALe0GWXXJFHx2l50ze3UaP1k19YZpWgoLFSmOQK3qYr3Oz TRzTmRvWFbsFIpkFFUdG0D7l00fXzEqp2yGUH/l7XB7kLAoz+a0Y19GB/srqEPRm cIFakqfrdQ0sQFqYgIc83m8gLStrdzz2/Uo6JHNPQa3a4/yRd8mWJUsBKkTvGcqG zeRKGy37/i4uUXO6SnuPE+e7sYmg3b2DtqfFHgnvGvfcl5lAvEg72kCMwb36uD0= =lLla -----END PGP SIGNATURE----- --Sig_/cDjcuaqnR0P+vNAdvzz=xvy--