Re: [boost] Release Tools Analysis Part II: Developer Feedback Systems

From: David Abrahams (dave_at_[hidden])
Date: 2007-08-17 14:34:05

on Fri Aug 17 2007, Stefan Seefeld <seefeld-AT-sympatico.ca> wrote:

> David Abrahams wrote:
>> on Fri Aug 17 2007, Stefan Seefeld <seefeld-AT-sympatico.ca> wrote:
>> 
>>>> Would QMTest be used to drive multi-host testing across the internet
>>>> (i.e. at different testers' sites), or more likely just within local
>>>> networks?  If the former, how do its facilities for that compare with
>>>> BuildBot?
>>> QMTest would typically be used to drive individual 'test runs',
>>> presumably only over local networks, 
>> 
>> Why presumably?  Is there a limitation that prevents it from going out
>> to the web?
>
> No. I'm just speculating what users might do with it.
>
>>> and can then be used during the aggregation of the results of such
>>> test runs into test reports.
>>>
>>> As such, it is complementary to the facilities offered by buildbot.
>> 
>> Can you explain why it makes sense to use two systems?
>
> I'm not quite sure I understand the question. Automating builds
> (scheduling build processes triggered by some events) is quite
> different from managing test databases.

So QMTest doesn't schedule build/test processes?  It's just a database
manager?

>>>>> How could this be useful for boost ?
>>>> A good question, but I'm more interested in "how Boost might use it."
>>>> That is, something like, "We'd set up a server with a test database.
>>>> QMTest would run on the server and drive testing on each testers'
>>>> machines, ..." etc.
>> 
>> Still looking for that.
>
> Yes, I realize that. But as I indicated earlier, I'm not convinced
> QMTest is a good tool to schedule / drive that. 

I meant I want some kind of analogous statement about a way we could
use it that you *are* convinced of.

> I'd use a buildbot setup for that. (Of course you may argue that it
> is hard to convince potential testers to install yet another piece
> of software, but that's a different argument, I think.)

I'm not worried about that at this point.

>>> I'm not sure. boost.build would need to be extended to allow
>>> QMTest to gain access to the database structure (the database
>>> already exists, conceptually, in terms of the directory layout...).
>>> Volodya ?
>> 
>> There's no a priori reason that Boost.Build needs to maintain the test
>> database, is there?
>
> No.

So what are the alternatives to that arrangement?

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com
The Astoria Seminar ==> http://www.astoriaseminar.com