Advertisement
Front, Kernel, Security, Distributions, Development. See your byline here on LWN.net.
| |||||||||||||
|
| |||||||||||||
The 2.6.32-rc8 kernel is out
Linus has released 2.6.32-rc8. "The
way things are going, this will likely be the last -rc. I wish we had more
people looking at the regression list, but at some point I'm just going to
have to say 'ok, enough is enough'." Details may be found in
the
full changelog.
(Log in to post comments)
The 2.6.32-rc8 kernel is out Posted Nov 20, 2009 16:56 UTC (Fri) by Tuxie (guest, #47191) [Link]
Are all regressions from 2.6.30 to 2.6.31 fixed by now? Those between 2.6.29 and 2.6.30? If they are, I'm OK with them releasing 2.6.32 with some regressions if they aren't severe and they will be fixed in 2.6.32.x.
However, if they aren't fixed I'm getting truly worried. At the very least, a 2.6.x kernel should be delayed until the regressions from 2.6.(x-1) are fixed.
That's just my humble opionion as someone who is not a kernel developer though.
The 2.6.32-rc8 kernel is out Posted Nov 20, 2009 17:32 UTC (Fri) by ariveira (guest, #57833) [Link]
Clearly no becouse i'm still waiting for this to be fixed ;P
http://bugzilla.kernel.org/show_bug.cgi?id=13362
The 2.6.32-rc8 kernel is out Posted Nov 20, 2009 19:05 UTC (Fri) by mb (subscriber, #50428) [Link]
> However, if they aren't fixed I'm getting truly worried. At the very least, a 2.6.x kernel should be delayed until the regressions from 2.6.(x-1) are fixed.
So you want to stall Linux development just because a regression in a random driver that (obviously) nobody cares about is unfixed? I don't think that is a very good idea.
The 2.6.32-rc8 kernel is out Posted Nov 20, 2009 23:51 UTC (Fri) by k8to (subscriber, #15413) [Link]
Isn't the idea that drivers should be in-kernel that they won't just randomly break with no one caring?
The users apparently care, they're speaking here. The developers apparently don't.
The 2.6.32-rc8 kernel is out Posted Nov 21, 2009 0:37 UTC (Sat) by dlang (✭ supporter ✭, #313) [Link]
rather than talking in generalities.
exactly which driver is broken that the developers don't care about?
how do you know the developer has been told about the problem? (note that filing a ticket in your distro bugzilla does not mean that the kernel developer knows about it)
The 2.6.32-rc8 kernel is out Posted Nov 21, 2009 3:37 UTC (Sat) by k8to (subscriber, #15413) [Link]
Maybe you should ask ariveira who posted a specific link to a bug filed at kernel.org?
The 2.6.32-rc8 kernel is out Posted Nov 20, 2009 17:03 UTC (Fri) by qg6te2 (guest, #52587) [Link] I wish we had more people looking at the regression listSorry to be a pain, but I've never heard a convincing argument as to why the number of regressions isn't required to be zero before releasing a new kernel. I realise that it can be hard work and time consuming to fix everything, however this lack of perseverance (and the appearance of a cavalier attitude) simply wouldn't fly in a mission critical environment. It either works with the given hardware as it should, or it fails. Perhaps a requirement of any new patch should be that it first passes a set of regression tests? Furthermore, even if a patch (by itself) passes the tests, its combination with other patches may cause a regression (where each of the patches doesn't individually cause a regression). If so, this would indicate there is something wrong with the kernel at a deeper level -- in this case the root cause should still be investigated and fixed, instead of simplistic patch reverts.
The 2.6.32-rc8 kernel is out Posted Nov 20, 2009 18:09 UTC (Fri) by adobriyan (guest, #30858) [Link]
> Perhaps a requirement of any new patch should be that it first passes a set of regression tests?
There is none.
The 2.6.32-rc8 kernel is out Posted Nov 20, 2009 18:41 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
there are tests, but the problem is that there is a LOT of different hardware out there. nobody has (or can have) everything, let alone every permutation of all the different hardware combinations (if for no other reason that most, if not all of the hardware hasn't been manufactured in enough quantity to have one for every combination with every other piece of hardware)
so it's impossible to have it completely tested prior to release.
once it gets out in the hands of users they find issues with their hardware, software, usage pattern, or just workload. these get reported as regressions.
since usually the developers do not have the hardware to duplicate the problem, they cannot just 'go and fix it' they have to have the user who found the problem test things. this is a slow process.
sometimes the problems are actually faulty hardware, which makes it even harder to deal with.
The 2.6.32-rc8 kernel is out Posted Nov 20, 2009 20:25 UTC (Fri) by adobriyan (guest, #30858) [Link]
There is none even for non-driver specific software,
except what major commercial distros have in-house.
Regardless, the possible endeavour of adding reasonable "make test"
The 2.6.32-rc8 kernel is out Posted Nov 20, 2009 22:49 UTC (Fri) by Ed_L. (guest, #24287) [Link] since usually the developers do not have the hardware to duplicate the problem, they cannot just 'go and fix it' they have to have the user who found the problem test things. this is a slow process.Hey -- I resemble that remark! I've a fairly rare Abit AT8 RD480-based Main board with ULi 1575 SB. Works fine with CentOS 5.x, but the sound (RealTek ALC883) is GEF under at least 2.6.29 and newer, including 2.6.32.rc7 Rawhide. You'd think snd_hda_intel would be pretty beat-up by now, but noooooo. Blacklist snd_hda_intel and everything is fine, (but no tunes). Enable snd_hda_intel and no joy: occasionally it will boot to nicely working sound, but most usually it just locks the system, requiring hardware reset. I've reported this as Bugzilla 521004 but am not optimistic this will be fixed by anyone but myself. Who else has one of these things? I'm a good C coder, but not a kernel hack. Should I display more patience and (continue) to wait for direction from Fedora, or has anyone a link to tips for debugging device drivers? It acts like a memory problem....
The 2.6.32-rc8 kernel is out Posted Nov 20, 2009 23:42 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
if you can compile a kernel.org kernel for your machine and duplicate the problem there report it directly to the kernel developers.
they mostly do not use bugzilla, look up in the MAINTAINERS file the sound chip you have and it will list how to contact the maintainer for that driver. In my experiance they love to have a user is can run the latest version of stuff to test (even with a turnaround of a couple of days)
The 2.6.32-rc8 kernel is out Posted Nov 20, 2009 18:48 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
quote:
Sorry to be a pain, but I've never heard a convincing argument as to why the number of regressions isn't required to be zero before releasing a new kernel. I realise that it can be hard work and time consuming to fix everything, however this lack of perseverance (and the appearance of a cavalier attitude) simply wouldn't fly in a mission critical environment. It either works with the given hardware as it should, or it fails
if you require zero bugs before release you will never release anything.
In addition, development of new things doesn't stop while you are working on regressions. there are thousands of developers working on Linux, there are ~30 known regressions. what are the other developers supposed to do while the release is held up?
what happens in practice is that they keep working on their projects (with for most of them have nothing to do with the regressions anyway). if you delay the release you may fix a few more of the regressions, but the result is that the pile of new changes that has accumulated is larger. The larger the new changes are, the more likely it is that there will be regressions (interactions between changes, not knowing all possible hardware combinations, etc) and therefor (with your policy) a longer delay before the next release, leading to an even larger pile of changes for the release after that, ......
as much as it offends purists, the current strategy is doing a pretty good job of balancing regressions with progress. things could be better, but delaying releases is not the answer.
The 2.6.32-rc8 kernel is out Posted Nov 22, 2009 17:20 UTC (Sun) by madscientist (subscriber, #16861) [Link]
The OP didn't say that Linus should require zero bugs, he said Linus should require zero _reported regressions_, which is an entirely different, and possibly achievable (unlike zero bugs) goal.
Nevertheless, it won't happen for reasons similar to the ones clugstj mentions. The reality is that the kernel is too complex to serve both the "support new cutting-edge hardware/features" and "provide a rock-solid mission-critical OS" masters. Basically the kernel.org kernels lean more towards the former and rely on the distributions such as Red Hat Enterprise and SUSE to satisfy the latter.
Although it bums me out when a kernel breaks my hardware (either at home or at work), I have a pretty strong feeling we'd all be a lot LESS happy overall if Linus started moving back to "stability" at the expense of "capabilities".
The 2.6.32-rc8 kernel is out Posted Nov 23, 2009 13:05 UTC (Mon) by niner (subscriber, #26151) [Link]
One also has to keep in mind: it's not only about features. New kernels
usually also contain fixes for bugs in previous kernels. So putting a new kernel on hold till new bugs ("regressions") are all fixed also keeps people from receiving fixes to old bugs. So what's more important? New or old bugs? For me personally the decision was to live with minor regressions to get some bug fixed that really was bugging me.
The 2.6.32-rc8 kernel is out Posted Nov 23, 2009 18:16 UTC (Mon) by madscientist (subscriber, #16861) [Link]
I'm confident that the OP felt it a given that bug fix kernels would continue to be released: that is, saying that the NEXT kernel will ship with zero regressions in no way says that previous kernels cannot have bugs fixed there before the new kernel comes out; you don't have to wait.
The 2.6.32-rc8 kernel is out Posted Nov 20, 2009 19:55 UTC (Fri) by jmm82 (subscriber, #59425) [Link]
"however this lack of perseverance (and the appearance of a cavalier attitude) simply wouldn't fly in a mission critical environment."
I do not think that the kernels directly off kernel.org would ever be used for mission critical tasks. Also, the number of regressions in the kernel will never be 0 regardless of what any statistic could report.
The 2.6.32-rc8 kernel is out Posted Nov 20, 2009 20:07 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
in a mission critical environment you never trust software right out of the box, be it from kernel.org, from RHEL, from microsoft, or from anyone else.
you always test it first.
if you test a kernel.org kernel and it meets your needs, there is no reason not to use it in a mission critical environment.
The 2.6.32-rc8 kernel is out Posted Nov 20, 2009 17:26 UTC (Fri) by clugstj (subscriber, #4020) [Link]
I'm not a kernel developer either, but I can figure out why perfection is never achieved. The reason the 2.6.32 kernel has to come out soon is that it is holding up the tons of changes people want to get into 2.6.33. Linus' kernel doesn't go directly into anything "mission critical" - it would be plain stupid to do so.
Is it really worth holding up a release for weeks because of a regression in a feature that 0.01% of users will see? Reverting a change is MUCH safer than rushing out a "fix".
It's a difficult situation that he is in, he must balance the desire to get new features into the kernel with the desire for quality in what is already there. If quality is your only goal, you will never get any new features in. If speed it your only goal, you will put out junk. I think he is doing a remarkably good job of balancing the two.
|
|
||||||||||||