Micro Release Exception needed for nova/glance/keystone

[Matt Zimmerman]

On Tue, Nov 29, 2011 at 12:50:07AM +0000, Dave Walker wrote:
> On Fri, Nov 25, 2011 at 04:15:43PM -0800, Clint Byrum wrote:
> > I was just reviewing the SRU's that Chuck Short uploaded for keystone,
> > nova, and glance to oneiric-proposed, and it strikes me that really
> > OpenStack core components should go through the MicroReleaseException
> > process.
> > 
> > Upstream has active QA, and as of diablo supports a stable release branch
> > with policies around acceptance.
> > 
> > Just sending this to ubuntu-devel as a PSA that if your SRU has more
> > than 2 or 3 bugs to fix at one time, its probably not going to be able
> > to pass through our manual patch review process. However, take a look
> > at the criteria here and consider applying for a micro release exception:
> > 
> > https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions
> 
> Hi Clint,
> 
> I think this really needs some further clarification.
> 
> I followed this process earlier this year, when performing an SRU for
> bind9 which involved a new upstream version.. This was jumping from
> upstream versions 9.7.0 -> 9.7.3 in Lucid.
> 
> I raised the subject with the TB, and mdz responded that:
> "MicroReleaseExceptions is a list of standing exceptions. It's not
> necessary to go through the tech board to handle one-off requests like
> this one. The SRU team can decide what to do here without TB
> involvement." [0]
> 
> Is this still the case?

I see the distinction as:

A. "Should we update package foo to version x.y.z in order to fix bugs N and
   M?" should be cleared with the SRU team.  The SRU team can set policy and
   make exceptions to it as appropriate to act in the best interests of
   Ubuntu users.

B. "Should we, *in general*, track upstream bugfix releases of package foo and
   trust that they're appropriate for use by all Ubuntu users?" should be
   cleared with the TB.  The TB has set criteria to help evaluate whether this
   is appropriate.

It sounds like Clint is suggesting that B. would be more appropriate than A.
for OpenStack.  I haven't personally checked if the OpenStack components
meet the documented criteria.

FWIW, I would support the TB in delegating more of this authority to the SRU
team if that would streamline things.  So far, there have only been a
handful of exceptions, and it hasn't been an issue.

-- 
 - mdz