On Wed, Aug 12, 2015 at 06:46:39AM +0200, Martin Pitt wrote: > 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. Sorry, I think what you're describing is not what I meant. I'm not suggesting that we should use the last result of D prior to P's upload; I'm saying that P's upload should trigger the test of whichever version of D has been most recently built, *not* the most recent version of D's source that has been uploaded. This also implicitly solves the problem of who you blame when two packages are uploaded in parallel, and D version 2 regresses its tests against P version 2 but you haven't tested D2 against P1 or D1 against P2. With the above, you first test D1 against P2, and then D2 against P2. If D1+P2 passes but D2+P2 fails, you know it's D2's problem; if D1+P1 passed but D1+P2 and D2+P2 fail, it's P2's problem; if D1+P1 passed, D1+P2 failed, and D2+P2 passes again, it's some kind of transition where D2 and P2 are supposed to go into the archive together. (I know there's no code to enforce this last bit - the "supposed to go in together" part - but that's ok; it's still better than what we currently have.) > 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. Right, that's what I was meaning to suggest. Some of these failures are going to be of the form "D1 can't be installed on top of P2", and that's ok, that's still a relevant result. > 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. That's unnecessary overhead IMHO. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ [email protected] [email protected]
signature.asc
Description: Digital signature
-- Ubuntu-release mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
