Support receiving patches via e-mail

[stevenroose]

I recently heard that SourceHut and/or Gitlab have a feature where each repo has a project-specific e-mail address where someone can send a .patch file to in order to open a pull-request. This would not require contributors to create an account in order to contribute.

This is kinda in parallel to #184, as it's also about federation, but not really full federation between instances, just using e-mail and git in their already "federated" context.

Ideally, this would

• assign a project-specific e-mail address
• allow incoming e-mail with a .patch file as attachment and publish that as a PR
• reply to that e-mail with some unique identifier so that this user can somehow post new .patch files to update the PR

[lunny]

But we still need the email has been registered on this instance?

[stevenroose]

No the idea is that users don't have to register in order to submit patches. F.e. on a single-user instance, which I think is an important use case, one shouldn't want anyone to register, but everyone to be able to interact via e-mail.

[Seirdy]

This also would allow users to use the same workflow that they use with standard git repos. In many setups, users clone the upstream repo, make their changes, and then email a patch to a mailing list. A maintainer reviews the patch (replying with suggested changes if necessary) and applies it if it looks good.

Git is designed for this workflow; git will automatically draft an email, fill out the subject and recipient, optionally let you add a message body in your $EDITOR and send it so you don’t even have to open your mail client. There’s a reason why git uses email addresses to label commit authors!

This flow is much easier than creating an account for a gitea instance, forking a repo, cloning your fork, checking out a branch, making your commits, and finally filling out a web form to merge them upstream.

This flow can be implemented step-by-step:

1. Allow the option to create a PR from a patch generated by git format-patch, if users prefer that over creating and cloning a fork.
2. In email notifications for new PRs, attach the patch to the email as if it was sent by git send-email so the maintainer can apply the patch like they normally would.
3. Allow users to reply to notification emails and have those replies show up in the web interface. GitHub already does this.
4. Allow creating PRs by sending an email using git send-email

If these four steps are completed, Gitea repos will support both GitHub-style PRs and the standard email flow used by projects such as Linux, ffmpeg, all the projects on Sourcehut.

I'll make issues for these if they don't already exist.

[wULLSnpAXbWZGYDYyhWTKKspEQoaYxXyhoisqHf]

this would require a mailing list software already in place, wouldn't it?
or is the idea to integrate it fully into Gitea? @stevenroose

[6543]

I think the best way woul be if email server is a seperate deamon(s) (e.g Postfix and Dovecot), and gitea has an accout witch is checked by gitea's cron job via pop3/imap.

[tecosaur]

Just wanted to chime in to express my interest in this feature. In my opinion, this is a big deal for https://docs.gitea.io/en-us/comparison/. I don't see why accepting mailed patches should be a "sourcehut special".

In addition, this has the potential to suddenly make gitea a viable home for some large patch-based projects.
This seems like something gitea could be proud of.

Patch acception seems to already be coming in #10007, accepting with email seems like a logical next step, and could proceed some really nifty features like making CI available to patch mailing lists.

[tfardet]

I'm also very interested in email-related features, but I would propose to take it a bit further.
I'm not sure this is the right place for a discussion about this, so tell me if you'd rather have me open another issue about this.

TL;DR: enable email-based federation for PRs in the UI (may benefit from discussion about possible overlap with work on ActivityPub-based federation)

Details

Rather than just enabling email one way, how would you feel about making it a first class citizen in the UI?
Since Gitea probably already runs everything that's required to both send or receive emails via/from git send-email so I don't think anything additional would be required on the server.

As mentioned, one would need an email address associated to each project.

Then, when creating a PR, the UI could provide the option to target an email address rather than pick a local target branch.
This would enable Gitea to federate PRs across Gitea servers but also with other forges using email-based workflows.

Maybe naively, I don't think it would require a lot more work compared to supporting patches from emails but it would enable users that do not know how to use email-based workflows (or just don't like it) to interact easily with these forges.

[lunny]

Maybe we can create a email proxy user, all PRs from emails could be counted as this user but attach the original author's email address in every PR or commit

[ktprograms]

If the plan is to support mirroring comments on PRs to/from the web UI and email, you'll probably need to figure out how to properly support bottom-posting, to not overly annoy the users on the email side?

The mailing list for patch should be independent of PR, because their habits are different.

Some suggestion:

• General email guide for kernel development: https://www.kernel.org/doc/html/latest/process/email-clients.html
• Use plain text: https://useplaintext.email
• https://git-send-email.io

[theAkito]

Since seemingly so many people are in favour of this feature, I'd like to add a different perspective on this.

I think, it is not expedient to support such an antiquated feature. It arose from a time, when mailing lists were common & a lot of functionality on the internet went through e-mail technology.

It's a comparatively cumbersome feature, which does not complement or even replace the existing features to apply pull requests or patches or anything like that.
It's simply an alternative, which is only there, due to historical reasons.

I'm also a bit surprised how this feature is so much hyped up by some. This isn't anything special or useful. It's just something that people were doing back then, because they lacked the resources & technology to do better. Which we have & do now.

While I'm not against additional features, adding features can add issues, too. There is more to be maintained, fixed, make work with other features, etc. I don't see how maintaining this feature adds significant value to Gitea as a product.
It's a nice gag feature.

I'm sure there's a tiny niche using this, but I'm not sure if that is worth the effort.

This is a different view on the issue, which I made public, because I was a bit surprised by the support & hype around it, even though it evolved basically into a gag feature, over the decades.