Den ons 20 nov. 2024 kl 14:50 skrev Daniel Shahaf <d...@daniel.shahaf.name>:
> 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 Two more reason to make more use of the PY version. > > > > 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 > ? > Missed that one, but I'm looking now. It did't work with Py3, but I changed a few things in r1921976. It seems a bunch of tests fail right now, don't know if it XFails() but isn't marked properly or if it fails due to code rot or something else, I'll try to make them work. > > 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.) > So I'd say we have consensus on moving to the Python implementation - several +1 and no-one objecting. And since this is far from core code and it can easily be reverted I don't see a problem at all. > 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? > This is the main question but no-one said so yet. It'll be a while before I remove the Perl implementation and even then it can easily be resurrected. > B. Would more maintainers use the interactive functions if they [the > interactive functions] were implemented in Python? > No, not because of the language, but maybe if it was more widely know they exist. I've used them a little and they are very nice. Using the scripts to nominate would have prevented the backport failure we recently had, where "votes:" (with small letter "v") prevented automatic merge. On the other hand I find it more difficult remembering how to call the script than to edit STATUS manually... > 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!". :) > Agree. > > Cheers, > > Daniel > > > Kind regards, > > Daniel > > > > > > [1] https://perldoc.perl.org/perldeprecation#Perl-5.42 >
