Re: [Administrivia] On ruby and contrib/

Michael Haggerty [off-list ref] writes:

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.

It is true that in-tree stuff can go in-sync with the rest, but I
think that is irrelevant, as we are discussing a tool in contrib/;
if it is part of the core, it deserves that benefit over tools
developed out-of-tree (that need to worry about utilizing new
features after a version check).  After moving tools that we want to
keep as a part of core out of contrib/, they will still be in-sync.

For those that alternative third-party designs and implementations
for solving the non-core problems they try to solve (e.g. ciabot,
continuous, blameview) can exist, it would be better for the
ecosystem of they compete with their alternatives on the same
ground.

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.

That is a very good point.

Michael

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