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 732A913877A for ; Sat, 26 Jul 2014 11:09:46 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 6E6A8E0AAE; Sat, 26 Jul 2014 11:09:41 +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 47E20E0919 for ; Sat, 26 Jul 2014 11:09:40 +0000 (UTC) Received: from dutt.localnet (g231053041.adsl.alicedsl.de [92.231.53.41]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: johu) by smtp.gentoo.org (Postfix) with ESMTPSA id 25FD533FFF1; Sat, 26 Jul 2014 11:09:39 +0000 (UTC) From: Johannes Huber To: gentoo-dev@lists.gentoo.org Cc: Pacho Ramos Subject: Re: [gentoo-dev] About current ppc/ppc64 status Date: Sat, 26 Jul 2014 11:09:09 +0200 Message-ID: <3430846.f0TO2t7hW6@dutt> User-Agent: KMail/4.13.3 (Linux/3.15.6; KDE/4.13.3; x86_64; ; ) In-Reply-To: <1406364266.20388.34.camel@gentoo.org> References: <1406316517.20388.22.camel@gentoo.org> <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-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" X-Archives-Salt: 9e6e8f2b-68e3-48d0-8bc7-0c8849d56ff5 X-Archives-Hash: fded6bb6078fcd316805d2cbb5d7bf89 Am Samstag, 26. Juli 2014, 10:44:26 schrieb Pacho Ramos: > 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 escri= bi=F3: > > > > >> On 07/25/14 15:28, Pacho Ramos wrote: > > > > >>> That is the reason for me thinking that maybe the way to go= would > > > > >>> be to > > > > >>> do the opposite -> keep only base-system and a few others s= table > > > > >>> and > > > > >>> drop stable for most of the rest. This big effort could be > > > > >>> accomplished > > > > >>> in a week by other developers willing to help (like me) and= would > > > > >>> 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 summ= ary, > > > > >>> have a > > > > >>> stable tree they are able to keep stable). That will also h= elp > > > > >>> people in > > > > >>> ppc* teams to know that the remaining stabilization bugs, a= part of > > > > >>> being > > > > >>> much less, are important enough to deserve rapid attention,= as > > > > >>> opposed > > > > >>> to current situation that will have some important bugs mix= ed with > > > > >>> tons > > > > >>> of stabilization requests of apps that got ppc stable keywo= rds > > > > >>> years ago > > > > >>> and are currently no so important. > > > > >>=20 > > > > >> Yes, please let's just do base system stable. I've been ran= domly > > > > >> 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 stabiliza= tion > > > > >> effort > > > > >> on the base system, so that might work best. Something to th= ink > > > > >> about > > > > >> for mips too. > > > > >=20 > > > > > Nice, one think we would need to discuss is what do we consid= er base > > > > > system :/ > > > > >=20 > > > > > I guess packages maintained by base-system, toolchain and... > > > > > xorg-server > > > > > and co... what more > > > > >=20 > > > > > Not sure if we could have a list of current stable tree for p= pc*, > > > > > once > > > > > do we have that list, ppc* teams can drop from that list what= they > > > > > 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 > > > > catalyst. > > > > I would think we should start with base/packages, but I don't w= ant to > > > > limit it to just those because I at least need a more for build= ing and > > > > 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 bo= thering > > > the rest of us about stabilizations, and we don't have to worry a= bout > > > filing stable requests on them. > > >=20 > > > That would let you stabilize things that you need to build the st= ages. > > >=20 > > > William > >=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 > 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.ma= sk > some, tune the list of stable packages... ++ from Gentoo kde point of view