micro release exception for bzr
Martin Pool
mbp at canonical.com
Fri Sep 17 08:19:38 BST 2010
Hi,
I'd like to get bzr approved under
<https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions>
as a package that can upload minor updates in to Ubuntu SRUs. I
believe we already meet the criteria for this.
For the last year and a half we have made a major release a few months
before the Ubuntu release, for instance 2.2.0 in early August for
Lucid. We then do 2.2.x minor releases at intervals, which have only
safe reasonably-minimal bug and documentation fixes. The criteria for
changes to our stable branches are intended to match the criteria for
Ubuntu updates, so if they don't match we can certainly consider
changing them. In particular fixes to the stable branch, unless there
is an compelling reason:
* must not change APIs
* must not change default formats or interoperability
* should have a Launchpad bug number
* should have a reasonably small patch,
* should not have gratuitous code cleanups or rearrangements
* should add new tests for fixed bugs
* should be careful of anything that may change cross-platform behaviour
(http://doc.bazaar.canonical.com/bzr.dev/developers/cycle.html#reviewing-for-the-stable-branch)
You can get a sense from
<http://doc.bazaar.canonical.com/bzr.2.2/en/release-notes/index.html>
of the kind of thing we typically do in bugfix releases.
We've successfully had several releases SRU'd in the past but there
has been some confusion about whether the update should cherrypick
particular fixes or take the whole bugfix update. I think it's much
preferable to take the whole update so we avoid divergence between the
upstream and Ubuntu version, and because actually most of the bugs
that do get into the bugfix release are worth taking.
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.
(They do take a while to run, some tens of minutes depending on
hardware.) Alternatively perhaps the tests should be run from the
packaged form after building, which may catch a wider range of
problems.
Our process in the past has been to nominate the most important bug
fix in the release as the 'figurehead' and use that to drive off an
SRU of the whole thing. If there's a better way to ask for them,
please let me know.
Thanks,
--
Martin
More information about the technical-board
mailing list