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

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?)

-- Brane