[openstack-dev] [Fuel] Backporting bugfixes to stable releases

Mike Scherbakov mscherbakov at mirantis.com
Mon Jun 2 20:03:53 UTC 2014


Thanks Dmitry.
Can we do #2 using new cool gerrit feature (thanks to Infra team!) ?
- when patch is merged, button "Cherry Pick To" appears near Review button,
you can easily choose branch by clicking on it?


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



-- 
Mike Scherbakov
#mihgen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140602/1fd7558c/attachment.html>


More information about the OpenStack-dev mailing list