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 _______________________________________________ OpenStack-dev mailing list OpenStackfirstname.lastname@example.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev