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. 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. > I find detect-conflicting-backports.py and merge-approved-backports.py somewhat useful, so I think they should remain. > > 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 would favor to remove backport.pl too for the same reason as manage-backports.py: the complexity of managing these scripts is not worth it. > 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. > > -- Ivan Zhakov
