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 
)
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 
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
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
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
I’m not talking about personal instances, those don’t let me contribute changes back.
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?
You meant mirroring GitHub repositories on an Haiku hosted instance?
Or tracking bugs directly on the Haiku hosted repository software ?
Sorry, your use of complex phrasing with passive voice in English confused me and I misunderstood you.
Anyway, yes, self hosted instances do let you contribute. It works this way:
- You run your own git instance with whatever tool you want
- You put your patches there
- You send a message to the maintainers informing them that you made changes
- It is up to the people who decide to use Githubto figure out how to pull the changes and integrate them in their repo
This is how Git should work. Github attempts to turn it into a centralized system, but we don’t have to blindly follow that, even if some repositories are hosted at Github.
I will have to do that as well, since Github requires 2FA now and for security reasons I have that now tied to my work computer to secure Github things I do there appropriately, so, no Github access from home anymore for me. For now I can still push things directly to Github without authenticating, and I can reply to issues by email. The web interface is completely unreachable, so, no creating pull requests, no creation of new forks, no creation of issues. Unless I do it from work during lunchbreak.
Now, regarding opposition: there will be some if we ask the already overworked Haiku sysadmins to handle this. On the other hand, moving to another hosted system only pushes the problem back until that other provider also starts doing stupid things or shuts down. At least we can pick one that uses opensource software this time…
And, for a full migration, Haikuports would have to decide what to do with the existing tickets and pull requests. Can these be migrated? Having them spread in two different places would be annoying.
Well, this is not really a nice way to contribute to a project in my view. Usually if you want to contribute to a project, you use the tools that they have decided to use, whether you are fond of them or not.
The correct way in my opinion would be to start a discussion among the Haikuports members/contributors on the HaikuPorts mailing list and try to convince them to switch. Apart from checking with Haiku’s sysadmins if they are OK with it.
2 Likes
nephele has been complaining for several months, if not years. Nothing happens. We are having this discussion here again. I think it is not working? So all that’s left is making it annoying for the people who don’t move out of github 
Also, haikuports is not part of Haiku, so Haiku sysadmins have no special word in that decision. Unless we ask them to host it, of course, but that will be a big change of how Haikuports operate (even if there is a large overlap in the contribution teams, officially, it’s not the same project).
1 Like
Maybe the majority of Haikuports members want do stay on GitHub? Isn’t that a valid choice also? I don’t necessarily advocate for the use of GitHub but I don’t see a reason to actively try to force people off it either.
That’s what I was referring to.
3 Likes
The problem i see with this model is that a big part of contributing back, atleast for me, is also reviewing changes. In some areas I have more expertise than others and If I cannot review changes that can’t be utilized, and in the same way I cannot benefit from reviews of other people as easily, or the turnabout time becomes way too big.
So I do agree with you that it is possible, but for me I think it is infeasible, we had this situation with gerrit before and I don’t think that was fun for either of us : /
Coming back to this: Is there interest from the haikuports team to move to any other soluton?
Github kind of forces the issue with their 2fa requirement, which already makes some devs unable to access github.
If there is interest let me know and I can set up a solution on a vps to try it out.
Options mentioned in this thread:
- Gerrit (Code review only)
- Forgejo (codeberg) (both)
- Gitea (both)
- Gogs (both)
- Gitlab (both)
- Trac (tickets only)
I would discount gitea in favor of Forgejo.
Gigs and trac do not support oauth2. So for the moment that would leave
- Gerrit
- Forgejo
- Gitlab
Since gerrit can’t be used standalone (no tickets) that leaves us with two options, personally i would strongly lean to forgejo of those two options.
Is there interest in trying out forgejo for this purpose? Or does anyone have suggestions on how we could set up the gerrit+trac combo, making sure that trac supports oauth2. Or any other ticketing software that is equivalent and supports oauth2.
Regards
1 Like