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 5E6CC138A3F for ; Sun, 5 Apr 2015 12:32:45 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 8F977E0940; Sun, 5 Apr 2015 12:32:39 +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 D2EB8E092B for ; Sun, 5 Apr 2015 12:32:38 +0000 (UTC) Received: from [192.168.1.223] (100.159.16.95.dynamic.jazztel.es [95.16.159.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: pacho) by smtp.gentoo.org (Postfix) with ESMTPSA id 3C013340706 for ; Sun, 5 Apr 2015 12:32:37 +0000 (UTC) Message-ID: <1428237147.22472.1.camel@gentoo.org> Subject: Re: [gentoo-project] Re: Council meeting 2015-04-14: call for agenda items From: Pacho Ramos To: gentoo-project@lists.gentoo.org Date: Sun, 05 Apr 2015 14:32:27 +0200 In-Reply-To: <20150404220205.GA415@linux1> References: <20150402141428.GA31638@oregano.home.lan> <201504032214.01310.dilfridge@gentoo.org> <20150404220205.GA415@linux1> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.11 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-Transfer-Encoding: 8bit X-Archives-Salt: 940b76f4-6a7d-454b-b031-f349cbe2dc9c X-Archives-Hash: 3d10842cc60a8cec7086893943ddab9f El sáb, 04-04-2015 a las 17:02 -0500, William Hubbs escribió: > On Sat, Apr 04, 2015 at 11:13:54AM -0400, Rich Freeman wrote: > > On Sat, Apr 4, 2015 at 10:31 AM, Michael Palimaka wrote: > > > On 04/04/15 07:13, Andreas K. Huettel wrote: > > >> Am Freitag, 3. April 2015, 22:01:32 schrieb Rich Freeman: > > >> > > >>> For reference, the policy we came up with last time for ia64 and alpha only was: > > >> > > >>> "If a maintainer has an open STABLEREQ, or a KEYWORDREQ blocking a > > >>> pending STABLEREQ, for 90 days with archs CCed and otherwise ready > > >>> to be stabilized, the maintainer can remove older stable versions of > > >>> the package at their discretion. A package is considered ready to be > > >>> stabilized if it has been in the tree for 30 days, and has no known > > >>> major flaws on arches that upstream considers supported." > > >> > > >> If we're bringing this up again, we should maybe also clarify it. My understanding at the time was that the removal of older stable versions may leave the deptree of the arch in question in a broken state, however bad that is. There seem to be different interpretations though. > > > > > > I am against breaking the deptree for any arch that has a stable > > > profile. It's reasonable to expect devs to dekeyword revdeps to ensure > > > the deptree is consistent. > > > If the state of the arch really is that bad, its profiles should be > > > switched to dev or exp to reflect reality. > > > > > > > Tend to agree, but be careful what you ask for. Which would the arch > > team REALLY prefer after ignoring a bug for 90 days? The stable > > depgraph is broken and they have to hurry and stabilize one package to > > fix it, OR the stable depgraph is fine, but suddenly 300 packages no > > longer have stable keywords at all. Fixing the latter would be a > > royal PITA without git. Getting rid of stable on those 300 packages > > is also a lot of work for the package maintainer without some kind of > > tool to automate this. > > I agree. I think the temporary stable depgraph breakage is the lesser of > the two evils in this case. Also, I would add that, once an arch team > starts getting hit with enough deptree breakage they should be able to > make the decision to revert their profiles to dev or exp without council > intervention. > > William > I wonder if maybe we should suggest to finally move ia64/alpha/sparc to testing (as was done for mips, sh...) :/ If we are willing to break their stable tree, probably would be better to finally move them to testing (or to only have a really small stable tree for base-system/toolchain)