micro release exception for LibreOffice

[Scott Kitterman]

On Wednesday, June 13, 2012 11:57:26 PM Bjoern Michaelsen wrote:
> 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.
> 
> 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.
> 
> 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.
> 
> Best,
> 
> Bjoern
> 
> (*) Dont even try to suggest to regulary do such developments as vendor
> patches on the old stable branch:
>     a) missing the upstream testing will hurt severely (I am not talking
> about automated tests, but plain boring manual alpha/beta testing) b)
> Forwardporting and merging such changes to upstream master around release
> is nontrivial -- wasting resources we do not have -- and in themselves
> create regression risks.
>     c) Keeping them vendorpatches is even less of an option. We will quickly
> and rightfully be cut off upstream QA -- ignoring bugs reported on Ubuntu
> -- because we ship a different product. That was exactly the situation
> Ubuntu was facing at both go-oo and Suns OOo.
> Such things should only be done as rare exceptions -- not as the rule.

Clamav got it's MRE based on a different, but I think conceptually similar 
situation.  We didn't really have a choice because of the nature of what it 
does but to keep it updated.  Do get it approved, I had to lay out a QA 
process for it that made it reasonable to upload to -proposed/updates without 
a detailed code review by the SRU team:

https://wiki.ubuntu.com/ClamavUpdates

Based on your situation, it makes a lot of sense to SRU minor versions.  I 
think the trick is to define the QA process needed to make everyone comfortable 
with doing it.

Scott K