On Thu, Oct 13, 2016 at 1:05 PM, Branko Čibej <brane_at_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, <jcorvel_at_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
Received on 2016-10-13 13:41:39 CEST