| |||||||||||||
|
| |||||||||||||
Kernel prepatch 2.6.27-rc8
Linus has released 2.6.27-rc8. "This
one should be the last one: we're certainly not running out of regressions,
but at the same time, at some point I just have to pick some point, and on
the whole the regressions don't look _too_ scary." It is worth
noting that the e1000e corruption problem remains unsolved; one assumes
that the final 2.6.27 release will not happen before that gets fixed.
(Log in to post comments)
Kernel prepatch 2.6.27-rc8 Posted Sep 30, 2008 1:02 UTC (Tue) by miguelzinho (subscriber, #40535) [Link]
Who cares if there is regressions!? Lets release the damn thing anyway.
Kernel prepatch 2.6.27-rc8 Posted Sep 30, 2008 2:06 UTC (Tue) by jreiser (subscriber, #11027) [Link] Who cares [about regressions]? I care. I want my software to run properly. It runs today; it obeys the rules. I expect it to run properly tomorrow.
It obeys the rules. Really? Posted Sep 30, 2008 6:13 UTC (Tue) by khim (subscriber, #9252) [Link] I've dounf that software which DO "obeys the rules" rarely have a regressions. Software which bends them is in trouble...
Kernel prepatch 2.6.27-rc8 Posted Sep 30, 2008 7:34 UTC (Tue) by nix (subscriber, #2304) [Link]
Some of us would rather the kernel not melt our hardware without warning
nor allow other software to melt it, thanks. Or even someone else's.
Kernel prepatch 2.6.27-rc8 Posted Sep 30, 2008 8:13 UTC (Tue) by flewellyn (subscriber, #5047) [Link]
Thank you, Microsoft Quality Assurance Department.
Kernel prepatch 2.6.27-rc8 Posted Sep 30, 2008 16:11 UTC (Tue) by bronson (subscriber, #4806) [Link]
You'll care about regressions the moment you hit one, I promise.
Kernel prepatch 2.6.27-rc8 Posted Sep 30, 2008 17:11 UTC (Tue) by iabervon (subscriber, #722) [Link]
I recently hit a regression going from 2.6.24 to 2.6.25, because of an overly-general quirk that would break old Lenovo 3000 N100s with old BIOS; 2.6.26 had already been released when anybody actually tried 2.6.25 on such a machine. At some point, you have to estimate that the known regressions aren't a big deal compared to the unknown regressions anyway; those will have to be handled as user support instead of QA, and so user support might as well take over the remaining known regressions, too, if they're sufficiently minor. Once the remaining regressions can be taken care of by -stable when they get fixed, it's time to do the next merge window.
Kernel prepatch 2.6.27-rc8 Posted Sep 30, 2008 2:39 UTC (Tue) by jwb (guest, #15467) [Link]
One wonders if the e1000e problems will also hold up the release of Ubuntu 8.10. It's hard to imagine them shipping without 2.6.27, and it's also hard to imagine them shipping without e1000e.
Regarding the e1000e, it's very interesting to note how many bugs can be fixed if people just pay attention. I count patches for at least 3 separate bugs, so far, none of which would have been fixed except people are scouring the driver to find the source of the NVRAM corruption.
Perhaps the kernel would be improved by some kind of "driver emergency of the week"?
Kernel prepatch 2.6.27-rc8 Posted Sep 30, 2008 10:01 UTC (Tue) by kragil (guest, #34373) [Link]
I think they really should postpone the release...
.. then again Mark is proud of releasing on time.
But not every Ubuntu user is always updating his/her system .. so I am not really happy ..
Kernel prepatch 2.6.27-rc8 Posted Sep 30, 2008 12:02 UTC (Tue) by rvfh (subscriber, #31018) [Link]
What has Ubuntu got to do with this? Mandriva is in the same boat, and I guess many others (Fedora?). In fact we all are in the same boat!
Let's wait a bit, calm down, breath... Either a fix is found, or the driver needs to be reverted to its 2.6.26 form. Somehow.
Kernel prepatch 2.6.27-rc8 Posted Sep 30, 2008 15:34 UTC (Tue) by felixfix (subscriber, #242) [Link]
-- What has Ubuntu got to do with this?
I believe it was Mark Shuttleworth of Ubuntu who wanted releases done by the calendar instead of the software state. But I could be wrong; I don't pay much attention to Ubuntu.
Kernel prepatch 2.6.27-rc8 Posted Sep 30, 2008 15:41 UTC (Tue) by pr1268 (subscriber, #24648) [Link] Either a fix is found, or the driver needs to be reverted to its 2.6.26 form. Somehow. That, of course, assumes that 2.6.26 isn't affected. I haven't read the 2.6.27 changelog (yet) so I'm unsure whether the e1000e driver has changed between these releases.
Kernel prepatch 2.6.27-rc8 Posted Sep 30, 2008 9:01 UTC (Tue) by kasperd (guest, #11842) [Link]
I think the kernel should not be released with known regressions. Why would anybody even think about it? If it is just because it delays their possibility to start merging new features, maybe there should be a development branch that is always open for merges. That would lead to the following model:
There are three branches, which would currently be 2.6.26.x releases, 2.6.27-rc release candidates, and 2.6.28 development. Only fixes for crashes, security problems, and regressions are accepted for the first two, only the development branch gets new features.
Once the release candidate has been free from known regressions for a week or two, it gets promoted to an actual release. That would mean at once 2.6.26.x is discontinued. The latest 2.6.27-rc is pronounced 2.6.27. And the latest 2.6.28 development version is branched into 2.6.28-rc1 and 2.6.29 development.
And now that I have thought that whole thing through, it sounds a lot like the debian model. Did I just reinvent an existing development model?
Why would anybody even think about it? Posted Sep 30, 2008 9:40 UTC (Tue) by tialaramex (subscriber, #21167) [Link]
"Why would anybody even think about it?"
Because all non-trivial software contains bugs, and all subsequent releases will contain regressions. So the question is, at what point do the new features and bug-fixes of a new version out-weigh the regressions. If your answer is "never" then you don't need to argue with the LKML, the only conceivable solution for you is to run the same release forever.
Why would anybody even think about it? Posted Sep 30, 2008 10:19 UTC (Tue) by eru (subscriber, #2753) [Link] A regression is a special case of a bug, because you already have both a test case for it and a version of software that does not have the bug (the previous version). So it should be easier to fix. A regression also annoys people more than a new bug in a new feature or a previously unknown bug that also affects the previous version, because people expect the new version to be better or at least as good than the old one, but with regressions it clearly isn't.
Why would anybody even think about it? Posted Sep 30, 2008 12:04 UTC (Tue) by hmh (subscriber, #3838) [Link]
Yes.
And a regression that bricks *very* common hardware, and one that is usually embedded in mainboards (be them of servers, desktops or laptops) at that, is well into the "critical, release-blocker" category.
Yes, the kernel *always* releases with one or two regressions. But it will really be a rotten day for us Linux developers (PR-wise) if Linus decides to release with the current e1000e bricking issue.
Why would anybody even think about it? Posted Sep 30, 2008 16:30 UTC (Tue) by JoeBuck (subscriber, #2330) [Link] There's no danger of that; it's clearly a release blocker.
e1000e bricking? Posted Oct 1, 2008 17:50 UTC (Wed) by vonbrand (subscriber, #4458) [Link] AFAIU, nobody really knows if this issue is in the kernel (in the driver or elsewhere) or if it is some weird interaction with userland.
Kernel prepatch 2.6.27-rc8 Posted Sep 30, 2008 12:04 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
in an ideal world every regression report would get tracked down and confirmed/eliminated before a release.
in practice this doesn't happen for several reasons.
sometimes the reporters don't have the time to respond
sometimes it a really odd race condition that's been around for years and just now triggered
some regression reports are hardware bugs/failures
and sometimes it's just not worth holding _everything_ up just to wait for one regression.
would you be willing to wait a year for the next kernel becouse of a bug in a ISA network card driver?
someone mentioned the debian release cycle, they don't really hit zero regressions before a release either, they will remove entire packages from a release if that package doesn't fix all the 'release critical' bugs. going from a working package to no package at all is definantly a regression.
as for the argument that you should back-out any changes that cause regressions, the problem is that sometimes you can't easily tell what change caused the problem. If someone who can duplicate the problem can do a bisect to find what change caused the problem it usually gets fixed very quickly (by backing out the change if nothing else works), but in cases where this isn't clear it's hard to do.
examples of some of the items on the regression list
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11569
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11512
for a full report look at http://groups.google.com/group/fa.linux.kernel/browse_thr...
some of these look like they really should be fixed, some are questionable.
the biggest reason for Linus' comment is that experiance has shown that there is a point where waiting longer doesn't end up getting these things fixed any faster. (remember the year long 'freezes' of the kernel in prior development models?)
Kernel prepatch 2.6.27-rc8 Posted Sep 30, 2008 12:42 UTC (Tue) by SEJeff (subscriber, #51588) [Link]
Yeah, one that (sadly) doesn't work all that well. They have went over it again and again, but the current form of kernel development works as well as it gets right now.
The biggest change recently was the -next tree. The only point of it is to make sure all sorts of git trees can actually build and play nicely together. Without it, Andrew Morton was starting to have trouble keeping up.
|
|
||||||||||||