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

[Dave Steele <dsteele@gmail.com>]

On Tue, Nov 1, 2011 at 8:46 AM, Holger Levsen <holger@layer-acht.org> wrote:

Hi Dave,

...

> Here's the output of a script that scrapes
> http://piuparts.debian.org/sid/state-dependency-failed-testing.html and
> analyzes blocking packages:

[...]

> This output says that there are currently 2899 packages
> in state-dependency-failed-testing traceable to a state-failed-testing
> package (that doesn't exactly match Piupart's count of 2920). 274 packages
> are responsible for that blocking. More than half of them (1588) are
> blocked by a single package, libreadline6. 1005 of those packages would be
> cleared for testing by removing only libreadline6 from the list of
> blockers. Possibly, at least some of those exposed packages may have
> blocking numbers in the 1000 range (e.g. 'python' is in that list).

thats a nicer distinction than what my script provides. I guess I will use
yours, or take some ideas at least ;)

> The source for the script piublocker is at
> https://github.com/davesteele/piublocker

I'm currently offline, so cannot look myself: is it written in shell or
python? Or something completly different? ;)

In any case, such a list of blockers should be included in piuparts-reports
ASAP.


cheers,
       Holger

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.

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. 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). 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. But, in both cases, it may cause other packages to spend months in the waiting queue. In deference to those waiting packages, perhaps the policy should be to aggressively retest.