<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Oct 28, 2013 at 2:24 PM, John Garbutt <span dir="ltr"><<a href="mailto:john@johngarbutt.com" target="_blank">john@johngarbutt.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 25 October 2013 10:18, Joe Gordon <<a href="mailto:joe.gordon0@gmail.com">joe.gordon0@gmail.com</a>> wrote:<br>
> On Oct 24, 2013 9:14 PM, "Robert Collins" <<a href="mailto:robertc@robertcollins.net">robertc@robertcollins.net</a>> wrote:<br>
>> On 24 October 2013 04:33, Russell Bryant <<a href="mailto:rbryant@redhat.com">rbryant@redhat.com</a>> wrote:<br>
>> > 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>
>> Cool<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>
>> The other thing I'm seeing some friction on is 'significant features'<br>
>> : it sometimes feels like folk are filing blueprints for everything<br>
>> that isn't 'the code crashed' style problems, and while I appreciate<br>
>> folk wanting to work within the system, blueprints are a heavyweight<br>
>> tool, primarily suited for things that require significant<br>
>> coordination.<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>
>> Why a subset of nova-core? With nova-core defined as 'knows the code<br>
>> well *AND* reviews a lot', I can see that those folk are in a position<br>
>> to spot a large class of design defects. However, there are plenty of<br>
>> folk with expertise in e.g. SOA, operations, deployment @ scale, who<br>
>> are not nova-core but who will spot plenty of issues. Is there some<br>
>> way they can help out?<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>
>> I'm not sure about this bit here: blueprints don't have the spec<br>
>> content, usually thats in an etherpad; etherpads are editable by<br>
>> everyone - wouldn't it be better to keep the conversation together? I<br>
>> guess part of my concern here comes back to the (ab)use of blueprints<br>
>> for shallow features.<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>
>> I'd like to add:<br>
>> - has an etherpad with the design (the blueprint summary has no<br>
>> markup and is a poor place for capturing the design).<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>
>><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>
>> I think this makes a lot of sense. Its the same basic triage process<br>
>> we're using in the TripleO Kanban experiment - things that aren't in<br>
>> the project current roadmap don't get unlimited resources; some things<br>
>> are declined, and things in the roadmap everyone in the team comes<br>
>> together to ensure a timely, effective delivery. The difference is<br>
>> that we're operating with a deliberate overlap between folk's effort -<br>
>> keeping the concurrent topics being worked on low, sacrificing a<br>
>> little output to duplicate effort, but gaining a whole lot of<br>
>> velocity.<br>
>><br>
>> Joe: I disagree about merging patches with not-"approved" blueprints.<br>
>> They are no worse than patches that don't have a blueprint.<br>
><br>
> I based that on this statement, which I think sums it up well "If the patch<br>
> implements a feature, it should reference a blueprint. The blueprint should<br>
> be approved before the patch is merged"<br>
><br>
> <a href="https://wiki.openstack.org/wiki/ReviewChecklist" target="_blank">https://wiki.openstack.org/wiki/ReviewChecklist</a><br>
><br>
> This does raise the question of what is consisted a feature though.<br>
<br>
</div></div>Here is a really bad attempt at codifying what I think about features vs bugs:<br>
1) If its a new API call, or a change in behaviour, or a new config<br>
setting, its a feature<br>
2) If its just refactoring or just adding tests, it is neither a<br>
feature or a bug<br>
4) A bug is a change to ensure the system operates "as expected" by<br>
the current documentation<br>
3) A bug should be changed to a feature if it matches case (1)<br>
<br>
If we don't approve the blueprint first, we may end up not having<br>
enough information to create the required documentation, so I vote we<br>
enforce that a blueprint should be approved before we merge code.<br>
<br>
Getting a blueprint approved as low priority, should be quicker and<br>
easier than getting the associated code approved. Granted that might<br>
not be the case today, but we need to fix that.<br>
<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div>That sounds like a great start. I think there is one more. </div><div><br></div><div>Major refactoring that will consist of many patches, having a BP makes it easier to see how the seperate patches are part of a larger effort.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888">
John<br>
</font></span><div class="HOEnZb"><div class="h5"><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>
</div></div></blockquote></div><br></div></div>