I still think our code development is fine.
What the new process tries to do is to document the process, and in fact a large part of the idea is to just make it possible for us to say 'this is how we do things, and here is the path this patch took on its way to be integrated.'
I've jokingly called it the 'ISO9000' process -- it doesn't really change how you do things, but you have to document how you do things. And I say jokingly, because the DCO process is obviously meant to be anything but cumbersome (unlike the ISO9000 process), and is really designed to be as easy to integrate as possible.
No. The thing is, the actual developers see how things work, and in fact take all of this for granted. Our changelogs document who does things, so for example, a recent changelog has looked like this (this is just randomly selecting a pretty short one that shows what I try to explain): ChangeSet@1.1737.1.87, 2004-05-22 22:09:49-07:00, firstname.lastname@example.org
[PATCH] rmap 37 page_add_anon_rmap vma
From: Hugh Dickins email@example.com
Silly final patch for anonmm rmap: change page_add_anon_rmap's mm arg to vma arg like anon_vma rmap, to smooth the transition between them.
Here there's two things you see: The changeset was sent to me by 'firstname.lastname@example.org' (who is [kernel maintainer] Andrew Morton), and the original author was Hugh Dickins. Additionally, what you don't see (but also gets logged) was that I was the person who 'committed' it to the source control system.
What we haven't had is a process -- a set of documented rules for how we do this. So sometimes it says 'From: Hugh Dickins,' and sometimes it would say 'Based on code by Hugh Dickins,' and usually when a patch went through multiple people we didn't record the people who just passed it on at all.
Which isn't a problem for developers, since the important part of the information is there, but it's a problem if we try to explain how we do things.
So the DCO is trying to formalize this documentation to the point where we can just say 'these are the rules we follow,' and that just ends up making a number of people more comfortable -- especially the kind of people who haven't actually been involved, so they've not seen the process in action. Is this going to make the process laborious? Will it dissuade some from contributing, or encourage more contributions?
I designed the system to be as minimally intrusive as possible, so no, I don't think it will cause any problems. Right now the discussion is all about making sure people know about the process, and have the option to comment on it and we can still change anything if people have issues with it. But I expect that once everybody is used to it, it's going to be just another line in the explanations that get passed around with the actual changes that has a specific format and that people update as they pass these changes around. Did you foresee this day coming?
In the sense that people have discussed having something like this for a while, yes. In the sense of 'did we foresee 12 years ago that we'd need to create such a documentation system,' obviously not. Obviously this applies only to code that is contributed going forward. Are you as confident about the integrity of the code in the kernel today as you were a year ago?
Yup. If there is one positive thing on the SCO lawsuit is that it has caused a lot of discussion -- most of it has obviously been just flamage and noise, but it sure as hell has made people more aware of the issue. How do you expect members of the community will react to the DCO?
So far it's been pretty positive, and a number of people have said 'that makes sense.' There's been worry about the exact details, and for example, sometimes the changes are just so trivial (i.e. one-liner obvious fixes, spelling errors etc), that there is a feeling that we should probably have a 'fast track' where we don't even worry about who does it, since it doesn't matter.
FEEDBACK: Do you think the DCO is necessary? Why or why not?
Send your feedback to the SearchEnterpriseLinux.com news team.