On Sat, Jan 30 2016, Sylvain Bauza wrote: > I suggest you look how to revert an RPC API change by thinking of our > continuous deployers, you might discover something interesting there. > :)
This is an interesting thought indeed. If you consider every commit to be releasable so then deploy-able, then there's somehow a blurry line on what are bugs and not bugs as soon as you merge any code. But then if you support such a continuous deployment you have to commit that many resources to not have to use git revert, and, as you describe, a way to both revert and support the broken behavior. Considering your reply, I imagine that this is not the case in the project(s) you contribute to unfortunately. :-( Something to think about maybe. > I would like to understand your 1% estimate. Do you think that only one > merged change is bad vs. 100 others good ? What I meant was that if in a "permission policy" your error rate is 1%, the "forgiveness policy" is likely to be 2%. (and it was merely meant as a guesstimate joke based on my few past experience contributing to FOSS – YMMV) > If so, how can you be sure that having an expert could not avoid the > problem ? What's an expert? > I disagree with you. Say that one change will raise an important gate issue > if merged. Sure. Easy to imagine since this happened just yesterday where all the telemetry projects gates got broken by devstack merging Keystone v3 support by default¹. > 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. Oh right… you mean like the change that broke all the telemetry project gates this week… but that has been merged by a team of (what you call) experts? Should we dispose them from devstack-core since they don't qualify anymore to your definition of expert? > 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 ? It's funny that you pose a theoretical case that just happened a few days ago. But you're not posing the problem correctly. …unless you want to kick out Sean and Dean (sorry guys ;-), there is already a forgiveness permission. Which means acknowledging that, people do mistakes, whatever their level of expertise is, whatever your test coverage is, and when that happens, you fix it. And it's easier/faster to fix with a larger team than a few. Which mean inclusion. Which mean openness. You want zero defect? Then remove all humans from the equation (good luck with that :-). The point of my original email is that team should recognize that, embrace it, and not try to implement the opposite. That does not mean giving any power to anyone, that just means being fair and trusting people to be good and honest. Most people just are – unless proven otherwise as Joshua stated. ;-) ¹ https://review.openstack.org/#/c/271508/ Cheers, -- Julien Danjou -- Free Software hacker -- https://julien.danjou.info
signature.asc
Description: PGP signature
__________________________________________________________________________ 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
