[openstack-dev] [Fuel] Backporting bugfixes to stable releases
Dmitry Borodaenko
dborodaenko at mirantis.com
Wed Jun 4 20:18:26 UTC 2014
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
<dborodaenko at 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
More information about the OpenStack-dev
mailing list