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 1Rbwas-0003zB-98 for garchives@archives.gentoo.org; Sat, 17 Dec 2011 15:54:40 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 0F02E21C0DE; Sat, 17 Dec 2011 15:54:28 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id C2C5421C03B for ; Sat, 17 Dec 2011 15:53:57 +0000 (UTC) Received: from epia.jer-c2.orkz.net (D4B2706A.static.ziggozakelijk.nl [212.178.112.106]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jer) by smtp.gentoo.org (Postfix) with ESMTPSA id C85041B400C for ; Sat, 17 Dec 2011 15:53:56 +0000 (UTC) Date: Sat, 17 Dec 2011 16:53:50 +0100 From: Jeroen Roovers To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] mass stabilization and non-x86-non-amd64 arches Message-ID: <20111217165350.0e5a8001@epia.jer-c2.orkz.net> In-Reply-To: <1324136311.3047.12.camel@belkin4> References: <4EECB3A1.6010006@gentoo.org> <1324136311.3047.12.camel@belkin4> X-Mailer: Claws Mail 3.7.10 (GTK+ 2.24.5; i686-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: a1c4629e-f4c3-4805-8916-117608155a01 X-Archives-Hash: b5a3c56ff99f3aa20a838977d24cc67f On Sat, 17 Dec 2011 16:38:31 +0100 Pacho Ramos wrote: > El s=C3=A1b, 17-12-2011 a las 16:22 +0100, "Pawe=C5=82 Hajdan, Jr." escri= bi=C3=B3: > > For several mass-filed stabilization bugs I got comments why I > > didn't cc arches like ppc. And correctly so. > > One problem is that I cc x86 and amd64 via "edit many bugs at once" > > Bugzilla feature, and when filing bugs the script checks that it's > > repoman-possible to stabilize given package on x86 and amd64. > >=20 > > Not all packages are even keyworded ~ppc, and I guess there are > > packages that can be stabilized on x86 and amd64, but not ppc > > because of ~ppc dependencies. I would think you'd stabilise only packages for which a previous version is already stable. If you focused on that, the problem of dependencies being unstable wouldn't exist. ~arch on all ebuilds simply means no security support, so asking to go stable means adding that, and this changes the entire purpose of your stabilisation bugs when you ask arch teams to go stable for the first time. > > All of that is of course solvable with a smarter script, however I'm > > really worried about the additional load on the "rare arches". Um, so somebody else will have to go through the whole load of bug reports to fix the arch teams you left out? Because your script doesn't do it? > > What do you think? Should I make my scripts smarter, or is it fine > > to just cc x86 and amd64? Is anyone from non-x86-non-amd64 arch > > teams annoyed by the queue of stabilization bugs? I'd like you to file correct stabilisation bug reports. Which means CCing all arches that have /previous/ ebuilds stable. We've always done it like this. > I am not in ppc* teams but, from my point of view, looks like they are > understaffed and I doubt they could handle so many requests. Same goes for all the less popular architectures. > For mass stabilization purposes I would keep the script for amd64/x86 > only for now :-/ The only way to maintain these architectures properly is to not exclude them in the first place. Once you start doing that, you might as well stop supporting security, go ~arch or drop them entirely. The only way to show there is a problem with staffing and/or the availability of supported systems is to include these arch teams in stabilisation bugs and then draft in more developers. In a volunteer project, hiding the problems makes sure no one will come in and fix them. The good thing about including slow arch teams is that when you've gathered up a couple hundred or thousand bug reports, you can make a very good case about dropping the old stable ebuilds, effectively moving the slow arch to unstable. jer