I am afraid still not clear enough. But it may be because I am insufficiently in the loop of project objectives and scope. What I think / deduced:
- What: Federated issue management (MVP?)
- How: Standard protocol and vocabulary (data format)
- Where: Forge-specific implementations (?), starting with Gitea (Golang)
Gitea is fully committed to adding federation support, which is great. What purpose serves a full fork that you need to keep in sync and where FedeProxy federation has subtle differences with Gitea federation?
I would understand this fork if FedeProxy were an independently installed application that you deploy side-by-side with a forge product and which communicates via API’s. Then nothing will dissolve over time, however. But this would make sense to me: you bootstrap with Gitea, strip what you do not need, and build upon what remains. It would also allow a self-hosted FedeProxy-only instance (in the sort of forge-specific Ports & remote Adapters architecture we discussed some time ago). It would be a reference implementation where best-practices for protocol and vocabulary is used and with full documentation and tests accompanying it.
In this setup the “where” would be:
- Where: FedeProxy module, independently installable, optionally self-hostable (and reference impl. for forge devs)
Another reason for a fork (with the original “where”) might be that the MVP of Gitea would be different in requirements and use cases than the MVP of ForgeFed while protocol and vocab are evolving, but would ultimately be integrated into Gitea, after which Forgefed ‘dissolves’ their Golang impl. and move on to the next forge federation support quest.