Switching the forgefriends codebase from Gitea to Codeberg

Development
#1

Bonjour,

I’m considering switching the forgefriends codebase from being a long standing fork of Gitea to being a long standing fork of Codeberg instead.

There are pros and cons:

Pros

  • The codebase is field tested with a large user base in production
  • Codeberg is developed on Codeberg and does not require using proprietary software
  • Codeberg governance is democratic and documented
  • Codeberg takes an active part in the ongoing forge federation effort

Cons

  • Pull requests for features will have to be submitted to Gitea first and it will take longer for them to be reflected in the Codeberg codebase
  • There are Codeberg specific commits that needs to be discarded for the codebase to be used for self-hosting

Maintaining a long standing fork of a codebase can be made very difficult when the upstream project is subject to governance and technical instability. No project is ever perfect in this regard but I think Codeberg offers significantly better guarantees in both areas than Gitea. For instance, there currently is an unresolved conflict of interest in the Gitea governance. The Codeberg governance is more democratic, more transparent and less likely to be subject to such problems. Other examples, on the technical side of things, are the regressions that required multiple point releases when 1.16 was published as well as the accidental publication of release candidates in lieu of stable releases for both 1.16 and 1.17. The Codeberg codebase is curated differently and is less likely to be subject to such problems.

Another important aspect is the ability for forgefriends developers to upstream bug fixes in a timely manner. In that respect it is difficult to foresee how things would go with Codeberg. Codeberg maintainers won’t be keen on merging a bug fix that has no impact at all on Codeberg. But the contribution loop will be a lot smoother for other bugs because it won’t involve working on GitHub. I’m the only one in this case currently but imposing that burden on forgefriends contributors is not consistent with the goals of the project. Features and complicated bugs that are not of interest to Codeberg will still have to go through the Gitea upstreaming process but it will be a win to have at least some features and bugs fixed as Codeberg contributions.

Overall the effort to make the switch is a matter of:

I don’t suppose it will be much. If it turns out to be a bad choice, reverting will be a matter of going back to how it was before. I don’t see how anything irreversible (or difficult to revert) will happen.

If no significant blocker / burden is discovered in the next few days, I’ll do the necessary legwork to make it happen.

Cheers

DRAFT: monthly report, August 2022
#2

On the “cons” side, @gusted writes in the chatroom:

FYI every few days someone will merge upstream 1.16(or whatever is stable branch) and it will be deployed. However when there is a regression or a bug it will be reverted and reported to Gitea(or 6543 or me just creates a PR for it). So I don’t think you can consider it stable in that sense.

#3

Comparison of the 1.16 branches. There is a total of 50 commits. Some of them are not labelled as expected with the CB/ prefix in the commit subject (e.g. codeberg: or refactor & fix). Some of them are commits backported ahead of time and show as duplicates.

