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. Regards, Evgeny Kotkov
