On Mon, Nov 18, 2024 at 3:52 AM Daniel Sahlberg <daniel.l.sahlb...@gmail.com> wrote: > > Hi, > > Regarding scripts in tools/dist: > > backport.pl is a heavy user of "given ... when ..." and given that these > constructs will be removed[1] when Perl 5.42 is released (pun intended), we > need to take some action. I'm guessing we have about one year before hitting > a brick wall. > > backport.pl is "considered deprecated" according README.backport, but it > seems danielsh added this on his own - I can't find a discussion or decision > on dev@. > > Both scripts can handle the nightly backport job (running on svn-qavm) as > well as the backport conflict detection (currently on ci2.apache.org). > backport.pl also has an interactive mode where it can review existing > nominations and create new ones in the correct format. > > I see two options: > * Rewrite backport.pl to use if/else blocks instead. This should be quite > easy but I don't think we have a test suite to verify the result so we might > find regressions further down the line. > * Bite the bullet, delete backport.pl and officially switch to backport.py. > > The first option seems like the simplest here-and-now, but we are still in > the position where we have two different scripts doing more or less the same. > > For the second option, we would loose the interactive features but I believe > we have more developers fluent in Python so we can better support it going > forward. If we select this option, we either need to decide that the > interactive features can go away, or we need to spend the resources > rebuilding them in Python. We also need to do changes on svn-qavm, I can > volunteer to do this. > > I'm leaning towards the second option. The interactive features are nice but > I usually don't use them so I wouldn't mind loosing them - I think the > advantage of a more widely used language is more important. > > Thought and comments? > > Kind regards, > Daniel > > > [1] https://perldoc.perl.org/perldeprecation#Perl-5.42
I'm +1 to switch to the Python implementation. After C, the next largest part of our codebase is in Python, and it seems more people are comfortable with it these days. 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: backport.py merge-approved backport.py detect-conflicts backport.py lint-status 'merge-approved' normally would run nightly by svn-role, but could run manually, e.g., by a release manager. 'detect-conflicts' normally would run nightly by buildbot, but could run manually. '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'. If there are maintainers who prefer nominating and voting interactively, there can be two additional subcommands: backport.py nominate backport.py vote but we don't need to implement these if there isn't interest in using them. Thoughts? Nathan