Re: [PATCH v1 19/25] contrib: remove 'diff-highlight'

From: Felipe Contreras <felipe.contreras@gmail.com>
Date: May 9, 2014, 17:45 UTC
Message-ID: <536d142c3524_693d7fd30c9d@nysa.notmuch>
In-Reply-To: <xmqqa9aq28a4.fsf@gitster.dls.corp.google.com>

Junio C Hamano wrote:

Show 5 quoted lines

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

*You* said this[1]:

 - Eject tools in contrib/ that would benefit the users better if
   they were outside my tree.  There are a few points to consider
   when judging "benefit better if outside":

   * Their release cycle requirements are better met outside my tree
     (the "remote-hg depends not just on Git but Hg internal" issue
     we have discussed).

   * They are actively maintained.  The overall Git maintainer would
     merely be being a bottleneck than being a helpful editor with
     respect to these tools if we keep them in my tree, and we
     expect that the tool maintainer would do a much better job
     without me.

 - Keep tools that are not actively maintained but still used by the
   users widely in my tree, but when their external dependencies
   become baggage to Git as a whole, demote them to contrib/ and
   stop installing them by default.

 - I would not mind having install.contrib-frotz target in the
   top-level Makefile for each of the remaining contrib/frotz
   hierarchies for those users and distro packagers who know their
   platform meets the dependency requirements.

So make up your mind. Which tools should be ejected from contrib and for what reasons?

> The contrib/README file was written back when Git was still a small
> and young project

If contrib/README is not appropriate, then rewrite it. Having a maintainer making decisions about what goes in and goes outs arbitrarily helps no one.

Or just remove it and be done with the pretense of haing any consistency.

> The sole mention of possible removal from contrib/ is this one:

Now you are contradicting what you said in [1]. Surely git-remote-hg/bzr aren't the only tools that meet the criteria you set in [1].

Show 6 quoted lines

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

You are twisting the events incredibly. *You* started by threatening the removal[2]:

> Having said that, I agree with the conclusion of your message:...
> and I am inclined to be persuaded that the users of remote-hg/bzr
> may better off if they are unbundled from my tree.

I said I wasn't interested in working on this *after* you said they were not going to the core, and they should move out-of-tree.

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

But it hasn't matured enough. That's *YOUR ASSUMPTION*.

Look at all the fuzz my patch series has created. Does it seem to you these are the symptoms of an ecosystem mature enough to let third-party tools to flourish?

If you think so, then let's continue cleaning up contrib. These tools will "flourish" according to you.

Show 5 quoted lines

> In any case, that suggestion to remove not related to the "stick",
> either, and certeinly not about "prove yourself" purge that does not
> even exist.
> 
> So I think most of these removal patches can safely be ignored.

Excellent, so you agree you engage in double standards. Tools stay in the core even when they haven't proven themselves (and even without tests), tools get dropped from the tree even when they have proven themselves.

Got it.

[1] http://article.gmane.org/gmane.comp.version-control.git/248233 [2] http://article.gmane.org/gmane.comp.version-control.git/248242

-- 
Felipe Contreras