From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1QpjCM-0005gk-Vx for garchives@archives.gentoo.org; Sat, 06 Aug 2011 15:54:03 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A9C0C21C24A; Sat, 6 Aug 2011 15:53:49 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id A80C021C246 for ; Sat, 6 Aug 2011 15:53:36 +0000 (UTC) Received: from mail-vx0-f181.google.com (mail-vx0-f181.google.com [209.85.220.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: mattst88) by smtp.gentoo.org (Postfix) with ESMTPSA id 26AAE1BC002 for ; Sat, 6 Aug 2011 15:53:36 +0000 (UTC) Received: by vxi39 with SMTP id 39so1881450vxi.40 for ; Sat, 06 Aug 2011 08:53:34 -0700 (PDT) Received: by 10.52.180.166 with SMTP id dp6mr3832239vdc.314.1312646014074; Sat, 06 Aug 2011 08:53:34 -0700 (PDT) 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 Received: by 10.52.168.1 with HTTP; Sat, 6 Aug 2011 08:53:14 -0700 (PDT) In-Reply-To: <4E3D60D6.2070702@gentoo.org> References: <1312307887.2901.2@NeddySeagoon> <4E38B4D9.7020603@gentoo.org> <1312404150.2882.2@NeddySeagoon> <20110804200630.GE4840@comet.ucsd.edu> <1312496361.2864.0@NeddySeagoon> <4E3BC710.6090402@gentoo.org> <20110805104952.GK81662@gentoo.org> <4E3BCD6E.8030101@gentoo.org> <4E3BED69.6060003@gentoo.org> <20110805134412.GC17729@gentoo.org> <4E3BF61F.7050300@gentoo.org> <4E3C1B32.2020105@gentoo.org> <4E3C39C5.3010700@gentoo.org> <4E3CB0E3.4030108@gentoo.org> <4E3D10B0.80107@gentoo.org> <4E3D60D6.2070702@gentoo.org> From: Matt Turner Date: Sat, 6 Aug 2011 11:53:14 -0400 Message-ID: Subject: Re: [gentoo-project] Council discuss: overlapping council terms of two years To: gentoo-project@lists.gentoo.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: X-Archives-Hash: 026bbbf596634ff9018488b8f40269a8 On Sat, Aug 6, 2011 at 11:42 AM, Markos Chandras wrot= e: > On 08/06/2011 04:33 PM, Matt Turner wrote: >> On Sat, Aug 6, 2011 at 6:00 AM, Markos Chandras >> wrote: >>> I never said to completely drop these arches. When did I say that? >>> I just want a more realistic approach on how well an arch is >>> supported. Why you people are afraid to admit that we have >>> problems? Having an arch with constantly >200 stabilization bugs >>> open clearly proves that the manpower cannot handle the situation. >> >> I think it's important to put some numbers on this. >> >> x86 =A0 =A0 =A0 =A0 =A0 =A0 =A080 =A0 =A0 =A02 =A0 =A0 =A013 amd64 =A0 = =A0 =A0 =A0 =A0 =A040 =A0 =A0 =A01 =A0 =A0 =A07 > > This is just hilarious :) The numbers of developers are not even close > to reality Same situation with the rest of the architectures, really. >> The only architecture that is seriously backlogged in ppc, which is >> probably due to the fact that we used to have lots of users. Just a >> couple of weeks ago, ppc64 was in the same situation, until >> xarthisius > > What if xarthisius, armin76, me and jer take 3 months off? What an evil > scenario :). The problem is when an architecture relies on a *single* > (or max 2) developers. You can't possibly claim that this architecture > is supported. You have a single/double point of failure. They can easily > retire someday or even lose their motivation. And then what? It would be > far too late to act We're in pretty bad shape if that happens. We do have http://www.gentoo.org/proj/en/infrastructure/dev-machines.xml Maintainers could help arch teams greatly by giving their package a quick test build on the development boxes. Not sure that's really an acceptable solution though. I wonder if we can't set up an automated system where a package maintainer goes to a webpage and enters the package they'd like to submit for a keyword request. The page would display the requirements for each architecture, and the maintainer could then start a test build that would run on the development boxes in a testing chroot, and then give the results back to the maintainer. That would certainly make the situation simpler for everyone. Maybe that's deserving of a separation thread. Matt