Open Stack

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160130/87a93403/attachment.pgp>