Re: patch submission process, was Re: [PATCH v6 06/16] merge_recursive: abort properly upon errors

[Lars Schneider <larsxschneider@gmail.com>]

> On 06 Aug 2016, at 10:58, Johannes Schindelin <johannes.schindelin@gmx.de> wrote:
> 
> 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@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
> 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.

Great discussion! I would like to share my perspective a someone who is
a (relatively speaking) new Git contributor and who has never interacted
on mailing lists before Git:

1.) "git format-patch" and "git send-email" work great for me. It took some
    time to learn how they work but now I have my own "submit.sh" based
    on those tools and posting a new series is a piece of cake.

2.) Initially it was hard for me to ensure that my patches don't break build or 
    tests on Linux and OS X. Travis CI helps me a lot. I just wished we could
    get Windows support, too.

3.) I noticed that I get two types of reviews. The first kind points out things
    in my patch that are obviously wrong. The second kind are things that require
    a discussion. When I get feedback of the first kind, then I am always super
    eager to send out a new roll just because I don't want any other reviewer
    to waste time on obviously wrong patches. However, I have the impression
    that frequent re-rolls are frowned upon. If we would use Git for the patches
    instead of email, then I could add "squash" patches to indicate changes in
    the current roll that will be squashed in the next roll (I know I could
    send squash patches as email, too... but for me that gets confusing quickly).

4.) Reviewing patches is super hard for me because my email client does not
    support patch color highlighting and I can't easily expand context or look at
    the history of code touched by the patch (e.g via git blame). I tried to setup
    Alpine but I wasn't happy with the interface either. I like patches with a GitHub
    URL for review but then I need to find the right line in the original email to
    write a comment.

Again, this is just my point of view as a "newbie" and I definitively don't expect
the Git community to change their established workflows.

Cheers,
Lars