Felipe Contreras <felipe.contreras@xxxxxxxxx> writes: > And you are still conveniently avoiding the question: > > Based on what reasoning? Go re-read what was already said in the thread. I still think remote-hg and remote-bzr can and will flourish on their own merit, and unbundling will be better for the end users for the reasons stated there already. Having said that, I've been thinking (not because of this thread, but because I like imerge better and better these days) that there should be a much better way to have a list of recommended third-party plug-ins that enrich the Git ecosystem. We have https://git.wiki.kernel.org/index.php/InterfacesFrontendsAndTools (Jakub cc'ed as he often nudges those who announce their tools to add an entry there) but honestly, git-scm.com is the first site the end users who do not hack on Git would visit, and we probably should have a catalog there (Scott and Peff cc'ed for that site). One way to help it may be to add a Documentation/gitthirdparty-tools.txt in my tree that would automatically be pulled into git-scm.com site as a part of the manual. A richer ecosystem with tools outside my tree would not materialize unless there is such a mechanism to advertise the existence of them, and having to include a copy of each and every third-party tools in my tree and keeping them relatively fresh is not going to scale in the long run (Michael and Matthieu Cc'ed as I saw exchanges on multimail in a near-by thread). Such a file would probably cluster "plugins" into different categories (post-receive hooks, remote-helpers, mergetools, etc.) and limit the entry descriptions to a single paragraph of several lines tops, with URL referring to the third-party maintainer's site (e.g. a repository at GitHub). >> > Of course it wasn't a mistake. >> >> I doubt about the "Of course" part. The first reaction after seeing >> that the new "changegroup" is used only inside check_version(3,0) >> and nowhere else was to wonder if that import is necessary (or even >> safe) for the pre-v3.0 versions. > > I don't care about your first reaction. If that was only present in > newer versions, how do you think it would pass the testing on older > versions? > > https://travis-ci.org/felipec/git > > Normally I would explain the details of why this is the case, and send > the crash regresion fix for v2.0 with a clear explanation,... Without such an explanation in the log message, how would you expect anybody to guess correctly? Seriously, if you do not care about my first reaction, why do you even want to live in my tree? > The fact that I'm the maintainer and I say it'ss good should be good > enough, and if the current version in "master" renders unusable the > existing Mercurial clones, hey, it's only in contrib, right? One potential merit I would see for keeping them in my tree is that your change will see second opinions from others involved in the project (including me), without giving a total rein based on the sub-maintainership alone. All the changes from sub-area maintainers are vetted by at least two sets of eyeballs that way. But after having to deal with you and seeing that you do not take constructive criticism well, I doubt such a possibile merit will ever materialize in the area where you alone work on. Letting you do whatever you want in your own tree may benefit the users of remote-hg/remote-bzr better as the (bitter) second best option. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html