Den tors 16 juli 2026 kl 13:51 skrev Ivan Zhakov <[email protected]>: > 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 >
I've spent some more time to think of this and I believe nominate-backport.py still has some value. 1. The format of STATUS takes a bit to get used to and to get right. We have stories of people messing up the format (Nathan) and I'm guilty of that myself. 2. There is a problem with the current script inserting the nomination under a specific "well known headline", depending on the type of backport (especially for a .0 release), that could be wrong. nominate-backport.py takes care of (1), creating a properly formatted nomination including a Branch: if there is one. We could resolve 2 by simply outputting the nomination to stdout instread of rewriting STATUS. That way the user is responsible for adding it to STATUS and committing. The complexities of parsing STATUS is hidden within the backport.py "library" and that still needs to be maintained if detect-conflicting-backports.py and merge-approved-backports.py should function. (Some minor parts, like inserting a new nomination, could be removed but all major plumbing needs to stay). manage-backports.py is probably overly complex. It was written this way to try to replicate all interactive features of backport.pl. I think there is value in a script that merges a nomination the same way merge-approved-backports.py will do - maybe manage-backports.py should be replaced with a very simple script that takes a revision number, finds that nomination (ignoring if it is approved or not) and merges the nomination (possibly opening subshell with automatic revert upon exit). Updating and committing STATUS would still be a manual operation, as above. Does this sound reasonable? Cheers, Daniel
