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 82AD6138247 for ; Wed, 22 Jan 2014 17:05:28 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E0CB7E0E31; Wed, 22 Jan 2014 17:05:08 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id B08E0E0E28 for ; Wed, 22 Jan 2014 17:05:07 +0000 (UTC) Received: from marga.jer-c2.orkz.net (D4B2706A.static.ziggozakelijk.nl [212.178.112.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jer) by smtp.gentoo.org (Postfix) with ESMTPSA id CA70C33FBC8 for ; Wed, 22 Jan 2014 15:46:07 +0000 (UTC) Date: Wed, 22 Jan 2014 16:46:01 +0100 From: Jeroen Roovers To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: Add a KEYWORD representing any arch Message-ID: <20140122164601.0b51a460@marga.jer-c2.orkz.net> In-Reply-To: <21211.40692.574361.53989@a1i15.kph.uni-mainz.de> References: <20140114213719.GA2684@laptop.home> <201401190336.10465.vapier@gentoo.org> <1390123713.24148.121.camel@belkin5> <21211.40692.574361.53989@a1i15.kph.uni-mainz.de> X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; 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=US-ASCII Content-Transfer-Encoding: 7bit X-Archives-Salt: 6027875a-4ad5-4440-bacf-57deb4b598c7 X-Archives-Hash: 9217c44b706368ad86b94c0975fc17df On Sun, 19 Jan 2014 10:46:28 +0100 Ulrich Mueller wrote: > Instead, we should come up with a clear set of rules under what > circumstances package maintainers are allowed to stabilise ebuilds > themselves on all architectures. The cases where stabilisation is important (for security, progress) are usually those where this arbitrary type of stabilisation is not an option, unless we drop all pretence of upholding the dictionary meaning of "stabilisation". What we need is architecture teams that clearly do the work (as a team), or we drop their stable status. Recent "advances" in stabilisation practices certainly haven't helped establish a reliable picture of some teams. If a team cannot keep up stabilising thousands of packages, then it should focus in the short term on dropping keywords for "extra" packages, and then in the long term focus on getting a reliable base system up to date (i.e. drop all the "fun" keywording and focus on what that platform really must have to get a system running). If all that doesn't pan out, then we should set the QA hounds on them. :) jer