On Oct 24, 2013 9:14 PM, "Robert Collins" <robe...@robertcollins.net> wrote: > > On 24 October 2013 04:33, Russell Bryant <rbry...@redhat.com> 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.
I based that on this statement, which I think sums it up well "If the patch implements a feature, it should reference a blueprint. The blueprint should be approved before the patch is merged" https://wiki.openstack.org/wiki/ReviewChecklist This does raise the question of what is consisted a feature though. > > Patches for a *declined* blueprint however, I agree they should > require special examination. > > -Rob > > -- > Robert Collins <rbtcoll...@hp.com> > Distinguished Technologist > HP Converged Cloud > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev