David Abrahams wrote: > on Fri Jun 06 2008, "troy d. straszheim" > <troy-rPoGFrA5WPqukZHgTAicrQ-AT-public.gmane.org> wrote: >> I'd sorta prefer to stay ignorant, though if nobody else digs in I may >> end up taking you up on this, or imposing on some of my local windows-savvy >> colleagues. > > For what it's worth, it's been my experience that when the lead guy > tries to stay ignorant of one of the platforms, the software's > cross-platform-ness is usually severely compromised.
Yeah, let me rephrase: I'll take you up on those VMs, it is important to me that this stuff Just Works on windows. (There is also cross-project-ness (i.e. icecube, kde) to think about long term). Obviously the pipeline is quite full right now, I do appreciate any time that you can give this as we spin up. > > I'll try to get my XP32 and XP64 VMs testing this stuff. > If you hit something nasty feel free to point me at a paused VM. I started a wiki page you might want to scribble on as you go: http://svn.boost.org/trac/boost/wiki/CMakeForRegressionTesters >>>> - Consider the business of triggering these builds. Probably another >>>> little python script using the svn bindings. >> or one that makes an xmlrpc call to the trac plugin... > > That's what Bitten does. The slaves poll the trac plugin periodically > to see if there's anything to do. The server knows what changed in the > repo, what area of the repo the recipe is testing, and what platforms > have tested what revisions. We'd probably want to do it a little > differently, but one thing that we should keep is that Bitten always > starts testing with the latest revision and works its way back through > untested revs. Agreed, the working-backwards logic is good. As for the bitten grouping into 'platforms' via pattern matching and all that... as a first go at it we can put in a dummy queue that simply matches the fqdn as reported by the slave. >>> Niftypifty! Pretty soon we'll have to start talking about what kind of >>> display we really want. >> I think we can start talking about this now... As I mentioned, I've seen >> some of Evan's consulting work (some very elaborate web front-ends) >> and it is absolutely killer, > > Evan? I'm trying to remember... is that the guy you were hanging with > at BoostCon? Yah. I think we've nailed down a good interface for having the javascript query the database in a way that keeps the trac plugin pretty much out of the loop, so more presentation logic gets moved from the server's html-templating engine into the browser... less coupling, more efficient bandwidth usage, snappier interface, significantly less load on the server. We'll see. > Thanks for all your work on this! No worries. I'm really looking forward to being able to tell if compilation problems are Just Me or something more sinister. -t _______________________________________________ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
