On 09/13/2014 11:07 PM, Michael Still wrote: > Just an observation from the last week or so... > > The biggest problem nova faces at the moment isn't code review latency. > Our biggest problem is failing to fix our bugs so that the gate is > reliable. The number of rechecks we've done in the last week to try and > land code is truly startling. >
This is exactly what I was saying in my ranty email from 2 weeks ago [1]. Debt is everywhere and as any debt, it is unlikely going away on it's own. > I know that some people are focused by their employers on feature work, > but those features aren't going to land in a world in which we have to > hand walk everything through the gate. > The thing is that - without doing work on the code - you cannot know where the real issues are. You cannot look at a codebase as big as Nova and say, "hmmm looks like we need to fix the resource tracker". You can know that only if you are neck-deep in the stuff. And then you need to agree on what is really bad and what is just distasteful, and then focus the efforts on that. None of the things we've put in place (specs, the way we do and organize code review and bugs) acknowledge or help this part of the development process. I tried to explain this in my previous ranty email [1] but I guess I failed due to ranting :) so let me try again: "Nova team needs to act as a development team". We are not in a place (yet?) where we can just overlook the addition of features based on weather they are appropriate for our use case. We have to work together on a set of important things to get Nova to where we think it needs to be and make sure we get it done - by actually doing it! (*) However - I don't think freezing development of features for a cycle is a viable option - this is just not how software in the real world gets done. It will likely be the worst possible thing we can do, no matter how appealing it seems to us as developers. But we do need to be extremely strict on what we let in, and under which conditions! As I mentioned to sdague on IRC the other day (yes, I am quoting myself :) ): "Not all features are the same" - there are features that are better, that are coded better, and are integrated better - we should be wanting those features always! Then there are features that are a net negative on the code - we should *never* want those features. And then there are features in the middle - we may want to cut those or push them back depending on a number of things that are important. Things like: code quality, can it fit withing the current constraints, can we let it in like that, or some work needs to happen first. Things which we haven't been really good at considering previously IMHO. But you can't really judge that unless you are actively developing Nova yourself, and have a tighter grip on the proposed code than what our current process gives. Peace! N. [1] http://lists.openstack.org/pipermail/openstack-dev/2014-September/044722.html (*) The only effort like this going on at the moment in Nova is the Objects work done by dansmith (even thought there are several others proposed) - I will let the readers judge how much of an impact it was in only 2 short cycles, from just a single effort. > Michael > > > -- > Rackspace Australia > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
