Re: [Administrivia] On ruby and contrib/

On 06/05/2013 02:04 AM, Junio C Hamano wrote:

Junio C Hamano [off-list ref] writes:

quoted

* 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:
[...]

I don't have an opinion on allowing Ruby into the core, except to say
that I would personally prefer *some* alternative that is more capable
than shell and more modern and self-consistent than Perl.  Python, Ruby,
and Lua would seem to be the obvious candidates, with the latter being
easiest for packagers.

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.

For completeness, let me point out two other small advantages of contrib:

* a tool in contrib can assume that it is being bundled with the
corresponding version of Git, and therefore doesn't necessarily have to
go to the effort of supporting older versions of Git.

* at the source-code level, a tool in contrib can take advantage of some
of the Git build/test infrastructure, though I don't know whether they
currently do.


But my main point is that I think it would be easier to phase out
contrib/ if there were a good alternate way of providing visibility to
"satellite" projects.  The relevant Git wiki page [1] is the most likely
candidate, but it is a bit overwhelming due to its size, it has fallen
into disuse because it was broken for such a long time, and it is not
prominently linked to from git-scm.com.  If it were curated a bit, it
would help users find the best ancillary tools quickly.  Perhaps ranking
the tools based on the results of the Git user surveys would help bring
the most popular to the top of each category.

Michael

[1] https://git.wiki.kernel.org/index.php/Interfaces,_frontends,_and_tools

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/