Open Stack

On Mon, Oct 28, 2013 at 2:24 PM, John Garbutt <john at johngarbutt.com> wrote:

> On 25 October 2013 10:18, Joe Gordon <joe.gordon0 at gmail.com> wrote:
> > On Oct 24, 2013 9:14 PM, "Robert Collins" <robertc at robertcollins.net>
> wrote:
> >> On 24 October 2013 04:33, Russell Bryant <rbryant at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131028/e3c7bd07/attachment.html>