On Sun, Apr 18, 2010 at 12:21:21PM -0400, Joel Feiner wrote: > On Sun, Apr 18, 2010 at 7:45 AM, Mark Kettenis <[email protected]>wrote: > > > > From: Keith Packard <[email protected]> > > > Date: Sat, 17 Apr 2010 21:17:28 -0700 > > > > > > On Fri, 16 Apr 2010 21:57:47 +0200, <[email protected]> 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. _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
