Re: What's cooking in git.git (Aug 2017, #05; Tue, 22)

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Sep 19, 2017, 16:20 UTC
Message-ID: <20170919162035.GB75068@aiede.mtv.corp.google.com>
In-Reply-To: <alpine.DEB.2.21.1.1709191733450.219280@virtualbox>

Johannes Schindelin wrote:

Show 7 quoted lines

> What you need is a tool to aggregate this information, to help working
> with it, to manage the project, and to be updated automatically. And to
> publish this information continuously, without costing you extra effort.
>
> I understand that you started before GitHub existed, and before GitHub was
> an option, the script-generated What's cooking mail was the best you could
> do.

On second reading, I think you're talking about GitHub's code review ("pull request") feature, not a bug tracker.

There's been some active work (some that you've been involved in, I believe) on getting information from a GitHub pull request to the mailing list. One possibility would be to get information to also go in the other direction, so people have information about what happened to their patch in one place.

I can also see why you are directing your attention to the maintainer for this one, since if the entire project adopts the GitHub Pull Request workflow, then the complexity and other flaws of such a two-way sync could be avoided.

Unfortunately the maintainer is not the only person you'd need to convince. You'd also need to convince patch authors and reviewers to move to the new workflow. There are likely some potential contributors that this would bring in, that would like to get involved in the Git project but had been deterred by e.g. the mailing list's aggressive filtering of any email with an HTML part. Meanwhile it would also be a large adjustment for existing contributors, so it's not risk free.

I personally like how Bazel[1] handles this. They have two ways to contribute:

 A. People used to GitHub can use a pull request like they are
    accustomed to.

 B. People preferring a more structured code review can use Gerrit.

Having only two ways to contribute means that the code review information is still easy to archive and search, just like our mailing list archive.

(Actually, an example I like even more is Akaros[2], which also appears to accept patch contributions by email.)

Adding new ways for a contributor to submit a patch would mean that we can experiment with new workflows without getting in the way of people using an existing one.

Thoughts? Jonathan

[1] https://bazel.build/contributing.html [2] https://groups.google.com/forum/#!forum/akaros