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."
Good idea, even if some people will say that SCO scared them into doing it (they say it is a factor, but not the driving reason)
Over years, Linux development team has become an enterprise. Finally they realised that they need accounting.
Anything that prevents the possibility of another SCO-type BS lawsuit is a Good Thing.
Hopefully it can avoid patent issues too. If something goes into Linux and later some company (Microsoft?) files a patent lawsuit, there may be evidence of prior art if the code was "certified" on a certain date.
On the reverse side, it can provide exactly who contributed the code (which can already be done mind you), but this time, they certified it for use, which can possibly cause more legal troubles.
There are only 10 kinds of people in this world... those who understand binary and those who don't
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!
The story is a little light on the details. The change management system they use (I remember hearing it was BitKeeper) ought to log the users who contributed the code automatically. What I'm wondering is if Linus is talking about validating the identity of the contributers. If so, this will prevent any anonymous code contribution. I wonder how many people who work for companies that signed NDAs are contributing code that will no longer be able to do so?
That we will soon see SCO/AdTI press-releases saying "we were right! There are serious problems with the way Linux-hackers handle the code! After all, if there are no problems, why are they taking these steps to correct the situation? This proves once and for all that our claims regarding Linux are true!"
Lesbian Nazi Hookers Abducted by UFOs and Forced Into Weight Loss Programs - -all next week on Town Talk.
Take my comments with a grain of salt, because I am up to my eyes in process development because we are trying to get CMM Level 2 certification where I work.
I don't see a problem at all with documenting the way things are done. I know a lot of people resist it, but think about it. How hard would it be for Linus to just write down how he does things. You'd be surprised how many times you uncover problems (or potential problems) when you have to write down your processes. Sometimes, you immediately see ways to improve things. If not, then at most you are out a little bit of effort.
But I really think that Linus wants to do this so that when he is on the stand and a SCO attorney asks him how code is added to the kernel, he can just say "RTFM!".
My beliefs do not require that you agree with them.
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)
Perhaps this will also help to avoid attempts from hackers to insert backdoors as we have seen recently..
The authentication needs to be done using GPG (GNU Privacy Guard) or PGP (Pretty Good Privacy). This will prevent anyone in the future from inappropriately placing code in the kernel. These two programs provide an excellent means of determining the authenticity of the author. Moreover, the origins of all code submissions can easily be tracked and catalogued using some open source software some friend of mine and I have been working on. In a nutshell it works like this: Code is received either by FTP, E-mail or (virtually) any other mans. At the end of the encrypted code, the code is signed and encrypted with the writer's key. Each of these keys is kept in a database that contains verified information about the writer. This can include their name, and address, or whatever is appropriate. This database is kept as a public record of which code belongs to whom, and when it was created (or submitted). Think about it... anybody who wants to submit code should not be able to do so anonymously. This stands to reason in light of what has been going on lately with SCO. Moreover, this method looks good to executives who have no idea how software is developed and is a legitimate method of proof. So far as being on the Internet, this project is not right now, some friends of mine and I at the University have been beta testing it and it works wonderfully and is very secure. Thank you for your interest!!!! Any thoughts?
I hope not, since the "unprofessional" model has worked so well (and I'm not being sarcastic). This is more an acknowledgement that GNU/Linux is swimming in dangerous waters, and has enemies with money to burn. Even though SCO's claims have apparently turned out to be lame, you have to assume that intellectual property traps are being set left and right.
Excerpt from the first: So anyway, what do people think? Would such a license management approach with tools, protocols, and standards (ensuring every work received or sent comes with a legally binding machine-readable license and related audit trails for derived works) promote more clearly titled (in a legal sense) free software or would it be the slippery slope to the "right-to-read" future? Without explicit licensing handling, are we just setting the free software or open content communities up for legal challenges down the road as people just try to do their best without such tools? Is trying to automate license handling really that much different (in a bad way) from the current situation of often distributing zip files including both content and license?
Excerpt from the second: This need for a license is especially true for making derived works you plan to redistribute, because here your liability seems highest. If we are to have a lot of free software and free content, based on fine grain collaboration made possible by the internet allowing us to rapidly modify each others works, that is a lot of licenses citing a lot of authors. If these licenses get lost (as in the midi file download example I cited), the content can no longer be considered free. Handling lots of papers is what computers are good at. The less time people need to spend thinking about, negotiating, and managing paperwork and extra files related to free licenses, the more time they can spend making free software and free content.
A 21st century issue: the irony of technologies of abundance in the hands of those still thinking in terms of scarcity.
Signing patches alone may not entitle kernel development to be called "professional". Don't forget that many patches are sent over SMTP, and it is possible for spoof a real kernel contributor. Of course, most of the spoof attempts will fail, but with the present and potential future scale of the kernel development, Father Brown's `unnoticed' theory might manifest.
Do companies like Microsoft or Sun make Developers certify that the code they submit in a particular check-in isn't "borrowed" from GPL'd or other open source stuff?
Seems Linux is well ahead of professional organizations in this respect.
Well obviously we'd love Linux to be better than Windows and OSX in every way. Thats pretty unrealistic though. You can't honestly say that either Windows or OSX is definitively better than the other in every way, and for that matter I'd argue that there are ways in which Linux is already clearly better than both. But no OS will ever be all things to all people.
I'd also add that the kernel lacks nothing that would allow good hardware detection, as thats not really the kernel's job. Device drivers... well, we could go on about that forever, but thats a matter of convincing hardware manufacturers to play nice with Linux. And yeah, some of that falls on the kernel developers, but they're not even remotely the whole problem.
The way I read it, this 'process improvement' is just to provide more precise accountability for changes. Sounds good as far as resolving future legal issues, but I doubt if it'll result in a better kernel.