Open Stack

Just wanted to confirm what Sean said -- as someone who just joined the OpenStack community last
year, going to implement a vaguely worded blueprint and then having the code review be derailed
with people saying "well, you probably should be using this completely different design" is fairly
frustrating.  While you come to anticipate certain changes, IMHO it's definitely much better to decide
on the design *before* you start coding, that way code reviews can focus on the code, and you don't have
to completely rewrite patches as much.

Best Regards,
Solly Ross

----- Original Message -----
From: "Sean Dague" <sean at dague.net>
To: openstack-dev at lists.openstack.org
Sent: Tuesday, April 15, 2014 1:45:16 PM
Subject: Re: [openstack-dev] [Nova] nova-specs

On 04/15/2014 11:42 AM, Russell Bryant wrote:
> 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.

I think the previous process is a huge demotivator to contributors, when
they file a blueprint with minimal info, it gets approved, they spend
months working on it, and only at the end of the process does the idea
get dug into enough for people to realize that it's not what anyone wants.

At that point people are so invested in the time they spent on this
feature that turning that conversation productive is really hard.

Catching more of these up front and being more explicit about what Nova
wants in a cycle is goodness.

	-Sean

-- 
Sean Dague
Samsung Research America
sean at dague.net / sean.dague at samsung.com
http://dague.net


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev