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

On Thu, 16 Jul 2026 at 11:21, Ivan Zhakov <[email protected]> wrote:

> On Wed, 15 Jul 2026 at 23:31, 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]> <[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. 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.
>>
>> I am +1 to remove nominate-backport.py and manage-backports.py: the
> complexity of managing these scripts is worth it.
>
> Typo here. I meant to say that "the complexity of managing these scripts
is NOT worth it".

-- 
Ivan Zhakov