Open Stack

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.

-- 

Thanks,

Matt Riedemann