On 15. 7. 2026 14:35, Evgeny Kotkov via dev wrote:
Branko Čibej<[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.
-- Brane
