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