Hey all, Steve Langasek [2015-08-11 16:58 -0700]: > Thanks for the quick fix. While it may have been a pre-existing bug it was > clearly a pretty bad one, especially while in the midst of a major > transition.
Right, these days issues like this are visible much more often than during "normal" development. > Failing closed is certainly better than failing open here, so I'm happy to > have this change. However, false-positives do cause drag on development. I > think the correct policy here should be that, if the new version of the > reverse-dependency in wily-proposed has not yet been built, test results > from the most recent built version are used instead (whether that's a > previously-dispatched test, or a test that needs to be dispatched now > because of a new upload of this package). > > Do you agree? Would that be straightforward to implement? It's easy to implement as in fact that was my first approach :-) (I still have the patch/test case laying around). However, I discarded it as this would only help in one direction, for the specific case that you ran into. Suppose P is a newly uploaded package, and D is the newly uploaded reverse depends which isn't built yet (or FTBFS). * If the last result of D is "regression" then P would still be held in -proposed due to it, and you have to make D build and succeed its tests to advance it (or override it). * If the last result of D is "pass", then by looking at this we can't know whether the new version of P is responsible for breaking D. I find the latter behaviour rather unsatisfactory, and in some sense even worse than your original case, as that's one (and perhaps the main) path to introduce known regressions into the release. So I discarded that patch and instead implemented the current behaviour of waiting for D. A current example of this is http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#apt which is waiting on python-apt that is depwait on a newer apt. In this particular case it would be correct to let apt propagate, but we also did have cases where python-apt needed to be adjusted to a newer apt. This is also not ideal, hence the "compromise". A better way would be if we could run an autopkgtest with *only* P and its dependencies from -proposed, but keeping D and everything else from -release. This would tell us whether P is responsible for breaking D or not. This requires some juggling with apt pinning, and it feels like it'll run into trouble in some cases; but it certainly sounds like an interesting experiment. Another idea would be to introduce querying Launchpad into britney -- it could check if D is merely waiting to be built (and then wait for it), or FTBFS (and then falling back to the previous result). This should provide a better compromise, although I suppose it'll make britney run quite a bit longer. In the short term, if the current behaviour turns out to be too unwieldy, I'm also ok with plugging in the "consider previous result" patch until we have a better solution. Opinions, better ideas? Thanks, Martin -- Martin Pitt | http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
signature.asc
Description: Digital signature
-- Ubuntu-release mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
