Haikuports gerrit

HaikuPorts has 4 repositories. That should not be a problem.

HaikuArchives is larger (almost 400), so indeed that’s a thing to take into consideration.

Another aspect is the usage of github pages as well as the continuous integration support. For example, haikuports.cross is using Github actions to do a bootstrap build of Haiku and all packages, on several architectures, everytime something is changed. At the moment this is paid by Microsoft since they provide Github actions for free. What are the offers for other hosting platforms? If we go self-hosted (for everything or just the CI), who will do the work to run the CI servers?

Back in 2022, Gitlab briefly considered deleting all “inactive” projects (getting no new commits or tickets) after some time. They cancelled that plan after a lot of complaints, but they can’t keep providing disk storage to everyone for free forever, so, surely this will come back at some point, or some other restrictions will be put to push people into paid plans (and likewise Github will do similar things at some point, it’s only a question of when).

So, a lot of things to consider and plan…

Also, Haikuports used to have its own SVN server I think? before moving to bitbucket and then to github. The old website (Trac based) is still online at http://ports.haiku-files.org so that’s one thing already up and running :slight_smile:

1 Like

The 100 repo limit per organization isn’t a hard limit.
It’s probably more meant as some sort of spam protection so that random users can’t fill the whole platform with thousands of nonsense repositories,and in most cases this limit is more than enough.
If it isn’t,like for HaikuArchives,you can request the limit to be increased for your organization: https://docs.codeberg.org/getting-started/faq/#i-need-to-request-more-resources-from-an-administrator.-how-do-i-do-that%3F
There’s also Codeberg pages as alternative to Github pages,and they host a Woodpecker CI instance as alternative to Github actions.
It’s also nice to know that they already collected enough donations to keep everything running for another 12 years,as stated in their FAQ,so we don’t have to worry about paid features that may come in the future.
Considering all that,I think Codeberg would be a pretty good fit,if we decide against self-hosting which would be even better,of course.

May I ask what was the reason to move away from Bitbucket into another walled-garden?
Don’t see any downsides there that Github doesn’t also have.

I’m not a fan of Gerrit from the admin side… it’s extremely difficult to manage. however from the user side it’s fine. It was the easiest system to transition over to our new SSO provider.

Currently bug reports for haikuports go into github issues… do we have a plan here? Do we want all the haikuports issues reported in our trac instance? I feel like that might clog up our bugtracker.

Though… maybe the new Trac 1.6 version will solve “all of our scaling issues?”

I’d love to run something like gittea, but that hasn’t been popular in the past.

Not sure we need to pick one or the other, can’t you integrate github with gerrit?
Also some of you sound very anti to something that is provided free to us, and a lot less maintenance compared to hosting your own things. Are we not already short on disk? And the bus-factor of admins that knows how to run gerrit seems like one?

2 Likes

Gitea is fine too. I use it personally (but i would make s new css theme if haiku were to use it)

I think gerrit would be very nice so we have one code review tool to use and not severall, especially on different platforms.

The possibility of all haikuarchive changes to be in one gerrit seems very interesting to me.

“provided free to us”
→ It’s not free if you pay with your data.
That applies to all products of Micro$oft,Google,Amazon,Facebook and similar companies.
I’d rather pay 5 Euro/month for a trustworthy Gitea instance than paying Micro$oft with usage data.

2 Likes

Codeberg’s Forgejo fork of GitTea is very similar but severs ties with the Chinese Communist Party members that made GitTea (if I remember correctly about the reason for the fork). If Codeberg is willing to raise the limits, it might be worth a try.

I agree about the “prying A.I.'s” of Microsoft though. Germany’s privacy laws put U.S. laws to shame. I’ve cancelled my LinkedIn account twice over similar issues.

1 Like

I’ve read the Forgejo announcement blog post today when I tried to find out more about the differences between Gitea and Forgejo: Beyond coding. We forge. — Forgejo
I don’t find any mention of the Chinese Communist Party there,but it looks like Gitea went commercial with a new company Gitea Ltd. behind it instead of the community.
I can’t find a lot of differences between Gitea and Forgejo currently,but maybe they will develop more unique features in the future.

All good points. This is honestly why we ended up on Github originally. It was a nice backup to our infrastructure we could use in an emergency. (for those unaware, our source code is continuously pulled by Github in case the sysadmin team breaks something :wink: )

2 Likes

Ah! Yeah! I forgot the name of this project. I saw a Forgejo server a few days ago and thought it looked nice. The down side is ForgeJo is really new in the landscape.

1 Like

No, they should remain separate. It could be a second Trac instance (there already is an old unused one on haiku-files.org)

There are some “bridges” that turn github pull requests into Gerrit change requests, but I think it results in a “worst of both worlds” situation, adding up the complexity of both systems.

Yes, it’s nice to have it for free as long as it lasts. It will probably not last forever, but it will last “long enough” that we can not worry about it for now and focus on other problems first (at this point, it is not even really a problem).

There is also the question of where GitHub is going in the future, they seem to be trying AI (GitHub Copilot) and inserted an ad for that on all GitHub webpages. Personally I am not so happy about that (mainly for ecological reasons, these systems are very power hungry), but that is only my personal opinion and I have barely started even moving my own personal repos out of Github. So I will not make demands to Haikuports to move theirs until I’m done with mine :slight_smile:

That’s good for Haiku, but Haikuports is exclusively at GitHub for now. I guess an option is to set up a read-only mirror of it on some other forge, at a minimum?

1 Like

Codeberg’s migration tool, given a private access token, allows to migrate of GitHub’s PRs, Issues, Wikis, Labels, Milestones, Releases… sounds promising, albeit that looks more like a “one time thing”, than a “mirror mode”.

FWIW, migration went smoothly for my private repos (admittedly small test case).

Will be nice to see how the work on federation on both forgejo/gitea pans out.

1 Like

I guess an option is to set up a read-only mirror of it on some other forge, at a minimum?

That’s what I did with Gitea (makes it easy to create a mirror including wiki, tickets, etc…) :

Sync happen every 2 hours. HaikuArchive will be done over the weekend.
Would be better to have it hosted on a official server though rather than a personal one.

2 Likes

Yeah, essentially we would mimicing the other repos we host on Gerrit today and makes sense.

That’s long gone :slight_smile:

This is really the only pain point I think. Trac has been great, but it gets abused a lot by spammers. I kinda don’t want to add a second trac instance for folks to abuse.

1 Like

with SSO atleast we would have a shared account space to kick abusers off of : )

2 Likes

The reasons spammers target our Trac is because it immediately sends every message to haiku-bugs@freelists.org, and then it is published on the freelists archives. So, spamming links there works for their SEO, even if we quickly delete the messages from Trac itself. So it’s very worth the effort.

And I guess the recent improvements in machine learning made it easier to generate messages that will not wake up our spam detectors.

I agree with nephele, switching it to SSO might help.

3 Likes

I’d love to… except Trac doesn’t support oauth2 :slight_smile:

Investigate oauth2 support in Trac. · Issue #84 · haiku/infrastructure · GitHub is tracking this one.

1 Like

Is there any objection to there beeing set up an own instance to use? regardless of wether that is sr.ht (forgot the sw name), gitea, or gerrit?

Who could oppose to setting up your own personal instance? You do whatever you want :slight_smile:

I’m not talking about personal instances, those don’t let me contribute changes back.