Early backports to reduce post-release fixes

[Emmet Hikory]

Reinhard Tartler wrote:
> Luca Falavigna writes:
> 
>> How can we help motu-sru to avoid some SRU requests for trivial tasks,
>> allowing a greater audience to test packages without the need to
>> upgrade? My proposal is to prepare early backports of the most commonly
>> used packages in Universe. Starting from Feature Freeze, we could
>> identify some packages with high popcon and determine if it's worth to
>> prepare a backport for current stable release (new upstream releases,
>> new features to be tested, and so on), so the main part of the Ubuntu
>> users can effectively test packages and report issues, so they can be
>> fixed in time for the release.
> 
> Short: I like the idea.
> 
> I could imagine a lightweight approach: Activate the ~ubuntu-dev (or
> ~motu) PPA, and use it as "backports-staging" archive. Proposed policy:
> 
> - proposed package backports should be tracked via a malone bug
> - any motu may upload there if he feels that a package should be
>   backported, mentioning the LP bug number
> - the backport teams tracks these bugs and approves backports if
>   "enough" positive feedback from users has been given in the LP bug

    After reviewing the backports process (1), I don't think we need an
even lighter-weight process to handle these.  From my reading, it only
takes a few people to say it works to be backported.  If these initial
reports are negative, then the package ought be fixed in the development
release anyway.

    Despite the process, I don't think this will actually help with the
problem at hand.  In my experience, the majority of packages that fail
to work at all (or perhaps even install) suffer from one of three
problems: 1) they missed a library transition (perhaps even an informal
one), 2) they need to be built against a newer version of the build
tools because they failed to include some change that was done at a
lower level, or 3) they have some incompatibility with some other change
in the distribution that went untested during the cycle.

    Since backports (or PPA builds) are rebuilds, they will mask issues
of the first two types, and since they would be targeted at the previous
release, will not be affected by the third.  With the current situation,
some packages fail, are trivial to fix, and are fixed (albeit perhaps
with some delay for various reasons).  With such a change, we may
instead have a perception of regressions: where a package that is known
to work as a backport suddenly doesn't work in a release users are
likely to be significantly more annoyed than in the case where they
upgraded to something that didn't work.

    We would do better to try to close outstanding dependency issues by
reviewing the debcheck output (2), and revitalise the work on automated
installation tests using piuparts, to get that running on some shared
infrastructure with viewable output.  This ought resolve most
installation issues, and with appropriate piuparts scripting, may even
be able to handle many of the cases where a package completely fails to run.

    For more comprehensive work towards ensuring that packages work as
expected, it may be sensible to write test cases for the automated
testing framework (3).  This would probably benefit from extensions to
cover a wider variety of software than is currently tested.

1: https://help.ubuntu.com/community/UbuntuBackports
2: http://qa.ubuntuwire.com/debcheck/
3: https://wiki.ubuntu.com/Testing/Automation/Desktop/

-- 
Emmet HIKORY