[openstack-dev] [murano] why not abandon launchpad milestones and/or blueprints?

Kirill Zaitsev kzaitsev at mirantis.com
Tue Dec 29 06:49:30 UTC 2015


One more argument in favour of abandoning use of milestones is that they do not work well with new stable branch release structure and us having multiple repositories rely on one launchpad. We might have murano ver 1.0.5 and murano-dashboard ver 1.0.3, which would be totally fine under current stable-branch release scheme and really weird in launchpad. I.e. have several active milestones or have only the latest milestone active. Or we would have to make unnecessary releases, to keep tags in repositories synced (which I also do not think is a nice thing to do).

-- 
Kirill Zaitsev
Murano team
Software Engineer
Mirantis, Inc

On 22 December 2015 at 17:18:25, Kirill Zaitsev (kzaitsev at mirantis.com) wrote:

Hi all. A couple of meetings ago I brought this up and promised to start a discussion in the ML.
There are two ideas behind this letter:

1st) Since we (and openstack at large) started using reno for release notes — launchpad milestones became redundant as a tracking tool of what have been done during development of a certain version of an app.
We might still use milestones for what we’re planning to do during a certain period of development, but in my opinion it never really worked, since dozens of open/in-progress bugs get transferred at release time to the next milestone.

I’d like to discuss the idea to stop using milestones on l-pad and just target bugs/bps to series.

+1 from me on the idea as I don’t see milestones being useful anymore

2d) We currently have 3 ways to track something we’d like to implement: wishlist-bug, blueprint, spec. A spec always require a blueprint, but a blueprint doesn’t always require a spec.

The idea is to minimise the number of tracking tools we use here and to stop using blueprints altogether. For small features this would mean assigning a wishlist-level bug. And for large features we should file a spec anyway and probably a specially tagged bug.

Pros: simpler more streamlined release/bug/feature management. One place to search for all functionality.
Cons: we would have to write Closes-Bug, which is kind of misleading. We wouldn’t be able to track dependencies between bugs the same way we now do for bps.

I don’t have a strong opinion on this one, so I would love to hear out some opinions on this one.

-- 
Kirill Zaitsev
Murano team
Software Engineer
Mirantis, Inc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151229/b39af57c/attachment.html>


More information about the OpenStack-dev mailing list