Re: [PATCH 0/2] git-candidate: git based patch tracking and review

[Jeff King <peff@peff.net>]

On Wed, Nov 11, 2015 at 03:12:05PM +0000, Richard Ipsum wrote:

> > All that being said, my gut feeling is that a system like this should
> > not be developed within the Git project itself. Code review is a
> > complicated thing, and I expect that different people will have very
> > different ideas about how it should work. It would be a bad idea for the
> > Git project to "bless" one system by including it in our source tree.
> > (Earlier in the Git's history it was easier to get something accepted
> > into "contrib", but that has gotten much harder over time.)
> 
> The aim is not to bless one particular system but to eventually
> provide a common data model that all review systems can share,
> so that it is possible to do distributed reviews with arbitrary UIs
> in a widely compatible way.

I think that's a laudable goal, but I didn't see any discussion or
documentation of the data model in your patches. Maybe that would be a
good place to start.

> If we add git-candidate to contrib then it can act as a reference
> implementation, so that this data model can be validated and tested
> by additional developers.

That can happen outside of git's contrib/ directory, too.

I think Michael's "bless" argument applies to the data model, too. Is
your data model a good one? Should other systems adopt it, or is it
still a work in progress? We don't know yet.

I think I'd rather see it prove itself before entering the git tree, if
only because it doesn't really gain anything by being inside the git
tree. Once upon a time that was a good way to get publicity and easy
hosting, but these days it is easy to find git hosting, and I am not
sure people actually explore contrib/ all that much.

-Peff