Ad ResultsDB:
I'd like to add "store in resultsdb" option to our post_results process, so
I (we ;-)) can start to catch some bugs on that front.
For that, I need a box to run resultsdb. No huge requirements, just an IP accessible from
the test-clients, mysql and python >= 2.6 should be more than enough. For starters
I'll probably run the beast on my laptop, so I can react fast and test out new
versions during first week or two. Then I'd like to move it to either staging or
production autotest server, in order to be able to move my laptop :)
The initial coding for enabling resultsdb storage should not take more than a day or two.
J.
----- Original Message -----
From: "Kamil Paral" <kparal(a)redhat.com>
To: "AutoQA development" <autoqa-devel(a)lists.fedorahosted.org>
Sent: Wednesday, August 10, 2011 2:03:06 PM
Subject: Re: Planning for AutoQA 0.7.0
> I'd like to schedule a teleconference for Thursday but before I do,
> let's get a list together of the proposed features. Once we have a
> list, I'll schedule a meeting.
Let's do an email discussion this time. I don't see any topic we need
to discuss at real-time and I think emails are more convenient in this
case.
>
> My proposals are holdovers from 0.6.0 that didn't get finished:
> * #347 - Test results are sometimes linked incorrectly in bodhi
> -
https://fedorahosted.org/autoqa/ticket/347
Definitely, I'd like to see this ticket at 0.7.
>
> * #355 - Determine Use Cases for Functional Self Tests
> -
https://fedorahosted.org/autoqa/ticket/355
>
> * #353 - Create AutoQA Functional Self Test Cases
> -
https://fedorahosted.org/autoqa/ticket/353
This is #352. Which one do you have on mind?
I believe the above-mentioned tickets will take time. We can put it
into the milestone, or we don't have to, it doesn't matter, as long as
we know we want to work on that continuously.
>
> Any other proposals?
I was contacted by hongqing. He wants to provide a new test
mediakit_sanity into 0.7, which will check ISO images of Branched
composes. He needs to download those images. Now he uses a two stages
method, first downloading the iso from remote to a local dir, then
another watcher monitoring the dir. He says implementing this ticket
would reduce the complexity.
#350 Add support for using file proxy
https://fedorahosted.org/autoqa/ticket/350
I'm willing to work on this ticket. But as I've written this down, I
realized I don't know the reason why hongqing needs to cache those
ISOs. We need to cache those files only if:
a) we run multiple tests on it
b) we run the same test several times of the same ISO
Can you clarify, hongqing? Thanks.
My other thoughts:
I believe our two major tests are in a fairly-good shape. Upgradepath
starts to be solid, and depcheck will need to be re-written/modified
in the future, but that's a large task and it works good enough
nowadays. I'd like to concentrate on the infrastructure now. We need
to create a solid base that will allow us to easily trigger tests,
store results, report them, and finally allow independent test writers
in the far future.
That means working on:
1. staging server + continuous integration and testing
2. resultsdb
3. easy deployment of clients
4. easy maintenance of servers
Resultdb is a Josef's playground, I hope he will provide some
proposals here. CI and testing seems like your area of interest, Tim,
and the two tickets you mentioned match that theme.
I am interested to work on:
#254 Transfer autoqa library to autotest clients
https://fedorahosted.org/autoqa/ticket/254
#196 Use standard logging facilities
https://fedorahosted.org/autoqa/ticket/196
There are in "nice to have soon" milestone, so again we can but don't
have to put it to 0.7 milestone directly.
Again I'd like to release 0.7 in about three to four weeks, what's
done is done, the rest is pushed to a later release.
Thoughts?
_______________________________________________
autoqa-devel mailing list
autoqa-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/autoqa-devel