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

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Sep 29, 2017, 12:15 UTC
Message-ID: <alpine.DEB.2.21.1.1709291402440.40514@virtualbox>
In-Reply-To: <905a4adf-a6bd-7484-f81c-0381f7200cfc@suse.de>

Hi Nicolas,

On Tue, 19 Sep 2017, Nicolas Morey-Chaisemartin wrote:

Show 27 quoted lines

> Le 19/09/2017 à 17:43, Johannes Schindelin a écrit :
> >
> > C'mon, don't *try* to misunderstand me.
> >
> > Of course there need to be updates as to the state of patch series.
> >
> > It's just that mails only go *so* far when you need to connect and
> > aggregate information. You need the connection between the original patch
> > series, the latest unaddressed reviews, links to the branches, history of
> > the patch series' iterations, and ideally links to the repositories of the
> > contributors with *their* branch names. And then, of course, your verdict
> > as to the state of the patch series and your expectation what happens
> > next.
> >
> > To relate that, you are using a plain text format that is not well defined
> > and not structured, and certainly not machine-readable, for information
> > that is crucial for project management.
> >
> > 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.
> 
> Would something like patchwork fix your need ?

Maybe. Here is the link, for other interested parties: http://jk.ozlabs.org/projects/patchwork/ and https://github.com/getpatchwork/patchwork

> They now seems to have a REST API, which means it could probably be
> pluggeg into Junio's scripts and work seemlessly for him (or any other
> happy ML user) while other people can browse through the web interface.

It seems that patchwork's design calls for the communication still being performed as previously, and just providing a web interface to search a little more efficiently through the mails containing patch submissions.

Git's mailing list, of course, poses the problem to patchwork that the status of any patch series is opaque to any automatic system that does not specifically try to connect the What's cooking dot to the patch mail dots.

Also, a point that came up in a private discussion with another core Git contributor this week: how many reviewers actually even so much as test-compile, let alone look at the code in context? I am fairly certain that none do, *just* because of the shortcomings of the process.

Patchwork would not address this, of course.

In my ideal world (in which there would be world peace, too, so it would be pretty boring, therefore you should not put much stock into what I am saying next), the direction would be the other way round: the tool should not scrape the mailing list and make the results accessible via web interface. Instead, the tool would let me sidestep the mailing list altogether, using it just as a lossy communication medium (and keep the lost information accessible in different ways). SubmitGit "threatened" to allow me to do this: I could open a PR at https://github.com/git/git and then hit a button and off it goes. SubmitGit stops there, though; If it would have continued from there (and did not make the initial step difficult by requiring some registration not everybody is comfortable with), it would have fulfilled my wishes. Alas, it is written in Scala, using a framework I am utterly unfamiliar with, so I could not do anything about it.

Ciao, Dscho