Contribute to projects on proprietary forges #607

Open
opened 2 months ago by fnetX · 4 comments
fnetX commented 2 months ago
Collaborator

During the Codeberg hackathon, I was made aware that this idea was only propagated via voice and never actually written down, so let's do it now:

We had the idea to create a bot that allows users of Codeberg (or other Gitea instances) to create issues and PRs on proprietary forges. While Gitea is working on federation, it's unlikely that they'll participate soon.

  • fork an upstream project to a repo on Gitea instance
  • create an issue or PR there (local branches etc)
  • mention @codebergforgeforwarderbotservicethingy or some shorter more intuitive name
  • specify metadata in a machine-readable format (e.g. just put the URL of the upstream project after the mention)
  • the pull request is forwarded upstream using a codeberg-owned user / bot with the content created downstream, and ideally a nice description alike "Hey, some people don't want to join your proprietary walled garden. You normally miss contributions from those people, but we were so nice to forward them to you here ..." (let's fine-tune this later :D)
  • content is bidirectionally mirrored, mentions of the codeberg bot are turned into mentions of the downstream user, labels, comments etc are mirrored, too

Note that this approach shifts the responsibility of allowing more submissions from the projects (set up mirror etc) to the user (quickly contribute to any project from your home instance without the need to permanently mirror the whole project)

During the Codeberg hackathon, I was made aware that this idea was only propagated via voice and never actually written down, so let's do it now: We had the idea to create a bot that allows users of Codeberg (or other Gitea instances) to create issues and PRs on proprietary forges. While Gitea is working on federation, it's unlikely that they'll participate soon. - fork an upstream project to a repo on Gitea instance - create an issue or PR there (local branches etc) - mention @codebergforgeforwarderbotservicethingy or some shorter more intuitive name - specify metadata in a machine-readable format (e.g. just put the URL of the upstream project after the mention) - the pull request is forwarded upstream using a codeberg-owned user / bot with the content created downstream, and ideally a nice description alike "Hey, some people don't want to join your proprietary walled garden. You normally miss contributions from those people, but we were so nice to forward them to you here ..." (let's fine-tune this later :D) - content is bidirectionally mirrored, mentions of the codeberg bot are turned into mentions of the downstream user, labels, comments etc are mirrored, too Note that this approach shifts the responsibility of allowing more submissions from the projects (set up mirror etc) to the user (quickly contribute to any project from your home instance without the need to permanently mirror the whole project)
fnetX added the
enhancement
contribution welcome
service
codeberg
labels 2 months ago
fnetX changed title from Send PRs to proprietary forges to Contribute to proprietary forges 2 months ago

It is a great idea and, IMHO, complementary to the long term efforts towards federation. Its main benefit would be to spread the idea that remote pull requests are possible and desirable with actual examples.

In the context of the https://forgefriends.org project we did something similar but with a human being instead of a bot. Here are a few examples:

There are more at singuliere and realaravinth and it documents the problems and solutions that were found.

It is a great idea and, IMHO, complementary to the long term efforts towards federation. Its main benefit would be to spread the idea that **remote pull requests are possible and desirable with actual examples**. In the context of the https://forgefriends.org project we did something similar but with a human being instead of a bot. Here are a few examples: * https://github.com/go-gitea/gitea/pull/18124 & https://lab.forgefriends.org/forgefriends/forgefriends/-/merge_requests/30 * https://github.com/go-gitea/gitea/pull/18203 & https://lab.forgefriends.org/forgefriends/forgefriends/-/merge_requests/32 There are more at [singuliere](https://github.com/go-gitea/gitea/pulls?q=is%3Apr+author%3Asinguliere+is%3Aclosed) and [realaravinth](https://github.com/go-gitea/gitea/pulls?q=is%3Apr+author%3Arealaravinth+is%3Aclosed) and it documents the problems and solutions that were found.

If the developer issuing the pull request already has a ProprietaryForge account, the PR could be relayed on his/her behalf by the bot. There would not be a need for a shared / proxy account managed by the bot. Such a shared / proxied account is problematic because it would be complicated or sometime impossible for the user to claim ownership of their PR on ProprietaryForge at a later time.

If the developer issuing the pull request already has a **ProprietaryForge** account, the PR could be relayed on his/her behalf by the bot. There would not be a need for a shared / proxy account managed by the bot. Such a shared / proxied account is problematic because it would be complicated or sometime impossible for the user to claim ownership of their PR on **ProprietaryForge** at a later time.
fnetX changed title from Contribute to proprietary forges to Contribute to projects on proprietary forges 2 months ago

If the developer issuing the pull request already has a ProprietaryForge account, the PR could be relayed on his/her behalf by the bot. There would not be a need for a shared / proxy account managed by the bot.

Such a bot would actually work much better if implemented client side (i.e., from JavaScript in the browser). GitHub, GitLab, BitBucket and gitea all have a REST API that should be rich enough to support implementing this.

Such a shared / proxied account is problematic because it would be complicated or sometime impossible for the user to claim ownership of their PR on ProprietaryForge at a later time.

You could always sign your git commits.

> If the developer issuing the pull request already has a **ProprietaryForge** account, the PR could be relayed on his/her behalf by the bot. There would not be a need for a shared / proxy account managed by the bot. Such a bot would actually work much better if implemented client side (i.e., from JavaScript in the browser). GitHub, GitLab, BitBucket and gitea all have a REST API that should be rich enough to support implementing this. > Such a shared / proxied account is problematic because it would be complicated or sometime impossible for the user to claim ownership of their PR on **ProprietaryForge** at a later time. You could always sign your git commits.

I would like to mention that ForgeFlux(disclosure: I'm one of the core devs) is involved in implementing software forge federation external to the forge. Implementing federation for Gitea, Sourcehut, GitLab and GitHub is part of the project's objective --- very similar to the requirements mentioned by @fnetX.

We felt that native federation on software forges will take time to implement as all forge developers will have to be convinced to participate. But implementing federation entirely using the forge's API can be implemented independently without the forge developers' involvement.

So far, we are close to federating issues on Gitea(Gitea issues can be viewed on compatible ActivityPub implementations like Pelorma) and we plan to start work on GitHub as soon as we get Gitea working.

User experience wise, foreign users will be able to send contributions via a bot account on the native forge and foreign repositories will be synchronized under a bot account namespace in the local forge.

Federated contribution workflow

So if a foreign contributor is interested in contributing to a project in another forge, the following process will take place:

  1. Contributor requests synchronization of upstream repository

  2. ForgeFlux software synchronizes upstream repository under a bot account

  3. Contributor forks and creates PR against synchronized, bot account owned repository

  4. ForgeFlux will synchronize the PR on upstream forge

  5. If upstream maintainers give feedback on PR, ForgeFlux will synchronize comments

  6. If PR is good and upstream maintainers satisfied, they can merge the PR. ForgeFlux will close the contributor's PR on the contributor's forge, do git pull upstream and update bot-owned repository on the contributor forge

I would like to mention that [ForgeFlux](https://forgeflux.org)_(disclosure: I'm one of the core devs)_ is involved in implementing software forge federation external to the forge. Implementing federation for Gitea, Sourcehut, GitLab and GitHub is part of the project's objective --- very similar to the requirements mentioned by @fnetX. We felt that native federation on software forges will take time to implement as all forge developers will have to be convinced to participate. But implementing federation entirely using the forge's API can be implemented independently without the forge developers' involvement. So far, we are close to federating issues on Gitea(Gitea issues can be viewed on compatible ActivityPub implementations like Pelorma) and we plan to start work on GitHub as soon as we get Gitea working. User experience wise, foreign users will be able to send contributions via a bot account on the native forge and foreign repositories will be synchronized under a bot account namespace in the local forge. ## Federated contribution workflow So if a foreign contributor is interested in contributing to a project in another forge, the following process will take place: 1. Contributor requests synchronization of upstream repository 2. ForgeFlux software synchronizes upstream repository under a bot account 3. Contributor forks and creates PR against synchronized, bot account owned repository 4. ForgeFlux will synchronize the PR on upstream forge 5. If upstream maintainers give feedback on PR, ForgeFlux will synchronize comments 6. If PR is good and upstream maintainers satisfied, they can merge the PR. ForgeFlux will close the contributor's PR on the contributor's forge, do `git pull upstream` and update bot-owned repository on the contributor forge
Sign in to join this conversation.
No Milestone
No Assignees
4 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.