Kamil,
Many thanks for initiating the discussion and putting time into crafting
a high-level diagram to illustrate the idea.
On Wed, 2010-01-13 at 10:46 -0500, Kamil Paral wrote:
As we were discussing in the latest threads, we will probably
need some results database server in the future so we can then
access it by different front-ends or RPC calls. I tried to
think about the whole concept of AutoQA and create a picture
that would correspond to my ideas. Have a look at it at:
http://kparal.fedorapeople.org/misc/autoqa/architecture_idea.png
What are your opinions on this topic, which things need to be discussed,
what do you disagree with? I believe we should discuss these issues
properly so won't implement something that would need to be re-worked
soon after.
I see the database server as the biggest and nearest challenge now,
because the current irb site can easily display installer tests results,
but you can hardly use it for displaying package update results (rpmlint,
rpmguard). When we want to do something more with it than just sending
it to the mailing list, we will need the results server, I reckon.
I believe you are dead on in identifying the need for a more effective
results reporting/review mechanism for package update tests.
One challenge I see is designing a schema that can efficiently
accommodate current and future front-end reporting needs. I often worry
if we try to build something too universal, will it become useless? If
the cost (time+energy) of making something generic is too high, I'd
certainly be in favor of multiple front-ends and results servers. Do we
have a good handle on what the specific schema needs each front-end
might have?
Will, is it possible to separate the current irb database from the
irb
front-end itself, so we could use it as a basis for the results database
server? And then connect the current front-end to it, as well as other
front-ends?
Thanks,
James