On Fri, 9 Aug 2024 at 23:17, Clark Boylan <cboylan@sapwetik.org> wrote:
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.
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.
I agree that this is a subjective matter and may have more than one interpretation.
Oh, and on that note of licensing, the next and following releases of Forgejo will be GPL3-or-later-licensed.
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.
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/
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.
Yeah, this is again something subjective so not really a point to continue discussing.
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).
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.
Ack.
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).
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.
Ack. These are good points. PS: From "the outside" it also looks like you are doing a very decent job!