On Mon, Oct 28, 2013 at 2:24 PM, John Garbutt <j...@johngarbutt.com> wrote:
> On 25 October 2013 10:18, Joe Gordon <joe.gord...@gmail.com> wrote: > > 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. > > Here is a really bad attempt at codifying what I think about features vs > bugs: > 1) If its a new API call, or a change in behaviour, or a new config > setting, its a feature > 2) If its just refactoring or just adding tests, it is neither a > feature or a bug > 4) A bug is a change to ensure the system operates "as expected" by > the current documentation > 3) A bug should be changed to a feature if it matches case (1) > > If we don't approve the blueprint first, we may end up not having > enough information to create the required documentation, so I vote we > enforce that a blueprint should be approved before we merge code. > > Getting a blueprint approved as low priority, should be quicker and > easier than getting the associated code approved. Granted that might > not be the case today, but we need to fix that. > > That sounds like a great start. I think there is one more. 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. > John > > _______________________________________________ > 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
