Re: [gentoo-dev] About current ppc/ppc64 status

[William Hubbs <williamh@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 4015 bytes --]

On Sat, Jul 26, 2014 at 10:44:26AM +0200, 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...

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]