Early backports to reduce post-release fixes

[Scott Kitterman]

On Tue, 27 Jan 2009 12:19:07 +0100 Luca Falavigna <dktrkranz at ubuntu.com> 
wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>When I was a motu-sru member, I realized the great majority of SRU
>candidates to be processed were related to visible bugs (crashes when
>doing normal tasks, uninstallable packages, and so on). This kind of
>issues could have been addressed in time for the release if widespread
>testing was conducted on the affected packages.

For basic issues like installability and builability I think we're better 
of relying on automated tools meant to be used archive wide like puiparts 
and rebuildd.

>We cannot enforce people to upgrade to current development release just
>to have more testers, many people believe development release is
>completely unusable until release day. I was moderator of Italian
>forums, I have several examples of these "isterisms", where people was
>scared to see "development branch" in MOTD!

These aren't random fears.  People without sufficient experience to dig themselves out of a 
sudden and deep whole should not be running the development release.

>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.
>
>What do you think?

I've certainly done this for packages I'm interested in.  It works.  Mostly 
what it needs is interested parties to test backports so we can approve 
them.

Scott K