(dropped -devel@ from the Cc) On 08/04/08 at 16:26 -0500, Raphael Geissert wrote: > Lucas Nussbaum wrote: > > > > What needs to be done is: > > - run installation/removal/purge tests for all packages > > - run upgrade tests for all packages in etch > > - make changes to piuparts to fix false positives or reduce the number > > of failures by ignoring the less critical ones > > - file all the bugs (many of those are RC) > > On log processing, what about doing a dependency-based log processing? > so if package bar depends on foo, and foo fails to upgrade (or doesn't pass > all the piuparts tests) it is very likely that bar will fail too, at least, > because of foo. > > I think there was some tool around to build a dependency tree out of a > Packages, so the main part of the log processing tool is already done. If you consider the whole dependencies tree, failing subtrees (subtrees where all packages fail because of the root failing) are usually shallow, so there's no real need for a complex tool. What I used to do was: 1. process logs 2. when I run into a log where the failure was caused by another package, jump to this other package 3. file the bug against this package 4. look for all the other packages affected by the failure of this package, and mark them as such 5. goto 1
The main problem with this sort of QA work is that you have to put the cursor at the right spot between "do everything by hand" and "over-engineer complex tools that, in the end, won't do the job". The final goal is to file bugs about problems in Debian, not to write nice tools :-) -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
