On Fri, 17 Jul 2026 at 18:55, Evgeny Kotkov via dev < [email protected]> wrote:
> Daniel Sahlberg <[email protected]> writes: > > > I've spent some more time to think of this and I believe > nominate-backport.py > > still has some value. > > > > 1. The format of STATUS takes a bit to get used to and to get right. > > We have stories of people messing up the format (Nathan) and I'm guilty > > of that myself. > > > > 2. There is a problem with the current script inserting the nomination > > under a specific "well known headline", depending on the type of backport > > (especially for a .0 release), that could be wrong. > > > > nominate-backport.py takes care of (1), creating a properly formatted > > nomination including a Branch: if there is one. We could resolve 2 by > > simply outputting the nomination to stdout instread of rewriting STATUS. > > That way the user is responsible for adding it to STATUS and committing. > > > > The complexities of parsing STATUS is hidden within the backport.py > > "library" and that still needs to be maintained if > > detect-conflicting-backports.py and merge-approved-backports.py should > > function. (Some minor parts, like inserting a new nomination, could be > > removed but all major plumbing needs to stay). > > Personally, I would be in favor of removing all interactive scripts that > work > with STATUS and keeping the minimum of what's needed for the automated > parts (detect-conflicting-backports.py, merge-approved-backports.py). > > For example, if that was our current state, we wouldn't have had the > problem with the script being unable to find an appropriate section when > interactively adding the nomination. > > I don't think that occasionally messing up format of the STATUS file is > a big deal, as long as we have a regular checker that detects this. > > +1. -- Ivan Zhakov
