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?

[ghost]

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.

[kbingham]

What's the definition of a gag feature?

[theAkito]

definition of a gag feature

Thanks for asking, I should've been clearer.

It's a feature for fun, only. It's like when Star Wars/Star Trek fans create a theme for something. It's cool & funny, but rarely anyone uses it, because it's more of a joke (something for the laughs), than an actual theme one would want to apply, since it's not about usability or something that fits the current needs & demands of the users, but about being fun.

Another example would be running Doom on a calculator. It's really fun. It's really cool. It looks cool. But nobody actually seriously plays Doom on a calculator. Even the amount of people playing actual Doom on an actual computer the way it was originally intended is far from being popular, anymore.
Still, everyone knows about this, because it's fun!

Same with this one. It's fun. I'm not "against" this, or something. I'm just saying, it's unnecessary & overhyped. It's funny, but not useful in 2022.

[aparcar]

Check out the links above about kernel development and try to decide for yourself how much of a niche use-case email workflows are

[theAkito]

Check out the links above about kernel development

😆

I really have to laugh now, because I actually was recently touching the world of kernel development and noticed how terrible e-mailed patches are. The whole system is absolutely terrible. Atrocious to the bone.

This was another reason, why I was surprised by the hype for this issue, because I was thinking about how terribly inaccessible kernel development works now. 😄

[theAkito]

That said, Kernel development is a niché.

Obviously, using a kernel is widespread, but barely any user is putting effort in Kernel development. It's a highly closed up system, where one reason for this is exactly this antiquated form of patch management.

So, it's important to not confuse usage with actual development efforts. Actual development efforts on the Linux Kernel are not done by the majority of developers. Not even close.

---

In the meantime, I have also found another fact, which supports my statements.

I don't see why accepting mailed patches should be a "sourcehut special".

Did anyone ask, why it is(was?) a "SourceHut special" to begin with?

If this feature would be so terribly useful and needed, all the hosted Git solutions would provide it. Yet, they don't, because pretty much all other modern alternatives are superior in 99% of use cases.

And even if they would start providing it, it would be a part of polishing & fleshing out Git support, rather than providing a necessary or very useful feature. It's a funny to have feature, which is almost always already superseded by other methods of patch submission or code contributions in general.

[SamWhited]

I really have to laugh now, because I actually was recently touching the world of kernel development and noticed how terrible e-mailed patches are. The whole system is absolutely terrible. Atrocious to the bone.

This was another reason, why I was surprised by the hype for this issue, because I was thinking about how terribly inaccessible kernel development works now. smile

Maybe you could explain why you don't like it so we can attempt to avoid those pitfalls if this or a similar feature ever gets developed? It may be relatively niche, but it's still quite a popular workflow (sourcehut, for example, uses it exclusively and plenty of projects other than the kernel use email based workflows). I tend to prefer it and strongly disagree with what you said, but since you didn't detail why it's hard to know if it's a legit criticism or just your personal preference. Tastes differ, naturally.

[theAkito]

Maybe you could explain why you don't like it so we can attempt to avoid those pitfalls if this or a similar feature ever gets developed?

It's not that I "dislike" or "don't like it", it's just that I don't really see a realistic point in why anyone should use it, except it is absolutely necessary, for example in an extremely restricted environment.

For example, doing any kind of patch work requires the user to get used to manually creating the diffs & make e-mailing work, etc.

If the user needs to get used to manual stuff like this, then he might as well get used to the normal process of applying a patch, like what developers use all the time.

Now, based on that, we could say, that it's not necessary to do it manually. Let's make a GUI for it. That's what usually happens. If something is too complicated on the CLI or otherwise too difficult to construct, a GUI is usually created for it.

However.... if we are going to make a GUI for it, then why do we need the e-mail patches to begin with? We already have GUIs on Git frontend platforms. We don't need a second GUI or an extended GUI for e-mail patches, because it's not necessary.

So, from what I know, there is literally no reason to ever use e-mail patches, except someone lives in a wild forest, where there is only e-mail client access for users. Otherwise, if a developer has a normal computer with a normal browser, with a fair enough internet connection, there is no objective reason to actively use e-mail patches. At least, I know of none. Maybe someone can shine some light on it, because so far I have read no significant advantage beyond "we have always done it like this" and "it's cool" and "look, the Kernel team does it, too".

It may be relatively niche, but it's still quite a popular workflow (sourcehut, for example, uses it exclusively and plenty of projects other than the kernel use email based workflows).

I don't think so, but I don't have enough data to back that thought up, so maybe you, or anyone else here, could enlighten me on that.

The SourceHut example is, in my view, as mentioned previously, backing up my statements. If SourceHut is the lone wolf doing it, there must be a catch. And the catch is, there is little to no point in using it over alternatives.

As for the other projects you hint on:
Can you name a single modern project, which uses e-mail based patches?

Not one of those dinosaur projects literally coming from a different millenium...

Is there a single modern project that actively uses e-mail patches? I doubt it.

And whether those dinosaur projects use it, does not matter, because 95% of their reasoning for using stuff like this is the reason nobody should ever use to do something:
"We have always done it like this."

As soon, as people in decision focused positions take over that argument and deem it valid, the project associated with it, will go down the drain, eventually.
Never do something, because "we have always done it like this". Else, we would still be using horses to travel the lands & landline phones for an expensive call. Or perhaps we would still be running around with spears & swords.

That said, I honestly am interested in the projects that use this workflow and perhaps even favour it over the more obvious alternatives. I really do not understand, besides "we have always done it like this". There is no other point in doing that.

I tend to prefer it and strongly disagree with what you said, but since you didn't detail why it's hard to know if it's a legit criticism or just your personal preference. Tastes differ, naturally.

Again, I do not "dislike" or "don't like" it. I am not "against" it. If this feature gets implemented, I won't break into anyone's home for it. 😄
What I'm saying is, that this issue focuses on something, that is ultimately unnecessary. It's like using a dangerous and easy to break plane from the 1900's, when you have the choice to use a modern Boeing for the same cost, which basically almost flies on its own and you don't have to constantly worry about it breaking mid-flight, essentially killing all passengers.

Any project, especially open source projects, have a limited amount of resources. The biggest & most obvious ones are developer time & money. While time is money, so actually it's all about money in our world, unfortunately.

So, if developer time is spent on this issue, it will indubitably, lack on some other issue/bug/improvement/whatever. It's simply logical, that this will happen & it cannot be avoided without magic.

Which basically leads me to my final point in this explanation.

I am not "against" it. I think your reasons are understandable, from a human perspective.

All I am trying to do is to lessen the hype about this & pointing out, how this feature extension is not really necessary, especially when you look at the cost/performance ratio.

Even more so, when I look at quotes like these.

Rather than just enabling email one way, how would you feel about making it a first class citizen in the UI?

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/.

Like what? 🤔

The first one would be a huge change taking tons of resources (correct me if I'm wrong) for essentially no real improvement.

The second one is simply not reflecting reality. It ain't a big deal. It's far away from a "big deal". It doesn't matter. Else, you would see this feature all over the Git world. Yet, you don't. Because, honestly, nobody (as in, by far the most developers) cares. (Bringing back the point about SourceHut being the only provider... Yes, because it's not like this is a super demanded feature.)

I do not want developers using up their resources on something, that is essentially very unnecessary, when they at the same time could (looking at the amazing Gitea developers; great people with great work!) improve Gitea performance, UX, etc. I have tons of UX improvements for Gitea, for example. I think, they matter like 100 million times more than some weird fringe feature, most developers don't care about. Perhaps, they don't even know about it....

P.S.:

I feel like I have to emphasize this, so people don't hate me for "hating" when I actually just try to explain a different view on the topic:

I do not "dislike" this. I do not "not like" it. It's just a waste of energy and I'm trying to point that out.

I could imagine this being created as a plugin by a third party, that would otherwise not do any development on the core Gitea project, in the first place. Then, we don't "lose" core maintainer time over this.

[theAkito]

Fun fact:

"We have always done it like this." has brought us the QWERTY keyboard layout, which is essentially a very bad one. However, "we have always done it like this", because of typewriters.

Now, the whole world is stuck with some crappy QWERTY-derived layout, which does not make sense for any language. It only makes sense on typewriters.

If people wouldn't have thought "we have always done it like this", everyone would use DVORAK, Colemak, Workman or even Neo2, which are objectively superior layouts. Yet, barely anyone uses them, because the QWERTY virus is spread all over the world.

Legacy IP & IP is another example like that. We shouldn't even be using Legacy IP anymore, at all, except in very rare circumstances. We should only be using IP. And the fact, that you are asking yourself right now, whether "IP" is supposed to be "IPv6" proves my point!

HTML is another example, which is absolutely enraging.

There are plenty of examples like these and I have just one thing to say to whoever supports the old ways:

It's time to move on.

---

Using an inferior method of doing something voluntarily is not a matter of personal preference. It's a matter of not willing to accommodate to the usage of something better.

A method is "inferior" if it has worse performance for the same cost or if the cost/performance ratio is generally comparatively bad.

In this specific case of submitting Git patches, there is no real advantage in using e-mail patches over what we have & do now.

[tecosaur]

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.

This is simply not accurate. You might say that in your own (limited?) usage, you have not found mailing list development to work well, but you seem to be mixing personal taste and general truths.

Mailing lists allow for an alternate development workflow, which is arguably cumbersome without good tools (I'd hate to try this using Outlook as my email client), but that offers a number of advantages compared to PR-based development, such as the ability to mix discussion and code: e.g. Someone asks if a feature would be a good idea, the community discusses it, someone produces a patch, the patch is reviewed, etc. all within the same thread. Here's an example of a this sort of thing happening with a bug report:

With good tools, mailing-list development can end up being more convenient than web forges. However, quite a few people (like yourself!) are put off by the idea of using a mailing list. Hence, this is why having a forge that supports both modes of development at once is (to quote past me) "a big deal".

If you were actually interested in finding more out about mailing list development, rather than just spewing "lol, email? so outdated" into this issue, there are numerous writings on this you could have looked at, e.g.:

• https://web.archive.org/web/20180522180815/https://dpc.pw/blog/2017/08/youre-using-git-wrong/
• https://drewdevault.com/2018/07/02/Email-driven-git.html
• https://begriffs.com/posts/2018-06-05-mailing-list-vs-github.html

Just because you can't see the value doesn't mean there isn't any.

I'll also note that while the LKML is most often raised as a prime example of Mailing-list development, there are plenty of other large FOSS projects actively developed this way, e.g.

• Nginx
• Most Apache projects (e.g. Cassandra, Arrow, Apache HTTP server, etc.)
• Git itself
• Most GNU projects (e.g. GCC, Ghostscript, Coreutils, Guile, Guix, Nano, Octave, ...)
• LibreOffice
• Xen
• The R programming language
• and more...

[techknowlogick]

While I do appreciate the discussion on this topic, I'm temporarily locking the issue. I think there are pros/cons to this and a lot if those details have been captured.