Open Stack

On Mon, Oct 28, 2013 at 9:24 AM, 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
>

This line is the only one I have a little bit of concern with when looking
across all projects. We just have to get better at documentation if we're
going to make the docs the measure to log bugs against a project. John,
your docs are really on target here, but I fear other projects would
struggle to set expectations for how something is supposed to work. For
example I don't think Hyper-V is documented much at all. So just be careful
with this one, use good judgement, and keep this in mind when looking for
docs to write.

Anne


> 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.
>
> 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/025d74ce/attachment.html>