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 1297A138A3F for ; Sun, 5 Apr 2015 19:50:53 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id EBBE4E08C2; Sun, 5 Apr 2015 19:50:46 +0000 (UTC) Received: from mail-ob0-f171.google.com (mail-ob0-f171.google.com [209.85.214.171]) (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 70C2CE0841 for ; Sun, 5 Apr 2015 19:50:46 +0000 (UTC) Received: by obbfy7 with SMTP id fy7so17956242obb.2 for ; Sun, 05 Apr 2015 12:50:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=bd0ctsj5V7dP8rd69ILZ9GEZtW4ODbexw3rgCj8A7iY=; b=KveMw9mfiqLQHSNRVi0SlbHcyCNi92aQsCb4S3T1R+uZW/dvj3cC7u2gANuPofru8S vgyQVPCuRvZ4J16UUtrHDxjkNxCwe+o/OhN6tz/BuWKkeJvBmUlTJO1qnl4tgTyZ3PtQ 2KPGD53/n4SyszzHNpPpMVVnuj+UdmvgnSDCdbbvYSocl+oXTS99Ok/dc0+0wJrCdoTZ SYs0xG+m1ZiVExYgN3TuSWS7VL5HK24vczm2bbAYpjWJmHUna771g1Lsg3MNqg52xeJO 91RzA7PiDwhW/tTD3h3NMHhlCVXo4sR/ggj9HmR55lRS9miuhqVYyEr2eHhsFLhOS5HA 1AEg== X-Received: by 10.60.35.102 with SMTP id g6mr14766465oej.7.1428263445790; Sun, 05 Apr 2015 12:50:45 -0700 (PDT) Received: from linux1 (cpe-76-187-91-128.tx.res.rr.com. [76.187.91.128]) by mx.google.com with ESMTPSA id h8sm2003942obe.2.2015.04.05.12.50.45 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 05 Apr 2015 12:50:45 -0700 (PDT) Sender: William Hubbs Received: (nullmailer pid 2954 invoked by uid 1000); Sun, 05 Apr 2015 19:50:44 -0000 Date: Sun, 5 Apr 2015 14:50:44 -0500 From: William Hubbs To: gentoo-project@lists.gentoo.org Subject: Re: [gentoo-project] Re: Council meeting 2015-04-14: call for agenda items Message-ID: <20150405195044.GA2917@linux1> Mail-Followup-To: gentoo-project@lists.gentoo.org References: <20150402141428.GA31638@oregano.home.lan> <201504032214.01310.dilfridge@gentoo.org> <20150404220205.GA415@linux1> <1428237147.22472.1.camel@gentoo.org> 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-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wRRV7LY7NUeQGEoC" Content-Disposition: inline In-Reply-To: <1428237147.22472.1.camel@gentoo.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Archives-Salt: 66814960-7299-4709-9c58-38f85e2a665a X-Archives-Hash: 33b350b892ce4f62fb27b5ebb567cb05 --wRRV7LY7NUeQGEoC Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Apr 05, 2015 at 02:32:27PM +0200, Pacho Ramos wrote: > El s=E1b, 04-04-2015 a las 17:02 -0500, William Hubbs escribi=F3: > > 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 blockin= g a > > > >>> pending STABLEREQ, for 90 days with archs CCed and otherwise re= ady > > > >>> to be stabilized, the maintainer can remove older stable versio= ns 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 k= nown > > > >>> 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 ba= d 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 ens= ure > > > > 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. > > > > > > >=20 > > > 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. > >=20 > > 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. > >=20 > > William > >=20 >=20 > I wonder if maybe we should suggest to finally move ia64/alpha/sparc to > testing (as was done for mips, sh...) :/ =20 Also let's add ppc and ppc64 to this list; they were brought up in the message starting this discussion. I personally would vote for moving all of these arch's to exp status. That becomes a separate action and does not answer the underlying question that keeps coming up. That question is, if a maintainer opens a stable request and assigns an arch team to it, and that arch team has no activity on the stable request for 90 days, what should the maintainer do? I would say that the maintainer can at their discression remove the old stable version. Yes, that would temporarily break the stable depgraph, but it could be argued that the old version is by definition broken since the newer version the maintainer wants stabilized could have fixes for bugs in the old version. William --wRRV7LY7NUeQGEoC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlUhkhQACgkQblQW9DDEZTh9+QCcCVvMPmDUqiJgWgPRZIQiL+s3 XyAAn3CfF+1hoVvEk23elbNbrLX7cNmp =gjha -----END PGP SIGNATURE----- --wRRV7LY7NUeQGEoC--