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


<div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jun 2, 2014 at 12:33 PM, Dmitry Borodaenko <span dir="ltr"><<a href="mailto:dborodaenko@mirantis.com" target="_blank">dborodaenko@mirantis.com</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Our experience in backporting leftover bugfixes from MOST 5.0 to 4.1<br>
was not pleasant, primarily because too many backport commits had to<br>
be dealt with at the same time.<br>
<br>
We can do better next time if we follow a couple of simple rules:<br>
<br>
1) When you create a new bug with High or Critical priority or upgrade<br>
an existing bug, always check if this bug is present in the supported<br>
stable release series (at least one most recent stable release). If it<br>
is present there, target it to all affected series (even if you don't<br>
expect to be able to eventually backport a fix). If it's not present<br>
in stable releases, document that on the bug so that other people<br>
don't have to re-check.<br>
<br>
2) When you propose a fix for a bug, cherry-pick the fix commit onto<br>
the stable/x.x branch for each series it is targeted to. Use the same<br>
Change-Id and topic (git review -t bug/<id>) to make it easier to<br>
track down all backports for that bug.<br>
<br>
3) When you approve a bugfix commit for master branch, use the<br>
information available so far on the bug and in the review request to<br>
review and maybe update backporting status of the bug. Is its priority<br>
high enough to need a backport? Is it targeted to all affected release<br>
series? Are there backport commits already? For all series where<br>
backport should exist and doesn't, create a backport review request<br>
yourself. For all other affected series, change bug status to Won't<br>
Fix and explain in bug comments.<br>
<br>
Needless to say, we should keep following the rule #0, too: do not<br>
merge commits into stable branches until it was merged into master or<br>
documented why it doesn't apply to master.<br>
<span><font color="#888888"><br>
--<br>
Dmitry Borodaenko<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br>Mike Scherbakov<br>#mihgen<br><br>
</div></div>