DRAFT: Fedeproxy is written in Go to share code with Gitea

[dachary]

@aschrijver

I think I understand now.

Your feedback is invaluable: when I wrote the initial version I completely failed to communicate what I intended. We’re getting close although there still are significant differences between what you reworded and what I intended to convey.

@aschrijver

The FedeProxy fork (which could technically also be a Gitea branch if it wouldn’t have to address broader requirements for other forges) will gradually “meld” anything purely Gitea-related up to the point where Gitea has native “federation support”.

Well put.

@aschrijver

At that point the FedeProxy Golang codebase will take on a life of its own, and become a more independent app that supports ever more forges and is installed side-by-side to them (like in the case of Gitlab).

The fedeproxy codebase has a life of its own from the very beginning (i.e. October 2021). It replaces the current codebase entirely and will support Gitea and GitLab, as the current codebase does. Since it is written in Go and includes all the Gitea codebase, supporting Gitea will be easier. But in both cases fedeproxy will communicate with the forge via the API and will be installed side-by-side to them.

In other words the following happen in parallel, not in sequence:

• Implementation of the fedeproxy server as a service that runs side-by-side an existing Gitea or GitLab instance
• Contributions from the fedeproxy codebase to the Gitea codebase to further federation
• Merge from the Gitea codebase into the fedeproxy codebase to benefit from the work done by the Gitea developers regarding federation (and other parts of the code that is common)

@aschrijver

When project “independence stage” is reached you may still incorporate Gitea code, but less frequently and there’s no need for the high-effort syncing anymore

Exactly: over time the parts that are common to Gitea and fedeproxy will be identical, as a library would.

@aschrijver

Similarly Gitea from then on will evolve their own federation capability on their own, now based on mature standard specifications that evolve too.

Yes, although “then on” suggests a sequence of event. It really happens all in parallel. Fedeproxy make progress at its own pace. And Gitea has its own development lifecycle happening at the same time.

@aschrijver

If I am on the right track in my line of thinking, then eventually you’ll want to strip, rather than carry the ballast of ‘dead code’.

I concur. Initially though (i.e. for the next few years) I think stripping would make things more difficult than carrying the entire Gitea codebase.