$ git log --no-merges --oneline codeberg/codeberg-1.16...gitea/release/v1.16
7991757e6 CB/update: change text since we do allow account creation via Oauth2
2b30b126f CB/refactor: use our captcha fork
68c54d6a8 codeberg: use our captcha fork
c40d2d3e3 CB/fix: correct code for default sort type
6cf4af638 CB/bp: Explore filter
dd8c9f273 Support `hostname:port` to pass host matcher's check (#19543) (#19544)
777d7523d Prevent intermittent race in attribute reader close (#19537) (#19539)
dc03d44a8 Fix 64-bit atomic operations on 32-bit machines (#19531) (#19532)
9b00d79d0 Fix migrate release from github (#19510) (#19523)
67c4cf34c When view _Siderbar or _Footer, just display once (#19501) (#19522)
289d1f39a Prevent dangling archiver goroutine (#19516) (#19526)
e768f121d refactor & fix
ae65cbaaf CB/feat: Only show relevant repositories on explore page (!32)
957e241a6 Prevent dangling cat-file calls (goroutine alternative)
99e133b59 API: Search Issues, dont show 500 if filter result in empty list (#19244)
5471311ce CB/debug: check for second case
5c589b7de CB/debug
496475681 Provide configuration to allow camo-media proxying (#12802)
91eb05a4c CB/tmpl: Add impress to emails
7c2ef9b36 Delete related notifications on issue deletion too (#18953)
8af36e89f Fix lfs bug (#19072)
aabb9b1e6 CB/bp: Add button for issue deletion (#19032)
732d5e5a2 CB/bp: [API] Allow removing issues (#18879)
b0c45feb9 CB/revert: Do not use longtext but stay with text like gitea 1.15 for issues and comments
68d8731cd CB/feat: Simple rate limiting for issues
cbd1f3cfd CB/contrib: add opengpgkey to reserved usernames
eedc795f1 CB/design: Migrate codeberg.css into a custom theme & add codeberg-dark
9e629b1b8 CB/contrib: Remove Wontfix from Advanced label set
23da01c24 CB/tmpl: make dropdown links fitted
b73a46f61 CB/contrib: Update default labels (-wontfix +good first issue)
dc4d8e977 CB/contrib: reserve usernames about and home
ea76e01a4 CB/tmpl: Fix rebase (remove icons) + update donate link
267a22c07 CB/feat: Fix for 1.16 / Move codeberg topic model
b52d9e604 CB/ui: Revert upstream color changes to our Design
e73c680ff CB/tmpl: nav - take logo from Design kit, fix baseline
ede50b2d5 CB/feat: Targeted banners w/ repo topics (#27)
3d6b6fa62 CB/tmpl: codeberg patch: make oauth2 login invisible
4b33155e3 CB/tmpl: Codeberg banners
a300df3f7 CB/feat: Add announcement widget (#16)
8c037512c CB/tmpl: Open pages in new tab (#13) (#15)
c208c5d03 CB/tmpl: helper link to blog about mirror deactivation
d7eae2e77 CB/tmpl: link access token instructions to CB Docs
e285eea32 CB/tmpl: signup info (captcha + throwaway mail)
88b7259a5 CB/tmpl: Move Codeberg links to dropdown (#21)
def085315 CB/tmpl: template changes
95307e312 CB/feat: Hide users from explore view who have no repos
bca82ff2f CB/feat: Hide mirrors from explore view
e96b0ce84 CB/contrib: Change default label set
0768f600e CB/contrib: sync blacklist
7c5ebbb38 CB/meta: Issue template, clarify use of the repo
#4 
$ git log --no-merges --oneline codeberg/codeberg-1.17...gitea/release/v1.17
d1e53bfd7 (gitea/release/v1.17) Update notification count for non-mobile version (#20544)
fc7b5afd9 Add missing Tabs on organisation/package view (#20539)
210b096da Ensure that all unmerged files are merged when conflict checking (#20528) (#20536)
d6bc1558c Update lunny/levelqueue to prevent NPE when reads are performed after close (#20534) (#20537)
5f40152a1 CB/ui: Landingpage renovation (!35)
d48f05dfe CB/bp: Add "X-Gitea-Object-Type" header for GET `/raw/` & `/media/` API (#20438)
dbc0f1178 CB/feat: use our captcha fork
0308bf2c2 CB/tmpl: Add impress to emails
e52e605c3 CB/revert: Do not use longtext but stay with text like gitea 1.15 for issues and comments
1611c8fdd CB/feat: Simple rate limiting for issues
918abcc38 CB/design: Add custom codeberg & codeberg-dark theme
143e34858 CB/tmpl: make oauth2 login invisible
9d90929de CB/feat: Targeted banners w/ repo topics (#27)
f18528f0b CB/tmpl: Codeberg banners
be5177467 CB/feat: Add announcement widget (#16)
a29e70381 CB/tmpl: Open pages in new tab (#13) (#15)
9c1558b35 CB/tmpl: link access token instructions to CB Docs
ce86f5413 CB/tmpl: signup info (captcha + throwaway mail)
9823fda77 CB/tmpl: Add Dropdown for Codeberg links (#21)
af1100dac CB/tmpl: template changes
883b705e2 CB/feat: Only show relevant repositories on explore page (!32)
bbf1ffdc8 CB/feat: Hide users from explore view who have no repos
bc3ee9823 CB/feat: Hide mirrors from explore view
f3fe4397b CB/contrib: Change default label set
f43636e39 CB/contrib: extend reserve usernames
23ba74935 CB/meta: Issue template, clarify use of the repo
#5

After reviewing all non-gitea/upstream issues in Codeberg I did not find anything that would require a patch to the gitea codebase. Which is a good sign.

I’m still unclear about how the indivudual CB/ commits are tracked though.

#6

I browsed all Codeberg issues for which there is a matching Gitea issue in GitHub. None of them are opposed by anyone in Gitea. They are all waiting for an implementor to do the work.

All other issues that have not matching Gitea issue are either related to Codeberg pages, because the person interested in the change did not have a GitHub account (two of them) or just because it was not created yet.

#7

After today’s exploration I’m less convinced about the technical stability of Codeberg over Gitea. There is no CI and the code deployed in production is manually tested in a VM before being deployed. Which sometime leads to regressions when cherry-picking a fix that needs reverting.

In addition it seems that moving CB/ commits to the latest stable branch is essentially an ad-hoc manual process. Testing that it works as expected is also a manual process.

#8

I won’t pursue this idea further.

#9

So, in the pros and cons table the dealbreaker is basically “ad-hoc manual process”, right? You might create a CB Community issue “Automate build” with reference to this. I assume that for CB, growing bigger all the time, such automation to become more relevant. And they can dogfood Codeberg-CI for it.

1 Like
#10

Codeberg is not meant to be a codebase for someone else to use, that’s the main issue and it has various consequences, among which the lack of automation indeed. It would be worth contributing to Codeberg as you suggest if the idea of having a self-hostable Codeberg was on the roadmap. That would be the first thing to work on before implementing something to that effect, IMHO.

1 Like