Re: Non-critical bug fixes/new hardware drivers in stable releases?
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 timeenergy 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. pgpKVYQJfDsf2.pgp Description: PGP signature -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Non-critical bug fixes/new hardware drivers in stable releases?
Tim, 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. Backporting changes is risky. Ubuntu makes the decision that security fixes are worth the risk of backporting. If you are talking about changes that are available in later releases, then the affected users are able to upgrade. In my opinion, it is more important that we don't break the machines of people for whom everything is currently fine. I would love to see Ubuntu backport all new features to past versions, but that would leave little point in having releases at all. It would make it nearly impossible to check quality as the system would be in continual flux. In order to backport non-critical/security updates, we would need people testing those updates - people who could be working to make the next releases better. With limited resources, I think system stability on past versions would suffer. Aaron -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Non-critical bug fixes/new hardware drivers in stable releases?
Backporting changes is risky. Ubuntu makes the decision that security fixes are worth the risk of backporting. If you are talking about changes that are available in later releases, then the affected users are able to upgrade. In my opinion, it is more important that we don't break the machines of people for whom everything is currently fine. I'm not talking about new features (aside from possibly new drivers). I'm mainly talking about bugs that, while not security/data loss bugs, are still significant annoyances. The HAL bug I mentioned earlier in the thread is the perfect illustration of what I mean. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Non-critical bug fixes/new hardware drivers in stable releases?
Hi, I've been lurking/occasionally posting here for a while, and I would like to bring up an issue that has been a real annoyance in my attempted use of Ubuntu (as well as other Linux distributions, notably Debian) this summer. In short, while I feel that Ubuntu has made real progress with regards to desktop Linux - comparing Hoary and Feisty (the last release I had used prior to this summer) is like night and day. More works out of the box, it's FAR easier to get all the popular non-free codecs, and it generally feels like a modern desktop operating system. However, in installing Ubuntu I ran into a whole slew of issues that, while not will make your system explode/lets hackers in/causes data loss bad, are quite annoying nevertheless. Some examples include: 1. Many USB storage devices can't be properly unmounted using the GUI. One must use the console or use non-optimal workarounds (that are distinctly UNSUPPORTED) to fix this. The bug in particular can be found at https://bugs.launchpad.net/ubuntu/+bug/99538 2. My laptop (a MacBook, don't laugh :) ) won't suspend-to-RAM with the default kernel. To be precise, it will suspend, but it will not resume :) This is fixed in newer kernels (such as those in Gutsy) and can be worked around with a kernel recompile in 2.6.20. However, one must either compile a kernel or use apt-pinning with Gutsy sources to use this fix - a decidedly unsupported and nonintuitive fix. 3. Many other examples that I can't think of off the top of my head - though one may see many of these by looking at the Howto configure XYZ wiki pages. Words such as recompile, add this repository, etc etc seem to be a constant occurence here. This is especially apparent when it comes to new hardware that has drivers, albeit ones that weren't ready as of the stable release. 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... Tim -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
