Daniel Sahlberg wrote on Mon, 18 Nov 2024 08:52 +00:00: > 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@.
IIRC, I told dev@ I figured it was time to deprecated backport.pl and no one objected. There wouldn't have been much discussion; the Perl and interactive parts of the backport scripts never received much attention. Substantively, the .pl is deprecated in favour of the .py because the .py's internals are much cleaner. > 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. Some more differences: - There's an old bugfix, r1765903, that may have never been ported to backport.pl. - 'release.py write-changelog' reuses backport.py library functions: https://svn.apache.org/viewvc/subversion/trunk/tools/dist/release.py?revision=1921278&view=markup#l1626 > 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 Have you seen https://svn.apache.org/viewvc/subversion/trunk/tools/dist/README.backport?revision=1911928&view=markup#l55 ? > 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. > Thank you. :) > 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? > I don't follow development closely nowadays, but when I did, I was +1 to switch to .py for the automated functions, for whatever that may be worth. (Opinions depreciate.) As to the interactive functions: they don't have a Python equivalent, and I don't think they ever had many users, but for what users they have they do make it much easier to contribute to maintenance of stable branches. So: A. Would removing these functions break any maintainer's proverbial spacebar heating? B. Would more maintainers use the interactive functions if they [the interactive functions] were implemented in Python? The goal I have in mind here is to make it as easy as possible for maintainers to contribute. To graft hwright@'s phrasing, the steps for a maintainer to edit STATUS should be "1. Profit!". :) Cheers, Daniel > Kind regards, > Daniel > > > [1] https://perldoc.perl.org/perldeprecation#Perl-5.42
