|
|
Boost Interest : |
From: troy d. straszheim (troy_at_[hidden])
Date: 2008-06-09 06:52:23
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