Hi, On 01/03/2013 02:59 PM, Anthony Liguori wrote:
Dave Neary <dneary@redhat.com> writes:
On the other hand, ensuring we have the right to ship the code which is submitted to us is a good idea - and pushing the responsibility for asking to the maintainers integrating the code upstream is reasonable. How we do that is an implementation detail - we could of course "hack" SOB as the kernel has done to mean "I've checked and this is fine". It is important to realise that using SOB for this purpose is convention - a process hack, rather than something inate in SOB: http://elinux.org/Developer_Certificate_Of_Origin
The reason I started the thread is to clarify what the process is for oVirt. I'd certainly prefer it to be what's commonly accepted as DCO but what's important is for the process to be documented clearly and followed correctly.
I really think there's a lot of value is not inventing something new so I think we should make every attempt to follow DCO as it's commonly implemented.
Agreed. The two models I've seen for DCO that work well are the kernel one (which you're familiar with), which suits that project's decentralised nature very well, and the Mozilla one: http://www.mozilla.org/hacking/committer/ which maps well to that organisations way of working (with reviewers & super-reviewers taking the responsibility, as opposed to individual developers). Formalising the process through Git as the kernel does, and making it clear at some point in the submission process that you have the right to make the submission, is sufficient I think. I don't think we should require signed agreements to be conscientious from new maintainers. Regards, Dave. -- Dave Neary - Community Action and Impact Open Source and Standards, Red Hat - http://community.redhat.com Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13