Hello Stephen, Stephen Kitt [2014-03-25 0:45 +0100]: > > Recent versions of autopkgtest now ship the new > > /usr/share/doc/autopkgtest/README.running-tests.gz which I hope > > explains the use cases and how to run them. > > It does explain the various use cases, but I found auto-package-testing more > helpful in that it contains the actual launcher scripts (prepare-testbed and > run-adt-test) used on the CI platforms. Indeed these are still what we use in production for i386/amd64. For armhf and ppc64el we already use the new adt-virt-lxc and adt-run directly, and that's what we want to move to next cycle, too. I'll have a meeting with Antonio (http://ci.debian.net) tomorrow to discuss the next-gen architecture, for sharing this between D and U. > > > I'm wondering how all this meshes with Ubuntu's "fast migration" approach: > > > I'm guessing it doesn't see build-time tests which are run as part of the > > > build... > > > > It kind of does by rejecting packages which don't build on all > > platforms, i. e. if tests during build fail on a particular arch. > > Right, I was thinking of the positive side; as I understood it there is some > sort of bonus in the "proposed" migration in Ubuntu for packages with working > autopkgtests. Not really a bonus as such. The condition is that for a package X upload, the tests of X and all tests of X's reverse dependencies have to succeed, otherwise it doesn't propagate. If there are no tests, the package still propagates once the other conditions are met (built and installable on all arches). > If that is correct then it would be better to use tests during the > build and also as autopkgtests, wouldn't it? It's better to have both kinds of tests, yes. They don't necessarily need to be the same (and in most cases aren't). They have a different scope and purpose. > That's what I liked about DEP8 at first — it helps avoid brown-bag errors ;-). That too :-) But I mostly value them for avoiding the introduction of ABI changes or otherwise changed behaviour which break existing packages. E. g. if we upload a new pygobject which breaks our graphical installer (ubiquity), we'd hold pygobject instead of noticing the breakage in the release two weeks afterwards, which is how it should be. Thanks, Martin -- Martin Pitt | http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
Attachment:
signature.asc
Description: Digital signature