[openstack-dev] [oslo] nominating Alexis Lee for oslo-core

Sylvain Bauza sylvain.bauza at gmail.com
Sat Jan 30 12:55:18 UTC 2016

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160130/dc0909ce/attachment.html>

More information about the OpenStack-dev mailing list