Open Stack

On 09/15/2014 04:01 AM, Nikola Đipanov wrote:
> 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.

+1 Well said, Nikola.

-jay