From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 03B9D13832E for ; Wed, 17 Aug 2016 14:25:53 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 73C2A21C17C; Wed, 17 Aug 2016 14:25:44 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 4FA6F21C06D for ; Wed, 17 Aug 2016 14:25:43 +0000 (UTC) Received: from [192.168.1.107] (unknown [92.185.72.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: pacho) by smtp.gentoo.org (Postfix) with ESMTPSA id 74E56340E0A; Wed, 17 Aug 2016 14:25:41 +0000 (UTC) Message-ID: <1471443937.31785.67.camel@gentoo.org> Subject: Re: [gentoo-dev] New Working Group established to evaluate the stable tree From: Pacho Ramos To: Rich Freeman Cc: gentoo-dev Date: Wed, 17 Aug 2016 16:25:37 +0200 In-Reply-To: References: <6046d13b-1a54-aa5e-ab16-df448b0f8c59@gentoo.org> <1471248012.31785.32.camel@gentoo.org> <20160815141922.GA3878@linux1.gaikai.biz> <1bff7eb3-cc91-bba7-1f7f-9e7f76906df3@gentoo.org> <20160815161241.GA21389@whubbs1.gaikai.biz> <20160815173130.GA21750@whubbs1.gaikai.biz> <20160815191248.GA21981@whubbs1.gaikai.biz> <1471423826.31785.52.camel@gentoo.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.20.4 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-Transfer-Encoding: 8bit X-Archives-Salt: c30d9ab5-8e3b-400b-beed-785aa8f80c19 X-Archives-Hash: 73b51c56013f27d85df641b83393485d El mié, 17-08-2016 a las 09:07 -0400, Rich Freeman escribió: > I'm not sure I agree.  If it is scripted, then isn't it just a few > more cpu cycles? Well... until I see that script, I won't trust it. We are for a long time supposedly allowing people to move things to testing after 90 days and that is not working at all because of that. Simply try to go to our current pending gnome stabilization, and you will see how difficult does it turn (for example, another issue is with the optional reverse dependencies, that would require to use.mask some USE flags for some packages in some arches). Once that script is ready... I am unsure about why are we even discussing this as, after that dekeywording task can be feasible after 90 days, the picture in all exotic arches with change so much that we would need to meet again in some months to evaluate the result  The problem is that I don't think that is really feasible... and looking to that script still being unavailable and we still discussing about how to improve this makes me think it's a harder issue to achieve :( > Why even have a stable keyword?  What does it even mean if everything > gets stabilized in 90 days whether it is tested or not, or whether it > even builds? > Well, personally I don't think why many of that arches are supposedly still having a reliable stable tree. Most of them are relying on Ago doing most of the work (that is mostly buildtime testing... and I have no issue with that, as adding also runtime testing to all the packages and arches is completely unrealistic). Anyway the "stable keyword" would still give the packages 90 days of being in the tree (at least) for the hypothetical bugs to appear. If they don't appear, maybe they don't exist (like in most cases) or, in the worst case, that arches are so few used that I am sure the burden would be high enough.   > Take the degenerate case.  Suppose an arch team is completely AWOL. > If we go with my route and de-stabilize packages then you end up with > an arch that is de-facto experimental with no stable packages (or > maybe @system only) after some period of time.  If we instead > stabilize anything after 90 days if there is no response then the > AWOL > arch team ends up having more stable packages than any other arch, > because they're the only ones not reporting bugs. Well, if we have the script, I am the first one preferring your route... but that route is of dekeywording stuff is allowed for a long time and we still have nothing, then, until that script is even a draft, I don't consider it a real option.