[openstack-dev] [oslo] nominating Alexis Lee for oslo-core
Matt Riedemann
mriedem at linux.vnet.ibm.com
Sun Jan 31 23:36:13 UTC 2016
On 1/31/2016 4:24 PM, Matt Riedemann wrote:
>
>
> 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.
*none of us are experts over the whole thing I meant.
>
> 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
More information about the OpenStack-dev
mailing list