[qmtest] getting started

[Mark Mitchell]

> - kicking off the nightly build
>   -- does QMTest kick it off or does make/cron
>      kick off QMTest?

The former.

> - policy/procedure for maintaining tests
>   -- do developers check them in or add them via the
>      gui/browser?

Either works; the goal is to be as flexible as possible.  We generally use 
a CVS repository full of tests; users update that and check it back in to 
share the tests.

>   -- if they're checked in, do you make a resource a
>      prerequisite install them to a useful place?

I'm not sure if I understand this question, but I think the answer is "no". 
There's no integration between QMTest and source management systems; how 
the tests get back into an official repository is beyond the scope of 
QMTest.

> - automatically create bugzilla tickets for
>   new/unexpected failures?

No -- although adding automatic support for talking to defect tracking 
systems is definitely something in which we are interested.

> - when reporting a failure, how can I specify which
>   tag should be used to check out the source when
>   attempting to reproduce the problem

A failure in QMTest, or a failure in the tested sotware?

> - how is the test database propogated to the test machines?
>   -- share them over nfs?

Correct -- or any other method you like.  The key constraint is that the 
test database has to be accessible in the same way on all of the machines 
being used to run tests.

> - are there any database classes that stores tests as
>   plain text files?

Our GCC test database handles GCC tests that are stored simply as source 
code, which might qualify.

Yours,

-- 
Mark Mitchell                mark at codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com