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

Bus

[kevin_conaway]

What if he gets hit by a bus? What would happen then?

Is there a hierarchy of maintainers (like the succession to President) or what?

Seems to me they should have at least 2 people at that spot so its not completely a single point of failure.

Re:Bus

[Pieroxy]

As far as my experience has shown me, there is no 'single point of failure' in any team made of humans. Some things would be lost for sure, but life (of the project) would just go on.

Of course, as everything in life, it is not black and white. He would have to be replaced (or the devel structure shifted) and changes would result from this. But the whole thing would not just stop.

Re:Bus

[greppling]

What if he gets hit by a bus? What would happen then?

Nobody knows but I am not worried. The Linux kernel community has always been great in adopting to new circumstances. Alan Cox decided to drop kernel work for a year to do a MBA? No problem, his role got taken over by a couple of people. Linus has to decide to drop BK? No big problem, Linus start writing GIT, which is quickly taken over by other people, and after 2 weeks development continues almost as if nothing happened. Dave Jones gets overworked pushing bug fixes from 2.4 to 2.6? No problem, maintainers step in and push the stuff themselves.

I have a lot of trust in the robustness of the LK development.

Of course, development would suffer without Andrew Morton. His skill in managing the process is just impressive. But it would not break the process.

Start adding unit tests

[Anonymous Coward]

Add a requirement that each bug should have a failing unit test, that fails before the patch is applied and succeeds after the patch is applied.

Re:Start adding unit tests

[Nasarius]

An OS kernel is to an extent the impractical side.

No. Unit testing a monolithic kernel is impractical. Unit testing and OO-like design are some of my favorite benefits of microkernels. Creating mock-hardware to use in the testing would still be extremely complex, but worthwhile in the end.

it's an architectural problem

[idlake]

This is an architectural problem, not a resource problem. There is no reason why the Linux kernel should require the baroque system of manual patches and updates that is currently in place. Instead, it should be composable at runtime out of many modules that are encapsulated enough and insulated enough from one another to be developed and updated independently.

Re:it's an architectural problem

[mrchaotica]

I think the kernel you're looking for is HURD. ; )

Re:it's an architectural problem

[pstreck]

bah, hurd is a just another peice of vaporware :) *ducks*

Re:automated testing in kernel development?

[Anonymous Coward]

Automated tests can be an excellent tool for software issues, but aren't as valuable when dealing with some of the hardware interaction problems that kernel bugs get reported for. A Perl module can spit out the result of a test immediately, whereas a kernel bug might only show up after a few days of heavy load, or be amazingly specific about the combination of hardware in use, perhaps enough so that only a few people in the Linux community would have the same kit.

Still, it's something to have a go at. There are quite a few automated tests done on the linux kernel already, such as the Linux Test Project - http://ltp.sourceforge.net/.

Re:What I wan't to know is...

[justsomebody]

Well, here it is (odd second#) ftp://ftp.kernel.org/pub/linux/kernel/v1.1/v1.1.0. tar.bz2 for you to feel kewl and believe me, that it was still fresh in 94

Re:Test?

[brunson]

It sounds like they could benefit from a practice in Xtreme Programming. The test cases should be written before the patch is written and submitted with the patch. The test cases would then go into a regression framework and the regression test must be passed before a release.

You can't test quality into the product

[petej]

Quality comes from design and implementation, not testing. Testing confirms that quality (or its lack). Testing is only one means of achieving that confirmation, and it's almost never the most effective of those means (assuming "effectiveness" is measured as number of defects removed per unit of effort expended).

Re:Test?

[laptop006]

Show me how to write usable test cases for hundreds of peices of random hardware.

That which can be tested already is (The big one I can think of is filesystem stability).

You should at least read kernel traffic to see how much attention some of this code gets, and personally, I'm amazed at how few bugs are left, and how many of those are just badly designed hardware.

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

[iabervon]

The thread actually went in the other order. Linus said he was worried about Andrew burning out, and asked him how he was doing. Andrew said he's fine with his job, but that getting patches that don't work slows him down a lot. Then he said that there doesn't seem to be much queued for 2.6.15.

The reason for 2.6.15 being light isn't that everyone's using 2.4; 2.6.13 got so many changes that the changelog (since 2.6.12) was too big to send to the mailing list. My theory is that the latest change to the process (everything for 2.6.14 had to be ready two weeks after 2.6.13 came out) meant that everything close to ready got done in a hurry to meet that deadline, instead of slipping towards 2.6.15. There's also been focus on streamlining the process, which means that stuff goes through it faster, so the volume he's dealing with for a given throughput is lower.