Junio C Hamano <gitster@xxxxxxxxx> writes: > * fc/contrib-related (2013-06-03) 4 commits > - contrib: related: parse committish like format-patch > - contrib: related: add option to parse from committish > - contrib: related: add support for multiple patches > - Add new git-related helper to contrib > > Waiting for the design review to settle. As people may have seen in the discussion on the earlier iteration, something like this (there may be a room for bikeshedding the name, though) that takes either a range of changes or set of patches and finds people who may be able to review them may be a good addition to our official toolchest. http://thread.gmane.org/gmane.comp.version-control.git/221728/focus=221796 Right now, "related" is in contrib/ primarily because its design review phase is not yet finished and because it is in Ruby, which the rest of the system does not depend on. I have some administrative comments on two issues as the maintainer. * Do we want to add Ruby dependency? * Do we want to keep expanding contrib/? These have been triggered by "related", but the comments in this message are not limited to the specific topic (e.g. you can read it with s/Ruby/<any language we currently do not depend on>/). On Ruby: Assuming "related" is a good idea, to make it as the proper part of the system out of contrib/ when its design review phase is finished, one of these things has to happen: 1. Find a volunteer to rewrite it in one of the languages that we know the platforms our current users use already support, which means either C (not a good match), POSIX shell (not the best match), or Perl. 2. Promote Ruby to the first-class citizen status, which involves making sure people on platforms that matter do not have problem adding dependency on it (I am primarily worried about MinGW folks), and also making sure core developers do not mind reviewing code written in it. As long as we can get as high quality reviews on changes written in Ruby as we do for the current codebase, it is OK to go route #2, and that may hopefully happen in the longer term as and there will be some people, among competent Ruby programmers, who have understood how the pieces of entire Git are designed to fit together by the time it happens. I however do not know how much extra burden it would place to add dependencies to platform folks, so obviously the safer approach is 1 at least in the immediate future. My understanding is that msysgit folks are already having trouble with Python, and we do not want to go route #2 at least for now. Having to ship a variant of Git with NO_PYTHON is already bad enough. And that is why the option 1 above does not list Python as a possible candidate. On contrib/: Back when Git was very young, it made sense to bundle third-party tools in our tree's "contrib/" section to give them visibility and users convenience. Now Git ecosystem has grown to have many users who know Git and who do not necessarily come to this list, and with easy-to-use hosting sites where anybody can publish their ware and collaborate with their contributors, "giving more visibility" angle of contrib/ has outlived its usefulness. When there are multiple third-party tools that address similar needs, there is not much point picking one at random and ship it over others, and shipping all of them is simply crazy. In an ecosystem with flourishing third-party add-ons, their products should and will stand on their own. As the maintainer, I've been thinking about closing contrib/ area for new stuff, and shrinking existing ones, either by moving stuff that are only useful within the context of Git to main part of the tree (e.g. "contrib/workdir" may move to a new directory "addons/", some of remote-helpers in contrib/ may move to "remote-helpers/", etc.), and removing others from contrib/, for this reason. Of course, interested folks can take the last version of the removed ones and continue improving them as standalone projects. And that is why the list of possible actions in the previous part does not have "3. Keep it in contrib/ forever" as an option. That is all for the "administrative comments" as the maintainer. The rest is just a personal opinion. If we were looking at a compelling and sizeable web application that depends on Rails, it is very likely that it would not make much sense to rewrite it in other languages only to avoid a new language dependency on Ruby. But "related" is "read and extract some info out of text files, spawn a 'blame' (or two) based on that info, read to collect further info and summarize", for which Ruby does not especially shine compared to Perl, which is the language we already depend on. Because of this, I am moderately reluctant to add Ruby dependency only for this script. Unless I know people who regularly give us high quality reviews, and those who support various platforms, are fine with it, that is. In the shorter term (read: up to 2.0), I am inclined to vote that we should go route #1 (i.e. rewrite in Perl once the design settles). My "personal opinion" above of course assumes that everybody agrees that "related" is a good addition. If not, there is "3. not add it to contrib/ and leave it as an out-of-tree third-party project" option. -- 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