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 97C9213877A for ; Sat, 26 Jul 2014 08:36:59 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 3ED83E0D57; Sat, 26 Jul 2014 08:36:55 +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 62CA0E0D48 for ; Sat, 26 Jul 2014 08:36:54 +0000 (UTC) Received: from [192.168.1.223] (113.139.217.87.dynamic.jazztel.es [87.217.139.113]) (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 0D1F534009B for ; Sat, 26 Jul 2014 08:36:52 +0000 (UTC) Message-ID: <1406363809.20388.32.camel@gentoo.org> Subject: Re: [gentoo-dev] About current ppc/ppc64 status From: Pacho Ramos To: gentoo-dev@lists.gentoo.org Date: Sat, 26 Jul 2014 10:36:49 +0200 In-Reply-To: <20140725200743.GA5497@linux1> References: <1406316517.20388.22.camel@gentoo.org> <53D2B248.4090004@gentoo.org> <1406317833.20388.24.camel@gentoo.org> <53D2B6A0.4070009@gentoo.org> <20140725200743.GA5497@linux1> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.4 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: 8bit X-Archives-Salt: 5fea558f-6e26-4562-b349-ff68a9d763d1 X-Archives-Hash: 75e1c7a063f90e08e2c16700b05793e1 El vie, 25-07-2014 a las 15:07 -0500, William Hubbs escribió: > 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ó: > > >> 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 stable 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 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 with 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 randomly 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 base > > > 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 they want > > > and we get a new list that will be the final result. What do you think > > > about that? > > > > > > > > > > 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 want to > > limit it to just those because I at least need a more for building and > > maintaining. Where should we start to compile such a list? > > 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 bothering > the rest of us about stabilizations, and we don't have to worry about > filing stable requests on them. > > That would let you stabilize things that you need to build the stages. > > William > 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...)