micro release exception for LibreOffice

[Scott Kitterman]

On Wednesday, June 13, 2012 01:13:56 PM Kees Cook wrote:
> On Wed, Jun 13, 2012 at 10:05:03PM +0200, Sebastien Bacher wrote:
> > Le 13/06/2012 21:46, Kees Cook a écrit :
> > >The upstream requirements and test suite requirements are very nicely
> > >met, but without a demonstrable history of successful Ubuntu SRUs,
> > >I think it's premature to grant an MRE.
> > 
> > Hey Kees,
> > 
> > So to summarize:
> > - we have regression in precise and some unfixed data loss bugs
> > - we have a SRU ready to address those (new upstream point release)
> > - the SRU team is not wanting to review that update since we don't
> > have SRU rules compliant tracking for every single commit in the
> > update and they suggested to apply for MRE
> > - the TB teem is not wanting to grand a MRE
> > - the libreoffice maintainer position is that libreoffice is too
> > complex to "cherry pick" the fixes we need in a reasonable timeframe
> > while assuring we don't break thing (he trusts upstream testing of
> > the whole update over what a cherry pick in Ubuntu would provide)
> > 
> > What do you suggest as a way out of this situation?
> 
> It needs to be solved with the SRU team, IMO. My take on the MRE process
> is that it represents a recognition from the TB that past SRUs have been
> so successful that there is no reason for the SRU team to examine future
> SRUs. It wasn't designed as a way to bypass the quality controls of the
> SRU process.

I'd put it differently based on my experience with having gotten several MREs 
approved (clamav, KDE SC, and postfix).  I've viewed it as recognition that 
between upstream policy/test suites/etc and processes in place within the 
group of people doing the updates for Ubuntu the benefit of taking releases 
whole outweighs the risks.

As an example, in the case of clamav, we developed an extensive distro QA 
process to support getting an MRE.   Alternately in the case of postfix we have 
more basic distro QA combined with an upstream that is famously careful with 
commits for point releases and if anything more strict about adding new things 
in than our SRU policy.

In these and the KDE SC updates I've done the SRU team has been an important 
part of the process and that should continue.  This is a risk/benefit trade off 
and so a strict set of rules that apply to all packages isn't going to work 
(no one in the TB or SRU team needs to feel obligated to approve anything 
until they are comfortable that trade off is right - in some cases that may 
require doing some test cases).

Scott K