Live builds (was: Merged proto package)

[Dirk Wallenstein]

On Sun, Apr 18, 2010 at 12:21:21PM -0400, Joel Feiner wrote:
> On Sun, Apr 18, 2010 at 7:45 AM, Mark Kettenis <mark.kettenis at xs4all.nl>wrote:
> 
> > > From: Keith Packard <keithp at keithp.com>
> > > Date: Sat, 17 Apr 2010 21:17:28 -0700
> > >
> > > On Fri, 16 Apr 2010 21:57:47 +0200, <olafBuddenhagen at gmx.net> wrote:
> > >
> > > > I don't see why other distributions can't provide something similar.
> > > > Even without true live bulids, IMHO this makes the whole point about
> > > > xserver being too hard to build pretty moot.
> > >
> > > Not really; except for Gentoo, all these kinds of builds ever see are
> > > somewhere along 'master', so you can't go get bits from some other tree
> > > and build those. We're stuck in a linear world right now, and I'd like
> > > to make more parallel development possible.
> >
> > And really, if you want people to go beyond mere testing, and would
> > like them to contribute back code they pretty much have to compile
> > from a git tree.
> >
> > I just occasionally contribute code to X.org, but I'd like to do more.
> > However in many cases my attempts go a bit like this:
> >
> > 1. Update my checked out Xserver master tree.  Realize that I had some
> >   uncommitted fixes in there.  Spend half an hour googling git
> >   documentation how to recover from the fact that I now have a tree
> >   with merge conflicts.  (I don't use git on a regular basis).
> >
> > 2. Run configure for Xserver.  Figure out that I need proto package X.
> >
> > 3. Checkout proto package X.  Run configure, figure out that I need a
> >   new macros package.
> >
> > 4. Run configure for Xserver again.  Figure out that I need proto package
> > Y.
> >
> > etc. etc.
> >
> > Typically by the time I've gone through the trouble of doing a dozen
> > of these iterations, I run out of time.  When I come back at it a week
> > (or a month) later, I have to start all over again.
> >
> > So I very much *do* believe that reducing the number of git modules
> > needed to build the server will increase my productivity and increase
> > the number of diffs you'll see from me.
> >
> 
> Or you could use build.sh or jhbuild or moral equivalent.  For testing, I
> have an entire X system checked out and use jhbuild to update it.  It also
> automatically saves your work (via git stash) so you can deal with merge
> conflicts later.  You also don't have to worry about hunting for
> dependencies and configuring those individually and manually.
> 
> http://wiki.x.org/wiki/JhBuildInstructions
> 
> It's non-trivial, but not terribly complex to set up.  And once it's set up,
> you can pretty much forget about most of what's on that page.  You just run
> jhbuild -f modular-buildrc build xserver or whatever and you're good to go.


A full-fledged meta-git repo management tool suite would be nice. Such
an application would, for example, be able to:
- inform about the state of the modules (dirty, ahead of origin/master,
  not on master, etc)
- swap in and out personal trees. Maybe simply per symlinks.
- check out a particular katamari version of each module

Does something similar exist already? One might assume that all larger
projects, like for example desktop environments, could need something
like that.