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

[Dave Steele]

On Tue, Nov 1, 2011 at 8:46 AM, Holger Levsen <holger at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/piuparts-devel/attachments/20111101/e36286e4/attachment.html>