Re: RFH: piuparts testing of the archive
(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
| lucas@lucas-nussbaum.net http://www.lucas-nussbaum.net/ |
| jabber: lucas@nussbaum.fr GPG: 1024D/023B3F4F |
Reply to: