<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Oct 23, 2013 at 4:33 PM, Russell Bryant <span dir="ltr"><<a href="mailto:rbryant@redhat.com" target="_blank">rbryant@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Greetings,<br>
<br>
At the last Nova meeting we started talking about some updates to the<br>
Nova blueprint process for the Icehouse cycle. I had hoped we could<br>
talk about and finalize this in a Nova design summit session on "Nova<br>
Project Structure and Process" [1], but I think we need to push forward<br>
on finalizing this as soon as possible so that it doesn't block current<br>
work being done.<br>
<br>
Here is a first cut at the process. Let me know what you think is<br>
missing or should change. I'll get the result of this thread posted on<br>
the wiki.<br>
<br>
1) Proposing a Blueprint<br>
<br>
Proposing a blueprint for Nova is not much different than other<br>
projects. You should follow the instructions here:<br>
<br>
<a href="https://wiki.openstack.org/wiki/Blueprints" target="_blank">https://wiki.openstack.org/wiki/Blueprints</a><br>
<br>
The particular important step that seems to be missed by most is:<br>
<br>
"Once it is ready for PTL review, you should set:<br>
<br>
Milestone: Which part of the release cycle you think your work will be<br>
proposed for merging."<br>
<br>
That is really important. Due to the volume of Nova blueprints, it<br>
probably will not be seen until you do this.<br>
<br>
2) Blueprint Review Team<br>
<br>
Ensuring blueprints get reviewed is one of the responsibilities of the<br>
PTL. However, due to the volume of Nova blueprints, it's not practical<br>
for me to do it alone. A team of people (nova-drivers) [2], a subset of<br>
nova-core, will be doing blueprint reviews.<br>
<br>
By having more people reviewing blueprints, we can do a more thorough<br>
job and have a higher quality result.<br>
<br>
Note that even though there is a nova-drivers team, *everyone* is<br>
encouraged to participate in the review process by providing feedback on<br>
the mailing list.<br>
<br>
3) Blueprint Review Criteria<br>
<br>
Here are some things that the team reviewing blueprints should look for:<br>
<br>
The blueprint ...<br>
<br>
- is assigned to the person signing up to do the work<br>
<br>
- has been targeted to the milestone when the code is<br>
planned to be completed<br>
<br>
- is an appropriate feature for Nova. This means it fits with the<br>
vision for Nova and OpenStack overall. This is obviously very<br>
subjective, but the result should represent consensus.<br>
<br>
- includes enough detail to be able to complete an initial design<br>
review before approving the blueprint. In many cases, the design<br>
review may result in a discussion on the mailing list to work<br>
through details. A link to this discussion should be left in the<br>
whiteboard of the blueprint for reference. This initial design<br>
review should be completed before the blueprint is approved.<br>
<br>
- includes information that describes the user impact (or lack of).<br>
Between the blueprint and text that comes with the DocImpact flag [3]<br>
in commits, the docs team should have *everything* they need to<br>
thoroughly document the feature.<br>
<br>
Once the review has been complete, the blueprint should be marked as<br>
approved and the priority should be set. A set priority is how we know<br>
from the blueprint list which ones have already been reviewed.<br>
<br>
4) Blueprint Prioritization<br>
<br>
I would like to do a better job of using priorities in Icehouse. The<br>
priority field services a couple of purposes:<br>
<br>
- helps reviewers prioritize their time<br>
<br>
- helps set expectations for the submitter for how reviewing this<br>
work stacks up against other things<br>
<br>
In the last meeting we discussed an idea that I think is worth trying at<br>
least for icehouse-1 to see if we like it or not. The idea is that<br>
*every* blueprint starts out at a Low priority, which means "best<br>
effort, but no promises". For a blueprint to get prioritized higher, it<br>
should have 2 nova-core members signed up to review the resulting code.<br>
<br>
If we do this, I suspect we may end up with more blueprints at Low, but<br>
I also think we'll end up with a more realistic list of blueprints. The<br>
reality is if a feature doesn't have reviewers agreeing to do the<br>
review, it really is in a "best effort, but no promises" situation.<br>
<br>
5) Blueprint Fall Cleaning<br>
<br>
Finally, it's about time we do some cleaning of the blueprint backlog.<br>
There are a bunch not currently being worked on. I propose that we<br>
close out all blueprints not targeted at a release milestone by November<br>
22 (2 weeks after the end of the design summit), with the exception of<br>
anything just recently filed and still being drafted.<br>
<br></blockquote><div><br></div><div>++ to the entire process, two comments though.</div><div><br></div><div>* It would be great to get this into a wiki for future reference</div><div>* We shouldn't merge patches with un-approved blueprints. And when that happens having a wiki page to point to would be great.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
[1] <a href="http://summit.openstack.org/cfp/details/341" target="_blank">http://summit.openstack.org/cfp/details/341</a><br>
[2] <a href="https://launchpad.net/~nova-drivers/+members#active" target="_blank">https://launchpad.net/~nova-drivers/+members#active</a><br>
[3]<br>
<a href="http://justwriteclick.com/2013/09/17/openstack-docimpact-flag-walk-through/" target="_blank">http://justwriteclick.com/2013/09/17/openstack-docimpact-flag-walk-through/</a><br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Russell Bryant<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</font></span></blockquote></div><br></div></div>