Itamar Heim <iheim@redhat.com> writes:

On 01/02/2013 06:27 PM, Anthony Liguori wrote:

...

Hi,

I've noticed that the various oVirt projects are not using the DCO process correctly. While contributors are adding Signed-off-by's (Good), there's no Signed-off-by being added by maintainers (Bad).

http://lwn.net/Articles/139918/

It may seem like a minor thing, but SOB is meant to provide a chain of custody and it's less effective if the certification isn't also done by maintainers.

For VDSM, I see examples like:

commit 53c6801658a8c5e05ceb518ffd9ebfefa805fda9 Author: Antoni S. Puimedon <asegurap@redhat.com> Date: Tue Dec 18 22:33:39 2012 +0100

Fix blockSD pep8.

Change-Id: I2ed4ce2a5748a911f76da02f762e5bda9352b905 Signed-off-by: Antoni S. Puimedon <asegurap@redhat.com> Reviewed-on: http://gerrit.ovirt.org/10213 Reviewed-by: Dan Kenigsberg <danken@redhat.com>

The last 'Reviewed-by' ought to be a 'Signed-off-by'.

OTOH, ovirt-engine lacks any Reviewed-by tags. For example:

Author: Sharad Mishra <snmishra@linux.vnet.ibm.com> Date: Wed Dec 26 11:10:32 2012 -0800

core: removed obsolete classes vm_template_image_map_id and vm_template_imag

These clasees are not used anymore.

Change-Id: I82f0861644f155f7b6c27ba5acb3a069b6f1a8f6 Signed-off-by: Sharad Mishra <snmishra@linux.vnet.ibm.com>

I'm not sure if this is a limitation in gerrit. I know the question has come up regarding what OpenStack does. OpenStack doesn't use DCO. They have an explicit CLA that everyone must sign before participating[1]. DCO eliminates the need for such an agreement (when used properly).

[1] http://wiki.openstack.org/CLA

Regards,

Anthony Liguori

true, this isn't supported by gerrit when using fast-forward which all projects use but vdsm.

I know very little about the hackability of gerrit... do you know if this is reasonably fixable? Does gerrit allow pre-commit hooks? The GIT_COMMITTER_{NAME,EMAIL} bits are being set correctly so it should be possible to add the Signed-off-by in a hook.

we do enforce the signed-of by for the author of the patch in gerrit.

personally, i see the value of maintainer sign of for the kernel, which has multiple layers of maintainers, but not for ovirt which has no similar concept today.

Patches float around over time even after commit. A good example is a stable branch where patches are backported from master. It's nice to preserve the Signed-off-by history in that case. Then you end up with three SoBs from contributor, master maintainer, and then stable maintainer.

I'm fine with asking for a CLA though if it solves the issue.

I cringe at thought of trying to work out a CLA. We should exhaust all options with respect to following DCO properly I think before going down that road. Regards, Anthony Liguori

Richard Fontana <rfontana@redhat.com> writes:

On Wed, Jan 02, 2013 at 01:24:01PM -0600, Anthony Liguori wrote:

...

...

I'm fine with asking for a CLA though if it solves the issue.

I cringe at thought of trying to work out a CLA. We should exhaust all options with respect to following DCO properly I think before going down that road.

A CLA would not address the issue I believe you are trying to solve with a change in DCO practices.

I'm probably not trying to solve the problem you think I'm trying to solve :-)

You seem to want *non-copyright-holders* to assert something they are not asserting today, right? No CLA does that.

I'm trying to answer the question of: "does oVirt have a CLA" where DCO is generally accepted as a form of CLA. But oVirt isn't following what is commonly accepted as the DCO process because maintainers aren't signing off on patches. I'm making no assessments about the validity of the process that oVirt is following. I only brought up a CLA because the topic of OpenStack was previously raised. Regards, Anthony Liguori

- RF

Richard Fontana <rfontana@redhat.com> writes:

On Wed, Jan 02, 2013 at 04:13:32PM -0600, Anthony Liguori wrote:

...

Richard Fontana <rfontana@redhat.com> writes:

...

...

You seem to want *non-copyright-holders* to assert something they are not asserting today, right? No CLA does that.

I'm trying to answer the question of: "does oVirt have a CLA" where DCO is generally accepted as a form of CLA.

But oVirt isn't following what is commonly accepted as the DCO process because maintainers aren't signing off on patches.

