micro release exception for bzr

[Martin Pitt]

Hello Martin,

Martin Pool [2010-09-17 17:19 +1000]:
> 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

Indeed the SRU policy has never really forbidden new upstream
microreleases, and in fact we have pushed them to -updates quite
often. The question is not so much whether the changes come in a new
upstream release or as debian/patches/, but rather whether all of the
changes are SRU policy compliant.

From what I remember from the previous bzr SRUs, I didn't remember
any, or at least not a lot of, problems in that regard.

The microrelease exceptions are actually for kinds of changes which do
not follow the SRU policy, i. e. they might change strings, the UI,
introduce new features, or have a lot of build system changes; Firefox
is a good example here. I agree that calling them "microrelease
exceptions" is indeed a bit misleadig here. We should perhaps just
call them "SRU policy exceptions"?

> 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

bzr has a great history of avoiding regressions, due to being so
meticulous about automatic tests. Also, regressions in it don't have
the potential to break your entire system, thus it's always possible
to fix a regression with another update.

So pushing those microreleases to stables seems fine to me (with both
my SRU and my TB hat on). With above criteria this does not even
require an extension of the policy IMHO, but I wouldn't mind adding it
there.

> Alternatively perhaps the tests should be run from the packaged form
> after building, which may catch a wider range of problems.

I'd prefer this. Testing the actually installed bits will also catch
packaging errors (like forgetting to install a particular Python
module or other file). This also provides a nice and standardized SRU
verification step.
 
> 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.

That's quite common indeed for this kind of update (GNOME
microreleases often do the same thing).

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: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/technical-board/attachments/20100917/6f1f9179/attachment.pgp