Yeah, if @adamfowleruk is too busy, we can indeed “re-home” Paladin back to HaikuArchives.
4 Likes
The real problem here is that the notion of GitHub “forks” isn’t all that great. There is always a “main” copy of the repository and all others are considered forks, and once someone has the “main”, it is not possible to pull it back from them, and if they are inactive, it stays at that.
HaikuArchives can be used as a way around that, if Haikuarchives has the “main”, then the HaikuArchives team can add and remove individual access to the repo as needed, and hopefully, HaikuArchives has a large enough team and adds new members to keep things alive.
It’s probably the best we can get if things stay at GitHub.
That being said, is someone planning to work on Paladin or UltraDV? If so, it’s up to them to decide how they want things set up. There isn’t really a point in HaikuArchives re-hosting the repository if no one is going to commit anything to it?
If an adopted repository is not returned back to HA after a maintainer stopped actively working on it, we’ll end up with the same situation as with UltraDV, where the original maintainer deleted it from his repo, and the community almost lost it.
1 Like
Re-hosting, and moving (old BeOS) software from somewhere else, at HaikuArchives does have at least one advantage: It’s easier to find for developers interested to improve/adopt a Haiku project. We often point newly arrived developers to HaikuArchives when they ask how to get their feet wet in their new Haiku environment.
1 Like
As logn as it is on GitHub there is no guarantee that it will remain online. It could be someone taking over HaikuArchives, GitHub closing down, someone doing a DMCA takedown, whatever crazy things.
Ideally the code should be stored in many different places for long term archival. GitHub isn’t the right place for that, so HaikuArchives is only very slightly better.
This sounds like a job for Software Heritage instead? And, it turns out, they do it rather well, they already have a dozen copies of UltraDV for example, including Berrett’s one: Search software origins to browse – Software Heritage archive
We should use an “Haiku” or “BeOS” tag on Github repositories for that instead. Less centralization is better for this.
2 Likes
Where can I set that? I’ve found “Tags” under “Settings” and those appear to be tags one can set for a specific commit, not the repo as a whole. Or maybe I misunderstood that…
Ah, yes, since “tags” is already used by Git, the thing I was talking about is called “topics”. They are available when editing the project description (click the gear icon at the top right, next to the “About” text).
Then you can explore the projects here: haiku · GitHub Topics · GitHub
1 Like
“Topics” does the trick, thanks.
Last week I sent an email to Adam but he didn’t respond, as yet.
The problem isn’t the source code itself but the dozens (if not not hundreds) of commits, comments, issues and PRs that are crucial for people to contribute.
We can claim the source code back at any time but what about the rest?
An app must not necessarily be in HaikuArchives, but if is moved to another repo at any point in time perhaps we may require to add HaikuArchives to the contributors so we can get it back.
BTW I didn’t know about Software Heritage. It looks interesting, thanks for sharing it.
2 Likes