On Sat, May 31, 2014 at 07:00:06AM -0400, Sean Dague wrote:
An interesting conversation happened when I put up a review to pull in devstack-vagrant to gerrit from github - https://review.openstack.org/#/c/96835/ about what in gerrit requires the CLA. I specifically don't want the CLA required on this, as I've actually gotten organic contributors on github because people found it useful to show up and throw a patch my way (then came back because the round trip from patch submission to merge was very short). [...] About 1/2 our dev tools in openstack-dev are not currently CLA required. It actually makes me wonder if any of them need to be. As these tools typically won't be part of an OpenStack release, it makes me wonder if we can drop the CLA on them entirely as a technical matter. For instance, why is there a CLA on devstack?
Given that the board still seems stalled on approving a transition to the contribution framework the development community wants, I wonder if we can at least reduce the number of projects that are creating new developer friction by having a clearer view on what in gerrit we believe has to have the CLA, and ask all the other projects if they want to remove CLA enforcement.
This is a good example of why I think this issue can't be resolved in an informed way without active consultation from the technical community. Bearing in mind I still don't currently have much understanding of gerrit or really any of the details of OpenStack development, I get the sense from this discussion as well as some other conversations that the situation today is something like this: * A project in the openstack repository namespace is seen as unquestionally covered by the (external to gerrit) CLA requirement (or maybe I have that backwards) * For projects under stackforge, it is seen as unquestionably correct that the CLA requirement is discretionary (for whoever has the discretion); the decision is influenced by the nature of the project * Any project under 'openstack-{something}' is seen as probably subject to the CLA requirement, except this is not completely adhered to via gerrit and there is some feeling it may not be correct in all cases * Projects that would otherwise naturally be under openstack-dev, at least, can avoid the uncertainty of the previous point by moving the project to stackforge * If a project is assumed to be covered by the external-to-gerrit CLA requirement (or someone with discretion decides to assume this) this is then always implemented by setting the gerrit property that says a contributor agreement is required. This then, I assume, is enforced through gerrit, except it can't currently be enforced for the CCLA, just for the ICLA (see Stefano's recent posting). * Gerrit (as a general observation) is designed to facilitate use by projects that require "contributor agreements" as well as the DCO, in the sense that you have those flags for requireContributorAgreement and requireSignedOffBy. I assume that implies that at least some administrative aspects of switching to a DCO system would be low cost, and also (see previous point) might (arguably) have some advantages over the current way the CLA system is administered through gerrit. * Projects in gerrit that *do* have the CLA requirement (in the gerrit sense) may have in an earlier stage of their existence not operated with any comparable CLA requirement - I suppose that is something that was obvious, but it's probably worth noting, somewhat akin to the useful point you make about risk at http://lists.openstack.org/pipermail/legal-discuss/2014-April/000243.html What I mean by that is, for example, if devstack-vagrant were judged to be covered by the CLA requirement, no one seriously thinks you're going to go back to the github contributors to devstack-vagrant and demand that they and their possible employers sign OpenStack CLAs. * I assume that the namespaces are for more than mere organizational convenience (what's the practical significance if devstack-vagrant goes from openstack-dev to stackforge?) How much if any of the assumptions above did I get right? Thanks, Richard