(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
--
Kristoffer Haugsbakk
