[openstack-dev] [all][tc] governance changes for "big tent" model

Jay Pipes jaypipes at gmail.com
Fri Oct 3 16:05:55 UTC 2014


On 10/03/2014 10:06 AM, Chris Dent wrote:
> On Fri, 3 Oct 2014, Anne Gentle wrote:
>
>> I'm reading and reading and reading and my thoughts keep returning to,
>> "we're optimizing only for dev." :)
>
> Yes, +many.

plus infinity.

> In my reading it seems like we are trying to optimize the process for
> developers which is exactly the opposite of what we want to be doing if
> we want to address the perceived quality problems that we see. We should
> be optimizing for the various user groups (which, I admit, have been
> identified pretty well in some of the blog posts).

Precisely.

> This would, of course, mean enhancing the docs (and other cross
> project) process...

Yep! This is something I harped on quite a bit in my second blog post.

> At the moment we're trying to create governance structures that
> incrementally improve the existing model for how development is
> being done.
>
> I think we should consider more radical changes, changes which allow
> us to work on what users want: an OpenStack that works.

Yay!

> To do that I think we need to figure out two things:
>
> * how to fail faster
> * how to stop thinking of ourselves as being on particular projects

More yay!

> I got hired to work on telemetry, but I've managed to do most of my
> work in QA related things because what's the point of making new
> stuff if you can't test it reliably? What I'd really like to say my
> job is is "making OpenStack the best it possibly can be".
>
> If we keep focusing on the various services as entangled but separate
> and competing interests rather than on how to make OpenStack good, we're
> missing the point and the boat.
>
> Our job as developers is to make things easier (or at least
> possible) for the people who use the stuff we build. Naturally we
> want to make that as frictionless as possible, but not at the cost
> of "the people's" ease.
>
> There are many perverse incentives in OpenStack's culture which
> encourage people to hoard. For example it is useful to keep code in
> one's own team's repository because the BPs, reviews and bugs which
> reflect on that repository reflect on the value of the team.
>
> Who is that good for?
>
> So much of the talk is about trying to figure out how to make the
> gate more resilient. No! How about we listen to what the gate is
> telling us: Our code is full of race conditions, a memory pig,
> poorly defined contracts, and just downright tediously slow and
> heavy. And _fix that_.

I think it's important to discuss both things: the gate structure (and 
various inefficiencies the gate *policies* create within the system) as 
well as the fragility and design of the code bases themselves.

> What I think we need to do to improve is enhance the granularity at
> which someone can participate. Smaller repos, smaller teams, cleaner
> boundaries between things. Disconnected (and rolling) release cycles.
> Achieve fail fast by testing in (much) smaller lumps before code
> ever reaches the global CI. You know: make better tests locally that
> confirm good boundaries. Don't run integration tests until the unit,
> pep8 and in-tree functional tests have passed. If there is a
> failure: exit! FAIL! Don't run all the rest of the tests uselessly.

Yup, ++.

> We need to not conflate the code and its structure with the
> structure of our governance. We need to put responsibility for the
> quality of the code on to the people who make it, not big infra.
> We need to make it easier for people to participate in that quality
> making. And most importantly we need to make sure the users are
> driving what we do and we need to make it far easier for them to do
> that driving.
>
> Obviously there are many more issues than these, but I think some of
> the above is being left out of the discussion, and this message
> needs to stop.

Amen, brother.

-jay



More information about the OpenStack-dev mailing list