Hi Stefan, 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.Schindelin@xxxxxx> 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 message). 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 bot framework? 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. Ciao, Dscho -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
