On 16. 7. 2026 09:48, Branko Čibej wrote:
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,
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.
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?)
And then add a pre-commit hook to verify the syntax. Wouldn't that be nice.
-- Brane
