Bugfix/hardware support updates to stable releases?
Hi, About a month ago I inquired here as to what Debian is doing regarding backported updates for stable releases. I did get some good responses to that thread, and I see why Debian doesn't expend too much energy making significant updates (like new GNOME, Xorg, etc etc) to *stable* releases - it would make them *un*stable. However, this still leaves the question of bugfixes and hardware support updates - things that, while not necessarily "new-toolchain" complexity, are mostly excluded by the current updates policy. As of now, there is no way for stable users to get many bugfixes or support for hardware released recently (basically anything since fall of last year) without resorting to installing testing/unstable packages or unsupported packages, all of which are not security supported. In my case, this has been quite a pain, as I have had to backport the kernel and about 5 auxiliary packages from testing/unstable to get reasonable functionality on my machine (a MacBook). I've also had to backport libgksu to get a fix for a problem which causes there to be an extremely high amount of CPU wakeups when gksu is used (as that kills battery life). Is there any plans to work on supporting such issues in the stable release, either through -volatile or the release updates? It would be nice to be able to - for instance - easily install using a new kernel with better driver support when running on a recent machine. This may not be a HUGE issue now, but it will be a year from now - witness the issues with Sarge and various SATA chipsets to see what can happen. If developers are working on this, I'd love to help as I can - it's by far the most significant issue holding me back from using any form of (GNU/)Linux. Yes, I know that users can always run testing or unstable, but not everybody wants that - things *do* break, and you end up with large-scale upgrades to the toolchain and core packages occurring quite often. That's fine for a Debian developer or power user, but not for everyone. Personally, *I* can run unstable, but would prefer to have a stable OS in addition to a development machine. Anyway, I'd love to hear what developers have to think on this Thanks once again for the great distribution, Tim
Re: Bugfix/hardware support updates to stable releases?
On Thu, 30 Aug 2007, Tim Hull wrote: > I've also had to backport libgksu to get a fix for a problem which > causes there to be an extremely high amount of CPU wakeups when gksu > is used (as that kills battery life). The best thing for this is to use backports.org, and in the cases where a package isn't available (and you've made one) consider asking the maintainer to upload a backport (possibly using the patches you've already made). > It would be nice to be able to - for instance - easily install using > a new kernel with better driver support when running on a recent > machine. The (continued?) ability of the development version of d-i to install stable would be very useful in allowing this to happen. [Though I suppose some machinations are required to get a kernel that actually works installed if the one distributed doesn't work.] Don Armstrong -- The game of science is, in principle, without end. He who decides one day that scientific statements do not call for any further test, and that they can be regarded as finally verified, retires from the game. -- Sir Karl Popper _The Logic of Scientific Discovery_ §11 http://www.donarmstrong.com http://rzlab.ucr.edu
Re: Bugfix/hardware support updates to stable releases?
> There are plans for an "etch + 1/2" release which would update the > kernel and X server to support newer hardware. I don't what the status > or timetable for this is.\ This would be great. I'm curious who is working on it... Why not use backports.org? Well, none of what I need is there. (I guess the kernel is, but it's only 2.6.21 and I *need* 2.6.22). It's also unofficial, so it's not something that a user buying a new machine would really want to use as a long term solution. Only release-critical bugs are fixed in a stable release. You can get > non-critical fixes for some packages by selective use of backports.org. It seems like it would be good to have all fixes that can be done without disruption... Ben. > > -- > Ben Hutchings > When you say `I wrote a program that crashed Windows', people just stare > ... > and say `Hey, I got those with the system, *for free*'. - Linus Torvalds > >
Re: Bugfix/hardware support updates to stable releases?
On Thu, 2007-08-30 at 20:05 -0400, Tim Hull wrote: > Hi, > > About a month ago I inquired here as to what Debian is doing regarding > backported updates for stable releases. I did get some good responses > to that thread, and I see why Debian doesn't expend too much energy > making significant updates (like new GNOME, Xorg, etc etc) to *stable* > releases - it would make them *un*stable. > > However, this still leaves the question of bugfixes and hardware > support updates - things that, while not necessarily "new-toolchain" > complexity, are mostly excluded by the current updates policy. As of > now, there is no way for stable users to get many bugfixes or support > for hardware released recently (basically anything since fall of last > year) without resorting to installing testing/unstable packages or > unsupported packages, all of which are not security supported. There are plans for an "etch + 1/2" release which would update the kernel and X server to support newer hardware. I don't what the status or timetable for this is. > In my case, this has been quite a pain, as I have had to backport the > kernel and about 5 auxiliary packages from testing/unstable to get > reasonable functionality on my machine (a MacBook). Why not use backports.org? > I've also had to backport libgksu to get a fix for a problem which > causes there to be an extremely high amount of CPU wakeups when gksu > is used (as that kills battery life). > > Is there any plans to work on supporting such issues in the stable > release, either through -volatile or the release updates? Only release-critical bugs are fixed in a stable release. You can get non-critical fixes for some packages by selective use of backports.org. Ben. -- Ben Hutchings When you say `I wrote a program that crashed Windows', people just stare ... and say `Hey, I got those with the system, *for free*'. - Linus Torvalds signature.asc Description: This is a digitally signed message part
Re: Bugfix/hardware support updates to stable releases?
On Thu, Aug 30, 2007 at 09:02:32PM -0400, Tim Hull wrote: > > There are plans for an "etch + 1/2" release which would update the > kernel and X server to support newer hardware. I don't what the status > or timetable for this is.\ > > > This would be great. I'm curious who is working on it... There was a BOF about it at debconf this year where we discussed a lot of the details. The video of that BOF is located at [0]. I haven't heard anything about it since then though. - David Nusinow [0] http://meetings-archive.debian.net/pub/debian-meetings/2007/debconf7/low/273_Etch_and_12_BOF.ogg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bugfix/hardware support updates to stable releases?
Le Fri, Aug 31, 2007 at 01:45:40AM +0100, Ben Hutchings a écrit : > > Only release-critical bugs are fixed in a stable release. You can get > non-critical fixes for some packages by selective use of backports.org. > Actually, I would be happy to hear opinions (in private if you think the question was trivial) on the follwing bug : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=425508 Basically, IBM does not distribute anymore the tarballs supported by Etch's `java-package', wich means that the package becomes much less useful on powerpc. Would this kind of problem be enough for a stable update? My gut feeling is that if in order to use Etch one has to know how to use backports.net, it is not really Etch anymore... Have a nice say, -- Charles Plessy Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bugfix/hardware support updates to stable releases?
[Charles Plessy] > Actually, I would be happy to hear opinions (in private if you think the > question was trivial) on the follwing bug : > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=425508 > > Basically, IBM does not distribute anymore the tarballs supported by > Etch's `java-package', wich means that the package becomes much less > useful on powerpc. If the package is totally broken because it can't download an external file it needs, then that would be an RC bug, appropriate to fix in an etch point release. It looks as though only part of the functionality is broken, though, in that there are multiple tarballs you can download with java-package and only one fails, so the situation is less clear. I'd still consider it something fixable in etch, but I'm neither a RM nor a java-package maintainer. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ signature.asc Description: Digital signature
"Etch and a half" ( was Re: Bugfix/hardware support updates to stable releases?)
Hi all, The idea (mentioned in the prior thread) of having an "Etch and a half" release with an updated X/kernel/installer sounds EXACTLY like what I was hinting at. Backports are great, but having a supported, Debian-tested release that Debian can give to users with new/exotic hardware (which has better support in newer kernels/X releases) would be much better. I've been wrestling with Etch this summer on my MacBook (first generation!), and such a release would probably eliminate 99% of my complaints. Many Debian users are probably in the same boat - they don't mind having an old GNOME/Emacs/coreutils, but do mind being stuck with a kernel/X/installer that doesn't fully support their hardware. Anyway, I'm curious - is this still a legitimate consideration within Debian? If it were to be done, it would have to be December/Januaryish (any later and it would be too close to Lenny, unless of course Lenny is late). I figure that this would be a new "branch" - much in the same sense as sarge, etch, lenny, and sid are. Thus, one wouldn't HAVE to upgrade, but new users and anyone standing to benefit from a new X/kernel (and possibly some other bugfixes) would want to consider using the new "etch and a half". I think this idea would definitely benefit Debian - more people would be able to use it, and it would remain quite stable while still supporting the latest hardware. Obviously, there are issues with the whole plan. For one, Debian would effectively have one more development branch - at least while any such "and-a-half" releases are developed. Effectively, this may end up looking like FreeBSD if such releases ever became common - albeit with less updates to the "-stable" branch. Furthermore, that would mean one more branch to support with security updates, upgrades to lenny (or lenny+1 if a "lenny-and a half" or a "lenny-and-two-thirds" are ever made), etc. These are all legitimate concerns. However, I think it's worth consideration - in my mind, this would fix Debian's greatest flaw in a way that's much better than the Ubuntuish "we must release the full distro every 6 months" approach. I'm curious to hear what everybody thinks regarding this whole concept, and I'd love to see Debian seriously consider this. Tim P.S. I know I am not a Debian developer, and I don't even have a package in the archive. I totally understand if you feel like it's a bit overreaching for me to bring things like this up. Rest assured that I appreciate everything Debian does, and I don't mean to detract from that AT ALL. I will say that I'd definitely test any "and-a-half" release if this ever came to fruition, and I'd work to help make it work out as I could. Heck, I've already been trying to work on making my own "and-a-half" to make Etch work fully on my MacBook :)
Re: "Etch and a half" ( was Re: Bugfix/hardware support updates to stable releases?)
Tim Hull wrote: > Anyway, I'm curious - is this still a legitimate consideration within > Debian? Yes. > If it were to be done, it would have to be December/Januaryish (any That's the plan. > Thus, one wouldn't HAVE to upgrade, but > new users and anyone standing to benefit from a new X/kernel (and possibly > some other bugfixes) would want to consider using the new "etch and a > half". That's the plan. > I think this idea would definitely benefit Debian - more people > would be able to use it, and it would remain quite stable while still > supporting the latest hardware. Yes. > However, I think it's worth consideration - in my > mind, this would fix Debian's greatest flaw Yes. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
