+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
