micro release exception for bzr

Colin Watson cjwatson at ubuntu.com
Fri Sep 17 11:14:58 BST 2010

On Fri, Sep 17, 2010 at 09:56:02AM +0100, Mark Shuttleworth wrote:
>  On 17/09/10 08:19, Martin Pool wrote:
> > We have a pretty substantial test suite (about 26,000 tests) which is
> > run on every release-branch commit, and we require new tests for bug
> > fixes or features if it is at all practical.  I believe the tests are
> > currently done during upstream releases rather than during package
> > builds, but I see no reason why they couldn't be turned on there.
> I'd rather require a manual test run confirmation before the archive
> pocket copy from -proposed to -updates than hammer the buildds every
> single time we build bzr.

IMO, we should generally be running test suites by default on package
uploads unless there's a very good reason not to; this is even part of
our main inclusion guidelines.

The bzr test suite is perhaps larger than most, taking 47 minutes on my
fairly heavily loaded laptop (so I'd expect it to be faster on most of
the buildds, with the exception of armel).  But bzr is only uploaded to
Ubuntu on the general order of once a month; this isn't a serious
imposition on the buildds, and it would give us assurance we wouldn't
get from manual runs: for instance, we're unlikely to get manual runs on
all architectures.

I'm not saying we have to run it on the nightly PPA builds; that would
probably be asking too much.  We could also turn it off by default on
particular architectures if it became a serious problem there, although
I think that's something we should think hard about.

The test suite was originally turned off in the package build not
because it was taking too long, but:

  * Flip DEB_BUILD_OPTIONS logic on the testsuite until someone figures out
    why it intermittently hangs under fakeroot.

The changelog entry dates from January 2007, and I don't know whether
that has been resolved since then.

Colin Watson                                       [cjwatson at ubuntu.com]

More information about the technical-board mailing list