[Administrivia] On ruby and contrib/

[Junio C Hamano <gitster@pobox.com>]

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