[openstack-dev] [PTLs] Proposed simplification around blueprint tracking

Mark Washenberger mark.washenberger at markwash.net
Wed Jun 19 17:50:32 UTC 2013


On Wed, Jun 19, 2013 at 6:51 AM, Thierry Carrez <thierry at openstack.org>wrote:

> Hi everyone,
>
> What follows is mostly of interest to PTLs and other $PROJECT-drivers
> that help them maintain Launchpad blueprints in order.
>
> Launchpad has a concept of "series goal" and "priority" (controlled by
> drivers), while most other fields (including "target milestone") can be
> modified by blueprint assignees.
>
> Currently we use "series goal" to bless a subset of blueprints and make
> them part of our "roadmap" for the cycle. This has several drawbacks:
>
> * It's difficult to find out about "proposed" blueprints
> * "Series goal" can get out of sync with "target milestone"
> * Stuff that is not "approved" for the series goal still appears in
> LP "milestone" view
> * Stuff that is not "approved" for the series goal does NOT appear on
> LP "series" view
> * Series-goal-accepted blueprints should have a "priority" set, but
> sometimes one is set without the other.
>
> To work around those drawbacks, we spend more and more time in release
> meeting to fix inconsistencies between those fields, which is clearly
> not the best use of our precious time.
>
> My proposal would be to simplify this by dropping the use of "series
> goal" altogether and just use a single field: "priority".
>
> Blueprint authors would indicate that they intend to land their stuff
> for a given milestone using the "target milestone" field.
>
> Drivers would see those appear in milestone/series views as "undefined"
> priority. They would triage them by setting one of those priorities:
>
> - Essential: Would prefer not to release without that feature
> - High: Important feature that we should have in the release
> - Medium: Optional feature that should still be part of the roadmap
> - Low: Optional feature that we should not follow on the release radar
>
> And that's it. Triaging incoming blueprints is just about setting this
> field.
>
> A script will automatically and regularly align "series goal" with
> "target milestone", so that the series and milestone views are
> consistent (if someone sets target milestone to "havana-3" then the
> series goal will be set to "havana").
>
> During the release meeting we'll only look into Medium/High/Essential
> blueprints, and the release status page should probably only list those
> as well.
>
> This also encourages people to set a target milestone, which is pretty
> essential in communicating out when a given feature is likely to land.
>
> So this simplifies a lot, but we lose /some/ granularity:
>
> * You won't have blueprints on your roadmap that are not targeted to a
> specific milestone, so it's more difficult to do a list of "would be
> great to have in this release if only someone wanted to take them"
> blueprints.
>
> * Blueprints that don't have a target milestone should probably also not
> have a priority, so that they are effectively "untriaged" (the automatic
> script might even check for that and remove priority when the target
> milestone is unset). That makes it more difficult to have a prioritized
> backlog (though we could use a "next" milestone to do that if people
> want it).
>
> Thoughts ?
>


This sounds like a fantastic improvement. I'd really like to have a "next"
milestone as well as an "Ongoing" milestone, for tracking the kinds of
long, drawn out refactorings / code improvements that cannot fit in a
single milestone but still need to be communicated to developers (though
not necessarily to the project update coordinators).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130619/9d14d445/attachment.html>


More information about the OpenStack-dev mailing list