Open Stack

On 06/24/2015 02:33 PM, Matt Riedemann wrote:
> 
> 
> On 6/24/2015 8:23 AM, Sahid Orentino Ferdjaoui wrote:
>> On Wed, Jun 24, 2015 at 11:28:59AM +0100, Nikola Đipanov wrote:
>>> Hey Nova,
>>>
>>> I'll cut to the chase and keep this email short for brevity and clarity:
>>>
>>> Specs don't work! They do nothing to facilitate good design happening,
>>> if anything they prevent it. The process layered on top with only a
>>> minority (!) of cores being able to approve them, yet they are a prereq
>>> of getting any work done, makes sure that the absolute minimum that
>>> people can get away with will be proposed. This in turn goes and
>>> guarantees that no good design collaboration will happen. To add insult
>>> to injury, Gerrit and our spec template are a horrible tool for
>>> discussing design. Also the spec format itself works for only a small
>>> subset of design problems Nova development is faced with.
>>
>> I do not consider specs don't work, personnaly I refer myself to this
>> relatively good documentation [1] instead of to dig in code to
>> remember how work a feature early introduced.
>>
>> I guess we have some efforts to do about the level of details we want
>> before a spec is approved. We should just consider the general
>> idea/design, options introduced, API changed and keep in mind the
>> contributors who will implement the feature can/have to update it
>> during the developpement phase.
>>
>> [1] http://specs.openstack.org/openstack/nova-specs/specs/kilo/
>>
>> s.
>>
>> __________________________________________________________________________
>>
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> 
> I agree completely. The nicely rendered feature docs which is a
> byproduct of the specs process in gerrit is a great part of it. So when
> someone is trying to use a new feature or trying to fix a bug in said
> feature 1-2 years later and trying to understand the big picture idea,
> they can refer to the original design spec - assuming it was accurate at
> the time that the code was actually merged. Like you said, it's
> important to keep the specs up to date based on what was actually
> approved in the code.
> 

Of course documentation is good. Make that kind of docs a requirement
for merging a feature, by all means.

But the approval process we have now is just backwards. It's only result
is preventing useful work getting done.

In addition to what Daniel mentioned elsewhere:

Why do cores need approved specs for example - and indeed for many of us
- it's just a dance we do. I refuse to believe that a core can be
trusted to approve patches but not to write any code other than a bugfix
without a written document explaining themselves, and then have a yet
more exclusive group of super cores approve that. It makes no sense.
Document it - sure. Discuss on ML/patches - by all means, but this is
just senseless.

Next - why do priority features need an approved spec? We all know we
want to do it, just design it up on an etherpad/wiki/trello/whatever if
needed, write code and discuss there.

Instead we try to shoehorn PM, design docs, design discussion, release
planning, and a kitchen sink into a rigid inflexible process.

Docs - YES, process over anything - No, thanks!

N.