Add "federated projects" #3129

New Issue

GiteaMirror · 2025-11-02T05:01:32-06:00

GiteaMirror commented

2025-11-02 05:01:32 -06:00

Originally created by @SoniEx2 on GitHub (Apr 2, 2019).

Gitea version (or commit ref):
Git version:
Operating system:
Database (use [x]):
- PostgreSQL
- MySQL
- MSSQL
- SQLite
Can you reproduce the bug at https://try.gitea.io:
- Yes (provide example URL)
- No
- Not relevant
Log gist:

Description

Hi! It would be extremely cool if gitea had decentralized projects. A project is a collection of repos/branches that share commits. Projects don't care who originally created them, and repos/branches are shown in update order. Additionally, a project could have a shared issue tracker (this may use ActivityPub), but that's outside the scope of this proposal.

Projects are created from a commit, and while this does contain authorship information, it's not attached to any specific repo. This is a very useful property.

Due to being that lightweight, a project federates as a simple commit. Additionally, the issues also federate. This means projects transcend social structures, which means a BDFL can't just say an arbitrary set of issues don't belong in the issue tracker.

This would be a HUGE win for decentralized development. Additionally, and especially for big projects with a lot of momentum, this would encourage new developers to participate, as they wouldn't feel like anything they attempt to contribute will go unseen/unused.

Screenshots

Originally created by @SoniEx2 on GitHub (Apr 2, 2019).   - Gitea version (or commit ref): - Git version: - Operating system: - Database (use `[x]`): - [ ] PostgreSQL - [ ] MySQL - [ ] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [ ] No - [ ] Not relevant - Log gist: ## Description Hi! It would be extremely cool if gitea had decentralized projects. A project is a collection of repos/branches that share commits. Projects don't care who originally created them, and repos/branches are shown in update order. Additionally, a project could have a shared issue tracker (this may use ActivityPub), but that's outside the scope of this proposal. Projects are created from a commit, and while this does contain authorship information, it's not attached to any specific repo. This is a very useful property. Due to being that lightweight, a project federates as a simple commit. Additionally, the issues also federate. This means projects transcend social structures, which means a BDFL can't just say an arbitrary set of issues don't belong in the issue tracker. This would be a HUGE win for decentralized development. Additionally, and especially for big projects with a lot of momentum, this would encourage new developers to participate, as they wouldn't feel like anything they attempt to contribute will go unseen/unused. ## Screenshots

GiteaMirror added the issue/duplicate label 2025-11-02 05:01:32 -06:00

GiteaMirror closed this issue

2025-11-02 05:01:32 -06:00

GiteaMirror commented

2025-11-02 05:01:33 -06:00

@techknowlogick commented on GitHub (Apr 2, 2019):

Federation is duplicate of #184.

For multiple proposals please open multiple tickets so they could be tracked independently of one another.

@techknowlogick commented on GitHub (Apr 2, 2019): Federation is duplicate of #184. For multiple proposals please open multiple tickets so they could be tracked independently of one another.

GiteaMirror commented

2025-11-02 05:01:33 -06:00

@SoniEx2 commented on GitHub (Apr 2, 2019):

It's not multiple proposals, it's one proposal with multiple factors. It can't be tracked independently because the proposal also takes the protocol into account and the protocol is useless without the proposal.

@SoniEx2 commented on GitHub (Apr 2, 2019): It's not multiple proposals, it's one proposal with multiple factors. It can't be tracked independently because the proposal also takes the protocol into account and the protocol is useless without the proposal.

GiteaMirror commented

2025-11-02 05:01:33 -06:00

@SoniEx2 commented on GitHub (Apr 2, 2019):

kinda ironic that a proposal somewhat focused on having issues be wide open gets closed.

@SoniEx2 commented on GitHub (Apr 2, 2019): kinda ironic that a proposal somewhat focused on having issues be wide open gets closed.

GiteaMirror referenced this issue

2025-11-02 12:19:03 -06:00

[PR #3130] [MERGED] Fix compile failed without gcc #16784

Sign in to join this conversation.