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 361A213877A for ; Sat, 26 Jul 2014 15:39:16 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id AF627E0E7B; Sat, 26 Jul 2014 15:39:11 +0000 (UTC) Received: from mail-oa0-f42.google.com (mail-oa0-f42.google.com [209.85.219.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id C9F0DE0E65 for ; Sat, 26 Jul 2014 15:39:10 +0000 (UTC) Received: by mail-oa0-f42.google.com with SMTP id n16so7012054oag.29 for ; Sat, 26 Jul 2014 08:39:10 -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=MZDFxSnGHE7Aol2+ou628PMqgXd0b1XnHG5ERWrsOHM=; b=0WOw22hMCGuNHXjm8fyvBau4nk/2NkPlPhudYLBtQfriBHDfPo8DocAnTdHeqF/2ZU vuVZjP5KvKUD8J7ZZ3/V1xp+uO/c/igfeahBsEm/FXVVuNT2Jb3Z80j4YxuzIGrJLePC HBP3cL14z/NcrdoYseGwhdCO2Mi1pJjF+LagVQZld6Q2af/HX9XBZnvEWMo6VgScVESC TFmeu8qypkzoDpbiDY4OU0zzpeA+twcs0IjDVIY9r4mE8mEXW0rBe0P1Szc39NklMkmZ ij81iSdwR0dOP4he7ugKvcB46V714IkdCn6mmE2dhNzdCLCxdjQi3oOKjLxAfNsRG6Yf vV6g== X-Received: by 10.60.133.203 with SMTP id pe11mr33069506oeb.24.1406389149974; Sat, 26 Jul 2014 08:39:09 -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 s10sm26425187obx.29.2014.07.26.08.39.07 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sat, 26 Jul 2014 08:39:08 -0700 (PDT) Sender: William Hubbs Received: (nullmailer pid 13672 invoked by uid 1000); Sat, 26 Jul 2014 15:39:04 -0000 Date: Sat, 26 Jul 2014 10:39:04 -0500 From: William Hubbs To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] About current ppc/ppc64 status Message-ID: <20140726153904.GA13389@linux1> Mail-Followup-To: gentoo-dev@lists.gentoo.org References: <1406316517.20388.22.camel@gentoo.org> <53D2B248.4090004@gentoo.org> <1406317833.20388.24.camel@gentoo.org> <53D2B6A0.4070009@gentoo.org> <20140725200743.GA5497@linux1> <1406363809.20388.32.camel@gentoo.org> <1406364266.20388.34.camel@gentoo.org> 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: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vkogqOf2sHV7VnPd" Content-Disposition: inline In-Reply-To: <1406364266.20388.34.camel@gentoo.org> User-Agent: Mutt/1.5.22 (2013-10-16) X-Archives-Salt: 8dccedbe-417c-454d-a48c-849b873d41bb X-Archives-Hash: 76ef20ddc1f9dcc0e58e625bbbb4677b --vkogqOf2sHV7VnPd Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jul 26, 2014 at 10:44:26AM +0200, Pacho Ramos wrote: > El s=E1b, 26-07-2014 a las 10:36 +0200, Pacho Ramos escribi=F3: > > El vie, 25-07-2014 a las 15:07 -0500, William Hubbs escribi=F3: > > > On Fri, Jul 25, 2014 at 03:57:20PM -0400, Anthony G. Basile wrote: > > > > On 07/25/14 15:50, Pacho Ramos wrote: > > > > > El vie, 25-07-2014 a las 15:38 -0400, Anthony G. Basile escribi= =F3: > > > > >> On 07/25/14 15:28, Pacho Ramos wrote: > > > > >>> That is the reason for me thinking that maybe the way to go wou= ld be to > > > > >>> do the opposite -> keep only base-system and a few others stabl= e and > > > > >>> drop stable for most of the rest. This big effort could be acco= mplished > > > > >>> in a week by other developers willing to help (like me) and wou= ld solve > > > > >>> the issue for the long term. I guess that is what HPPA team did= in the > > > > >>> past and I think it's working pretty well for them (in summary,= have a > > > > >>> stable tree they are able to keep stable). That will also help = people in > > > > >>> ppc* teams to know that the remaining stabilization bugs, apart= of being > > > > >>> much less, are important enough to deserve rapid attention, as = opposed > > > > >>> to current situation that will have some important bugs mixed w= ith tons > > > > >>> of stabilization requests of apps that got ppc stable keywords = years ago > > > > >>> and are currently no so important. > > > > >>> > > > > >> Yes, please let's just do base system stable. I've been randoml= y taking > > > > >> care of ppc but nothing systematic. Its pretty spotty. But at = the same > > > > >> time I don't like the idea of just loosing all the stabilization= effort > > > > >> on the base system, so that might work best. Something to think = about > > > > >> for mips too. > > > > >> > > > > >> > > > > > Nice, one think we would need to discuss is what do we consider b= ase > > > > > system :/ > > > > > > > > > > I guess packages maintained by base-system, toolchain and... xorg= -server > > > > > and co... what more > > > > > > > > > > Not sure if we could have a list of current stable tree for ppc*,= once > > > > > do we have that list, ppc* teams can drop from that list what the= y want > > > > > and we get a new list that will be the final result. What do you = think > > > > > about that? > > > > > > > > > > > > > >=20 > > > > At the very least, its what's needed to build the stages with catal= yst. =20 > > > > I would think we should start with base/packages, but I don't want = to=20 > > > > limit it to just those because I at least need a more for building = and=20 > > > > maintaining. Where should we start to compile such a list? > > >=20 > > > If we are going to do this, I think we should drop these arch's > > > to exp status in the profiles. That way, it keeps repoman from bother= ing > > > the rest of us about stabilizations, and we don't have to worry about > > > filing stable requests on them. > > >=20 > > > That would let you stabilize things that you need to build the stages. > > >=20 > > > William > > >=20 > >=20 > > But, moving ppc* to exp wouldn't lead us to likely break their tree? > > (because we wouldn't get any dependency issue even with "base" > > packages...) > >=20 > >=20 >=20 > I was thinking in this plan: > - Get a list with all packages stable on ppc > - Drop from that list what ppc teams want > - Run on all that packages ekeyword ~ppc* > - Run repoman to the full tree to fix the dependencies, use.stable.mask > some, tune the list of stable packages... That sounds reasonable, but, my point still stands. It would be up to you to maintain that list and stabilize new versions of those packages. I'm sure that's what the other architectures are doing that are marked exp. To answer Pacho's question about breaking their tree, well, if they know which packages they want stable, and we move the arch to exp, it is up to them to make sure their tree stays valid. I'm sure the other exp architectures do the same. William --vkogqOf2sHV7VnPd Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlPTy5gACgkQblQW9DDEZTg/uACfbZYtHnqpEMh4sd8+84JhqeuK mdYAoJ1sWOqiUOY45h2CLUIGD8B976Y2 =Lzs/ -----END PGP SIGNATURE----- --vkogqOf2sHV7VnPd--