[Piuparts-devel] Piuparts state-dependency-failed-testing analysis

[Holger Levsen]

Hi Dave,

dropping the cc: to debian-qa at ...

On Dienstag, 1. November 2011, Dave Steele wrote:
> The script is written in Python. It is far from production ready (much of
> it is about scraping the web page, and some of the rest is really ugly),
> but you are welcome to whatever is useful to you.
> 
> One recommendation - I think it would be good to create a bug entry
> template with blocking stats, a pointer to the test log, and a prompt for
> analysis for the failure. The piuparts bugs could be more effective if they
> routinely included stats ("This failure is holding up testing of 1500
> packages, or 33% of the total"). If state-dependency-failed-testing is
> going to stick around, better visibility of the big blockers is needed.

/me nods. state-dependency-failed-testing will definitly stay around. 
 
> I wonder about a policy for retesting failed packages. The libreadline6
> situation suggests that there is value in retesting failed packages on some
> schedule as base.tgz is updated.

see http://lists.debian.org/201107051044.04594.holger@layer-acht.org for an 
explaination about how packages are rescheduled.

> Similarly, the latest release of my
> package (gnome-gmail 1.8.2-1) is failing piuparts upgrade in wheezy,
> because of an install bug in the previous release (1.8.1-1).

whats the # of that bug? 

is it worth fixing in stable?

> Does that
> failure stick around until 1.8.3? Should it? I'm not sure. In the first
> case, it may not be a big deal for the developers of the failed packages
> for it to stay in a failed state. In the second case, the failure
> acknowledges the fact that there may be an upgrade issue for users.

yup. 

also, _I_ mostly care about the tests for sid+wheezy, as this is where things 
can still be fixed. I also look at squeeze+lenny2squeeze results, but only 
care about severe problems there.

and yes, it's getting time to setup squeeze2wheezy tests :-)

> But, in
> both cases, it may cause other packages to spend months in the waiting
> queue.

if packages depend on buggy packages, those packages _should be_ in the 
waiting queue. buggy packages must be fixed, thats the only way forward.


cheers,
	Holger