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]> <[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. > > 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) 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. Cheers, Nathan
