Open Stack

On 05/31/2014 12:21 PM, Richard Fontana wrote:
> 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)

Currently, yes, openstack/* projects are all CLA enforced as far as I know.

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

Correct.

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

Actually, most of openstack-infra is not under the CLA, and
openstack-dev (which is sort of vestigial) is mixed.

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

Yes, definitely.

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

Correct. It will actually prevent code upload to those projects if there
is not an active ICLA, which is one of the cryptic errors that new users
often hit and are confused about.

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

Yes. It's just another flag.

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

Correct.

> * 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?)

Yep, mostly just logically grouping. It makes sense to have the core
team for devstack-vagrant be the existing devstack team, so putting it
in the same place in the tree makes sense.

> How much if any of the assumptions above did I get right?

I think that's a pretty fair assessment. I also think that it's worth
noting that often times CLA enforcement on projects even in stackforge
wasn't something people actually directly wanted, but was a thing that
they copy / pasted from a template not realizing it was a decision in
the first place.

	-Sean

-- 
Sean Dague
http://dague.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/legal-discuss/attachments/20140602/dc6b787b/attachment.pgp>