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" <[email protected]> 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:[email protected]] >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" <[email protected]> >To: [email protected] >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 >[email protected] / [email protected] >http://dague.net > > >_______________________________________________ >OpenStack-dev mailing list >[email protected] >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >_______________________________________________ >OpenStack-dev mailing list >[email protected] >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >_______________________________________________ >OpenStack-dev mailing list >[email protected] >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
