Open Stack

On 04/15/2014 11:01 AM, 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.

There is a balance to be found here.  The benefit of doing more review
earlier is to change direction as necessary when it's *much* easier to
do so.  It's a lot more time consuming to do re-work after code has been
written, than re-work in a spec.

Yes, it's more up front work, but I think it will speed up the process
overall.  It means we're much more in agreement and on the same page
before code even shows up.  That's huge.

One of the big problems we've had in code review is the amount of churn
and re-work required.  That is killing our throughput in code review.
If we can do more up front work that will reduce re-work later, it's
going to be a *huge* help to our primary project bottleneck: the code
review queue.

-- 
Russell Bryant