On Tue, 4 Jun 2013, Junio C Hamano wrote:
Junio C Hamano <gitster@xxxxxxxxx> writes: 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.
As someone who builds minimalist builds (firewalls, openwrt, raspberry pi, etc), having to pull in a full ruby install to get git installed would not be something I'd like to see.
Yes, openwrt (and I) can build our own version, but that's a pain. I tend to build my tight systems from Debian and it's nice to be able to use stock packages.
I tend to use git for sysadmin type functions as much as for development, so it's very useful even on such small and slow platforms.
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.
If you can, you should leave just enough of a stub in place so that people who don't know about the change and try to run the stuff that used to be in contrib/ get a message pointing them to the new home.
David Lang -- 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