Re: [Administrivia] On ruby and contrib/

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 5, 2013, 17:41 UTC
Message-ID: <7v1u8g3160.fsf@alter.siamese.dyndns.org>
In-Reply-To: <51AEBAEF.6090402@alum.mit.edu>

Michael Haggerty <mhagger@alum.mit.edu> writes:

Show 5 quoted lines

> 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.

Show 9 quoted lines

> 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