Re: [PATCH 0/2] git-candidate: git based patch tracking and review
- From
Jeff King <peff@peff.net>
- Date
- Nov 14, 2015, 08:17 UTC
- Message-ID
- <20151114081707.GA32739@sigill.intra.peff.net>
- In-Reply-To
- <20151111151204.GA4249@salo>
On Wed, Nov 11, 2015 at 03:12:05PM +0000, Richard Ipsum wrote:
Show 12 quoted lines
> > 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