openstack team mailing list archive

[Thierry Carrez <thierry@xxxxxxxxxxxxx>]

Hello everyone,

TL;DR summary:

Currently "FixReleased" means "fix landed in an official release of
OpenStack". With this proposal "FixReleased" will mean "fix landed in a
given milestone", which will allow us to track bugs that landed on
master and are wanted in the milestone.

This should not change anything for developers, since the "FixReleased"
status changes are handled by release process. This does not affect
Swift, since Swift milestones are "releases" (Swift already uses
FixReleased this way).



For rationale and details, keep on reading:

Given the way we use LP bug statuses, we cannot track bugs that are
fixed in master but that we want backported to the milestone-proposed
branch before the milestone is released. There is currently no
difference between a change that landed in master + milestone-proposed
(FixCommitted/essex-1) and a change that only landed in master but that
we want backported in milestone-proposed (FixCommitted/essex-1).

This leads to confusion. Bugs in the latter category are no longer
showing as "work in progress" in lists like milestone pages in
Launchpad. Even when you spot them, setting such a bug back to
"InProgress" (to have it appear as milestone-critical and open in
milestone pages) is incorrect, since the bugfix was committed to master
already !

The proposed change (already accepted by affected PTLs) is that we use
FixReleased status to track changes that landed in milestone-proposed
(and therefore appear in a given milestone). Currently we use
FixReleased, together with a retargeting of the bug to the final
milestone, to indicate that the bug was fixed in an official release:
FixReleased/2011.3 for example.

With this change, we set the bug to FixReleased if it's present in a
given milestone-proposed branch. So changes that landed in master and in
milestone-proposed would be FixReleased/essex-1, while changes that only
landed in master but that we want backported in milestone-proposed would
be FixCommitted/essex-1. At release time, instead of setting all
FixCommitted/essex-N bugs to FixReleased/2012.1, we would just set all
FixReleased/essex-N to FixReleased/2012.1.

The only drawback of this approach is that it's a bit more difficult to
quickly tell if a bug is fixed in an (any) official release: you have to
look into the milestone field of FixReleased to check it's marked with a
final version ("2011.3") instead of a development milestone name
("essex-1").

The advantages of this approach are that we can finally track "bugs that
we want fixed in a milestone" without errors. It also aligns all
projects with the way Swift does it.

Comments, remarks before I start implementing that change ?
(This will result in some bugmail again, as we migrate current
FixCommitted/essex-1 bugs to FixReleased/essex-1).

-- 
Thierry Carrez (ttx)
Release Manager, OpenStack