Open Stack

Exactly.  Even if operators/users only comment with a +0, it's already
flushed out a lot of good details on several blueprints.

Thanks!
Matt


On 4/15/14 2:38 PM, "Tim Bell" <Tim.Bell at cern.ch> wrote:

>
>+2
>
>I think that there is also a need to verify the user story aspect. One of
>the great things with the ability to subscribe to nova-specs is that the
>community can give input early, when we can check on the need and the
>approach. I know from the CERN team how the requirements need to be
>reviewed early, not after the code has been written.
>
>Tim
>
>-----Original Message-----
>From: Solly Ross [mailto:sross at redhat.com]
>Sent: 15 April 2014 21:16
>To: OpenStack Development Mailing List (not for usage questions)
>Subject: Re: [openstack-dev] [Nova] nova-specs
>
>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
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev