Open Stack

On 11/11/2013 12:17 PM, Russell Bryant wrote:
> On 11/11/2013 12:08 PM, Mark McLoughlin wrote:
>> On Mon, 2013-11-11 at 11:41 -0500, Russell Bryant wrote:
>>> On 11/11/2013 10:57 AM, Mark McLoughlin wrote:
>>>> Hi Nick,
>>>>
>>>> On Mon, 2013-11-11 at 15:20 +0100, Nicolas Barcet wrote:
>>>>> Dear TC members,
>>>>>
>>>>> Our companies are actively encouraging our respective customers to have the
>>>>> patches they mission us to make be contributed back upstream.  In order to
>>>>> encourage this behavior from them and others, it would be nice that if
>>>>> could gain some visibility as "sponsors" of the patches in the same way we
>>>>> get visibility as "authors" of the patches today.
>>>>>
>>>>> The goal here is not to provide yet another way to count affiliations of
>>>>> direct contributors, nor is it a way to introduce sales pitches in contrib.
>>>>>  The only acceptable and appropriate use of the proposal we are making is
>>>>> to signal when a patch made by a contributor for another comany than the
>>>>> one he is currently employed by.
>>>>>
>>>>> For example if I work for a company A and write a patch as part of an
>>>>> engagement with company B, I would signal that Company B is the sponsor of
>>>>> my patch this way, not Company A.  Company B would under current
>>>>> circumstances not get any credit for their indirect contribution to our
>>>>> code base, while I think it is our intent to encourage them to contribute,
>>>>> even indirectly.
>>>>>
>>>>> To enable this, we are proposing that the commit text of a patch may
>>>>> include a
>>>>>    sponsored-by: <sponsorname>
>>>>> line which could be used by various tools to report on these commits.
>>>>>  Sponsored-by should not be used to report on the name of the company the
>>>>> contributor is already affiliated to.
>>>>
>>>> Honestly, I've an immediately negative reaction to the prospect of e.g.
>>>>
>>>>   Sponsored-By: Red Hat
>>>>   Sponsored-By: IBM
>>>>
>>>> appearing in our commit messages.
>>>>
>>>> I feel strongly that the project is first and foremost a community of
>>>> individuals and we instinctively push as much of corporate backing side
>>>> of things outside of the project. We try to spend as little time as
>>>> possible talking about our affiliations as possible.
>>>>
>>>> And, IMHO, the git commit log is particularly sacred ground - almost
>>>> above anything else, it is a place for purely technical details.
>>>
>>> This was exactly my reaction, as well.  I just hadn't been able to come
>>> up with a good alternate proposal, yet.
>>>
>>>> However, I do think we'll be able to figure out some way of making it
>>>> easier for tools to track more complex affiliations.
>>>>
>>>> Our affiliation databases are all keyed off email addresses right now,
>>>> so how about if we allowed for encoding affiliation/sponsorship in
>>>> addresses? e.g.
>>>>
>>>>   Author: Mark McLoughlin <markmc+ibm at redhat.com>
>>>>
>>>> and we could register that address as "work done by Mark on behalf of
>>>> IBM" ?
>>>
>>> That doesn't seem any better to me.  It actually seems more likely to
>>> break, since someone could be using an email address with '+' in it for
>>> some other reason, right?
>>
>> Oh, I'm not saying we parse the "ibm" bit and key off that. Just that we
>> can associate affiliation with email address while still allowing people
>> to use the same email address for everything.
>>
>> A better example - say Robert De Niro works for Nebula but uses his
>> gmail address for everything:
>>
>>   Author: Robert De Niro <taxidriver at gmail.com>
>>
>> but if he did some work sponsored by the NSA, he could do:
>>
>>   Author: Robert De Niro <taxidriver+soldmysoul at gmail.com>
>>
>> and we'd have the tracking tools associate the first email address with
>> Nebula and the second with the NSA.
> 
> Oh OK, I get it now.  That seems fine.  It keeps the git log more
> pristine, and uses the same thing (email address) that we use already
> for building.  There's really no technical work required to implement
> this, which is nice.  It would just be a recommended convention.
> 
>>> I think it may be worth looking at this from a different angle.  Perhaps
>>> we should tone down the focus on company metrics, and perhaps remove
>>> them completely from anything we control or have influence over.
>>
>> I'm down with that. We've definitely jumped the shark on this.
> 
> But Monty makes a good point that if we don't produce this information,
> someone else will with potentially questionable accuracy.
> 
> It's a tough situation, because we really do need to work to encourage
> viewing the project as a community of individuals, at least within the
> technical community.

++