[Piuparts-devel] piuparts squeeze->wheezy [i386] tests

[Andreas Beckmann]

On 2013-05-05 23:34, Michael Gilbert wrote:
> On a related topic, have you thought about possibly integrating
> piuparts.debian.org into britney's testing transition decision making

Ideally this is done via filed bugs :-) And that huge backlog was fixed
last year.

> Looking only at your bug page [0] (not taking into account other
> people doing piuparts bug reporting),
you should probably include the (archived) bugs submitted by the
pre-DD-me: debian at abeckmann.de

> Finally, over the past 5 years (since piuparts bug tagging started in
> earnest), there have been over 1,100 rc bugs tagged piuparts [1].
> That's enormous.  Automatically keeping all of those out of testing
> would be a huge win.

Most of the bugs were only discovered by tests implemented after the
packages already migrated ...

> So, I wonder if you have interest in working on this?  The sooner it
> gets started, the more rc issues there are that can be kept out of
> jessie from the start.  I also may be able to find some time to help.

The interesting tests where bugs are discoved that should prevent
migration are

sid
jessie2sid
wheezy2jessie2sid
wheezy2sid

wheezy2sid is a test to see what could break if the package currently in
sid would migrate to testing (although that may contain false positives
by skipping jessie, especially in freeze times)

all the other variations probably are "too late" to prevent migration

so for anything buggy in sid
* if it's an easily spotted bug, it could already be filed by someone else
* if it's a bug only spotted by piuparts, someone needs to process the
piuparts logs and file bugs
* if it's a fancy bug, we need to enhance piuparts to discover it in the
first place

There is also the edos file overwrite check done regularily by Ralf
Treinen ... I have an implementation that does that (and something more)
using piuparts ... also for cross-distribution updates
That would need to be run for more architectures than just amd64 ... and
that should become automated with some web interface to show the results
and logs. Similarily for multiaarch-conistall tests (all these were just
quick hacks)


Andreas