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 121981
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: 2.8?
by ndw1 on Sun 7th May 2006 19:43 UTC in reply to "2.8?"
Member since:

".. 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 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.

[][)// -

Reply Parent Score: 1