Re: The future of backport.py [Was: svn commit: r1936137 - subversion/branches/1.15.x]

On 16. 7. 2026 09:48, Branko Čibej wrote:
> On 16. 7. 2026 07:23, Nathan Hartman wrote:
>> On Wed, Jul 15, 2026 at 4:31 PM Daniel Sahlberg 
>> <[email protected]> wrote:
>>
>>     Den ons 15 juli 2026 kl 21:30 skrev Branko Čibej <[email protected]>:
>>
>>         On 15. 7. 2026 14:35, Evgeny Kotkov via dev wrote:
>>>         Branko Čibej<[email protected]> <mailto:[email protected]> writes:
>>>
>>>>         Your change adapted to this single specific modification of the section
>>>>         headers. The next, slightly different modification will break the script
>>>>         again.
>>>         +1.
>>>
>>>>         I really think the safest way is to always insert nominations before
>>>>         "Approved changes" and to fail if that heading isn't there. If the headings
>>>>         in the file make that insertion dubious, then the heading order should be
>>>>         fixed anyway. In the meantime, review of the diff before commit is kind of
>>>>         expected.
>>>         A more complex alternative could be: prompt for the section to insert
>>>         the nomination into, excluding the "well-known" Veto-blocked and Approved
>>>         sections.  If there is only one candidate section, insert into it without
>>>         prompting.
>>>
>>>>         Yes, I've looked at the script and I'm aware that the parsing code is opaque
>>>>         and complex. I didn't say my proposal leads to a simple change. But it does
>>>>         make the script more future proof.
>>>         A bit off-topic, but do we really want to keep supporting such a complex
>>>         script that automates adding STATUS entries and casting votes for them?
>>>
>>>         As I see it, the important part is having automation for _merging_ approved
>>>         STATUS entries (which we also have).  That's useful, because it automates
>>>         an error-prone operation that technically requires no manual steps once an
>>>         entry has been approved.
>>>
>>>         Voting and editing STATUS, on the contrary, are supposed to be manual
>>>         operations, because they are all about verifying the change.  To my mind,
>>>         working with a plain text file containing a list of entries is already
>>>         quite convenient by itself and supports all possible kinds of interactivity.
>>
>>         I've never used nominate-backport.py and hardly ever the
>>         older nominate.pl <http://nominate.pl>. I find it a waste of
>>         time to have to learn the quirks and bespoke command line of
>>         those scripts, just to add some lines of text or even just a
>>         +1 to a file. A simple nomination syntax checker would be
>>         useful – I sometimes get the indentation wrong – but a script
>>         to automate editing feels like overkill.
>>
>>     nominate-backport.py is very simple, it just takes two arguments
>>     (revision and justification).
>>
>>     manage-backports.py is more involved but it also takes care of a
>>     bit of the "error-prone operations" (quoting Evgeny above) of
>>     merging backports. It (interactively) offers to merge each
>>     backport (approved or not) so you can verify it merges properly
>>     and test it out, then reverts it and give you the opportunity to
>>     vote for it, updating STATUS as needed. Merging is done using the
>>     same code as the backport bot so it verifies STATUS is parsed
>>     properly.
>>
>>     These two scripts are the ones I would expect us to remove.
>>
>>     The backport.py "library" is also used by
>>     detect-conflicting-backports.py (used in the backportbot GHA),
>>     release.py (when drafting a changelog) and
>>     merge-approved-backports.py (the script used by the backport
>>     bot). I expect these uses will remain, as well as the library itself.
>>
>>     If we remove the scripts, README.backport must be updated. More
>>     or less reverting r1932433, 1925159, 1924264 (except the future
>>     removal of backport.pl <http://backport.pl>) and 1924110.
>>
>>     I have some time to do this tomorrow if decided. It also depends
>>     on Evgeny's timeline for rolling the next RC - I'd hate to see
>>     this being a release blocker but I'd also love to se it done
>>     before 1.15.0 so we could avoid releasing something we already
>>     consider removing.
>>
>>     Cheers,
>>     Daniel
>>
>>
>>
>> I have no opinion about the removal, but just as a datapoint for 
>> consideration, I have made syntax errors in the STATUS file more than 
>> once. That's the only problem with removing the scripts. The errors 
>> trip up the merge bot. Maybe one of the existing scripts could be 
>> morphed into a linter for STATUS. Just thinking out loud.
>
> We already have syntax checking implemented. I'd expose only that 
> through a script (that's smart enough to find the STATUS file in the 
> current working copy so that I don't have to tell it where it is, it's 
> right there, can't you see it?)


And then add a pre-commit hook to verify the syntax. Wouldn't that be nice.

-- Brane