Why would you do that?
Just put a comment ‘unmaintained - plwase take over’ and leave it there.
As long as it still works…
2 Likes
I mentioned that before, I am almost fully moved to postmarketOS, so I want to fully clean up things.
The source is out there, people can compile if they want it and even publish it, it’s FOSS software after all.
1 Like
Transfer the git repo to https://github.com/poetaster and I’ll take care of source. Transfer the Sailbook app to jolla user poetaster and I’ll take care of that.
1 Like
You could just fork it. Don’t see why original developer should transfer the repo at git. Instead, he could just archive it.
1 Like
Yes, that’s my intention 
Source will remain available, as this is FOSS software.
Dylan is not the original developer. But that’s beside the point. One reason is that contributions to repositories are not shown for forks. Another reason to have the main repo is to ensure that pulls can be made against a master. That won’t work well if I’m running a fork. If others have forked the main and he archives it, who manages the push pull rebase nonsense? Presumably that CAN be made to work. But I’m already taking on more that I should so I don’t want wrinkles.
Good point regarding PRs. I can suggest the following workflow:
- make new empty repo, consider new name for app
- push all commits from Dylan’s repo
Issues will not be transferred, you start from start. There is no fork link with Dylan and all PRs are via you.
That’s the way it was done when I took over Poor Maps codebase from Osmo. I was asked also to come up with the new name to avoid confusion. That’s why the name from Osmo’s time (WhoGo Maps) was dropped and replaced with Pure Maps.
Ah, ok. That sounds doable. But why the extra work? The maintainer of Tidings had been looking (only via the github readme) and I said I could help. He suggested just transferring the repo to me as the easiest way forward. All contributions and all the relationships to other developers are still live.
I’m just working out all the workflows for myself since I’ve taken on a bit much. In the case of planetos, he hadn’t had:
- Any copyright or license info (and was distributing libs in a questionable way.)
- No revision management system at all.
I’ve put every up but am still working out ways to add the copyright / license information. I should just prepend to all src and be done with it.
But why the extra work?
I guess all depends on Dylan’s and your preferences. I am just pointing out for possible solutions. But if he is happy to transfer repository, that would work as well.
I have made the first version of Sailbook, and i take it over again everything is transfer to my Gitlab as i dont use Github anymore, also into the Jolla store it would be transfer to my name.
7 Likes
One thing I’m also uncertain about is renaming. I’ve begun to remove or restructure dependencies for 3 apps which (planetos image/audio/video editors), if I rename them has the consequence that people who have the app installed won’t get the update. Maybe that’s not a big deal but it feels like a breach of contract to me ?
1 Like
A great! You rock rudi!
1 Like
Re renaming: it all depends on specifics. In my case with Pure Maps, I was asked and had no issues with it. But it is all up to agreement between current and future developer
I meant the contract between a dev who does a release with one name and then a new release with another name. you leave the users in the lurch a bit?
1 Like
looks like our discussion became irrelevant. but in the case of new name, it is a new package as well. So, users would have to start from the beginning. Which is obviously an issue if it is associated with logins and other data.
I presume it’s technically possible to do a one-time transfer on first boot of harbour-newname of the data from .config/harbour-oldname and .local/share/harbour-oldname to .config/harbour-newname and .local/share/harbour-newname. At least until application access privileges are severely restricted.