Thread (13 messages) flat view 13 messages, 7 authors, 2016-06-15

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

From: Jeff King <hidden>
Date: 2016-06-15 23:07:15

On Wed, Nov 11, 2015 at 03:12:05PM +0000, Richard Ipsum wrote:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help