The backporting rules are now part of Fuel wiki: https://wiki.openstack.org/wiki/Fuel/How_to_contribute#Backport_bugfixes_to_stable_release_series
There is also a new page on code review rules, please also review and make use of it: https://wiki.openstack.org/wiki/Fuel/Code_Review_Rules On Mon, Jun 2, 2014 at 12:33 PM, Dmitry Borodaenko <dborodae...@mirantis.com> wrote: > 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 -- Dmitry Borodaenko _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
