<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 16, 2015 at 5:32 PM, Kevin Benton <span dir="ltr"><<a href="mailto:blak111@gmail.com" target="_blank">blak111@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">We can't put in code and just hope for testing later. The tests are even more important in back-ports because there could be unexpected differences in the stable branch that make the patch not work correctly.<div><br></div><div>However, we do need to make sure that people aren't complaining about the testing methodology in the back-ports because it's too late for that.</div></div></blockquote><div><br></div><div>I am quick to point out testing deficiencies so I hope I wasn't too tired and unknowingly did the unspeakable that which you speak of (I think people can fail to notice the branch the patch is submitted against). Reviewing a backport should be 90% about backport procedures: Does the commit message contain everything it should? Does the patch meet backport criteria? (Any DB, RPC, configuration or API changes? Is it a new feature or a high value / low risk bug risk? Will this somehow break users on upgrade?) A backport should be ideally identical to its master counterpart, so I agree that commenting on spelling mistakes, comments, code placement, design and the like should be avoided. If that bothers you so much, send a patch to master to fix the grave error you spotted!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On Fri, Oct 16, 2015 at 2:23 PM, Fox, Kevin M <span dir="ltr"><<a href="mailto:Kevin.Fox@pnnl.gov" target="_blank">Kevin.Fox@pnnl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It would also help if the process could split out bug fixes from unit tests. I had a bug fix get stuck while the unit tests were bikesheded for a while, and then the delay of not getting quickly backported to the stable branches then kicked in. All the while I had to patch production clouds by hand with a non upstreamed fix. I'm all for having unit tests to ensure the bugs don't creep back in, but regression bugs should be fixed as quickly as possible.<br>
<br>
Thanks,<br>
Kevin<br>
________________________________________<br>
From: Edgar Magana [<a href="mailto:edgar.magana@workday.com" target="_blank">edgar.magana@workday.com</a>]<br>
Sent: Friday, October 16, 2015 2:04 PM<br>
To: OpenStack Development Mailing List (not for usage questions)<br>
Subject: Re: [openstack-dev] [neutron][stable] proactive backporting<br>
<div><div><br>
+ 2 and total support for it.<br>
<br>
Looking forward to reviewing the first set of them.<br>
<br>
Edgar<br>
<br>
<br>
<br>
On 10/16/15, 5:33 AM, "Ihar Hrachyshka" <<a href="mailto:ihrachys@redhat.com" target="_blank">ihrachys@redhat.com</a>> wrote:<br>
<br>
>Hi all,<br>
><br>
>I’d like to introduce a new initiative around stable branches for neutron official projects (neutron, neutron-*aas, python-neutronclient) that is intended to straighten our backporting process and make us more proactive in fixing bugs in stable branches. ‘Proactive' meaning: don’t wait until a known bug hits a user that consumes stable branches, but backport fixes in advance quickly after they hit master.<br>
><br>
>The idea is simple: every Fri I walk thru the new commits merged into master since last check; produce lists of bugs that are mentioned in Related-Bug/Closes-Bug; paste them into:<br>
><br>
><a href="https://etherpad.openstack.org/p/stable-bug-candidates-from-master" rel="noreferrer" target="_blank">https://etherpad.openstack.org/p/stable-bug-candidates-from-master</a><br>
><br>
>Then I click thru the bug report links to determine whether it’s worth a backport and briefly classify them. If I have cycles, I also request backports where it’s easy (== a mere 'Cherry-Pick to' button click).<br>
><br>
>After that, those interested in maintaining neutron stable branches can take those bugs one by one and handle them, which means: checking where it really applies for backport; creating backport reviews (solving conflicts, making tests pass). After it’s up for review for all branches affected and applicable, the bug is removed from the list.<br>
><br>
>I started on that path two weeks ago, doing initial swipe thru all commits starting from stable/liberty spin off. If enough participants join the process, we may think of going back into git history to backport interesting fixes from stable/liberty into stable/kilo.<br>
><br>
>Don’t hesitate to ask about details of the process, and happy backporting,<br>
><br>
>Ihar<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div></div></div><span class="HOEnZb"><font color="#888888">-- <br><div><div>Kevin Benton</div></div>
</font></span></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>