<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 16 October 2015 at 15:14, 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">
<div>
<div style="direction:ltr;font-family:Tahoma;color:#000000;font-size:10pt">Then how about the alternate approach of:<br>
<br>
For bug fixes, copying an existing in tree unit test and tweaking it slightly to test for the bug is sufficient to get it accepted instead of forcing it to be rewritten in whatever the new hotness for testing at the time thing is, that no one has good examples
for, nor has fully agreed on what a good example of that looks like, leading to long delays in the big fix being accepted? IMHO, bug fixes aren't the place to trail blaze unit tests.<span style="font-family:arial,sans-serif;font-size:small;color:rgb(34,34,34)"> </span></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="direction:ltr;font-family:Tahoma;color:#000000;font-size:10pt">
<br>
The unit tests can be rewritten to be "better" in a follow up review that doesn't necessarily need to be back ported.<br></div></div></blockquote><div><br></div><div>I am pretty confident that the experience you went through was an exception rather than the rule. We're pretty flexible and allow a patch to go in (master) with a promise of a follow up, if it's critical backport. The important thing is to identify that...and this is what Ihar is talking about in this thread.</div><div><br></div><div>It is noteworthy that 'trail blazing' as you say makes the patch difficult to backport, so any advice given in this direction was clearly pointing you the wrong way.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="direction:ltr;font-family:Tahoma;color:#000000;font-size:10pt">
<br>
Would that work?<span style="font-family:arial,sans-serif;font-size:small;color:rgb(34,34,34)"> </span></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="direction:ltr;font-family:Tahoma;color:#000000;font-size:10pt">
<br>
Thanks,<br>
Kevin<br>
<br>
<div style="font-family:Times New Roman;color:#000000;font-size:16px">
<hr>
<div style="direction:ltr"><font face="Tahoma" size="2" color="#000000"><b>From:</b> Kevin Benton [<a href="mailto:blak111@gmail.com" target="_blank">blak111@gmail.com</a>]<br>
<b>Sent:</b> Friday, October 16, 2015 2:32 PM<div><div class="h5"><br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>
<b>Subject:</b> Re: [openstack-dev] [neutron][stable] proactive backporting<br>
</div></div></font><br>
</div><div><div class="h5">
<div></div>
<div>
<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>
<div class="gmail_extra"><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>
-- <br>
<div>
<div>Kevin Benton</div>
</div>
</div>
</div>
</div></div></div>
</div>
</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>