Open Stack

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 :|