Re: Use of DCO
Hi,
On 01/03/2013 02:59 PM, Anthony Liguori wrote:
Dave Neary <dneary(a)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