Open Stack

On 1/30/2016 3:44 PM, Davanum Srinivas wrote:
> Sylvain,
>
> Let's agree to disagree. This works for Oslo, so lets leave it at that.
>
> Also, *please* switch Subject as this is not fair to Alexis's
> nomination if you wish to continue.

I agree, and apologize both to Alexis and the broader team for 
side-tracking this thread, that wasn't my intent.

I was just curious as to the overall oslo-core vs project-specific core 
teams, and trust that oslo-core doesn't overstep their bounds and 
approve changes they aren't sure about, much like nova cores shouldn't 
approve areas of a very large code base where none of us are experts.

Anyway, let's move on - and sorry again for diverting this.

>
> -- Dims
>
> On Sat, Jan 30, 2016 at 6:55 AM, Sylvain Bauza <sylvain.bauza at gmail.com> wrote:
>>
>> Le 30 janv. 2016 09:32, "Julien Danjou" <julien at danjou.info> a écrit :
>>>
>>> On Fri, Jan 29 2016, Sylvain Bauza wrote:
>>>
>>>> While my heart is about that, my brain thinks about some regressions
>>>> could
>>>> be happening because of a +W even for a small change.
>>>
>>> I suggest you read the git-revert manpage then, you might discover
>>> something interesting there. :)
>>>
>>
>> I suggest you look how to revert an RPC API change by thinking of our
>> continuous deployers, you might discover something interesting there. :)
>>
>>> The "shit happened" (e.g. bad thing merged) rate difference between a
>>> "permission" policy and a "forgiveness" policy is based on my very
>>> precise guessed estimation probably close to +1% in disfavor of
>>> "forgiveness". Right.
>>>
>>
>> I would like to understand your 1% estimate. Do you think that only one
>> merged change is bad vs. 100 others good ?
>> If so, how can you be sure that having an expert could not avoid the problem
>> ?
>>
>>> But at the same time, the velocity rate difference is close to +50% for
>>> that same policy. So I've picked my side. :)
>>>
>>
>> I disagree with you. Say that one change will raise an important gate issue
>> if merged.
>> Of course the change looks good. It's perfectly acceptable from a python
>> perspective and Jenkins is happy.
>> Unfortunately, merging that change would create lots of problems because it
>> would wedge all the service projects CIs because that would be a behavioral
>> change that wouldn't have a backwards compatibility.
>>
>> If we have your forgiveness policy, it could have this change merged
>> earlier, sure. But wouldn't you think that all the respective service
>> projects velocities would be impacted by far more than this single change ?
>>
>> -Sylvain
>>
>>> --
>>> Julien Danjou
>>> ;; Free Software hacker
>>> ;; https://julien.danjou.info
>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>

-- 

Thanks,

Matt Riedemann