just quickly (i.e. addressing only one point, will try to address more at
a later date) because I want to be mostly offline this weekend:
On Fri, 5 Aug 2016, Stefan Beller wrote:
> On Fri, Aug 5, 2016 at 1:20 AM, Johannes Schindelin
> <johannes.schinde...@gmx.de> wrote:
> > I also hate to break it to you that git-send-email is not going to be
> > part of any solution.
> It's written in perl, so it's not one of the core parts of Git that you
> mentioned above. I do use it though for my submission process.
The problem is not Perl, but how fiddly it is to set up. And that you lose
all the niceties of an email client (e.g. when you want to add a comment
before the diff stat that is not intended to become a part of the commit
But I had an apostrophe last night. I might have been a bit overzealous to
claim that git-send-email won't be a part of the solution. It cannot be
a *user-visible* part of any solution, that still holds true.
So here is the apostrophe: why not implement a bot that listens to the PRs
on GitHub, and accepts commands such as "@<whatever>bot please send this
upstream" via comments on the PR. It would then send the patches to the
list, from its own email address, on behalf of the contributor.
Lots of things to kink out, such as: does it need to be moderated? Record
what was submitted in its own git.git fork? Accept replies and attach them
to the correct PR? Maybe annotate those replies with the commits whose
patches were discussed? Maybe send out replies on the PR as emails? Maybe
try to auto-apply suggested patches? Cc: people who commented on earlier
iterations of the patch series? Maybe make interaction smarter using an AI
If only I had lots of time on my hand, I'd start by prototyping a node.js
server and hooking it up via webhooks, then show it off so others can
tinker with it.
This is not completely unlike submitGit, which was a good first attempt,
but I never used it because I needed it to do so much more than it already
did, *and* it complicated everything by requiring users to register with
an extra step to allow submitGit to send email on their behalf. It also
made contributing to it harder by choosing some non-standard web app
framework. Also, I really do not like having to go to a different website
just to send a GitHub PR to the list.
Anyway, that was my brain fart for the day.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html