Hi,
On 01/03/2013 02:59 PM, Anthony Liguori wrote:
Dave Neary <[email protected]> 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
_______________________________________________
Board mailing list
[email protected]
http://lists.ovirt.org/mailman/listinfo/board
