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 DCD0313877A for ; Sat, 26 Jul 2014 11:44:47 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E013EE0ACA; Sat, 26 Jul 2014 11:44: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 0741DE0A83 for ; Sat, 26 Jul 2014 11:44:40 +0000 (UTC) Received: from [192.168.1.100] (mobile-internet-5d6a80-173.dhcp.inet.fi [93.106.128.173]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: ssuominen) by smtp.gentoo.org (Postfix) with ESMTPSA id ABE2F33FC3B for ; Sat, 26 Jul 2014 11:44:39 +0000 (UTC) Message-ID: <53D3949B.7080406@gentoo.org> Date: Sat, 26 Jul 2014 14:44:27 +0300 From: Samuli Suominen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 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 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] About current ppc/ppc64 status 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> <53D3815F.80107@gentoo.org> In-Reply-To: <53D3815F.80107@gentoo.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Archives-Salt: f398a5fe-54b3-4870-a5a1-374a483c764a X-Archives-Hash: cba7630d062a4e59e4f000eaae496348 On 26/07/14 13:22, Anthony G. Basile wrote: > On 07/26/14 04:44, Pacho Ramos wrote: >> El sáb, 26-07-2014 a las 10:36 +0200, Pacho Ramos escribió: >>> 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...) >>> >>> >> 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... >> >> >> > > 1) I don't think we need to drop to exp if we do this right. +1. Only reason 'mips' was downgraded to 'exp' because there was absolutely nobody working on it at the time. I tend to regret that now. Also, aballier is using amd64-fbsd with 'stable' and 'dev', exactly to avoid breakage, since nobody really checks for 'exp' > > 2) I like this plan. Its not that we'll drop the whole arch to ~ at > once but trim at our discretion. Less chance of breaking everything. > +1