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 > point.
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 early days. -- 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
