Torvalds & Linux Dev Process

sebFlyte writes "Builder UK is reporting that Linus Torvalds is concerned that the Linux production kernel maintainence process might be overly taxing Andrew Morton, saying: "One issue is that I actually worry that Andrew will at some point be where I was a couple of years ago -- overworked and stressed out by just tons and tons of patches. If Andrew burns out, we'll all suffer hugely." Morton himself wants to make -mm releases more often. He sees bugs as more of a problem, rather than patches themselves. His solution is simple: "I'd like to release -mm's more often and I'd like -mm to have less of a wild-and-crappy reputation. Both of these would happen if originators were to test their stuff more carefully.""

Comments

I haven't moved to 2.6, others haven't either?

[garcia]

There doesn't seem to be much happening out there wrt 2.6.15," said Morton in a mailing list posting. "We're at rc2 [the second release candidate of 2.6.14] and I only have only maybe 100 patches tagged for 2.6.15 at this time. The number of actual major features lined up for 2.6.15 looks relatively small too," he said in a later posting.

Ok, not that much going on w/this kernel, and then we get:

In the same mailing list thread, Linus Torvalds, the creator of Linux and the maintainer of the development kernel, expressed concerns that the kernel development process may need to be changed to make sure that Morton is not overworked.

So, there isn't much traffic coming through and Morton wants to do even more -mm releases but Linus thinks he might become overworked? I'm confused. Any clarification on this from the list that the article doesn't give?

He suggested this may indicate that the kernel is nearing completion. "Famous last words, but the actual patch volume _has_ to drop off one day," said Morton. "We have to finish this thing one day."

I still haven't even bothered to move to 2.6.x as I have no reason to. I used to update my kernels immediately (and even ran various -AC, etc) but 2.4.x has been so stable for me that I see no reason to bother. Perhaps the reason why traffic is low is because of that?

automated testing in kernel development?

[markjugg]

In the world of Perl module development, automated testing plays an important role. As a gatekeeper myself, I often request that a code patch also come with an automated test, and the contributors often follow-up with one, if they didn't supply it in the first place.

In the Pugs project, the coders and testers are generally different people, when the tests being written first.

I'm fairly ignorant about the kernel development process, so I ask: could automated testing play a greater role in the quality assurance of the project?

Kernel 2.6 Problems (Was I better off with 2.4?)

[KhanReaper]

Is it me or has kernel 2.6 been comparibly unstable and quirky in the past six months? I have to admit that I am very disappointed with this instability and wish that the Linux developers would move back again to their old even-stable and odd-testing version numbering. Things did seem to be a lot more stable back then when this old versioning scheme was used. I mean really, for the past few months kernel quirks in 2.6 have made the kernel appear more like a testing kernel than anything. I am thoroughly disappointed.

I know that people will complain that I have not cited anything specific or tangible; that is fine. The point for me is that I am sick of random spurious issues that seem to be fixed in one release and then some new permutation thereof appears later. Candidly a lot of these things have to do with CPU throttling, power management, USB, and other aspects of the kernel.

While I appreciate how much Linux's hardware support has increased over the past few months, the desire for a more mature environment has left me wanting something more.

In all seriousness, if the quirks of kernel 2.6 keep persisting, I might be inclined to migrate to, god-forbid, BSD.

Unit Testing Is Hard

[Vagary]

As someone who uses unit testing for application development, I'd have to wonder whether the cost of setting up such a system would be worth the benefits? One of the big challenges in automated testing is measuring behaviour to check correctness.

How do you check that a kernel driver is using hardware correctly? It's more or less difficult to measure the beavhiour externally depending on the system. Effectively you need to use mock/simulated interfaces -- in this case probably virtual machines -- but then what kind of code coverage would you get?

Personally, for the kernel, I'd guess the bang-for-buck of adding static checking would be higher than dynamic checking.

better interface to the universe ..

[torpor]

.. it should be far easier for branches/nodes of the linux kernel codebase to cross-polinate.

the -mm releases are definitely a high order, public priority; but the broader picture is that there are as many possible permutations of linux code as there are tarballs being globbed.

i see the taxing of andrew (and linus before) as more of an issue of broken tools. if the linux kernel codebase had tools integrated into the core Makefile which would allow for easier tree/pruning/updates and public server integration as the most -common- interface to the .config/Makefile hegemony, i think we'd be seeing a whole lot more public, broader testing going on. its only because i can't confirm/share system .config databases with my peers that it makes it so hard to test other peoples patches; this could just as easily become a 'namespace' manipulated through existing tools ..

i mean, there are too many ways to get yourself a copy of the kernel, maneuver the patch universe (why haven't patch namespaces become another NS record type yet, i wonder..?), find bits you want to test, etc.

i imagine a broader 'namespace of patches, and public tested .configs from .torrent servers[or whatever]' as part of the -basic- Makefile in the kernel releases.. yes, svn&co. have their 'namespaces', but i'm talking about 'make update_patches -server:blahblah.org' as a commonly accepted means of contributing to the patch-sphere.

which is, actually, huge.

Re:Start adding unit tests

[Craig Ringer]

That's reasonable for some very high level subsystems in the kernel. For most things, such as drivers, the scheduler, etc, it's probably not.

Sometimes defining "pass" and "fail" is hard enough, with tuning efforts. Then there's cleanups. On top of that there are fixes to obsure drivers for hardware that nobody on LKML actually has.

I'm all for unit test based development, but there are some levels where it's practical, and some where I don't think it is. An OS kernel is to an extent the impractical side. I do like the idea of unit-tests from userspace to make sure nothing userspace-visible breaks, though.