Slashdot Mirror
Process Improvements in the Kernel Development
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."
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.
I hate sigs.
There is an article on this subject at groklaw
It covers more or less the same territory in a bit more depth.
"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.
blah
Patches submitted as AC will no longer be included in the Linux kernel
Do not try to read the dupe, thats impossible. Instead, only try to realize the truth
What truth?
There is no dupe
As taught to almost all people taking the moral high-ground, that are in the public eye:
Avoid even the appearance of wrong doing.
Guys, this is a great idea for accountability in the kernel source. In the next round, the "SCO" of that round might not be so blatently stupid and far more sinister. Please watch your code and keep it clean!
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 ?
Considering all the code thats been leaked lately, this is a welcome insurance policy to keep Linux on track as free alternative OS.
Do you need a website upgrade?
Remember that Linus "retires" from a version of the kernel when he thinks it is stable enough for a maintainer to supervise. Once he is freed from maintaining the current "release" version of the kernel, he starts working on the next development version.
He'll pass version 2.6 to someone and then start work on 2.7, just as he passed 2.4 to Marcelo Tosatti and then began working on 2.5.
IMO, it has its ups and its downs. It allows a greater degree of delegate-the-blame (Good for any large project, Objectively speaking), but it will reduce contributions.
tasks(723) drafts(105) languages(484) examples(29106)