Re: svn commit: r1936154 - subversion/branches/1.15.x

Branko Čibej <[email protected]>
Newsgroups gmane.comp.version-control.subversion.devel
Organization The Apache Software Foundation
Message-ID <[email protected]>
On 15. 7. 2026 10:16, Daniel Sahlberg wrote:
> Den ons 15 juli 2026 kl 09:45 skrev Branko Čibej <[email protected]>:
>
>     On 15. 7. 2026 09:16, [email protected] wrote:
>>     Author: dsahlberg
>>     Date: Wed Jul 15 07:16:43 2026
>>     New Revision: 1936154
>>
>>     Log:
>>     * STATUS: Nominate r1935797
>>
>>     Modified:
>>         subversion/branches/1.15.x/STATUS
>>
>>     Modified: subversion/branches/1.15.x/STATUS
>>     ==============================================================================
>>     --- subversion/branches/1.15.x/STATUS	Wed Jul 15 07:14:01 2026	(r1936153)
>>     +++ subversion/branches/1.15.x/STATUS	Wed Jul 15 07:16:43 2026	(r1936154)
>>     @@ -78,3 +78,15 @@ Veto-blocked changes:
>>       
>>       Approved changes:
>>       =================
>>     +
>>     +Candidate changes:
>>     +==================
>
>     The Approved changes section should always be last. It looks like
>     the nominate script doesn't parse the STATUS file thoroughly
>     enough, then makes this error when editing it. The auto-merge
>     automation won't like this.
>
>     Is this committed automatically by nominate-backport.py?
>
>
> Good catch, didn't see that. I will follow up in a reply to Evgeny's 
> commit r1936137.

Frankly, that commit was just fine. We've often added or renamed 
sections like that before a .0 release. I'd prefer to change the script 
so that instead of trying to find the "Candidate changes" section and, 
shudder, adding it blindly if it doesn't find it; it should look for the 
"Approved changes" and add the nomination just /before/ that.

And fail explicitly if it doesn't find that section. As it is now, the 
script is just a bit too naive for my taste.

-- Brane
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.