Non-"critical" bug fixes/new hardware drivers in stable releases?

[Francois-Denis Gonthier]

On August 30, 2007 06:32:55 pm Tim Hull wrote:
> What these issues have in common is that, under current policy (which calls
> for updates for security/data loss type issues ONLY), there is little or no
> chance of having them fixed in the stable release.  While I can see the
> merit of keeping changes to "stable" to a minimum, it seems like the
> existing policy of Ubuntu (and many distributions - I'm not blaming Ubuntu
> in particular) is leaving many users out in the cold with regards to their
> issues until the next release.
>
> I can see this policy for a server or enterprise desktop (and thus the LTS
> releases), but not a normal desktop.  For desktop users, it ends up making
> them fix some bugs/hardware support issues themselves using the command
> line/third-party repositories/building from source - which is something
> that should be avoided.  Has there been any consideration to easing the
> stable release updates policy to accommodate issues like these?
>
> I'm not necessarily advocating that the stable release receive every update
> under the sun (certainly not feature-only updates), but it seems like
> allowing more bug fixes/new drivers to enter the stable release would be
> beneficial to many end users. I think that many users are probably turned
> off by the "recompile, add this unsupported software, hack this code, etc
> etc" (I know this is what always ends up pushing me away from Linux) and
> this would go a long way towards alleviating this.
>
> Any comments?  I'm especially wondering what developers think of this
> issue...

Just pitching in.  I'm usually a full time lurker on the lists you participate 
to.  I can only admire the patience with which you are trying to get your 
point across.  I'm developing daily on Debian and Ubuntu, but I cannot be 
considered a Ubuntu developer.

I'm definitely can't disagree with you on some points.  It would be very nice 
for major release to receive more bugfix upgrades.  I believe this is already 
done through backports.  Programs that are developed under the umbrella of a 
big development project such as KDE or GNOME are very well handled by 
distributors such as Ubuntu.  

The sad thing is that backport is a costly process, and not all program can be 
backported.  Upstream sources can make it easy or not to backport software 
fix in a stable distribution. If upstream develops using one or more stable 
branches, its usually easy to retroactively apply bugfixes on the packages.  
Or one can just update from the stable branch.  If the program follows a 
continuous codeline, it up to the packager to pick the bugfix from upstream 
and backport it to the Ubuntu package.  As competent as the Ubuntu developers 
can be, this is a time&energy consuming process, which is also very much 
error prone.  Backported bugfixes needs careful testing, which often can't be 
done by the developers, whom may not know how to fully use the patched 
program.

With the Linux kernel, causing hardware problems, you can multiply the cost of 
this process by ... a big factor.  The kernel is developed in such a way that 
there is no long-lived stable branch that receives bugfix.  Branches are 
short lived, and big and important changes that would benefit stable Ubuntu 
release are always done on the most recent kernel.  Backporting some changes 
is sometimes possible, but backporting change of scale beyond minor might be 
prohibitive, and sometimes, hard or impossible for the developers to test 
since they access to a lot of hardware.  Yeah, the Ubuntu kernel team must 
have quite a bit of hardware at their disposal, but certainly not everything 
everyones cares about.

Fully porting a more recent kernel to a stable Ubuntu is the other option.  
The problem here is not breaking things that worked fine on older kernel.  A 
released kernel might be stable enough to fix problems people had with an 
older version, and not cause new problems to other people, but there is no 
way to know that without adequate and prolonged testing, by which time a 
newer kernel will have been released.  The kernel is quite a moving target...

In the end, it all boils down to manpower and time.  Manpower to make and test 
enough changes in a short enough time.  While I would like to see more 
backports in stable release, I don't believe Ubuntu should change anything in 
the way they process backports.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-devel-discuss/attachments/20070911/bf04785c/attachment.sig>