On Thu, 2010-05-13 at 09:51 -0400, Kamil Paral wrote:
Hello,
I have similar ideas long time in my head, created
a ticket now:
https://fedorahosted.org/autoqa/ticket/153
Of course rpmguard should be modular, at least from
source code perspective. That would allow easier addition
of new checks. Completely separate plugins in a yum way
are maybe too much, but that's up to consideration. I
really like the modular approach used in rpmlint.
I created rpmguard as a quick hack and also as my first
longer Python script. If time allows, I would like to
convert it into a tool with a more decent architecture
(modular design amongst other things), which would also
offer me to get my hands dirty with more complex Python
programming - looking forward to it.
Now the only question is about time frame. I believe
our top priority is now to have AutoQA with ResultDB
up-and-running, which will allow us to finally inform
people about glitches in our/their repositories and
packages. Having nicely structured test scripts comes
only after that, I assume. Right, wrong?
Definitely, we have 3 (4 really) milestones all geared towards
automating package update acceptance. This goal should be our
collective priority. The roadmaps everyone has been tracking and
keeping updated are tremendously helpful, thanks all!
* Package sanity -
https://fedorahosted.org/autoqa/milestone/Package%20Sanity%
20Tests
* Package update tests -
https://fedorahosted.org/autoqa/milestone/Package%20update%
20tests
* Depcheck -
https://fedorahosted.org/autoqa/milestone/autoqa%
20depcheck
* Resultsdb (pulling it all together) -
https://fedorahosted.org/autoqa/milestone/Resultdb
This thread wasn't intended to change priorities, just more about
thinking through what the future of rpmguard holds so we can get some
ideas documented for future reference, or in case anyone is anxious to
take on the challenge before we get to it.
Thanks,
James