proposed-migration mis-handling of numexpr, pytables

Steve Langasek steve.langasek at ubuntu.com
Wed Aug 12 05:10:18 UTC 2015


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/
slangasek at ubuntu.com                                     vorlon at 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/20150811/00494844/attachment.pgp>


More information about the Ubuntu-release mailing list