On 16. 7. 2026 07:23, Nathan Hartman wrote:
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]> <mailto:[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 <http://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 <http://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, DanielI 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.
We already have syntax checking implemented. I'd expose only that through a script (that's smart enough to find the STATUS file in the current working copy so that I don't have to tell it where it is, it's right there, can't you see it?)
-- Brane
