On Thu, Oct 13, 2016 at 1:05 PM, Branko Čibej <br...@apache.org> wrote: > On 13.10.2016 13:01, Branko Čibej wrote: >> On 13.10.2016 11:39, Ivan Zhakov wrote: >>> On 13 October 2016 at 10:59, <jcor...@apache.org> wrote: >>>> Author: jcorvel >>>> Date: Thu Oct 13 08:59:07 2016 >>>> New Revision: 1764631 >>>> >>>> URL: http://svn.apache.org/viewvc?rev=1764631&view=rev >>>> Log: >>>> Resurrect the '1.9.x-r1721488' branch, to give backport.pl another >>>> chance to execute the correct backport commands, after backport mess. >>>> >>> I'm wondering if we really need backport.pl running as cronjob to >>> merge backports automatically to the stable branches? It's not a first >>> time when this automatic job performs invalid merges. And as far I >>> understand we still spend some time to babysit this tool, fix bugs >>> etc. What is wrong with old proven process by merging revisions >>> manually? >> It doesn't happen all that often that backport.pl makes a mistake. I bet >> manual merging would be just as error-prone. >> >> Backporting is a well-defined process. The best possible way to document >> a process is to automate it. Errors will happen but that's no reason to >> revert to PEBKAC; bugs can be fixed. > > > In fact, now that I've read Johan's mail ... it /was/ a PEBKAC and > nothing was wrong with backport.pl.
Indeed, what we experienced last night was not a script bug (unless if you state that it should have protected against that race condition :-)). It was the first time the script was run from qavm3, so I was paying extra attention to potential problems. Anyway, it's not like we will migrate to a new machine every month, so it's quite an exceptional situation ... -- Johan
