Keeping native BeOS/Haiku software in Haiku Archives

I want to raise a topic regarding keeping BeOS/Haiku software on Haiku Archives if no one actively maintains it.

The first case is Paladin. A couple of years ago it was adopted by @adamfowleruk and was actively developed for a brief period. However, in January 2023, it will be three years since the last commit to the repository. Adam mentioned on the forum that he doesn’t have time to work on the project ATM, and pull requests from other developers are stalled, as can be seen in this topic.

Another case is UltraDV. This application was adopted by @Barrett, who made improvements to the app via crowdfunding in 2016 (see 1 and 2). However, after the breakup with the Haiku community, Barrett deleted the repository from his Github, and now the link to the repo from the app’s Depot page leads to nothing. Fortunately, it seems there is a package with the sources available in Haiku Depot. However, it would still be great to have it in Haiku Archives.

Finally, I’ve stumbled upon a repository with some old BeOS apps which aren’t available on Haiku Archives. Could someone please add them? They might not be valuable nowadays, but let’s keep them all in one place for preservation purposes.

1 Like

What do you suggest should be done with these application? I could´t parse it from your post :wink:

I thought it was clear - move all unmaintained apps back to Haiku Archives.

Not all old programs are available, and many don’t even run on Haiku anymore, so it makes little sense to keep them. You also have to look legally, because not everything is open source or freeware.

Paladin is an ide based on the beIDE and not an old program at all :wink:

I think archival is a noble purpose regardless of whether they run on Haiku or are generally useful today. Haiku Archives might not be the right place for something that is more of a bitsavers type of thing at this point though.

Not to me as it seems, thanks for clarifying :+1:
I thought these apps were still on HaikuArchives.

I agree with moving them back to HaikuArchives. The question is why didn’t they stay there in the first place. That way a maintainer change or stall of development doesn’t require any extra steps and if someone picks up the development again they can just make PRs against the Haikuarchive repo.

That’s actually a great question! ArtPaint is actively developed nowadays and yet stays in Haiku Archives.

2 Likes

Exactly. I recently started contributing quite a bit to a software on HA called ffmpegGUI. I’ve forked the repo, do my development there and make pull requests back to the original repo on HA. Just as intended, works great.
I really hope Paladin gets moved back, as I recently thought about contributing a few things to it. No promises though :wink:

3 Likes

“Adoption” (i.e. moving an app out of HA to a personal repo) is a two-edged sword.
I think that we should avoid this in the future.
Btw, I’ve sent an email to Adam to ask if he wants to consider moving Paladin back to HA

3 Likes

That only works well if someone closely monitors the PRs and merges them timely.
If people have to wait and wait for anyone to review a PR their motivation will vane.
Alternatively, HaikuArchives could (temporarily?) give the maintainer the necessary permissions for all of HaikuArchives. That would be possible where we know and trust the maintainer, but where to draw the line…?

Everybody is welcome to contribute with PRs on resident programs in HA and there is a bunch of us who more or less monitor the apps and may review/approve upon request.
One can obviously fork a specific repo and formally be recognised as a maintainer without necessarily removing the app from HA (by forking and setting upstream on HA and remote origin on personal repo may work).
I’m not against adopting but probably we need to require that if that happens, HaikuArchives GitHub account is granted commit rights on the adopted repo. Doing so we can claim the repo back if the adopter stops taking care of it.

EDIT: the real problem is with issues, PRs, commit history. Getting the code back is not an issue actually

1 Like

Isn´t it possible to give the maintainer the necessary permissions only for that specific repo?

I don’t think so. I’m not an expert github user though…

haikusrchives is just a github organization.
It doesn’t matter at all weather repos are in haikuarchives or some personal account. People can simply create a copy and work on that instead.

haikuarchives requires PRs to be merged by maintainers just as any private repo would.

Yes, the question was if the maintainer can be set per repo or only for all of HaikuArchives.

No idea? I answered to the OP. I think the question is moot since you can just copy the repository if you wish to work on it.

Well it´s obvious anyone can copy/clone/fork a repo and work on it. But the question is not “moot” in my opinion because the whole point of HaikuArchives is to keep Haiku software in a central location to be worked on and used by the community in an organized way. At least that´s how I see it :wink:

It is, actually. If it’s desired (I haven’t been paying much attention to the ArtPaint situation) I or another of the HaikuArchives admins can grant push access for a single user to a single repository.

1 Like

There looks to be some kind of backup of the repository here: GitHub - mvfranz/UltraDV: UltraDV video editor for Haiku

Not sure if it’s current to what’s in HaikuDepot, someone will have to try and determine that one way or another.

At least some of those look familiar but I didn’t actually check if we have them at HaikuArchives or not.