Junio C Hamano wrote: > Felipe Contreras <felipe.contreras@xxxxxxxxx> writes: > > > I already said this multiple times, but let me be clear once more: > > > > MASTER HAS A REGRESSION (for all versions of Mercurial). > > As you said, that is not a regression, isn't it? It is an old > breakage that existed even before 1.9 (was it 1.8.3 or something?) No. It does't happen in 1.9, it will happen in 2.0. That's a REGRESSION. > >> If you no longer want to have it in contrib/, I can drop it in future > >> releases (but not in v2.0), so that people can find the latest and > >> greatest directly from you. Otherwise, queuing a fix on 'pu' and then > >> to 'next' in preparation for an early graduation for the release after > >> v2.0 (and as a fix, it may want to go to older maintenance releases) > >> is also fine by me. > > > > Are you saying that the graduation plan is going to continue and they > > are going to move out of contrib and be distributed by default? > > I do not think that is going to happen. Then I don't understand what you mean by "graduation". > As we discussed already, I do see merit in unbundling it from my tree. You are blind. Move git-p4 and git-svn out of your tree. You know what will happen. > I can keep it in contrib/ as that is a slight benefit for you What is the benefit of being in contrib/? Even you yourself argued that there is not much point of 'contrib/' nowadays[1]. The only reason we might want something in contrib/ is so that it has a chance to mature before becoming part of the core. > (i.e. you can be lock-step with Git) but as long as you live in my > tree, you need to follow the same release schedule as the other > contributors, which may be detrimental to your users, compared to a > case where it is unbundled. It's much more beneficial to *our* users if these tools are distributed by default. > I do not see a strong reason to move it out of contrib, either. Really? So why did you say this?[2] > > Either way, I think if things go well, remote-hg will prove it's > > worth and move out of contrib and into git's core. > > That was what you promised when we started carrying it in contrib/; I > am still hoping to see it happen when it matures. Jeff said the same thing when he was acting as maintainer[3], and you didn't correct him: > I would one day like to have it as part of the main distribution, too, > but it would be nice to prove its worth in the field for a while > first. All this time I've been operating under the impression that once git-remote-hg proved itself, it would graduate out of contrib. So basically you tricked me, and I wasted insane amounts of time chasing a target that was impossible to reach. Fuck this. [1] http://article.gmane.org/gmane.comp.version-control.git/220178 [2] http://article.gmane.org/gmane.comp.version-control.git/220277 [3] http://article.gmane.org/gmane.comp.version-control.git/208648 -- Felipe Contreras -- 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