Linked by Thom Holwerda on Sat 6th May 2006 17:26 UTC, submitted by JMcCarthy
Linux Andrew Morton, the lead maintainer of the Linux production kernel, is worried that an increasing number of defects are appearing in the 2.6 kernel and is considering drastic action to resolve it. "I believe the 2.6 kernel is slowly getting buggier. It seems we're adding bugs at a higher rate than we're fixing them," Morton said, in a talk at the LinuxTag conference in Wiesbaden, Germany, on Friday.
Thread beginning with comment 121684
To view parent comment, click here.
To read all comments associated with this story, please click here.
2.8?
by diegocg on Sat 6th May 2006 20:06 UTC in reply to "Time for 2.7 series?"
diegocg
Member since:
2005-07-08

Perhaps it is time for them to stop their "live" fixes into the 2.6 production kernel, and start up the odd-numbered development line, 2.7

They don't need to do that. They could mark 2.6.17 as "stable" release and then continue the development for, say, another 10 releases, and release a "stable" release again.

And no, this wouldn't be the same than starting 2.7. Many people seems to miss the point that the "new development model" was created to _avoid_ bugs while at the same time adding new features, in some way. In a pure development release, people starts mergin stuff with less care than in a normal release and continues doing so for a long period of time. When you want to take the release out, it takes AGES to stabilize it (look at how much it took to release 2.6)

However, in the new development model you have no "unstable" release. All the releases are supposed to be stable, so people needs to do things well if they want to see their stuff merged. Instead of a Big Unstable Release which takes a year to become .0 and another year to become really stable, do small incremental improvements. This ensures that at least you can control much better the bugs: It's much easier to fix a bug report that says "something broke between 2.6.14 and 2.6.16" than "something broke between 2.4 and 2.6.0" because the number of changes between 2.6.14 and 2.6.16 is much smaller. From a Q/A POV, the current model makes things easier if you take care of them. IOW: While people can't avoid that 2.6 releases are not 100% stable, they're _quite_ stable. Look at the amount of things that have been added in the latest 5 releases: http://wiki.kernelnewbies.org/wiki/LinuxChanges - maybe 2.6 is not 100% stable, but looking at the current amount of changes, I'd say that it's a major hit that they can guarantee so much stability with so much stuff happening. You really need a good Q/A process to take kernels like that out and not make crash every machine at some point.


So my take: Sure, stop adding changes to 2.6 stable. But don't start 2.7: Start 2.8 directly with the same policies than now. Or mark 2.6.16 as stable release and continue developing 2.6.x (it's the same), but avoid pure development releases. For BIG projects like the linux kernel is, pure unstable releases are a bad, bad, bad thing.

Edited 2006-05-06 20:15

Reply Parent Score: 5

RE: 2.8?
by ndw1 on Sun 7th May 2006 19:43 in reply to "2.8?"
ndw1 Member since:
2006-05-07

".. Instead of a Big Unstable Release which takes a year to become .0 and another year to become really stable, do small incremental improvements. This ensures that at least you can control much better the bugs: It's much easier to fix a bug report that says "something broke between 2.6.14 and 2.6.16" than "something broke between 2.4 and 2.6.0" because the number of changes between 2.6.14 and 2.6.16 is much smaller. "

This is why versioning is important. The metrics or applied measurement and practice of pairing a release " header " to output is independent from the decentralized, worldwide and sometimes spontaneous input of release activity itself. Using some archival functions in git was a step in the right direction for Torvalds, et al. however there is room for improvement.

To me, versioning says everything about a project. There is time, and then there is the time it takes to complete an estimated or forecasted task both decided and arrived at by collaboration and personal effort. For example, the program sox for mpeg/*.Wav finagling is at version 12, while a young project with less than 6 months of development may be at increment .5, .99 or 1.01.

To serialize physical or virtual objects is commonplace. Take L.o.C. and book reference numbers. There is ISBN, where the biggest challenge is keeping the search database current with demand based, online need-to-know criteria. A borders.com worker told me the publishers are adding 3 digits to the ISBN. So, in the publishing realm some folks decided where, how and why before adding digits to a means of better providing book tracking services.

We need something similar in linux/sunos/mac world. A quick example: a product ID or UPC number can be generated every time a patch, bug fix or workaround to 2.6 is issued BUT.. there has to be strict definition, implementation, application and EXTERNAL review of this ad-hoc If, Then, Else rule.. Let us say this productID number has to be filed or put in an open repository with pure ODF storage and retrieval ( get and put ). A core productID framework could incorporate an incremental versioning system into the document itself. As long as it begins with UTF-8 or ISO-8859-1 or something standards compliant before its format gets translation it will be alright--heck, most mailing lists and list's Web folders do that. The " Else " part is harder: in this situation if we don't have the productID parity directly correlated or inline with the open repository there is no metre to the release and alas no true versioning.

[][)// - nickosf@comcast.net

Reply Parent Score: 1