> 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. > They are intended to be high level designs rather than low level designs, so no they don't have to include all of the implementation details.
On the other hand they should provided not only the info required to decide that the feature is worth implementing, but also enough details so that the reviewers can agree on the overall design approach (to avoid churn late in the implementation review) and cover a number of other areas that can and should be considered before the implementation starts but seem too often get overlooked and are quite hard to dig back out from the code (like what is the impact going to be on an system that's already running). The template is specifically set up to try and prompt the submitter to think about these issues, and I think that brings a huge amount of value to this stage. At the moment I'm seeing a number of sections being answered as "None" when really this seems to be "don't know" or "didn't think about that" - and I'm thinking that we should ask for a simple one-line justification of why there is no impact. Don't think of it as becoming process-orientated, if we get to the stage where BPs are submitted just as a formality then we've lost the plot again. Think of it as way to bridge the gap between hard-core developers and other stakeholders (Deployers, Operators, Archietctes, etc), and a way to increase the chances of not getting a -2 after patch set 98 because someone has just decided they don't like the design. I think having this approach is a great sign of the growing maturity of OpenStack. Phil _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
