Open Stack

On 06/24/2015 12:25 PM, Daniel P. Berrange wrote:
> Which happened repeatedly. You could say that
> the first patch submitted to the code repository should simply be a doc
> file addition, that describes the feature proposal and we should discuss
> that before then submitting code patches, but then that's essentially
> just the specs again, but with the spec doc in the main nova.git instead
> of nova-specs.git.

Something like this, yes.   I do not like the fact that the spec and the 
code are likely to be out of sync, and that the target audience for the 
spec after the feature is implemented is vanishingly small. We should 
put the effort into docs that is currently going in to specs.

But, I stand by what I said before: Gerrit is not the right tool for 
design, and specs are correspondingly owned by one person.  I think it 
is the approval part that really bugs me; the pedantry is its defining 
feature.  These are details much better hashed out in the code itself.

Specs prevent code from being written.  If you think too much code is 
written, then, yes, you will like specs. If, on the other hand, you 
think that things should be implemented and tested before being posted 
to the central repo, then specs are not nearly as valuable as end user 
docs.  I think and design in Code, not in specs.  There are too many 
details that you don't discover until you actually write the code, and 
thus the specs often do not reflect the reality of the implementation 
anyway.

So, what needs to be approved is not the spec, but the problem 
statement.  Saying "don't work on this until we agree your problem is 
something to solve" is far more useful than "don't work on this until we 
approve your design."