micro release exception for LibreOffice

[Clint Byrum]

Excerpts from Bjoern Michaelsen's message of 2012-06-13 14:57:26 -0700:
> Hi,
> 
> On Wed, Jun 13, 2012 at 01:13:56PM -0700, Kees Cook wrote:
> > Currently, it sounds like the SRU process for LO isn't working, and I
> > feel that's a separate problem. I think Colin's suggestions on improving
> > this are probably a good first step.
> 
> The SRU process is totally missing the realities of LibreOffice on Ubuntu. To
> implement it as written on time and without missing security disclosure dates I
> would need a team of ~five just for testing all changes in a 10 Mio LOC GUI
> application in each minor again and repeating all the upsteam testing again --
> this time with launchpad bugs. The current SRU process does not trust upstream
> testing at all -- which is also ignoring realities.
> 

The SRU process does trust upstream testing in the case where it is
known to the SRU team and tech board that upstream's processes are
sufficient to protect the users from regressions. This is precisely what
the MRE is for. 

> Also note that LibreOffice upstream explicitly synced its release plan to
> Ubuntu/Fedora release cycles to be able to provide a reasonably stable new
> LibreOffice major release (3.x.2/3) with the distro release and then be able to
> provide 3-4 stable minor fix-only updates. It is quite arrogant to assume the
> LibreOffice decision makers (with lots of experienced ex-OpenOffice veterans
> by now) dont know what they are doing with their codebase there.
> 

I don't think anybody thinks that! We'd just like to have a real understanding
of what they're doing to protect against regressions.

> Playing it by the (current SRU/MRE) book would make it easy for me: I would never
> touch LibreOffice once it is released with Ubuntu. Strictly speaking I would
> even leave the cherry-picking of security-fixes to the security team. Finally,
> I would have lot of additional air to breath for LibreOffice development.
> 
> And if there are no reasonable lightwight SRUs/MRE for me, and the quality of
> 3.x.2/3 is insufficient (and it will be -- esp. compared to other distros of
> the same age with later minors) the conclusion is simple: going with the last
> minor of the last major instead. It will not have fewer bugs -- only more bugs
> which are wellknown.  However, given the number of bugfixes in a major, this
> will give us a huge backslash -- not because of missing features, but because
> of missing fixes known to be corrected upstream. And I would never need to
> target a blueprint for the current cycle as whatever I do would only end up in
> the _next_ cycle.(*)
> 
> So: For best quality of LibreOffice on Ubuntu with the current resources we
> need a MRE for LibreOffice. Or a completely different SRU process for
> LibreOffice. Or lots of additional resources for LibreOffice. Its quite simple
> actually.
> 

I have not looked into upstream's stable release policies, but perhaps
if you provided documentation here, the TB would grant it. I don't see
any conclusive "NO" response yet.