Micro Release Exception request for ubuntuone package set

[Rodney Dawes]

Hi Martin,

Sorry for the slow reply. It's been an extremely busy couple of
weeks, with trying to get some U1 releases done, and the set of
security updates sneaking up in the middle of that.

Ditën e Tue, 05/06/2012 më 17.25 +0200, Martin Pitt ka shkruar:
> Hello Rodney,
> 
> Rodney Dawes [2012-05-30 14:54 -0400]:
> > I would like to request a Micro Release Exception for the
> > ubuntuone package set in Ubuntu, so that we may more efficiently
> > release SRUs to users.
> 
> A more recent new microrelease in -proposed [1] was in line with thet
> normal SRU policy, and all the bugs there got properly verified.
> 
> So my main question is, what is the reason why you ask for an MRE?
> Usually there is two reasons:
> 
>  * You want to do a large number of bug fixes which already get
>    regression tested through a process other than the current "call
>    for testing" during an SRU. Prime examples here are
>    landscape-client and nova.

We want this. We will generally have several bug fixes per package,
across several of our packages, which we will update. We also want
to have version consistency across all our packages, so that it is
easier for support to deal with.

>  * You want to introduce changes in those microreleases which are
>    are not covered by the usual SRU policy, like new features or UI
>    changes. Prime example here is Firefox.

We won't be doing this (at least, not yet anyway). When we have new
versions of all our packages working reliably in our PPAs, on all the
versions of Ubuntu which we want to support with that new version, then
we will likely revisit how to do this exactly. And I'm sure there will
be further discussion on the best way to do that in Ubuntu. But for now,
it's just normal frozen updates with bug fixes.

> In the first case you should point out how you can verify the actual
> .debs in -proposed, in a full Ubuntu environment (as that can/will
> look differently than sandboxes during package build, and packages in
> PPAs). In the second case you'd keep the individual bug verification,
> but should justify why UI/feature changes are necessary.

We have our own QA resources on Ubuntu One, and have them install
all the -proposed packages in a full Ubuntu in a VM to test. We
generally do this anyway, as waiting for original reporters to verify
fixes may never happen.