[openstack-dev] [oslo] nominating Alexis Lee for oslo-core
mriedem at linux.vnet.ibm.com
Sun Jan 31 23:24:39 UTC 2016
On 1/30/2016 3:44 PM, Davanum Srinivas wrote:
> 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
>>>> 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 ?
>>> 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
More information about the OpenStack-dev