Re: The future of backport.py [Was: svn commit: r1936137 - subversion/branches/1.15.x]

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