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-requ...@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. __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev