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.ba...@gmail.com> wrote:
Le 30 janv. 2016 09:32, "Julien Danjou" <jul...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Thanks,
Matt Riedemann
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
