Nathan Hartman wrote on Wed, 20 Nov 2024 21:17 +00:00: > 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. >
It was deliberate, yes, though I don't have a strong opinion on the matter. > 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. I don't see why we should avoid it: it's quite fine and proper for a library to be reused. We can have release.py continue to use backport.status as it does (doing whatever magic is necessary for the latter to be importable by the former), and extend backport.status with docstring comments and/or tests ensuring the depended-on functionality is not changed in a backwards incompatible manner. If we do seek to remove that dependency, however, it's probably easiest to have the backporting script stick the logsummary in a revprop on the merging commit, and let release.py fish it from there. Cheers, Daniel
