Use of DCO

[Dave Neary]

Hi,

On 01/03/2013 02:59 PM, Anthony Liguori wrote:
> Dave Neary <dneary at 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