micro release exception for LibreOffice

[Bjoern Michaelsen]

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.