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 1EDC5138A3F for ; Sun, 5 Apr 2015 12:44:12 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B73B4E09E4; Sun, 5 Apr 2015 12:44:08 +0000 (UTC) Received: from mail-ie0-f181.google.com (mail-ie0-f181.google.com [209.85.223.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 2F914E09A9 for ; Sun, 5 Apr 2015 12:44:08 +0000 (UTC) Received: by iedfl3 with SMTP id fl3so7133778ied.1 for ; Sun, 05 Apr 2015 05:44:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:content-type:content-transfer-encoding; bh=NJpIYoHxPpmxuEDFKQQb1jAazHbfME+YtYtcWiEkip0=; b=KAUfhg1A/rArc2nU9bb9R+q2Rjj59hArzG2H/mApyjcM0KAHImJcgUNWNns69dFoGS 1Lk49JSj7LeYqKSE1v8PT+C1fl5BW31V3B02e1dPWbDbxCF6iHo6MZ0mXRRtbhNw3DKq KkYZLzk0I6SxRWFux8F2e0v1th6IMrKrUp+G1sntQdxuzbKAx0yMCeUeat4z9UV5zrVF 1ORedmNqQTIgzCfTBQiRJd2xqBgoV0IrM9dYLMlW5WLxSy9FF/qhb5V6snGqQZIPrTvK QldlDRkeXtZewJhCi30fVJPd2N34H/zoGcjTr6y5ONhX4T9T1ENmRNt2nBxQMCQcRWeL 6X3Q== 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 X-Received: by 10.50.35.195 with SMTP id k3mr40229476igj.11.1428237847494; Sun, 05 Apr 2015 05:44:07 -0700 (PDT) Sender: yngwin@gmail.com Received: by 10.64.240.141 with HTTP; Sun, 5 Apr 2015 05:44:07 -0700 (PDT) In-Reply-To: <1428237147.22472.1.camel@gentoo.org> References: <20150402141428.GA31638@oregano.home.lan> <201504032214.01310.dilfridge@gentoo.org> <20150404220205.GA415@linux1> <1428237147.22472.1.camel@gentoo.org> Date: Sun, 5 Apr 2015 20:44:07 +0800 X-Google-Sender-Auth: EXLhwd_-utUgwz37xEStKhw3oR8 Message-ID: Subject: Re: [gentoo-project] Re: Council meeting 2015-04-14: call for agenda items From: Ben de Groot To: gentoo-project Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: eb385de1-5bac-407f-8933-8509abb0f7f8 X-Archives-Hash: 1d6350f05ab3ce71752f39d3e2e0b0f8 On 5 April 2015 at 20:32, Pacho Ramos wrote: > El s=C3=A1b, 04-04-2015 a las 17:02 -0500, William Hubbs escribi=C3=B3: >> 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 a= lpha only was: >> > >> >> > >>> "If a maintainer has an open STABLEREQ, or a KEYWORDREQ blocking= a >> > >>> pending STABLEREQ, for 90 days with archs CCed and otherwise rea= dy >> > >>> to be stabilized, the maintainer can remove older stable version= s of >> > >>> the package at their discretion. A package is considered ready t= o be >> > >>> stabilized if it has been in the tree for 30 days, and has no kn= own >> > >>> major flaws on arches that upstream considers supported." >> > >> >> > >> If we're bringing this up again, we should maybe also clarify it. M= y understanding at the time was that the removal of older stable versions m= ay 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 ensu= re >> > > 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) In support of this I offer bug #529196. --=20 Cheers, Ben | yngwin Gentoo developer