Open Stack

+1


On Tue, Jul 1, 2014 at 2:33 AM, Dmitry Borodaenko <dborodaenko at mirantis.com>
wrote:

> When you create a bug against a project (in our case, fuel) in
> Launchpad, it is always initially targeted at the default release
> series (currently, 5.1.x). On the bug summary, that isn't explicitly
> stated and shows as being targeted to the project in general (Fuel for
> OpenStack). As you add more release series to a bug, these will be
> listed under release series name (e.g. 5.0.x).
>
> Unfortunately, Launchpad doesn't limit the list of milestones you can
> target to the targeted release series, so it will happily allow you to
> target a bug at 4.1.x release series and set milestone in that series
> to 5.1.
>
> A less obvious inconsistency is when a bug is found in a stable
> release series like 5.0.x: it seems natural to target it to milestone
> like 5.0.1 and be done with it. The problem with that approach is that
> there's no way to reflect whether this bug is relevant for current
> release series (5.1.x) and if it is, to track status of the fix
> separately in current and stable release series.
>
> Therefore, when triaging new bugs in stable versions of Fuel or
> Mirantis OpenStack, please set the milestone to the next release in
> the current release focus (5.1.x), and target to the series it was
> found in separately. If there are more recent stable release series,
> target those as well.
>
> Example: a bug is found in 4.1.1. Set primary milestone to 5.1 (as
> long as current release focus is 5.1.x and 5.1 is the next milestone
> in that series), target 2 more release series: 4.1.x and 5.0.x, set
> milestones for those to 4.1.2 and 5.0.1 respectively.
>
> If there is reason to believe that the bug does not apply to some of
> the targeted release series, explain that in the commit and mark the
> bug Invalid for that release series. If the bug is present in a series
> but cannot be addressed there (e.g. priority is not high enough to do
> a backport), mark it Won't Fix for that series.
>
> If there are no objections to this approach, I'll put it in Fuel wiki.
>
> Thanks,
> -DmitryB
>
> --
> Dmitry Borodaenko
>
> _______________________________________________
> 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/20140701/0ac19a60/attachment-0001.html>