Early backports to reduce post-release fixes

Scott Kitterman ubuntu at kitterman.com
Tue Jan 27 22:22:45 GMT 2009

On Tue, 27 Jan 2009 12:19:07 +0100 Luca Falavigna <dktrkranz at ubuntu.com> 
>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 

Scott K

More information about the Ubuntu-motu mailing list