Re: [Administrivia] On ruby and contrib/

[David Lang <david@lang.hm>]

On Tue, 4 Jun 2013, Junio C Hamano wrote:

> Junio C Hamano <gitster@pobox.com> 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