Sorry typo: Fork. Which one you prefer? If no activity for very long time for app you would like to update.
1 Like
It’s already difficult enough to compare the apps that have different versions in Harbour, Storeman and Chum, so I prefer the continuing of existing apps instead of forks (keep settings and accounts is not possible for forks if an ap has no settings backup function…).
Unplayer is one of those apps where we have a fork and where I wish we had just a pull request… But the real problem is if devs abandon their apps, so I guess a fork is the only way to handle that properly when another one takes over.
1 Like
Is the maintainer responsive, even if otherwise “inactive”? If so, reach out for their thoughts, file an issue, etc. If it’s a clear bug, compilation error, etc. then I’d submit a pull request from the get-go. If they don’t have the time or energy to maintain it, that’s okay and I can offer to either help with maintenance or if they wish I can just fork and do my own thing. They’re not really under any obligations.
If it is feature work on something that hasn’t been explicitly approved, my general process is to file a feature request issue first. In the feature request, I’d be clear that I am willing / already have done the work, however it’s really up to the decision of the author whether or not to accept the work or the respective feature (after all, it might run counter to their intent / vision / scope of their work). I don’t just yolo throw features over the wall in PRs and expect the author to make a snap decision on whether or not they’d be willing to take on the extra scope or maintenance burden.
If the maintainer isn’t responsive, then I’m more inclined to fork. Doesn’t mean it’s a public fork, I could just do something for me.
5 Likes
The general idea is to cooperate whenever possible, but fork if necessary.
In addition to the great points already made, there’s also two kinds of forks:
- A soft fork that keeps the old name, so it can be installed over the old version. This is best done if you’re fixing an abandoned app, like fixing a small bug to make it work on modern Sailfish versions. No one will complain about that. You can also do this if you actually want to continue development, and the original maintainer is okay with that.
- A hard fork that changes the name, so it’s installed as a new app. This is best done if you’re making big changes that the original maintainer didn’t or doesn’t want or is no longer around to implement.
4 Likes
Maybe this belongs here too:
2 Likes
Thank You all for your replies. I sent comment to this repo and asked whether update could be done. Let’s see.
Thanks for clarifying that, I just remembered while reading this that I wondered why both version of Unplayer are shown as installed by Storeman…
Yes, my approach was to make contact if possible, usually via tickets. Where no responses where forthcoming over longer periods (many months) of time, I would consider if I could take on forking it.
The really hard choice is if it’s time to pull the fork from the original and just make it stand alone. I’ve done that, for instance, with Fahrplan, where it was clear the original was dead and PRs where just piling up there. Clean break.
3 Likes