[openstack-dev] [keystone][all] Move from active distrusting model to trusting model

Thierry Carrez thierry at openstack.org
Tue Nov 24 10:43:26 UTC 2015


Clint Byrum wrote:
> Excerpts from Brad Topol's message of 2015-11-23 13:38:34 -0800:
>> So to avoid the perception of a single company owning a piece of code,  at
>> IBM our policy for major projects like Cinder, Nova and currently many
>> parts of Keystone (except pycadf) is to make sure we do not do the
>> following for major OpenStack projects:
>>    * Employee from Company IBM writes code
>>    * Other Employee from Company IBM reviews code
>>    * Third Employee from Company IBM  reviews and approves code.
>>
>> Again for certain small projects we relax this rule.  And certainly we
>> could discuss relaxing this rule for larger portions of Keystone if needed.
>> But as a general policy we strive to stick to the distrust model as much as
>> we can as the "perception of impropriety" that exists with the  trusting
>> model can result in tangible headaches.
> 
> Thanks Brad. I think this is an interesting example where it's not
> the single organization that is not being trusted by the community,
> but the community that is not being trusted by the single organization.
> Their behavior may be warranted, but IMO a community member refusing to
> respect a contribution because it is from a single organization that
> is not theirs is an example of a community member misbehaving, which
> I feel should be dealt with quietly but swiftly. We should strive to
> understand anyone who feels this way, and do what we can to _address_
> their concerns, instead of avoiding them.

Right. The code is either in and supported by everyone, or out. If some
contributors object to the code being in, that should be resolved when
the code is being proposed (or initially merged), rather than by
assuming some areas of the code are now a specific organization's fault
(and therefore segmenting your code maintenance duties).

-- 
Thierry Carrez (ttx)



More information about the OpenStack-dev mailing list