On Tue, Apr 15, 2014 at 10:01:32AM -0500, Brian Elliott wrote: > > * specs review. The new blueprint process is a work of genius, and I > > think its already working better than what we've had in previous > > releases. However, there are a lot of blueprints there in review, and > > we need to focus on making sure these get looked at sooner rather than > > later. I'd especially like to encourage operators to take a look at > > blueprints relevant to their interests. Phil Day from HP has been > > doing a really good job at this, and I'd like to see more of it. > > I have mixed feelings about the nova-specs repo. I dig the open > collaboration of the blueprints process, but I also think there > is a danger of getting too process-oriented here. Are these design > documents expected to call out every detail of a feature? Ideally, > I’d like to see only very high level documentation in the specs repo. > Basically, the spec could include just enough detail for people to > agree that they think a feature is worth inclusion. More detailed > discussion could remain on the code reviews since they are the actual > end work product.
Having design discussions via gerrit comments on the actual code has been a really ineffective approach, because the stuff being discussed is often spread across multiple files and across multiple separate gerrit changes. That makes it hard to have a coherant discussion on the broad picture. The discussions get buried under the avalanche of comments from the many CI systems we have now too. The latter is IMHO one of the biggest problems I face in reviewing code changes in gerrit in general today. I think it is really beneficial to have a fleshed out design proposal right from the start. I've reviewed many patches where the feature overall made sense, but the implementation approach taken was total madness, needing a major/total rewrite. This was a major waste of time for the person submitting the patch, as well as for all the reviewers before me. A lot of people providing blueprints to Nova don't neccessarily have the domain knowledge to realize there are better ways of achieving their desired goals. So having them provide a high level design, allows for those who are knowledgable to guide them before they go down the wrong road. I've also come across cases where patches claimed to address a particular use case, but when you look at it in detail you find its actually missing the goal. A detailed blueprint makes it easier for reviewers to actually see if the proposed code is satisfying the original goals or not, as well as allowing people who later test the feature to evaluate whether it is working as intended or not. Finally the docs people have to writeup all these new features, and often struggle with the woefully under-specified blueprints we've had in previous releases. These better fleshed out blueprints should serve as a good basis for the docs people to writeup new features. IOW I think the nova specs design repo is going to be a significant win for everyone involved in Nova across the board. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev