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 -- technical-board mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/technical-board
