Yeah I think we need some way to handle that. Personally I do not mind
receiving patches via Email. Most of my daily workflow evolves around
email. Such as reading these threads that are just mails in my inbox.
Just like another other mailinglist or GitHub Repo that I am following.
A few of my friends do not ever want to have a GitHub account
(especially after the recent acquisitions) and thus rather submit
throught me or via some ML.
It probably goes a bit too far for our topic here but there is also
discussions around how to modernize the entire mail based workflow
without having a vendor lock-in over on the public-inbox ML [1].
Unfortunately, that discussion didn’t go far.
I was also thinking about hosting a patchwork [2][3] instance for this
kind of activity. While I can certainly do some work around accepting
patches (and translating them into PRS & commits) I wouldn’t start this
without a few more comitters that are willing to help out.
The workflow around that kind of ML archive (unless you have all the
mail locally) could look similar to this:
# create a new branch
nixpkgs/ $ git checkout -b some-patch origin/master
# apply the patch (series)
nixpkgs/ $ git am < $(curl https://something/patch/123/mbox/)
# review & test
nixpkgs/ $ git log / tig / nix-build …
This really isn’t that much different from checking out a PR (minus
being on the right commit when you apply the series).
Afterwards you can just open a PR or commit as usual or simply reply to
those patches via Email if you want to request changes / provide
feedback.
The big problem here is probably not sovling this (patch receiving &
applying) technically but how to handle feedback and CI results in those
cases. As we are pretty much stuck on GH right now. The troubles here
could be that you first argue with the submitter via E-Mail, do multiple
iterations of patches until everyone is happt. Afterwards you put that
PR up on GH and then some more feedback arrives. It would probably not
be great if those that accept that patches then have the burden of
synchronzing between GH and responding to feedback. GH doesn’t even
allow unregistered users to subscribe to updates on a PR/issue.
On the other hand, if the patches we are receiving via Email are usually
small, self-contained and do not cause long dicussions then I don’t see
why this wouldn’t work.
[1] RFC: Using public-inbox v2 repos for distributed patch lifecycle tracking - Konstantin Ryabitsev
[2] patchwork
[3] https://lore.kernel.org/patchwork/project/lkml/list/