Re: Upload of GNOME 2.6 to unstable
- To: email@example.com, firstname.lastname@example.org
- Subject: Re: Upload of GNOME 2.6 to unstable
- From: Sven Luther <email@example.com>
- Date: Wed, 12 May 2004 21:36:30 +0200
- Message-id: <20040512193630.GA20736@pegasos>
- In-reply-to: <20040426224033.GC17752@jaimedelamo.eu.org>
- References: <20040415221000.GC30253@nubol.int.oskuro.net> <20040417165713.GA878@quetzlcoatl.dodds.net> <20040417231518.GA26036@azure.humbug.org.au> <20040418122454.GC24239@jaimedelamo.eu.org> <20040420113708.GA20302@azure.humbug.org.au> <20040424141322.GA24602@pegasos> <20040426124531.GB14190@azure.humbug.org.au> <20040426133808.GJ25779@grep.be> <20040426224033.GC17752@jaimedelamo.eu.org>
On Tue, Apr 27, 2004 at 12:40:33AM +0200, Jose Carlos Garcia Sogo wrote:
> On Mon, Apr 26, 2004 at 03:38:08PM +0200, Wouter Verhelst wrote:
> > On Mon, Apr 26, 2004 at 10:45:31PM +1000, Anthony Towns wrote:
> > > On Sat, Apr 24, 2004 at 04:13:22PM +0200, Sven Luther wrote:
> > > > What about setting up a parallel autobuilder chain for experimental,
> > >
> > > Sure, that'd be great.
> > Although not easy. I'm not sure about this (haven't done any
> > experiments, maybe I should), but I suspect wanna-build does not handle
> > incomplete distributions (as experimental is one) very well.
> What about making experimental "chunks". I mean, right now we have in
> experimental gnome 2.6 and libtool (for example). Trying to autobuild
> that means choosing among unstable libtool and experimental libtool,
> which is broken ATM.
> IMHO this could be fixed if we had experimental/gnome2.6 and
> experimental/libtool, which are diferent subsets of experimental. The
> policy should say that each subset should be autocontained in addition
> with unstable. This means that experimental/gnome2.6 will be built
> with packages there in and unstable versions for those that are not in
> that subset.
> Will this make the trick?
Sorry for not having replied earlier on this, since i was not able to
really follow up on emails.
I believe that this should do nicely, and would be more in line with
what we really need. Even when pools were first mentioned, the name of
it suggested that we would have a pool for each group of packages which
work together and then have them moved into testing. This didn't quite
work like that which is why we have the solution we have now, but we
could implement tthis at the experimental level well enough, since it is
in the best interest ofboth the users and the different experimental
users to experiment mostly only a small subset of experimental packages
together with the rest of unstable.
For larger stuff, like new glibc/gcc/whatever, we could even have such
experimental subpools building more huger chunks of the archive for more
Now, aj, what do you feel about this, is this solution technically
feasible without too much modification of the current scheme ? If so,
then i will setup and maintain a powerpc autobuilder for it.