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

[Richard Ipsum <richard.ipsum@codethink.co.uk>]

On Thu, Aug 04, 2016 at 09:42:18AM -0700, Stefan Beller wrote:
> On Thu, Aug 4, 2016 at 8:58 AM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> >
> >> If we were to change our workflows drastically, I'd propose to
> >> go a way[1] similar to notedb in Gerrit, or git-series,
> >
> > Gerrit is a huge, non-distributed system. Complex, too. If we change the
> > patch submission process, we should make things *easier*, not *harder*. So
> > I think Gerrit is pretty much out of the question.
> 
> I did not propose to use Gerrit or git-series or git appraise.
> 
> However whenever I see these projects talking to each other, the talk focuses on
> a "unified review storage format" pretty often, which would make them compatible
> with each other. So then I could choose git-series, while you could go with
> git appraise (although that is written in go, so maybe too fancy already ;)
> Or there could be another new program written in C that follows the "review
> format".

This "unified review storage format" really does seem to be the missing
piece. The tool I've been working on for the past year (git-candidate)
was initially aimed at contrib[1], and was written in perl solely
to satisfy contrib rules. It would have been python otherwise.

The feedback from that thread[1], was that while git-candidate itself
seemed interesting it would be unreasonable to bless a particular
tool's format. So it seems to me that even if git-series had been
written in perl rather than rust it could have expected a similar
response to that of git-candidate, possibly.

As Stefan says, if we're able to establish a standard for storing
review data in git then it doesn't really matter what the tools are written in.

For what it's worth my possibly quite shoddy attempt at a library
implementing a possible review format for git[2] is written in perl,
mostly to satisfy contrib requirements.

> >
> > Even requiring every contributor to register with GitHub would be too much
> > of a limitation, I would wager.
> >
> > And when I said I have zero interest in tools that use the "latest and
> > greatest language", I was hinting at git-series. Rust may be a fine and
> > wonderful language. Implementing git-series in Rust, however, immediately
> > limited the potential engagement with developers dramatically.

Ironically contrib's language requirements actually raised the bar for me
because it meant that I had to learn perl.

> >
> > Additionally, I would like to point out that defining a way to store
> > reviews in Git is not necessarily improving the way our code contribution
> > process works. If you want to record the discussions revolving around the
> > code, I think public-inbox already does a pretty good job at that.

I agree, and must apologise if this response has been too off topic,
in any case I hope at least some of it was useful to someone.

Hope this helps,
Richard Ipsum

[1]: http://www.mail-archive.com/git%40vger.kernel.org/msg80972.html
[2]: https://bitbucket.org/richardipsum/perl-notedb