Felipe Contreras <felipe.contreras@xxxxxxxxx> writes: > Philippe Vaucher wrote: >> >> I have had patches and contributions rejected in the past, sometimes >> >> rudely. Same has happened to many others, if you contribute long >> >> enough, it is pretty much guaranteed that it will happen to you. >> >> Maintainer is wrong, or you are wrong, or someone is just having a bad >> >> day. >> > >> > This is not about a couple of patches I worked in a weekend being >> > rejected. This is about the work I've been doing since the past two >> > years almost like a full-time job dropped to the floor with no >> > explanation at all. I started with the expectation that they were going >> > to move to the core, because Junio said so, then he changed his mind and >> > didn't want to explain his reasoning. >> > >> > It's not just a bad day. >> >> Here are two posts where Junio and Michael Haggerty explain the >> reasoning to you: >> >> - http://article.gmane.org/gmane.comp.version-control.git/248727 >> - http://article.gmane.org/gmane.comp.version-control.git/248693 >> >> Basically, in your case it boils down to your social manners. > > You are not paying attention at all. > > Junio did *not* use my social manners as a reason to block the > graduation, nor the quality of the code, he used a *TECHNICAL* reason. > > Prior to his decision there were no complaints about my "manners" since > I returned. It was his *TECHNICAL* decision that triggered this. > > Junio never explained his *TECHNICAL* reason, and Michael Haggerty > simply said "there are good technical arguments for and against > moving git-remote-hg out of contrib", that was all his explanation for > the *TECHNICAL* reason. > > You, and other people, are using the behavior I displayed *AFTER* Junio > made his *TECHNICAL* decision as the cause for his decision not to > graduate. That's a wrong direction fallacy. I am not interested in distinction between technical and social that much. The points that were raised in the thread started by John Keeping, and some of the points that came to my mind while on that thread, even though I may not have mentioned in *that* thread, that affected the way *I* thought about the issue are these (not exhaustive): - We may be painted in a hard place if remote-hg or remote-bzr take us to a position where the Git as a whole is blocked while it is incompatible with the other side. Maintaining it as an independent project (aka Unbundling) would eliminate that risk, instead of having to handwave and say "that risk does not exist". - A remote-helper has to depend on both sides. Keeping it in either contrib/ or in core, as opposed to unbundling, may make things easier for the remote-helper maintainer, because at least it would allow the helper to advance with Git in lock-step (but I never heard that you do not prefer unbundling for this reason). - In a longer term, a properly maintained remote-helpers should work with wide varieties of Git and the remote system versions anyway, so unbundling would be logically the more "correct" thing to do. - Unbundling would make it less easier to use the remote-helpers for people who are used to keep up with my tree and pick them up from contrib/, but that is a tiny minority these days. Most people use what distros package, and the distros that already package contrib/ remote-helpers will switch their upstream to unbundled repositories in order not to regress their packages for their users. - On the other hand, unbundling will make it easier for the the end-users (both the ones who are fed distro packaged versions and the ones who build from the source _and_ who overcome the "less easier because now they have to pull from not just me but from the unbundled places" inconvenience) to keep up with the leading/bleeding edge, because the remote-helpers do not have to freeze at the same time other parts of Git are frozen before the release, and users and distros can pick improved remote-helpers up and even "mix and match", when they have some other reason that prevents them from updating Git itself. - Unbundling would also involve the risk of making them obscure, and the original reason why we added contrib/ area to host "having something is often better than having nothing" tools, even if some of them were of lessor quality, was exactly that. While building the momentum and the Git community, it was necessary to have a nursery. That reasoning no longer applies these days, and we have seen examples of third-party independent products that can improve the users' Git life flourishing. "We have less need for a nursery" is not a reason to kick bundled things out that want to be bundled, but it tells us that we no longer have to be afraid of unbundled things dying in obscurity, if there are other reasons that tell us unbundling is better. I may be missing some others, and I would be lying if I did not at all think of the "net liability" issue Michael brought up, but the above that does not include anything you labelled as "social manners" was more or less enough to convince me to say ... and I am inclined to be persuaded that the users of remote-hg/bzr may better off if they are unbundled from my tree. in http://thread.gmane.org/gmane.comp.version-control.git/247660/focus=248242 That is not to say that I disagree with Michael and social issues do not matter. -- 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