Max Horn <m...@quendi.de> writes:
> OK, I'll try to keep a professional tone from now on :-).
> Please consider that the willingness of people to collaborate with
> you in any way is directly related to how you treat them. That
> includes bug reports. The way you acted towards Jed, who was very
> calmly and matter-of-factly explaining things, was IMHO completely
> inappropriate and unacceptable. Indeed, I should augment my list
> of reasons why people might not want to contribute to remote-hg by
> one major bullet point: You. And please, don't feel to compelled
> to tell us that Junio is really the maintainer of remote-hg and
> not you: Whether this is true or not doesn't matter for this
Only on this point, as the top-level maintainer. I do not have any
opinion on technical merits between the two Hg gateways myself.
A tool that is in contrib/ follows the contrib/README rule.
I do not maintain it. Maintenance is up to the person who asked to
include it there. I do ask the people who propose to add something
in contrib/ to promise that they arrange it to be maintained.
I do not even guarantee that they are the best in the breed in their
respective category. When something is added to contrib/, others can
raise objections by proposing alternatives, by arguing that tools of
the nature are better kept out of my tree, etc. When remote-hg was
added, I didn't see specific objections against it.
There is one generic objection to adding anything new in contrib/ I
have myself, though.
In early days of Git, almost all users, who might be interested in
improving their Git experience by helping to polish third-party
tools, had clones of my tree and did not hesitate to come to this
list. Back then, having a copy of an emerging third-party tool in my
tree in contrib/ was a good way to give more exposure to it, and to
give those interested in it a place to meet and join forces to
improve it. Because Git population was small, almost everybody was
here, and it was an efficient distribution mechanism.
Git is now reasonably well known and has big enough user base, and
many users, even those who are inclined to help improving their Git
experience by contributing to third-party tools, do not necessarily
have a clone of my tree. A third-party tool around Git, if it is
any good, is likely to have much much better chance to thrive as a
free-standing project with its own community, compared to those
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