Forgot your password?
typodupeerror
Operating Systems Software Linux

Process Improvements in the Kernel Development 124

Posted by Hemos
from the changing-the-process dept.
Kalki writes "In an e-mail to the Linux kernel mailing list, sent Saturday, Torvalds proposed that kernel developers begin certifying that the code that they contribute is entitled to be included in the Linux kernel as well as a technique for "signing off on patches" that would better track which developers had handled source code contributions. check this Infoworld story on it."
This discussion has been archived. No new comments can be posted.

Process Improvements in the Kernel Development

Comments Filter:
  • A good thing. (Score:5, Interesting)

    by Raven42rac (448205) * on Monday May 24, 2004 @08:38AM (#9236652)
    The more organisation and delegation in Linux, the better. With the gains being made using Bitkeeper and this, I feel that Linux will make leaps and bounds in the next year. The things I hope for are better hardware detection and working device drivers for more devices (especially multifunction printers). I think Xandros is getting really close to the way things can be. But then again, I run a Debian CLI install on a Pentium II 350. I guess what I meant to say was, for Linux to gain mass market acceptance, it needs to do everything Windows/OS X does, but better, cheaper and faster.
  • Linus retiring? (Score:4, Interesting)

    by johnthorensen (539527) on Monday May 24, 2004 @08:38AM (#9236657)
    This is very speculative, but this looks like the sort of thing somebody does to ease the transition when they turn something over to another leader. Yeah, it's about a 1:10000 chance that I'm right, but remember you heard it here first...

    -JT
  • tracking (Score:5, Interesting)

    by colinleroy (592025) on Monday May 24, 2004 @08:40AM (#9236677) Homepage
    "signing off on patches" that would better track which developers had handled source code contributions.

    Linus Torvalds' problem is the fact that, as it is currently easy to find out who commited the patch, and often who provided it (which often appears in Bitkeeper's changelog), the whole submission process can be a blackbox - if I send a patch to alsa subsystem's maintainer, he'll probably apply it to alsa's CVS, maybe someone else will modify this patch, and when included in linux' main tree, only the merge information would appear.
  • by kbsingh (138659) on Monday May 24, 2004 @08:41AM (#9236692) Homepage
    Sounds pretty good. I think Linux needs a basic system of this sort in place as-soon-as-practical. It will bring together a lot of accountability of / for code in the Kernel itself. Plus, it should counter any issue like the SCO created one, in the future.

    Another interesting point here seems to be that with this management overhead and the admin work that issue such as this create, how much of time is Linus actually spending with them ? while he might be working with the technical side of things ?

    Inspite of all the noise, there are just a handfull of people contributing major code into the Kernel ( would 300 be a fair guess ? ) How are all these admin overheads going to effect their performance ? Also is anyone / everyone expected to research the piles and piles of patenets / copyrights before they make such a declaration ?

  • Good Idea (Score:5, Interesting)

    by Whitecloud (649593) on Monday May 24, 2004 @08:45AM (#9236722) Homepage
    This sounds like a good way to ensure accountability on who made what changes, and when they did it. Linus says the SCO debacle "have provided a "big impetus" for the changes", this will make sure similar legal action can be shot down immediately.

    Considering all the code [cnn.com] thats [slashdot.org] been leaked [pcworld.com] lately, this is a welcome insurance policy to keep Linux on track as free alternative OS.

  • His aim is different (Score:4, Interesting)

    by lazy_arabica (750133) on Monday May 24, 2004 @09:02AM (#9236823) Homepage
    Taken from Linus post (talking about SCO claims) :
    People have been pretty good (understatement of the year) at debunking those claims, but the fact is that part of that debunking involved searching kernel mailing list archives from 1992 etc. Not much fun.
    I suppose having lawyers read your private mail in order to find some clue about the origine of a piece of code make you a much more careful man.
  • by BinLadenMyHero (688544) <binladen@NOsPam.9hells.org> on Monday May 24, 2004 @09:03AM (#9236828) Journal
    I wonder if this is in any way related to this [slashdot.org].

    From FSF:
    We have just begun a project here at FSF to document and codify our process, so that it can be disseminated in the form of a policy manual and accompanying software, to all other Free Software projects who wish to solidify their legal assembly process. Distilling nearly two decades of organizational know-how into easy-to-understand software and documentation is no easy task, and we will rely greatly on your financial support to aid us in carrying out this momentous task.
  • by Spoing (152917) on Monday May 24, 2004 @09:09AM (#9236874) Homepage
    1. "People who don't understand how I interact with the people I work with literally feel better just having it down more as a documented process," he [Linus] said.

    That's exactly it. Why is it that most of the comments here say "Good...Linux needed more professionalism/riggor/process/...."

    I'm Mr Process myself. I ~love~ the SEI-CMM, will quote you hymn and verse from project plans, will dog you if you are sloppy and can't file a defect report on stuff you yourself wrote or if you mis-categorize it. Process is important because it makes people focus on doing the right thing when they don't want to.

    OTOH...I've also been following Linux (the kernel) for years and how it is managed. The added test suite is fantastic, as is Linus' stand on using the best tools for the task. Linus and the other core Linux developers are already motivated to do the right thing so adding more formal processes in that don't help with development is not a good thing. It's sad. I have no doubt that this extra layer will not get in the way...so it's not too sad!

  • by Xzzy (111297) <[sether] [at] [tru7h.org]> on Monday May 24, 2004 @09:11AM (#9236881) Homepage
    LKML is hardly private. Type darn near anything about linux into google and 50% of the results (or more) are going to be hits off that mailing list.

    It's gotta be one of the most mirrored lists out there.
  • When? (Score:5, Interesting)

    by miffo.swe (547642) <daniel.hedblom @ g m ail.com> on Monday May 24, 2004 @10:55AM (#9237837) Homepage Journal
    Now that the Linux development is totally transparent when will we be able to audit Microsoft, SCO, and other propriarity code for stolen bits and pieces?

    We should shout out of the top of our lungs that the propriarity way foster code stealing because no one can audit it.

  • Re:A Good Thing(tm) (Score:3, Interesting)

    by Deusy (455433) <(charlie) (at) (vexi.org)> on Monday May 24, 2004 @11:17AM (#9238025) Homepage
    Prevent [another SCO-type BS lawsuit]? Nothing will do that short of turning SCO corp. into a legal crater as an example of any other company foolish enough to attempt the same stunt.

    Fortunately SCO and Darl McBride are doing a great job of cratering themselves. Short of turning up and denying the crap SCO is flinging at people, IBM and the like have had to do almost nothing.

    Is it only me who gets the impression, lately, that everything SCO does digs their grave a little deeper?
  • Re:heheh (Score:3, Interesting)

    by bfields (66644) on Monday May 24, 2004 @11:35AM (#9238207) Homepage
    This is more an acknowledgement that GNU/Linux is swimming in dangerous waters, and has enemies with money to burn.

    On the other hand, the SCO case also showed that even a well-funded company given a year (so far) and great incentives to find intellectual property problems in the linux source has been unable to do so.

    Not that it's bad for the linux developers to be careful and think ahead.

    --Bruce Fields

No hardware designer should be allowed to produce any piece of hardware until three software guys have signed off for it. -- Andy Tanenbaum

Working...