Jeff King <p...@peff.net> writes:
> On Thu, May 08, 2014 at 07:58:30PM -0500, Felipe Contreras wrote:
>> No activity since 2012, no tests, no chance of ever graduating.
> I don't think "no activity" is an interesting indicator. This tool _is_
> actively maintained, but it has not needed any fixes since 2012. I use
> it for every single "git log" and "git diff" invocation I do via the
> pager.* config.
> If we are getting rid of contrib/ I would be happy to continue
> maintaining it out-of-tree.
I do not know how much attention you have been paying, and I suspect
that you may be aware of all of the following, but I'll send this
out anyway, primarily so that others involved in other subthreads
can find out the story behind this.
There is no "prove yourself is worthy or get evicted" purge going on
in the contrib/ area. I saw contrib/README referred to a few times
in the near-by threads, and I think these patches are done primarily
by deliberately misinterpreting one part of it in order to grab
attention by many people and also to sabotage the project.
The contrib/README file was written back when Git was still a small
and young project that was trying to build an ecosystem by having an
area to host stuff that are not core-material for some reason or
other (e.g. only useful in some environments, only useful for some
workflows, the design or code not up to par to be in core) in my
tree to ease discovery and distribution.
There, I wrote:
I expect that things that start their life in the contrib/ area
to graduate out of contrib/ once they mature, either by becoming
projects on their own, or moving to the toplevel directory. On
the other hand, I expect I'll be proposing removal of disused
and inactive ones from time to time.
The purpose the last sentence in that paragraph is there was to
protect our codebase and our users from those who see an opportunity
to throw their ware in to our tree and go AWOL, by giving me, the
maintainer, a "stick" to prod them, saying "You as the primary
author are responsible for taking good care of the ware you created
by responding to issues (questions, suggestions, bugs, patches) in a
prompt manner, or your ware may even get evicted."
Among contrib/ materials we have today, I do not think there is
anything that requires me to exercise that "stick". diff-highlight
certainly is not. Perhaps subtree is the closest, as I see issues
raised from time to time but the original champion seems to be
inactive for some time, but even there, I recently saw somebody
hinting to volunteer to take it over after sending a patch or two to
it, and I do not intend to exercise the "stick" yet.
The sole mention of possible removal from contrib/ is this one:
in which Felipe said:
I don't want to do anything for a "contrib" tool.
and I suggested that he has an option to make it a standalone
third-party project. With the promotion to the core has already
been ruled out in the thread that begins at this one:
that is one of the only two alternatives I can offer, given that the
Git ecosystem has matured enough to let third-party tools flourish
on their own merit. "We may want a better plug-in registry for Git"
I mentioned in
was to help us in that direction, but seeing that imerge mentioned
in many places I do not even regularly visit with the current
"discovery and distribution" infrastructure, perhaps yet another new
registry may not even be necessary. I dunno.
In any case, that suggestion to remove not related to the "stick",
either, and certeinly not about "prove yourself" purge that does not
So I think most of these removal patches can safely be ignored.
I agree with you and Jonathan that removal of contrib/vim may be a
good idea, but that is not due to "stick" nor "prove yourself",
either. Jonathan's proposed alternative $gmane/248506 does a good
job of explaining and justifying the change. It is a graduation "by
becoming projects on their own" that contrib/README mentions.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html