Bugs set to Fix Released by changelog-closes-bugs before fixed version is published

Bug Description

Some time ago, autopkgtest reported bug 135516 (ftbfs) against dict-en-za 20070206-1. autopkgtest refrained from retesting the package all of the time the bug was open, as it is designed to do.

During the release freeze, Matthias Klose uploaded 20070206-2, which fixes this bug. He used changelog-closes-bugs syntax to mark 135516 as closed.

Some time at or shortly before 2007年10月12日 08:47:59Z, a release manager accepted dict-en-za 20070206-2. As a consequence some time at or shortly before 09:06:18Z, bug 135516 was automatically marked Fix Released.

Some time between then and 09:26:22Z, autopkgtest's screenscraper on chinstrap fetched a new list of its own-filed bugs, and observed that dict-en-za was supposed to be fixed now.

At 09:26:22Z, autopkgtest completed its previous test run and considered which package to test. The most relevant package to test, in its opinion (which I agree with) was dict-en-za which had not been tested since 2007年09月22日.

autopkgtest downloaded the current source package from archive.ubuntu.com, which was 20070206-1. Of course the bug was still present since it was testing the old version, so at 09:26:55Z autopkgtest filed bug 151897.

Some time later 20070206-2 was published.

* Launchpad task:

IMO a bug which is closed by changelog-closes-bugs should not be marked as closed until at the very least the relevant source has been published.

Note however, that autopkgtest tests binary packages too and therefore a similar rule would have to be applied for binary packages. This part obviously needs thought given that the situation can be different on different architectures.

* autopkgtest task:

In the meantime I need to work around this problem by having autopkgtest not retest a package immediately after the bug has been closed.

What would be a reasonable period to delay ? Note that it is generally beneficial to retest a package quickly for the benefit of the developers, who would like to know sooner rather than later if it's still broken.

It should probably go fix-committed when the package is accepted and fix-released when finally published.

> What would be a reasonable period to delay ?

The publisher stars running every hour, on the hour and is usually done within 30 minutes.

Rather than screen scraping, can you use the Launchpad API? You can also then check the publishing status of the package after the bug is marked fixed.

This doesn't seem relevant for autopkgtest any more.

With the new staging through -proposed, we actually ensure that all binaries are built before the bug gets closed (which only happens on propagation to -release or -updates). The delay between publishing and hitting archive.u.c. is now rather negligible, so I think we can close this.