Junio C Hamano wrote:
> 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].
> 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.
> 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
--
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
