Open Stack

Our experience in backporting leftover bugfixes from MOST 5.0 to 4.1
was not pleasant, primarily because too many backport commits had to
be dealt with at the same time.

We can do better next time if we follow a couple of simple rules:

1) When you create a new bug with High or Critical priority or upgrade
an existing bug, always check if this bug is present in the supported
stable release series (at least one most recent stable release). If it
is present there, target it to all affected series (even if you don't
expect to be able to eventually backport a fix). If it's not present
in stable releases, document that on the bug so that other people
don't have to re-check.

2) When you propose a fix for a bug, cherry-pick the fix commit onto
the stable/x.x branch for each series it is targeted to. Use the same
Change-Id and topic (git review -t bug/<id>) to make it easier to
track down all backports for that bug.

3) When you approve a bugfix commit for master branch, use the
information available so far on the bug and in the review request to
review and maybe update backporting status of the bug. Is its priority
high enough to need a backport? Is it targeted to all affected release
series? Are there backport commits already? For all series where
backport should exist and doesn't, create a backport review request
yourself. For all other affected series, change bug status to Won't
Fix and explain in bug comments.

Needless to say, we should keep following the rule #0, too: do not
merge commits into stable branches until it was merged into master or
documented why it doesn't apply to master.

-- 
Dmitry Borodaenko