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
