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@xxxxxx> 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 -- 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