nixos/gitea: reconcile module requirements for forgejo

[bendlas]

Since forgejo's release lags behind gitea a bit, the otherwise assumed feature-parity doesn't hold for the period whan gitea has already been updated, but forgejo has not.

There is an agreement to support forgejo with the nixos/gitea package, in line with forgejo's self-imposed status of drop-in compatibility with gitea: #210790 (review)

Since the 1.19 -> 1.20 disparity window caused a temporary incompatibility - around the systemd unit becoming type notify - there have been discussions about supporting forgejo in a separate module.

But before conclusions are taken, maybe we can have another look at possible solutions:

• 👎 do nothing and accept that the disparity window may continue to cause tension
• 👍 fully split the modules
• ❤️ partially split the modules, with a shared base and forgejo maintainers moving common options from gitea to gitea-common
• 🚀 keep single module, when updating gitea, also update forgejo to latest compatible rc (which should be available at that point)
• 🎉 Support multiple gitea versions on a module level, to cover the disparity window.

[bendlas]

I'd go as far as 🚀 forgejo rc, because I think forgejo users will want to participate in testing rcs, otherwise they'd just use gitea.

[SuperSandro2000]

partially split the modules, with a shared base and forgejo maintainers moving common options from gitea to gitea-common

I think that is the best option to reduce code duplication and drift between the two but I wouldn't split the actual nix files but would add some helpers like isGitea/isForgejo and make things conditional based on that.

[bendlas]

helpers like isGitea/isForgejo and make things conditional based on that.

Keep in mind that since forgejo is meant to be a "friendly fork" which is upstreaming, there should never be a need for such distinctions, outside of that awkward period when forgejo is still preparing the final release.

EDIT So so that option would effectively turn out to: Support multiple gitea versions on a module level. Let me add that to the list ...

[techknowlogick]

@bendlas fwiw forgejo doesn't describe itself as a fork anymore, but rather "built on top of Gitea", and while they have contributed some bug fixes, they have let the Gitea team that there are many parts that they won't be contributing upstream, but rather "we are welcome to port it ourselves", which is already possible via the license, and would require us to track a wholly separate project.

[bendlas]

Interesting, I wasn't aware. That would point a bit in the direction of making a split. Still, I'd prefer to keep the same module, if you'll have us ;-)

[techknowlogick]

@bendlas happy to have everyone.
I'd recommend probably sticking to RCs of forgejo as otherwise all users of Gitea would need to be held up otherwise.

[emilylange]

I am now very much in favor of splitting the module and even the VM test.

There have been multiple occasions where interactions between gitea and forgejo maintainers in nixpkgs haven't really worked out.

And it's probably for the better, to part ways.
At least for now, maybe we can reconsider this in the future.

Edit: I talked to @bendlas in private, and we are now both in favor of splitting. I'll try to start working on it tomorrow, as I think this fairly time-critical. We did not hear from @urandom2 back, yet.

[techknowlogick]

@emilylange would you be willing to elaborate more on that? I've been staying out of any forgejo specific package update conversations as I'm not a maintainer of them*, but if that's a problem I can provide input as needed. Don't want anyone to feel excluded or poorly in any way.

*with exception of this conversation as it involves the cadence of Gitea nixpkgs release timings.

Some other things to think of in terms of this conversation overall, what would the impact of each choice when Gitea starts with LTS, would that prevent backporting LTS versions of Gitea if depending on the outcome of these discussions?

[RaitoBezarius]

Some other things to think of in terms of this conversation overall, what would the impact of each choice when Gitea starts with LTS, would that prevent backporting LTS versions of Gitea if depending on the outcome of these discussions?

In a complete split scenario, Gitea have their own life and maintainers can do whatever they want, Forgejo maintainers will also work separately. This is just decreasing the "shared workforce" due to it not working very well in the past, see #242863 for a recent example @emilylange had to work on.

[techknowlogick]

Thanks for sharing that context @RaitoBezarius :)

I'll abstain from voting, but hope that whatever the outcome is something that everyone is ok with. If there is anything I can do from the Gitea project itself, please let me know :)

[Ma27]

Added a 👍 and a ❤️ because I'd be fine with both solutions (though I'd prefer a full split).

This is just decreasing the "shared workforce" due to it not working very well in the past, see #242863 for a recent example @emilylange had to work on.

Since this was brought up a few times now, I'd like to respond to this as well: I fully agree that the RuntimeDirectory permission thing was unfortunate at best and I also actively reconsidered my stance on the nginx configuration topic (from neutral to - at least - skeptical), so I fully understand @emilylange's frustration here and personally, I'd like to use this to say sorry to you @emilylange, it was never my intention to make your work harder!

While I agree with a split (more on that below), it's important for me to not have bad blood because of it (and we do it purely based on technical reasons) :)

That being said I think I'd like to mention that both of these issues (assuming I haven't forgotten something else!) were problems for both gitea and forgejo, so they're not strictly related to the issue. However, the Type = "notify"-revert was a clear warning sign: we already have a noticeable difference between both codebases (because of the deviating release candence) and if I understand @techknowlogick's comments correctly, further differences are to be expected which also means that we'll probably have even more issues to deal with in the future, so we should learn from this incident now and do a split.

If both the gitea and forgejo maintainers come to the conclusion in the future that we should go back to the current model, we can still reconsider it.

[bendlas]

OK, now that everybody got to speak their piece and the decision seems to be settled, I feel less bad about potentially hijacking the thread, while we wait for the new forgejo module:

@techknowlogick: first of all thank you very much, for holding your hand out on part of gitea!

... contributed some bug fixes, they have let the Gitea team that there are many parts that they won't be contributing upstream ...

From the outset forgejo looks to me like 2.5 pages of moderately well-kept cherry-tip / rebase-outbox commits. A lot of it dealing with CI and branding. So for me, it's also a how-to for which places to look at in gitea for customization.

Are there any parts from forgejo, that you'd look at having in gitea?