[Piuparts-devel] Reporting piuparts results

[Lucas Nussbaum]

Hi,

On 28/12/06 at 18:45 +0200, Lars Wirzenius wrote:
> What should we do with piuparts reports? Is there a middle ground
> between labor-intensive manual bug reporting and wishful thinking that
> all developers will start running piuparts?

I've run several rebuilds of the archive during the last few months, and
I've also done some work with piuparts (about 30 or 40 bugs filed, I
think).

The main problem with piuparts is that it finds too many problems, some
of them more serious than others. I found it easier to hack it so that
it only finds a smaller set of problems.

The first thing to do would be to run piuparts with:
- all tests about symlinks, running processes, modified files disabled
- no debfoster run between removal and purge
so one would easily generate two lists:
(A) most severe failures (purging fails in an easy case)
(B) packages that cannot be tested

Then, all packages that were tested successfully could be tested again,
with tests becoming stricter and stricter.

This way, one only consider very similar failures, and the number of
logs to analyze for each piuparts run gets much smaller.

I'm also interested in turning such tasks (logs reviewing) into a more
collaborative process. I created an alioth project[1] for this. A good
start could be to maintain inside SVN a list of packages that cannot be
tested using piuparts. Please join the alioth project if you are
interested to work on this...

[1] http://alioth.debian.org/projects/collab-qa/
-- 
| Lucas Nussbaum
| lucas at lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
| jabber: lucas at nussbaum.fr             GPG: 1024D/023B3F4F |