I don't think there is any standard DCO practice, except in the sense that the Linux kernel project introduced the DCO (thus in a sense providing its greatest legitimacy) and AIUI they use the approach you are suggesting.[1] I am certain there are some other projects today that use the DCO without requiring maintainer signoff. (Though that may be because of differences in how such projects are run, I suppose.)

I'm not really sure. I don't know of any really that don't do maintainer Signed-off-bys. The various git tools are designed to follow this process (git-am will automatically add Signed-off-bys for you). It's only because oVirt is using Gerrit that this isn't all automatic.

But I see nothing wrong with your suggestion, certainly.

- RF

[1]It occurs to me to ask, and I'm too lazy to check: is the DCO documented by oVirt? If not it should be. The way the kernel does it, it is clear that maintainer signoff is necessary, as I recall.

Ack. Regards, Anthony Liguori

Dave Neary <dneary@redhat.com> writes:

Hi Anthony,

For the uninitiated is DCO = Developer Certificate of Origin?

Correct.

I am not sure whether oVirt has a formal process similar to the kernel's for this. Signed-off-by in oVirt probably doesn't carry the same baggage for maintainers as it does for the kernel.

For everyone else: this involved developers being asked, and at least verbally affirming, that they have written the patch themselves and have the rights required to publish their work under the relevant license.

A CLA gets around this by having an explicit Contributor Licensing Agreement where developers explicitly grant a license to some entity (usually the project's sponsoring entity or a non-profit supporting the project).

Both Mozilla and the Kernel, and several other projects, have avoided a CLA for a number of reasons - if you're aiming for a diverse developer base (as we are in oVirt) this can slow down adoption and participation by 3rd parties. For that reason, I would not encourage the adoption of a CLA for oVirt.

Agreed.

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. Regards, Anthony Liguori

Cheers, Dave.

On 01/02/2013 05:27 PM, Anthony Liguori wrote:

...

Hi,

I've noticed that the various oVirt projects are not using the DCO process correctly. While contributors are adding Signed-off-by's (Good), there's no Signed-off-by being added by maintainers (Bad).

http://lwn.net/Articles/139918/

It may seem like a minor thing, but SOB is meant to provide a chain of custody and it's less effective if the certification isn't also done by maintainers.

For VDSM, I see examples like:

commit 53c6801658a8c5e05ceb518ffd9ebfefa805fda9 Author: Antoni S. Puimedon <asegurap@redhat.com> Date: Tue Dec 18 22:33:39 2012 +0100

Fix blockSD pep8.

Change-Id: I2ed4ce2a5748a911f76da02f762e5bda9352b905 Signed-off-by: Antoni S. Puimedon <asegurap@redhat.com> Reviewed-on: http://gerrit.ovirt.org/10213 Reviewed-by: Dan Kenigsberg <danken@redhat.com>

The last 'Reviewed-by' ought to be a 'Signed-off-by'.

OTOH, ovirt-engine lacks any Reviewed-by tags. For example:

Author: Sharad Mishra <snmishra@linux.vnet.ibm.com> Date: Wed Dec 26 11:10:32 2012 -0800

core: removed obsolete classes vm_template_image_map_id and vm_template_imag

These clasees are not used anymore.

Change-Id: I82f0861644f155f7b6c27ba5acb3a069b6f1a8f6 Signed-off-by: Sharad Mishra <snmishra@linux.vnet.ibm.com>

I'm not sure if this is a limitation in gerrit. I know the question has come up regarding what OpenStack does. OpenStack doesn't use DCO. They have an explicit CLA that everyone must sign before participating[1]. DCO eliminates the need for such an agreement (when used properly).

[1] http://wiki.openstack.org/CLA

Regards,

Anthony Liguori

_______________________________________________ Board mailing list Board@ovirt.org http://lists.ovirt.org/mailman/listinfo/board

-- 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

On Thu, Jan 03, 2013 at 03:19:06PM +0100, Dave Neary wrote:

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).

The Mozilla approach is not a DCO (that is, it is categorically different from the Linux kernel DCO which is generally what people mean by "DCO"). In the history of all the painfully misguided approaches that have been taken on such matters, I consider Mozilla's approach (at least the last time I looked at it) quite benign. Nonetheless, it strikes me as rather more heavyweight than necessary for many projects. - RF