Stow needs a co-maintainer

[aspiers]

[Also posted at https://savannah.gnu.org/bugs/?65569]

As explained in #70 (comment), the current situation where I'm the only maintainer of Stow is not a healthy or sustainable situation for the long term.

I have in the past received one or two kind offers to help out, but at the time was regrettably too busy with professional and personal stuff to give them the attention they deserved. If you are one of those people, please accept my apologies and I'm glad you're reading this. If not, I need to dig out those old messages, contact the people involved, and see if they are still interested.

But in the mean time, anyone who reads this and may be interested in helping out, or just has suggestions for the best way forward, is welcome to add a comment below.

What would be needed of a new co-maintainer?

Hopefully I'm not asking for too much here! If someone has significant gaps in the below list, then most likely bringing them on as co-maintainer would be counter-productive, because if I had to spend time getting someone up to speed on the basics before getting to the complex stuff then it would be more effective to use that time to do the work myself.

• At least a decent grasp of Perl
• A decent understanding of Stow and the ability to learn how the implementation works without too much external assistance (I will be very happy to answer good questions about stuff which isn't obvious, but I don't have time to explain simple things which are already documented or easy to deduce by reading the existing code and docs)
• Plenty of experience doing code reviews
• Plenty of experience with git, GitHub, and the pull request workflow
• A public track record of contributing to Stow and other FOSS projects
• Strong communication skills, to be able to help write release notes and announcements, and help support the community
• Good situational awareness and ability to coordinate with me, so that we don't end up duplicating work or causing unnecessary merge conflicts or other inefficiencies

How much time / commitment would be needed?

I don't think we need to be too prescriptive about this to be honest. If someone has the ability to do excellent work but only on an occasional basis, that's still great. We could potentially even have a team of 3-4 trusted co-maintainers all working sporadically, as long as they can all do a great job of coordinating in a professional manner. Or if there is one awesome person out there with a lot of free time who can carry a lot of weight, that would also be fantastic. I'm open to all offers and suggestions.

I might be interested; what should I do next?

One thing I do want to avoid is someone making a very loose commitment just because they like the idea of having maintainer privileges and then not following through. I'm sure that's a very unlikely scenario, but please first focus on demonstrating an ability to "chop wood and carry water", as any good maintainer needs to be able to do.

So assuming you're already decently familiar with Stow as a user, I would suggest one or both of the following:

• Review any of the existing PRs.
• Pick an existing issue, propose a fix in the comments, and then after any necessary discussion, submit a PR. There are some already labelled "easy" which should be a good introduction to the codebase.

[aspiers]

I have also posted this at https://savannah.gnu.org/bugs/?65569

[aspiers]

Unfortunately no one has come forward yet.

I'd be really interested to hear from the Stow community whether there would be anyone interested in helping with maintenance if Stow was implemented in Python rather than Perl. In other words, is the lack of volunteers correlated with Perl being a somewhat obsolete language with a dwindling number of people who know it?

I have considered a Python port in the past, but never had the time. However with the recent evolution of LLMs and AI coding assistants, I was thinking it seems more within reach than it used to.

But even more remarkably, after a quick Google I have just discovered that a port already exists! Here it is: https://github.com/r-burns/stow.py

I'm wondering how I never heard of this before. Or maybe I did but forgot? Anyway, it looks like a very promising effort, with a few obvious holes, e.g.

• the test suite is tiny
• it hasn't been updated in 5 years, so is missing a bunch of recent bugfixes and enhancements

To be clear: if the community demonstrated sufficient enthusiasm for contributing to coding and maintenance if there was a switch from Perl to Python, then I'd definitely be open to the idea.

[RaphGL]

Since no one is seems to be answering, I felt like I'd give my 2 cents.

I've been using stow since at at least 2018. At some point in 2022 I think I got an error message I couldn't figure out why, then I found it it was a known bug and I found a workaround on stackoverflow (I can't quite remember what it was now but I'm assuming it's fixed by now). But by then stow was mostly unmaintained for 2 years (or so). So I was going to attempt and read the code, but since the source code is perl and it's full of sigils and regexes, I just decided not to bother learning a whole new language I wouldn't have a use for, just to fix a single bug I'm getting when attempting to deploy my dotfiles.

So I just decided to write my own tool that fit my own use cases and be done with it. If the code were written in python, I think I'd likely just attempt to fix the issue I had and moved on. I'm guessing that a lot of people have been prevented from reading, understanding and maybe contributing just due to either being put off by perl or just not understanding much of what is going on.

---

I also agree with the opinion that perl is in decline and python just has more users, so maybe you'll have better luck in finding experienced people willing to help maintain stow

[aspiers]

Thanks for sharing your thoughts. BTW the error message you're referring to may be #65 which is indeed fixed now.

[isarandi]

Hi @aspiers
if you're interested in Python porting, I did an exact port actually before reading this, just for my own use case at https://github.com/isarandi/stow-python I largely did it with Claude assistance, but I had to be in the loop, and it took about a day (and part of my goal was also to just get more experience wrangling Claude).
It is quite unpythonic, but it can probably be refactored while keeping tests in the loop.
I can't commit much time to this, but wanted to let you know about it.

[aspiers]

@isarandi Thanks very much for letting me know! This could be very helpful in constructing an official Python port ❤️

[isarandi]

I have done some more work to make it Pythonic while ensuring ~99.9% exact match in behavior (the differences are truly weird cases found by exhaustive testing with weird strings that never happen in reality). I'll push this soon also.

[aspiers]

@isarandi let's move discussion into #135.