proposed-migration mis-handling of numexpr, pytables

[Martin Pitt]

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)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/ubuntu-release/attachments/20150812/5e299d81/attachment.pgp>