On 24 October 2013 04:33, Russell Bryant <[email protected]> wrote: > Greetings, > > At the last Nova meeting we started talking about some updates to the > Nova blueprint process for the Icehouse cycle. I had hoped we could > talk about and finalize this in a Nova design summit session on "Nova > Project Structure and Process" [1], but I think we need to push forward > on finalizing this as soon as possible so that it doesn't block current > work being done.
Cool > Here is a first cut at the process. Let me know what you think is > missing or should change. I'll get the result of this thread posted on > the wiki. > > 1) Proposing a Blueprint > > Proposing a blueprint for Nova is not much different than other > projects. You should follow the instructions here: > > https://wiki.openstack.org/wiki/Blueprints > > The particular important step that seems to be missed by most is: > > "Once it is ready for PTL review, you should set: > > Milestone: Which part of the release cycle you think your work will be > proposed for merging." > > That is really important. Due to the volume of Nova blueprints, it > probably will not be seen until you do this. The other thing I'm seeing some friction on is 'significant features' : it sometimes feels like folk are filing blueprints for everything that isn't 'the code crashed' style problems, and while I appreciate folk wanting to work within the system, blueprints are a heavyweight tool, primarily suited for things that require significant coordination. > 2) Blueprint Review Team > > Ensuring blueprints get reviewed is one of the responsibilities of the > PTL. However, due to the volume of Nova blueprints, it's not practical > for me to do it alone. A team of people (nova-drivers) [2], a subset of > nova-core, will be doing blueprint reviews. Why a subset of nova-core? With nova-core defined as 'knows the code well *AND* reviews a lot', I can see that those folk are in a position to spot a large class of design defects. However, there are plenty of folk with expertise in e.g. SOA, operations, deployment @ scale, who are not nova-core but who will spot plenty of issues. Is there some way they can help out? > By having more people reviewing blueprints, we can do a more thorough > job and have a higher quality result. > > Note that even though there is a nova-drivers team, *everyone* is > encouraged to participate in the review process by providing feedback on > the mailing list. I'm not sure about this bit here: blueprints don't have the spec content, usually thats in an etherpad; etherpads are editable by everyone - wouldn't it be better to keep the conversation together? I guess part of my concern here comes back to the (ab)use of blueprints for shallow features. > 3) Blueprint Review Criteria > > Here are some things that the team reviewing blueprints should look for: > > The blueprint ... > > - is assigned to the person signing up to do the work > > - has been targeted to the milestone when the code is > planned to be completed > > - is an appropriate feature for Nova. This means it fits with the > vision for Nova and OpenStack overall. This is obviously very > subjective, but the result should represent consensus. > > - includes enough detail to be able to complete an initial design > review before approving the blueprint. In many cases, the design > review may result in a discussion on the mailing list to work > through details. A link to this discussion should be left in the > whiteboard of the blueprint for reference. This initial design > review should be completed before the blueprint is approved. > > - includes information that describes the user impact (or lack of). > Between the blueprint and text that comes with the DocImpact flag [3] > in commits, the docs team should have *everything* they need to > thoroughly document the feature. I'd like to add: - has an etherpad with the design (the blueprint summary has no markup and is a poor place for capturing the design). > Once the review has been complete, the blueprint should be marked as > approved and the priority should be set. A set priority is how we know > from the blueprint list which ones have already been reviewed. > 4) Blueprint Prioritization > > I would like to do a better job of using priorities in Icehouse. The > priority field services a couple of purposes: > > - helps reviewers prioritize their time > > - helps set expectations for the submitter for how reviewing this > work stacks up against other things > > In the last meeting we discussed an idea that I think is worth trying at > least for icehouse-1 to see if we like it or not. The idea is that > *every* blueprint starts out at a Low priority, which means "best > effort, but no promises". For a blueprint to get prioritized higher, it > should have 2 nova-core members signed up to review the resulting code. > > If we do this, I suspect we may end up with more blueprints at Low, but > I also think we'll end up with a more realistic list of blueprints. The > reality is if a feature doesn't have reviewers agreeing to do the > review, it really is in a "best effort, but no promises" situation. I think this makes a lot of sense. Its the same basic triage process we're using in the TripleO Kanban experiment - things that aren't in the project current roadmap don't get unlimited resources; some things are declined, and things in the roadmap everyone in the team comes together to ensure a timely, effective delivery. The difference is that we're operating with a deliberate overlap between folk's effort - keeping the concurrent topics being worked on low, sacrificing a little output to duplicate effort, but gaining a whole lot of velocity. Joe: I disagree about merging patches with not-"approved" blueprints. They are no worse than patches that don't have a blueprint. Patches for a *declined* blueprint however, I agree they should require special examination. -Rob -- Robert Collins <[email protected]> Distinguished Technologist HP Converged Cloud _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
