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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
