Getting LibreOffice more rolling

There are >60,000 user on precise alone using the LibreOffice ppas showing some clear interest in more up to date LibreOffice versions. Is there a way to deliver this to users?

    Some of those 60,000 are enterprises. Other enterprises want a more recent release but still want support from Canonical.

    Can we update/SRU minor release updates more quickly to releases?

    Can we even update/backport major releases?

    Mostly for LTS as non-LTS EOL doesnt make it worthwhile for non-LTS

    if so, when should such an update hit the repo? Upstream recommends LibreOffice x.y.0-x.y.2/3 for early adopters, and versions starting at x.y.4 or later for "conservative"/enterprise users --- (see: https://wiki.documentfoundation.org/images/archive/2/2c/20130819233457!LibOReleaseLifecycle.png)

     Major releases have regressions even at upstream EOL:

    20 open regressions in EOL 3.6: https://bugs.freedesktop.org/report.cgi?x_axis_field=component&y_axis_field=version&z_axis_field=&query_format=report-table&short_desc_type=allwordssubstr&short_desc=&product=LibreOffice&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&resolution=---&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=regression%2C+&bug_id=&bug_id_type=anyexact&emailtype1=substring&email1=&emailtype2=substring&email2=&emailtype3=substring&email3=&chfieldvalue=&chfieldfrom=&chfieldto=Now&j_top=AND&f1=version&o1=regexp&v1=^3.6&f2=noop&o2=noop&v2=&format=table&action=wrap

    83 open in 4.0: https://bugs.freedesktop.org/report.cgi?x_axis_field=component&y_axis_field=version&z_axis_field=&query_format=report-table&short_desc_type=allwordssubstr&short_desc=&product=LibreOffice&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&resolution=---&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=regression%2C+&bug_id=&bug_id_type=anyexact&emailtype1=substring&email1=&emailtype2=substring&email2=&emailtype3=substring&email3=&chfieldvalue=&chfieldfrom=&chfieldto=Now&j_top=AND&f1=version&o1=regexp&v1=^4.0&f2=noop&o2=noop&v2=&format=table&action=wrap

    We dont have any ARM builds in the PPA => no visibility of possible troubles there with an update

    We dont have all l10n in the PPAs because of space => no visibility of possible troubles there with an update

    For e.g. precise we have 15 backported dependencies => additional sources of trouble, esp. for stuff like clucene which isnt exclusively used by LibreOffice -- are these interlocked (that is: e.g. LO 3.5 depends hard on one version, LO 4.0 depends hard on something never), thus requiring dist-upgrades? -- possibly use internal packages?

    lost features: LibreOffice 4.0 killed binfilter, so any 3.5->4.0/4.1 upgrade would suddenly miss this, 4.1 kills python-uno (Python2 bindings)

micahg - I might not be able to attend the meeting, but I think throwing libreoffice in backports might be achievable if we crowdsource the dependency testing. I think enabling internal libraries is fine as long as we keep upgrading (one of the main issues with internal libraries is security support, but if we keep the releases moving, I don't think it's as much of an issue). If a dependency might be beneficial to other packages, it might be worth backporting separately. I would propose backporting after a successful SRU into the latest stable (so that's probably a .3 or .4 release at least). For the first LTS+2 backport, we'd have to wait until LTS+1 is EOL to avoid the backports must support upgrade issue, otherwise, after successful SRU would be a good time. I say after a successful SRU to try to insure minimal regressions in backports. While, that's not technically a requirement for feature backports, due to the amount of testing needed and the probable number of users using the backport, it seems advisable to try to mitigate regressions as much as possible.
@micahg: "For the first LTS+2 backport, we'd have to wait until LTS+1 is EOL to avoid the backports must support upgrade issue, otherwise, after successful SRU would be a good time." I seem to misunderstand that: LTS+2/Raring is EOL on January 2014, LTS+1/Quantal is EOL on April 2014, thus there would never be a backport. In general, backporting to a non-LTS makes little sense if you look at the schedules and stick to the sensible assumption that we dont want to backport before x.y.3/.4 -- e.g. ignoring the upgarde issue: 4.1.4 is scheduled for Dec 16, 2013 - Dec 22, 2013 and 13.04 Raring is EOL in January 2014.
@Bjoern: I was referring to the 14.04 LTS, we currently have an issue with Quantal so I'm not sure when backports would be feasible unless we backport to both Quantal and Precise after Raring is EOL.
relevant timeline links:
https://wiki.ubuntu.com/Releases
https://wiki.documentfoundation.org/ReleasePlan
suggested way forward:

    no changes in the way we handle precise

    work-item for bjoern: ask tech. board for an exception to release minor release updates (x.y.3-.6):

    to non-LTS releases

    LTS releases in the first 6 month

    after the package has been weathered in the ppa for at least 2 weeks

    (note: as the policy for the ppa allow the 'assumed final' rc to be uploaded -- usually ~rc2, which is released ~1 week before it is declared final, in a ideal world, that would put the update out ~1 week after upstream release)

    thus non-LTS (and the first 6 month of a LTS release) would walk through x.y.2 to x.y.6, with the last update in the last month before EOL (and thus when the next non-LTS is out already)

    if we conveniently wait until e.g. LTS+1 is EOL we can release to LTS+2 and LTS without having to bother about LTS+1

    for LTS releases after the first 6 month, we plan to update to each last point-release: x.y.6. Thus in total. t-series in a ideal world is assumed to look roughly like:

    4.2.2, 4.2.3, 4.2.4, 4.2.5, 4.2.6, 4.3.6, 4.4.6 (October 2015) ....

    still too harsh regressions/feature removals (see above: binfilter, python2 bindings) might spoil this.

    bug reporting for ppa releases:

    currently they are not at home on launchpad (not an official build) nor upstream (quite likely told its a packaging bug)

    open a launchpad ppa project for those? (Sweetshark)

    no, just use LibreOffice in launchpad with a tag (seb128)

afterthoughts -- beyond the call:

    dependency updates might still be an issue between majors

    as 4.2 might just want exactly one version of a lib and 4.3 might just want exactly a newer one

    using internal copies might mitigate this

    ironically, the quick and fast updates after 2 weeks in the ppa might make less users use the ppa as the updates are "fast enough" => reduces effectiveness of manual testing there.

Work items:
[bjoern-michaelsen] appraoch tech board for a Firefox style update exception for LibreOffice: TODO
[bryanquigley] outreach to enterprise customers to give them opportunity to object to faster releases: DONE