On Wed, Nov 20, 2024 at 9:22 AM Daniel Shahaf <d...@daniel.shahaf.name> wrote: > > Nathan Hartman wrote on Tue, 19 Nov 2024 16:00 +00:00: > > Looking through the backports stuff in tools/dist, currently it's a > > little bit messy. I wonder if things can be simplified with a minimal > > amount of effort. > > > > What if we had just one script, actually called backport.py, with > > subcommands to run the different operations? > > > > Suggested subcommands: > > > [edited to group these five] > > backport.py merge-approved > > backport.py detect-conflicts > > backport.py lint-status > > backport.py nominate > > backport.py vote > ⋮ > > 'lint-status' replaces backport.pl's interactive features. It seems > > most of us are editing STATUS by hand, but sometimes we make syntax > > errors that make the backports bot fail -- I've done that multiple > > times myself!! So, let's edit STATUS by hand and then run > > 'backport.py lint-status' to check for errors. I think it could be > > implemented as a dry-run of 'merge-approved'. > ⋮ > > Thoughts? > > It seems that you're suggesting two different things: > > 1. Group the backport-related functionalities under one roof. > > 2. Add a lint-status function. > > My thoughts: > > 1. Sure. How about tools/backport/merge-approved.py, > tools/backport/detect-conflicts.py, tools/backport/lint-status.py, etc.? > As scripts under one directory, to support shell tab completion (and > granular `svn log`). > > 2. Patches welcome. :-) > > Cheers, > > Daniel > (glad to see backport.py being used :))
On Wed, Nov 20, 2024 at 9:22 AM Daniel Shahaf <d...@daniel.shahaf.name> wrote: > > Nathan Hartman wrote on Tue, 19 Nov 2024 16:00 +00:00: > > Looking through the backports stuff in tools/dist, currently it's a > > little bit messy. I wonder if things can be simplified with a minimal > > amount of effort. > > > > What if we had just one script, actually called backport.py, with > > subcommands to run the different operations? > > > > Suggested subcommands: > > > [edited to group these five] > > backport.py merge-approved > > backport.py detect-conflicts > > backport.py lint-status > > backport.py nominate > > backport.py vote > ⋮ > > 'lint-status' replaces backport.pl's interactive features. It seems > > most of us are editing STATUS by hand, but sometimes we make syntax > > errors that make the backports bot fail -- I've done that multiple > > times myself!! So, let's edit STATUS by hand and then run > > 'backport.py lint-status' to check for errors. I think it could be > > implemented as a dry-run of 'merge-approved'. > ⋮ > > Thoughts? > > It seems that you're suggesting two different things: > > 1. Group the backport-related functionalities under one roof. > > 2. Add a lint-status function. Correct. > My thoughts: > > 1. Sure. How about tools/backport/merge-approved.py, > tools/backport/detect-conflicts.py, tools/backport/lint-status.py, etc.? > As scripts under one directory, to support shell tab completion (and > granular `svn log`). Ack, shell completion and granular log are good reasons to have separate scripts per concern. I was hoping to reduce clutter in the directory by combining them into one big script, but: I notice that you write: tools/backport/*.py rather than tools/dist/*.py or tools/dist/backport/*.py. If that's intentional, I like this idea. Currently, tools/dist contains a mix of tools for managing backports and release management; by re-homing the backport scripts under a new tools/backport subdirectory, we'd separate these two concerns, reduce clutter in each directory, and hopefully make it easier to find the right script to run. There's one caveat: tools/dist/release.py imports backport.status (used only in write_changelog). That looks like the only call site in a release management script that uses logic from the backport scripts. I don't see an obvious way to avoid it. Cheers, Nathan
