Forgejo instead of Gitea
Hi OpenDev friends, I wonder if Forgejo has ever been mentioned as a really free (as in speech) alternative to Gitea. If not, I think this is the best time because the two projects started to diverge (as of early 2024) and the further down the path of Gitea upgrades, the harder it might be to migrate. I think Forgejo presents itself as a better incarnation of Gitea for OpenDev because it is more aligned in spirit and has higher transparency than Gitea. All the reasoning behind Forgejo and related relevant details are summarised in [1] Please let me know if this could be welcome on OpenDev. If so, I can offer my time for being a bridge between the communities and helping with the possible migration. Kind regards, Radek [1] https://forgejo.org/compare-to-gitea/
On Thu, Aug 8, 2024, at 10:49 AM, Radosław Piliszek wrote:
When the soft fork happened we discussed it but it didn't seem urgent at the time as the intention was to keep the two code bases largely in sync. (Forgejo would do more releases to get features out quicker, but wasn't going to diverge in terms of codebase at the major release points if I understood the original intentions properly).
Yes, more recently the soft fork has become a proper fork and that may present some increased effort to migrate. However, it is important to note that we only use Gitea as a git mirror and content rendering system. This means it should continue to be relatively trivial to move from Gitea to Forgejo (or vice versa). We simply spin up the new system and replicate to it then add the system to the load balancer. I'm not terribly concerned about the fork becoming less soft as a result.
I think we should be careful making these assertions. In particular Gitea continues to be open source software developed in the open that accepts patches from external contributors. Last I checked they make their volunteer led "roadmap" (if it can be called that) public as part of every release they develop [2]. Yes, a private company holds the trademark, but as far as I can tell they continue to be doing open source. I don't think everyone has stopped using SQLite or Chromium etc just because a private company holds the trademark. Now not everyone may agree with all of the decisions they do make. I've personally been frustrated with the response on some of the bugs I've filed lately, but they did eventually get resolved (like the MySQL/MariaDB case sensitivity problems). Note the above is based on my personal interpretation of the rift that occurred but I am not deeply involved in either community. I do think that there are flaws in [1] like the assertion Gitea requires copyright assignment. (My own interpretation of that matter is that there was mass confusion over what the policy guidance required and what was requested and both sides could've handled the situation better. I am not a lawyer, but it seems that Gitea merely requests simplified copyright headers attributing "Gitea authors" and you join that membership retaining your copyright when code is merged. Again I'm not a lawyer don't consider this legal advice if you contribute to Gitea).
My personal opinion (I haven't discussed this with the wider team; we can probably use this thread for that) is that I'm not sure we would get many benefits from a change today which makes it a very low priority item for myself. In particular Forgejo's main strength appears to be the support for "forge federation" which we wouldn't be able to participate in as we use Gerrit as our Forge and Gitea/Forgejo would simply be git mirrors and content rendering. If people want to migrate I think we should be explicit about what benefits we expect to receive from or provide to Forgejo as a result. Then balance that against the effort required to switch in order to determine if we should proceed. I suspect that if we were starting with a blank slate we would lean towards Forgejo, but we are not and so far Gitea has been functional.
On Fri, 9 Aug 2024 at 19:38, Clark Boylan <cboylan@sapwetik.org> wrote:
I don't read it as the problem being just (or mainly) the trademark. [3] See for example [4] and [5] (this is one issue, just spread over two places). I see it as an example of bad open source governance at Gitea. Also, at no point does the page claim that Gitea is not open source and it is indeed still open source, albeit with a curious approach to license interpretation and code acceptance. Another good selling point for communities of OpenDev grade is the more transparent security process. [3] Originally yes, it was a dispute about a sudden appearance of a commercial company behind Gitea which some considered to be a "community"-based project. [4] https://github.com/go-gitea/gitea/pull/27455 [5] https://codeberg.org/forgejo/discussions/issues/67
Note the above is based on my personal interpretation of the rift that occurred but I am not deeply involved in either community. I do think that there are flaws in [1] like the assertion Gitea requires copyright assignment. (My own interpretation of that matter is that there was mass confusion over what the policy guidance required and what was requested and both sides could've handled the situation better. I am not a lawyer, but it seems that Gitea merely requests simplified copyright headers attributing "Gitea authors" and you join that membership retaining your copyright when code is merged. Again I'm not a lawyer don't consider this legal advice if you contribute to Gitea).
I think the problem is that it's not entirely clear (and all folks around, including you and me, can yell IANAL). Normally, one can mix and match MIT-licensed code, just preserving the copyright and license information as that is the clear requirement of the MIT license. Now, as cited above, they force the re-assignment of copyright. That's simply bad open source stewardship to me. Can they make such a rule without violating anybody's rights? Yes. Is it good? I think not. Oh, and on that note of licensing, the next and following releases of Forgejo will be GPL3-or-later-licensed.
I specifically haven't mentioned tech benefits because I don't think there would be any major ones *now* (except from the procedural ones already mentioned above). However...
If people want to migrate I think we should be explicit about what benefits we expect to receive from or provide to Forgejo as a result.
I think it opens a long-forgotten path to proper high availability. Seeing Forgejo as a more welcoming community, I think it's a better place to collaborate on that. Maybe it could result in OpenDev providing bug and project tracking capabilities based on Forgejo, reducing the need to rely on third parties (and good ol' Storyboard). But this is a long-term investment. Personally, I have this dream of combining Gerrit flow with Forgejo-based project and issue tracking. I have also a more concrete project now of considering the integration between Forgejo and Hound. And Forgejo benefits from supporting a use case in a major open source foundation.
Then balance that against the effort required to switch in order to determine if we should proceed. I suspect that if we were starting with a blank slate we would lean towards Forgejo, but we are not and so far Gitea has been functional.
I think it would be easy to outweigh the effort with any benefits since you said it's currently not relying much on any kind of persistence (correct me if I misinterpreted your words).
On Fri, Aug 9, 2024, at 12:23 PM, Radosław Piliszek wrote:
As mentioned above I disagree that this is the case. I know this is stated, but my understanding is they merely wished to keep copyright headers in code short to avoid an ever growing and incomplete list within the code. No change of ownership/copyright was required. It is still fair for people to refuse to contribute code if they wish to have explicit recognition at the top of the file, but this is different than giving up your claim to the associated copyright. I believe this practice is common; google's open source policies encourage it as well [6] (consequently this seems to be how k8s does it for example). OpenStack previously discussed similar things without reaching any concrete consensus on what should be required of the headers; however, I think OpenStack's guidelines allow for individual projects to opt into this method of attribution [7].
Are they making an explicit change? The FAQ [8] says they allow contributions under GPLv3 or later but no such contributions have occurred yet. I don't think it affects us either way as MIT or GPLv3 licenses should be fine.
To be clear I think our existing installation would be considered highly available? We do rolling upgrades that people don't seem to notice. I was able to do semi major database surgery recently without anyone noticing (other than it fixing issues caused by database table definitions that got corrected).
Seeing Forgejo as a more welcoming community, I think it's a better place to collaborate on that.
My perspective here is that both communities have struggled to get along. As someone with basically no Forgejo community interaction and minimal Gitea interaction related to our service (I file the occasional bug and have a couple bugfix commits in Gitea) I'm not sure that one community is more welcoming than another.
This should be possible with Gitea as well as Forgejo. The primary issue here has been lack of time to rearchitect the deployment architecture, test it all, then determine if this is feasible for our use cases. The most productive path forward on things like this is likely to start helping OpenDev as a whole so that the team can breath and find time to building new functionality like this.
The way Gitea is deployed today is as 6 independent Gitea installations fronted by a load balancer. The persistence/source of truth largely comes from the git repo state in Gerrit. We then replicate that to the 6 Giteas. The major exception to this is for project rename redirects. Those are in Gitea database alone; Gerrit has no knowledge of them. Currently, we handle replacing Gitea nodes by restoring the database content from a backup. We could also theoretically build the database state from our historical rename records as well. Using Gitea or Forgejo as a stateful service for content outside of git (like issues) would require us to redeploy things as a coherent cluster sharing and coordinating around that state. The bottlenecks we've got aren't due to Gitea so replacing Gitea won't improve them. The issues are largely due to the size of the team trying to maintain a robust set of existing services while still being able to lead lives outside of work and have the occasional vacation. With my definitely biased hat on here I think we're doing a decent job, but there is always more that could be done if we had more time. Forgejo may be worth considering if we expect it to reduce our time demands (because it is easier to upgrade and operate for example) or if it brings more people into the OpenDev admin space. I suspect it won't do either thing, but wanted to mention in case there is reason to believe otherwise. [6] https://opensource.google/documentation/reference/releasing/authors [7] https://docs.openstack.org/project-team-guide/legal-issues-faq.html#copyrigh... [8] https://forgejo.org/faq/#is-forgejo-licensed-under-agpl
On Fri, 9 Aug 2024 at 23:17, Clark Boylan <cboylan@sapwetik.org> wrote:
I agree that this is a subjective matter and may have more than one interpretation.
Yes. See [9]. [9] https://codeberg.org/forgejo/forgejo/pulls/4737
To be clear I think our existing installation would be considered highly available? We do rolling upgrades that people don't seem to notice. I was able to do semi major database surgery recently without anyone noticing (other than it fixing issues caused by database table definitions that got corrected).
I was specifically referring to the last q of the faq at [10]: "Why can't we use Gitea's issue tracker and wiki?" -> "Once Gitea can be run as a proper cluster this may change" [10] https://opendev.org/
Yeah, this is again something subjective so not really a point to continue discussing.
Ack.
Ack. These are good points. PS: From "the outside" it also looks like you are doing a very decent job!
participants (2)
-
Clark Boylan
-
Radosław Piliszek