Open Stack

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.

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).

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

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.

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

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_.

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.

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.

-- 
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent