Forge pull/merge requests bi-directional sync

[Robin Jarry]

Hi folks,

I am a strong advocate of the email based contribution workflow for open
source projects (and closed source projects as well, for what it's
worth). One of the de-facto helper tools for the email based workflow
has been patchwork for numerous years. It is used by major open source
projects (such as Linux, Git, DPDK, QEMU, OpenvSwitch, etc.).

On the other hand, we now live in a world dominated by code forges which
only allow the pull request workflow.

My intent is certainly not to start a debate in order to settle which
workflow is the best. Each has its advantages and drawbacks and in the
end it really falls back on personal preference and technical
background.

The point of this email is to find a way to unify both of these
paradigms and allow users on each side of the fence to work together
using the tool/platform of their choice.

At this point, I am only aware of one single project that implements
partial sync between GitHub and mailing lists (both maintainers Cc'd):

https://github.com/gitgitgadget/gitgitgadget

TL;DR for users that do not know this project:

* Pull requests created can be transformed as patches (or patch series)
  sent on a mailing list via a special /submit comment.

* Replies to the generated emails are mirrored on GitHub as comments on
  the pull request.

* After updating the pull request branch (either by adding new commits
  or by push --force), a respin (v2, v3, etc.) can be sent to the
  mailing list.

Unfortunately, it has some limitations:

1) Replies to comments are not be posted back to the mailing list.
   GitHub users are required to use a mixed workflow where they need to
   respond to comments using email.

   Pathological example:
   https://github.com/git/git/pull/1750#discussion_r1688684569

2) Patches sent on the mailing list are not converted to pull requests.
   This makes GitHub users second class citizens as they cannot follow
   the development via GitHub.

   That second point is crucial in unifying both workflows.

3) This project is GitHub specific and cannot be reused for any other
   forge (GitLab, Codeberg, Pagure, etc.)

I was wondering if Patchwork could be leveraged as a bridge between
these two worlds to help gitgitgadget (and possibly other tools)
implementing total and bi-directional synchronization between mailing
lists and code forges.

Patchwork already exposes events which could be reused to trigger
updates on GitHub (e.g. create new pull requests):

https://patchwork.readthedocs.io/en/latest/api/rest/schemas/v1.3/#get--api-1.3-events

As a matter of fact, lots of the patchwork API could be used as an entry
point for gitgitgadget and reduce the amount of raw email parsing.

I'd like to know if that is something people would be interested in and
what could be done to help make it happen.

Cheers,

-- 
Robin

> Causes moderate eye irritation.