Re: New QA scripts
On 11/6/07, Damyan Ivanov <dmn@debian.org> wrote:
> > This time, the data gathering is completely separated from the
> > reporting, the former is almost complete (it still lacks support for
> > the /dist pseudo directories in CPAN),
>
> I just added that.
Great!
> Should HTML output be implemented with an additional option to qareport
> or should one create separate htmlreport? I am also thinking about
I think that qareport could stay as a command line app, in any case,
it's pretty simple (105 lines, of which only 45 are unique to this
tool).
> several HTML outputs - one like what we have now - big list of packages,
> and one where packages are grouped by "verdict" (these needs upload,
> these needs upgrade, these need some other work, these have unfixed
> bugs, etc).
It seems that we can generate all of that without much trouble, in
fact, it's just a matter of changing sort order and the html output.
> > Speaking of which, I had the idea to make that page dynamic (the
> > reporting takes 1/4 second on alioth ATM) and add support for
> > commentaries, which would be very helpful.
>
> How do the scripts handle concurrency?
> sqlite anyone? :)
I haven't really tested concurrency, but cache.pm was written with
concurrency in mind, in fact, when you use -j in fetchdata, you have 3
concurrent processes; my major concern is to have some discrepancy
between databases, but everytime I'm about to save to the consolidated
database, I lock the source file from which I generate the
consolidated data, so nobody else can't even read it.
It all uses flock on the files, so the worst case is to have to wait
until another script finishes its work; deadlocks should not happen,
since all the scripts lock in the same order. And I would vote not to
add sqlite, storable seems to do the job pretty well; I was thinking
about a comments.pm module that handle that logic.
--
Martín Ferrari
Reply to: