Re: Migrate away from vger to GitHub or (on-premise) GitLab?

(Disclaimer that I’m relatively inexperienced with this project workflow)

My impression is that the email workflow is very flexible and tool-agnostic.[1] On the other hand it’s hard to get set up in a way that makes contributing to a project as easy as contributing to a project that is hosted on GitHub.[2]

† 1: Konstantin’s reply here seems to confirm this. And thanks by the
    way for all your emails on this workflow subject, which I always
    enjoy reading. And for your work on tooling that of course other
    email-based projects than Linux can use.
† 2: With the assumption that you already have an account there

What would really “sell” the email workflow would be to have some sort of program which can set everything up for you so that you can track your contributions as easily as a PR on GitHub. Of course people use all kinds of different platforms, but let’s say that it only was for the latest Mac OS (this is all hypothetical anyway). All you would need to do was to give your email credentials and whatever other technical email things that are required. Just install one program and track all your patches as well as the replies on them. More concretely: maybe it would have an email client which would make sure that all your outgoing emails are done correctly. Including things like not mangling patches in your reply because of hard-wrapping or something. (I created a support ticket for that on Fastmail yesterday.) Or: let you immediately inline a “scissor lines” patch into your current message based on a commit or just your current working tree.[3]

Also: never having to copy–paste message ids manually. :)

(Again, all hypothetical for the sake of the argument)

This program could be very opinionated and dictate a very rigid workflow; the point would be that there *is* a way to have a setup which is as easy as GitHub (modulo email credentials/technical things). Because then if you want to customize your workflow you are still totally free to put together your own tools just like what apparently many people do right now.

If this was even just hypothetically possible—I dunno—then that would be a strong argument in favor of this kind of project workflow.

I think that would be the best of both worlds.

† 3: That also sounds more convenient than pushing to a GitHub repo. in
    order to make a PR