| |||||||||||||
Kernel prepatch 2.6.10-rc3
Linus has announced the availability of
2.6.10-rc3. Changes since -rc2 include the un-deprecation of
MODULE_PARM() (it is generating too many warnings, and the fixes
will not be merged before 2.6.10), a new major number (180) for the "ub"
USB storage driver, some x86 single-stepping fixes, a large number of
"sparse" annotations, the token-based memory
management fix, a memory technology device (and JFFS2) update, a frame
buffer device update, some user-mode Linux patches, some page allocator
tuning, and a few architecture updates. See the long-format changelog for the details.
The emphasis at this point is on bug fixes and getting a solid 2.6.10 out the door. That may involve waiting for a bit; as Andrew Morton put it: "We need to be be achieving higher-quality major releases than we did in 2.6.8 and 2.6.9. Really the only tool we have to ensure this is longer stabilisation periods." (Log in to post comments)
Achieving high-quality major releases of the Linux kernel Posted Dec 4, 2004 4:33 UTC (Sat) by jreiser (subscriber, #11027) [Link] ... the only tool we have to ensure this is longer stabilisation periods.What? Don't the thousands of automated test cases that have been accumulated during more than a dozen years of development suffice? :-)
Achieving high-quality major releases of the Linux kernel Posted Dec 4, 2004 15:38 UTC (Sat) by ncm (subscriber, #165) [Link] Now, now, John, let's not be nasty.
One might suspect that some company (IBM, SGI, even RH or Suse) would have its own set of regression tests. However, there would seem no advantage in keeping them secret, and enormous advantages to not keeping them secret. We can conclude with some confidence that there is no such secret test suite.
You mean, like the LTP? Posted Dec 4, 2004 16:40 UTC (Sat) by louie (subscriber, #3285) [Link] LTP is IBM's effort at this. But I presume it has the same problems keeping up with the pace of development that every other non-core developer has.
Achieving high-quality major releases of the Linux kernel Posted Dec 5, 2004 17:14 UTC (Sun) by job (guest, #670) [Link] ... and let's not forget that if Linux was developed with the goal ofbecoming the catch-all UNIX kernel it is today, it would be forever stuck in political bickering, bad architecture decisions, and the like. It would not have attracted developers continously but when it's "ready" (which would be never).
Achieving high-quality major releases of the Linux kernel Posted Dec 4, 2004 19:37 UTC (Sat) by iabervon (subscriber, #722) [Link] Those are great for testing everything that's broken before. But they still have to have a variety of actual users test for things that just broke for the first time. Then there are all of the things that only break on computers with unexpected hardware combinations (IIRC there was a bug where the system thought it was out-of-memory when it was a NUMA system with a node that lacked some kind of memory entirely, which happened on some moderately common system).
Then, of course, there are the things that aren't strictly-speaking wrong, but cause common code to behave very poorly or trigger bugs in userspace needlessly.
Unfortunately, people aren't satisfied simply by a huge number of possible bugs the kernel doesn't have...
Achieving high-quality major releases of the Linux kernel Posted Dec 6, 2004 17:41 UTC (Mon) by cliffman (guest, #13144) [Link] I've said it before, and I'll say it again. We (OSDL) have machines, and code. We run automated tests, everyday. Results, code, and scripts are all publically available, here: http://www.osdl.org/lab_activities/kernel_testing/stp
and here:
We keep _nothing secret around here. it's all open. The problem is getting people to look at the test results, because OSDL doesn't have that many people available to do this. ( There's only three of us in tesdev, and we have other responsibilities. ) If _you have test code you want run, we'll help you add it to our rig. If _you would like to look at, analyse and comment on tests already rum, we're here to help. If you have kernel patches you want tested, our robots are here to serve you.
Kernel prepatch 2.6.10-rc3 Posted Dec 4, 2004 4:34 UTC (Sat) by jcm (subscriber, #18262) [Link] Those UML patches are probably worth taking a look at - I've seen variable issues with compilation with the last couple of "stable" kernels (e.g. with skas vs. non-skas building). There seem to be some ongoing issues with ppc UML support right now.
Jon.
Kernel prepatch 2.6.10-rc3 Posted Dec 4, 2004 11:08 UTC (Sat) by danielos (subscriber, #6053) [Link] "Of course, nobody will test -rc3 and a zillion people will test final 2.6.10, which is when we get lots of useful bug reports. If this keeps on happening then we'll need to get more serious about the 2.6.10.n process. Or start alternating between stable and flakey releases, so 2.6.11 will be a feature release with a 2-month development period and 2.6.12 will be a bugfix-only release, with perhaps a 2-week development period, so people know that the even-numbered releases are better stabilised." Andrew Morton I prefer first option, odd-even scheme at this level make confusion. But, yes it's true, nobody will test -rc3 and it would be fine if distro such as debian experimental do package rcX kernels, but the real point is that rcX are actually preX release in 2.6 tree: NO new features should be added in a rcX realease, a exception is ok, but for 2.6 this became the rule. So go with 2.6.10.x schema (and maybe with someone who maintain this subtree) d.
Kernel prepatch 2.6.10-rc3 Posted Dec 4, 2004 22:35 UTC (Sat) by hawk (subscriber, #3195) [Link] I think if they actually made a difference between -pre and -rc like 2.4 does, it would be easier to know how meaningful testing is.
Basically, use the -pre and -rc names like everyone expects them to be used - -pre is a prerelease, -rc is a release candidate.
Ie, throw out -pre's at whatever pace feels comfortable, when you would have released the final version, instead release -rc1 (then people know that this is considered "ready for release" by the developers, which will encourage testing). If nothing bad comes up, release the final version else release -rc2, etc.
This would at least be much easier to follow for people who don't really follow the discussions on LKML.
Kernel prepatch 2.6.10-rc3 Posted Dec 5, 2004 0:03 UTC (Sun) by khim (subscriber, #9252) [Link] This is all just stupid. The only sane way to go is to use 2.6.10.3 numbering style. Why ? Since 2.6.x now goes with big changes from time to time it's never known if 2.6.11 will be out in two to three weeks or may be two to three months. And bugfixes are needed all the time. So 2.6.10.3 will be good idea to have even if 2.6.10 is actually fully tested - you never know when new security bug will be discovered. Of course patch from 2.6.10 => 2.6.10.3 should be as small as possible: no enhancements, no cleanups, no big destructive changes - only bugfixes.
Kernel prepatch 2.6.10-rc3 Posted Dec 5, 2004 1:51 UTC (Sun) by Felix.Braun (subscriber, #3032) [Link] I have made good experiences with 2.6.9-ac. Granted, I'm just running them on my desktop (so I don't usually have huge uptimes anyway), but Alan's kernels seem rock solid. More so than 2.6.8 and 2.6.9 at any rate.
Kernel prepatch 2.6.10-rc3 Posted Dec 5, 2004 12:20 UTC (Sun) by danielos (subscriber, #6053) [Link] Actually I have no experience with -ac tree, but I don't think Alan tree is the same as what 2.6.X.x tree should be: just bug fix.
Most distros regularly apply patch to kernel to fix problems, it would be better if this is done upstream, at least for the common reported/solved problems, so having a better feedback from linux kernel developer in a less hidden chanel.
d.
Kernel prepatch 2.6.10-rc3 Posted Dec 5, 2004 13:42 UTC (Sun) by maceto (guest, #16498) [Link] Hope we can have a bugfix release now and a stable release for chrismas
There should be about 4-6 major releases pr year, and small updates between.
linuz,x.org, gnome/kde can coordinate their releases and thus other projects can follow...
Better upstream bug fixes :-)
Kernel prepatch 2.6.10-rc3 Posted Dec 5, 2004 16:07 UTC (Sun) by iabervon (subscriber, #722) [Link] The current -ac tree is just bugfixes, with the exception that the most recent one contains an experimental bugfix (that is, it should fix a real bug, but it might break other things). I don't think it had started the last time a distro released an official production kernel, though, so I don't think it's actually been blessed by the distros as the place they go for stability.
I'm not sure what his plans for 2.6.9-acX are when 2.6.10 comes out, so I'm not sure if 2.6.9-acX will continue until 2.6.10-acX has no regressions, like it should in order to really be a good stable series.
Kernel prepatch 2.6.10-rc3 Posted Dec 6, 2004 23:26 UTC (Mon) by Xanadu (guest, #1215) [Link] And all this is exactly why I'm still on a 2.4.* kernel. The .6 is still way too much "up-in-the-air" for my liking of having a "known stable" system. OK, yea, .6 may be kinda "faster" than .4, but, anything I need to do on a day-to-day basis, .4 is more than happy with. I use Gentoo, so "my" sources are still patched a bit, but:$ name -a Linux aragorn 2.4.28-gentoo-r2 #3 Sun Nov 28 21:10:48 EST 2004 i686 Intel(R) Pentium(R) 4 CPU 2.40GHz GenuineIntel GNU/Linux I can do everything I need to do. I see no reason to "upgrade" (first of all). Secondly, I see no reason to upgrade to a production kernel that is not only known to be buggy, but also not stable. My personal feeling is Linus should sit on it for a while and only accept bug-fixes, no more features for a while. (woah! that sounds like a development cycle! ...)
Kernel prepatch 2.6.10-rc3 Posted Dec 5, 2004 17:18 UTC (Sun) by job (guest, #670) [Link] I think breaking the "odd devel, even stable" rule was stupid. It was badfor 2.4 and it will be even worse for 2.6. There shouldn't be these kind of problems at all in the stable tree. The sub-releases should be mostly bugfixes in there, with some exceptions.
Kernel prepatch 2.6.10-rc3 Posted Dec 6, 2004 1:53 UTC (Mon) by cotte (subscriber, #7812) [Link] I do believe that it was actually a good idea. It's just handy for developers. In the 2.4. series -after splitting the 2.5.x- it was not too easy to bring enhancements into the tree. Marcelo was quite restrictive with what he took.There are two kinds of enhancements: Those that lead to restructuring the kernel or an entire subsystem, and small ones. The small ones can easily be tested and sorted out first, for example in the -mm tree, and then go into mainline when they are stable. As long as we don't have some of those "fundamental" enhancements at hand, the current way of maintenance allows for nice and fast integration of new features. I believe that Andrew and Linus are doing a good job at the moment, and I hope we can find a good way to deal with this stability issue while being able to bring new enhancements to the users fast.
Kernel prepatch 2.6.10-rc3 Posted Dec 6, 2004 11:11 UTC (Mon) by danielos (subscriber, #6053) [Link] ".. the current way of maintenance allows for nice and fast integration of new features .."
This is very interesting, but I'm not so sure it's all true. Some change such as plugable I/O scheduler was not in 2.6.0, and this is just one change that came to mind that restructures a piece of kernel, but there are a number. I think instead that kernel developers (and development model) are becoming smarted and smarted so that even structural change can be done in a stable tree. But some change such as reiser4 raise a lot of resistence.
It could be interesting a 2.7 tree in which it go all new concept in a clean way, while maintaining this development practice in 2.6, but maybe is better the reverse
Kernel prepatch 2.6.10-rc3 Posted Dec 6, 2004 14:31 UTC (Mon) by pflugstad (subscriber, #224) [Link] But, yes it's true, nobody will test -rc3 and it would be fine if distro such as debian experimental do package rcX kernels, but the real point is that rcX are actually preX release in 2.6 tree: NO new features should be added in a rcX realease, a exception is ok, but for 2.6 this became the rule.Amen. They're complaining that no one tests the -rcX releases - but people don't test them for precisely that reason - they considder them -preX rather than -rcX, so what's the point in testing them. The absolutely need to distinguish between -preX and -rcX. Pete
forget "final versions"; get a stable branch Posted Dec 6, 2004 16:30 UTC (Mon) by edmundo (guest, #616) [Link] I don't know much about current kernel development, but all this talkof "release candidates" and "final versions" doesn't make much sense to me. I would have thought you want a sequence of versions in which there are only bug fixes and in which one can therefore be fairly confident that there are no regressions: what is usually called a "stable branch". There can be no "final version" because if a serious bug is discovered there will have to be a new version that fixes it, until the whole branch is abandoned in favour of a newer branch. I think this is how the even-numbered kernels used to work, and probably they still do work that way once they get old enough. It sounds as though 2.6.x is not being developed as a stable branch in this sense (presumably with good reason) so someone should make a stable branch off it. Releasing 2.6.10.1, 2.6.10.2, etc, until the whole branch is superseded by 2.6.11.x, sounds like a good idea to me. That might avoid the ridiculous situation of a version not getting properly tested until it has been declared as "final" and then not getting properly fixed because it is then too late.
forget "final versions"; get a stable branch Posted Dec 7, 2004 2:58 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link] there has never been a kernel release that would qualify as 'stable' by your definition.
the 1.0, 1.2, 2.0, 2.2, and 2.4 kernels all received updates over their lifetime (and 2.0 and later still are)
at this point the 2.0 and 2.2 kernels are only receiving bugfixes, but not many of those so they barely qualify as maintained.
the 2.4 kernels are still receiving significant updates. not as significant as the 2.6 series, but still significant (look at the size of the patch for each release, if that was all bugfixes what in the world did the 2.4.17 kernel look like :))
every single kernel series has included driver fixes and updates, even under the most paranoid 'stability only' controls. these driver fixes and updates have resulted in random breakage for people useing them.
you are of course free to take any kernel release and turn it into a stable branch by your definition, but the work of backporting fixes is going to be quite a bit of work (and you also have to decide exactly what you define as a fix.. not a question with a trivial answer)
|
|||||||||||||