Re: [PATCH v2 01/17] contrib: remove outdated README
Junio C Hamano wrote: Felipe Contreras felipe.contre...@gmail.com writes: == contrib vs. core == This is the only point relevant to contrib vs. core: - 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. It will never happen. I already argued against it[1], multiple times. Essentially making the tests optional removes any possibility of blockage (pluse many more arguments). I already said that your It will never happen is a handwaving, and I already saw you argued against it. This is a red herring. Ignore the fact that it will never happen (which it won't), the next point remains a FACT, and you conveniently ignore it. ANSWER THIS: Essentially making the tests optional removes any possibility of blockage (pluse many more arguments). If the tests are optional, it doesn't matter if such change you are worried about happens or not (it won't). That's all there is to it. You made a wrong call. The tools *can* move into the core, and you said they couldn't. You may have been interested in contrib/core in the thread, but that does not prevent others from considering other aspects of the issue and different and possibly better solutions, which was to unbundle. That is IRRELEVANT to the fact that the tools *could* move into the core. You are using arguments (refuted) to demonstrate that the tools *might be better served* by being unbundled, in order to explain why they *could not* move into the core. That's a red herring. I was very confident back in that thread that the remote Hg bridge would not merely survive but would serve its users well as a standalone project, And you were wrong. There is a greater risk for these bridges to become unmaintained if we do not have them in my tree, and that would only hurt our users. But I did not see that particular risk at all for the remote Hg bridge. You have been very interested in maintaining it, and I don't think I ever had to prod you to respond to an issue raised on the list. It is an apples-and-oranges comparison to bring up git-svn/p4. In other words; if I had done a poorer job of maintaining these tools, they would have had a higher chance of moving into the core? If that's the case I would gladly stop any maintenance on them. Just say the word. I worked extremely hard so they could become part of the core, if being part of the core means I have to maintain them less, so be it. Besides, I want to see the git-core has the best thing among competing implementations for a specific niche subtask perception changed in the longer term so that it becomes natural for users to say something like For this particular task, there is no support in what comes with core (or there is a tool that comes with core to address similar issues but in a way different from what you want), and the go-to tool these days for that kind of task is to use this third-party plugin, Where are you saying that? Nowhere, that's where. Therefore every tool you unbundle, you are throwing to the wolves. Things like git imerge are helping us to go in that direction. I was hoping that the remote Hg bridge to be capable of becoming the first demonstration to graduate out of contrib/ that shows the users that is the case, not with just talk but with a specific example. You told me you wanted them to move to the core, you even moved them to the core. Then after years of work you change your mind, AGAINST my explicit will and with clear strong arguments AGAINST your apparently newly conceived idea. And idea you didn't explain clearly, and which you didn't give any chance of being refuted. In other words; an idea which very well COULD BE WRONG, and which very well could impact negatively many Git users. But you cannot even ponder the notion that you could possibly be wrong. After seeing these discussions, it tells me that the code is not fit for the core (also [*3*]), and I think there no longer is any reason for us to still talk only about contrib vs core. As you already said, you do not want to see them in contrib/, No, I want to see them in the core, and you said you did too. More importantly the vast majority of our users would want to see them in the core, therefore the discussion of contrib vs. core is pretty much relevant, but you don't care about them, do you? As I said, I will complain about this publicly _to our users_, which you are disregarding completely with this poorly thought decision and the subsequent ones. -- Felipe Contreras -- 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
Re: [PATCH v2 01/17] contrib: remove outdated README
On Fri, May 16, 2014 at 03:08:51AM -0500, Felipe Contreras wrote: Junio C Hamano wrote: Felipe Contreras felipe.contre...@gmail.com writes: == contrib vs. core == This is the only point relevant to contrib vs. core: - 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. It will never happen. I already argued against it[1], multiple times. Essentially making the tests optional removes any possibility of blockage (pluse many more arguments). I already said that your It will never happen is a handwaving, and I already saw you argued against it. This is a red herring. Ignore the fact that it will never happen (which it won't), the next point remains a FACT, and you conveniently ignore it. It may not block git being released, but as we can see from the recent patches that were needed to enable hg 3.0 support it can break and would have to follow *both* mercurial and git upstreams, not just git's. After thinking about this for a while, I would have to agree with Junio That it's better if a bridge between to actively developed applications not be coupled to one. This does not mean that I think git-remote-hg is not of a quality to be in the git.git tree, but it is simply a fact of development and stability. If git's remote-helper stuff changes but mercurial doesn't, we're fine because, having seen the speed of your fixes, we would have a fix before the next release without a doubt. However, if mercurial changes, like it just did, then git itself would need to make a release to have it actually work with the newest release. Having the tool out of tree allows the maintainer to fix things on both ends and release independently so that both situations above can be solved without any real hassle on git or mercurial's side. This goes for bzr, too, but it looks to be changing less quickly. tl;dr: This may not block a release, but it will make releases a lot more dependent on outside forces. Thanks, -- William Giokas | KaiSforza | http://kaictl.net/ GnuPG Key: 0x73CD09CF Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF pgp52E8cms84y.pgp Description: PGP signature
Re: [PATCH v2 01/17] contrib: remove outdated README
William Giokas wrote: On Fri, May 16, 2014 at 03:08:51AM -0500, Felipe Contreras wrote: This is a red herring. Ignore the fact that it will never happen (which it won't), the next point remains a FACT, and you conveniently ignore it. It may not block git being released, but as we can see from the recent patches that were needed to enable hg 3.0 support it can break and would have to follow *both* mercurial and git upstreams, not just git's. Indeed, it *can* happen, nobody has argued otherwise. The thing is how *likely* is it that it will happen again. As I said, in my experience developing this there has never been a single instance where such a change was required for *newer* versions of Mercurial. From what I can tell this is an exceptional situation. And it makes sense that when it happened, it happened exactly in the part where I wrote custom push() method. Mercurial has unstable API, but in unstable API's are part that are more stable than others. Generally the higher level the API is, the more stable it tends to be. The Linux kernels makes an even weaker promise of API stability than Mercurial does, but even then, the higher the API you use, the less likelihood you have of breakage. I've seen this in practice many times. And it does makes sense that for practical purses Mercurial would try to avoid changes in the higher level API, which require changes in many places, and not so much in lower level APIs, which might require a few changes here and there. The problem is that in order to replace the higher level API push(), I had to use the lower level API, and that's where the breakage happened, it was not unlikely. It is unlikely that another change in this particular API will happen soon, but not extremely so. As I already explained, this can be mitigated by contacting the Mercurial developers and figure out if their high-level API can accommodate the kind of functionality git-remote-hg needs. Maybe by adding a new option, or maybe by adding another high-level helper function. Either way, I doubt Junio is qualified at all to discern between the likelihood of future Mercurial API changes that would break git-remote-hg. He has seen one, and he is wrongly assuming there are more to come. After thinking about this for a while, I would have to agree with Junio That it's better if a bridge between to actively developed applications not be coupled to one. How exactly would it be better? If you concede that the Git release wouldn't be affected, then assuming a hypothetical future where git-remote-hg is bundled, and we have a Mercurial API breakage, we would have: Git v2.5 fail, Git = 2.5 get the fix If we unbundle, we have: git-remote-hg v0.5 fail, git-remote-hg = v0.5 get the fix What is the big difference? I presume you would say that git-remote-hg v0.5 could be released earlier than Git v2.5, so the users would get the fix faster. However, that is not the case if the breakage is detected *before* the Mercurial release happened, in which case both Git v2.4 and git-remote-hg v0.4 would already contain the fix, and it doesn't matter much which was released first. The problem is that I wasn't doing the continuous integration with the development version of Mercurial, which I am now, so these kind of exceptional issues would be detected earlier. Moreover, it is likely that the distribution package for git-remote-hg would not be maintained as rigorously as the Git package. It might not even be part of the official packages (e.g. ppa or AUR). Therefore, even if the git-remote-hg v0.4 happens earlier, it might reach the users later. Furthermore, we are talking about a single script that can be installed by hand easily. The users can simply override their distribution's script and install by hand the latest version, as many have been doing already when they report errors and want the latest fix. Even more. git-remote-hg will not have maintenance releases, if an exceptional issue like this happens, it can be back-ported to Git v2.3.x, Git v2.2.x, and so on. It seems like a very feeble argument in favor of unbundling *at best*. This does not mean that I think git-remote-hg is not of a quality to be in the git.git tree, but it is simply a fact of development and stability. If git's remote-helper stuff changes but mercurial doesn't, we're fine because, having seen the speed of your fixes, we would have a fix before the next release without a doubt. However, if mercurial changes, like it just did, then git itself would need to make a release to have it actually work with the newest release. That is not true. In this particular case, because I didn't build against the development version of Mercurial, yes, but not for the future. If I had the tests I have in place now, we would have detected the change earlier, and Git v1.9.2 would *already* contain the fix, and when Mercurial v3.0 got released we wouldn't need to make a Git release in response (same goes for unbundled
Re: [PATCH v2 01/17] contrib: remove outdated README
On Fri, May 16, 2014 at 05:21:36AM -0500, Felipe Contreras wrote: How exactly would it be better? If you concede that the Git release wouldn't be affected, then assuming a hypothetical future where git-remote-hg is bundled, and we have a Mercurial API breakage, we would have: Git v2.5 fail, Git = 2.5 get the fix If we unbundle, we have: git-remote-hg v0.5 fail, git-remote-hg = v0.5 get the fix What is the big difference? It's a matter of scope and where the releases happen, that is all. Thank you, -- William Giokas | KaiSforza | http://kaictl.net/ GnuPG Key: 0x73CD09CF Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF pgphjvVkMmMZ4.pgp Description: PGP signature
Re: [PATCH v2 01/17] contrib: remove outdated README
William Giokas wrote: On Fri, May 16, 2014 at 05:21:36AM -0500, Felipe Contreras wrote: How exactly would it be better? If you concede that the Git release wouldn't be affected, then assuming a hypothetical future where git-remote-hg is bundled, and we have a Mercurial API breakage, we would have: Git v2.5 fail, Git = 2.5 get the fix If we unbundle, we have: git-remote-hg v0.5 fail, git-remote-hg = v0.5 get the fix What is the big difference? It's a matter of scope and where the releases happen, that is all. Of course the core vs. out-of-tree question is a matter of where the releases happen. The question here was: in which way is out-of-tree a better place? If it's a matter of scope, that is; should a foreign vcs interface tool be bundled in the Git core? Then that question applies not only to git-remote-hg/bzr, but also git-p4, git-cvs, git-svn, and others. The answer to the first question seems to be; it's not at all clear (in fact there doesn't seem to be any valid argument in favour of out-of-tree). The answer to the second question is; we are not asking that question right now (for the moment foreign vcs tools should remain part of the Git core). I started the graduation series by saying there doesn't seem to be any good reason not to, and Junio agreed. Now Junio doesn't agree, but it's till the case there's no good reason not to. -- Felipe Contreras -- 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
Re: [PATCH v2 01/17] contrib: remove outdated README
Felipe Contreras felipe.contre...@gmail.com writes: Junio C Hamano wrote: Felipe Contreras felipe.contre...@gmail.com writes: 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. 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): Let's be clear; the discussion in that thread was contrib vs. core. Most of the points you mention below are not related to that. == contrib vs. core == This is the only point relevant to contrib vs. core: - 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. It will never happen. I already argued against it[1], multiple times. Essentially making the tests optional removes any possibility of blockage (pluse many more arguments). I already said that your It will never happen is a handwaving, and I already saw you argued against it. There is no point repeating that exchange. We both know, and bystanders with popcorns in their hands also know, that we have different opinions. You may have been interested in contrib/core in the thread, but that does not prevent others from considering other aspects of the issue and different and possibly better solutions, which was to unbundle. I was very confident back in that thread that the remote Hg bridge would not merely survive but would serve its users well as a standalone project, and the level of confidence was actually a lot higher than for a hypothetical case where other already in-core bridges like git-svn/p4 are somehow forced to become standalone, simply because of the difference in the depths of involvement of respective area maintainers. Without meaning any disrespect to Eric or Pete, I think my prodding them (by forwarding issues and proposed patches by others to them when I see them on the list) has been helping the area maintainers who have other time and attention obligations to help us, by drawing their attention and making their workload smaller (they can only Ack and have me apply, instead of maintaining a separate tree). There is a greater risk for these bridges to become unmaintained if we do not have them in my tree, and that would only hurt our users. In the ideal world, it may be better if it weren't that way, but at the same time, new issues that changing time brings to them seem to be handled more or less OK, so we have to be content with the status quo. But I did not see that particular risk at all for the remote Hg bridge. You have been very interested in maintaining it, and I don't think I ever had to prod you to respond to an issue raised on the list. It is an apples-and-oranges comparison to bring up git-svn/p4. Besides, I want to see the git-core has the best thing among competing implementations for a specific niche subtask perception changed in the longer term so that it becomes natural for users to say something like For this particular task, there is no support in what comes with core (or there is a tool that comes with core to address similar issues but in a way different from what you want), and the go-to tool these days for that kind of task is to use this third-party plugin, because it is simply unrealistic to expect my tree to forever be the be-all destination for everything. Things like git imerge are helping us to go in that direction. I was hoping that the remote Hg bridge to be capable of becoming the first demonstration to graduate out of contrib/ that shows the users that is the case, not with just talk but with a specific example. Anyway, the above is only within the discussion theme of John Keeping's thread [*1*]. You seem to be adamant that you do not consider other people's opinions that came in later threads you started [*2*], and I do not think that is a sensible way to discuss things. After seeing these discussions, it tells me that the code is not fit for the core (also [*3*]), and I think there no longer is any reason for us to still talk only about contrib vs core. As you already said, you do not want to see them in contrib/, and as you already saw, everybody other than you do not want to see them in core and some of them do not want to even see them in contrib/ for that matter. I do not see that there is any direction other than out. [Reference] *1* http://thread.gmane.org/gmane.comp.version-control.git/247660/focus=248167 *2* http://thread.gmane.org/gmane.comp.version-control.git/248705 *3*
Re: [PATCH v2 01/17] contrib: remove outdated README
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. Despite the (good) work you did, many people think the community and git as a whole as more to loose by having to deal with your theatrics, especially since you try to take everyone hostage of your situations. No amount of arguing (calling it ad hominem etc) will change anything at this point, you have to accept that your social actions have a big part of responsibility in this. IMHO, you should change your behavior into a more respectful one and give people some time to discover you changed, otherwise it is innevitable that you'll just get banned/ignored by mostly everyone. We spent way too much energy dealing with these silly issues, please find a way to deal with it that doesn't annoy everyone and doens't affect the friendlyness of the mailing list. Philippe -- 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
Re: [PATCH v2 01/17] contrib: remove outdated README
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. -- Felipe Contreras -- 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
Re: [PATCH v2 01/17] contrib: remove outdated README
On Wed, May 14, 2014 at 3:35 PM, Felipe Contreras felipe.contre...@gmail.com wrote: You are not paying attention at all. Junio may have been trying to be polite and not tell you directly that attitude was a factor. Whatever. He is the maintainer. Of all the folks in this list, he gets to call the shots when the criteria aren't 100% clear. Quite a few voices here have been heard, all telling you that you are wrong. Even if you might be right about some aspects, you are wrong. Time to let go. good bye, m -- martin.langh...@gmail.com - ask interesting questions - don't get distracted with shiny stuff - working code first ~ http://docs.moodle.org/en/User:Martin_Langhoff -- 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
Re: [PATCH v2 01/17] contrib: remove outdated README
On Wed, May 14, 2014 at 02:35:08PM -0500, Felipe Contreras wrote: Prior to his decision there were no complaints about my manners since I returned. It was his *TECHNICAL* decision that triggered this. There have been several complaints about your behavior since you returned[1,2,3,4], in addition to the times I and others have simply left threads because they did not feel that arguing with you was productive (a thing that several people, myself included, told you in the past that they would do). I have not paid all that close attention to this remote-hg contrib argument. Maybe you are 100% right and Junio is wrong and lying and cannot back up his decision, but somehow needs to cover it up through rhetoric. But that does not at all match my past experiences with Junio's behavior. And given my past experiences with you, and your behavior in response to the discussion, I find it likely that either mis-communication or your stubbornness is a likely factor. And also given those experiences, I've avoided wading into the thread myself or spending too much time thinking about it. I can understand that it hurts to be called a troll. I really do believe you are trying your best to improve git. But I hope you also understand that in terms of the time and emotional drains on other participants, from our perspective interacting with you is quite similar to interacting with a troll. Your continued arguing on this topic does not seem like it is going anywhere, and I believe is wasting time and hurting the atmosphere of the list. Please stop. You have had many chances to interact with people on the list[5], and now you are seeing the consequences of your behaviors: people have little tolerance for you and will stop paying attention. -Peff [1] http://article.gmane.org/gmane.comp.version-control.git/247108 [2] http://article.gmane.org/gmane.comp.version-control.git/247121 [4] http://article.gmane.org/gmane.comp.version-control.git/247168 [3] http://article.gmane.org/gmane.comp.version-control.git/248000 [5] Even though you were previously asked to leave, I believe people on the list gave interacting with you a fair shot in the past month or two. And we somehow still ended up at the same place. That's just my perception, of course. I'd invite anybody watching to form their own opinions. -- 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
Re: [PATCH v2 01/17] contrib: remove outdated README
Felipe Contreras felipe.contre...@gmail.com 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
Re: [PATCH v2 01/17] contrib: remove outdated README
Jeff King wrote: On Wed, May 14, 2014 at 02:35:08PM -0500, Felipe Contreras wrote: Prior to his decision there were no complaints about my manners since I returned. It was his *TECHNICAL* decision that triggered this. There have been several complaints about your behavior since you returned[1,2,3,4], [1] http://article.gmane.org/gmane.comp.version-control.git/247108 This is not a complaint, you are merely saying you are not interested in discussing with me without mentioning any bad behavior at that time. And this is not related to remote-hg/bzr. [2] http://article.gmane.org/gmane.comp.version-control.git/247121 This is a complaint without pointing out what are the specific instances of bad behavior, present or past. [4] http://article.gmane.org/gmane.comp.version-control.git/247168 This is not a complaint about bad behavior. Unless you think making a bet is bad behavior. And this is unrelated to remote-hg/bzr. [3] http://article.gmane.org/gmane.comp.version-control.git/248000 This is a complaint about a factual statement, a prediction about the future that turned out to be true. Unflattering factual predictions can hardly be considered bad behavior And this is unrelated to remote-hg/bzr. I have not paid all that close attention to this remote-hg contrib argument. Maybe you are 100% right and Junio is wrong and lying and cannot back up his decision, but somehow needs to cover it up through rhetoric. But that does not at all match my past experiences with Junio's behavior. The fact that something hasn't happened in the past doesn't mean it's not happening right now. I am still waiting for Junio's answer to *one* question. If your expectation about Junio is correct, it should be easy for him to say Felipe is wrong, here's where I explained in full my rationale of the technical issues that triggered my decision to demote the remote helpers, and as you can see, the importance of the decision is well matched by the detail of my explanation. But he is not doing that, is he? It would be easy for him to do that, why isn't he doing so? You are giving him a free pass. I can understand that it hurts to be called a troll. I really do believe you are trying your best to improve git. But I hope you also understand that in terms of the time and emotional drains on other participants, from our perspective interacting with you is quite similar to interacting with a troll. Yes, I can understand that, and I would understand if Junio said I was acting *like* a troll. But he unequivocally said I was a troll, even when I asked for clarification. Maybe that's acceptable to you. That's where I draw the line. Your continued arguing on this topic does not seem like it is going anywhere, I'm not arguing on this topic any more. I gave up on Junio trying to answer my *one* question. The remote helpers will not graduate because Junio said so, and he didn't explain his reasoning. That's an unfortunate fact. All I'm trying now is to move foward, by: 1) Add a warning about the new location of remote-helpers (Junio chose to argue instead) 2) Remove the remote-helpers and replace them with warning stubs (Somehow the patches didn't reach the mailing list) 3) Make sure everything is in place for users and packagers to use the new location (it can't never be as good as graduating to the core) (The fact that Junio is preventing 1) and 2) doesn't help) Additionally: 4) Correct any misconceptions in the lingering threads and I believe is wasting time and hurting the atmosphere of the list. Please stop. Tell other people to stop. I am merely replying to misconstrued conceptions. If other people stop, so would my replies. I am not going to let the record about such an important decision be tainted by these misconceptions. [5] Even though you were previously asked to leave, I believe people on the list gave interacting with you a fair shot in the past month or two. And we somehow still ended up at the same place. That's just my perception, of course. I'd invite anybody watching to form their own opinions. And that's entirely Junio's fault for making a haste decision, and giving no rationale about it. Given all the time I've spent on these tools, I wasn't willing to let my work be threated like crap by Junio. I deserved an explanation, and if he wasn't going to give one, I'd rather leave the project trying to get one (even if that meant behaving in a way other people considered bad). And BTW, I still think git-archimport and git-quiltimport should be demoted from the core, and I think the contrib area should be cleaned up, many of the tools removed, and others maintained out-of-tree. Do not think I sent those patches to troll. Cheers. P.S. While we disagree on many topics, I do appreciate the fact that you are never condescending and try to be honest, and when it becomes difficult to do that, you explain so and leave the discussing. Never letting
Re: [PATCH v2 01/17] contrib: remove outdated README
Junio C Hamano wrote: Felipe Contreras felipe.contre...@gmail.com writes: 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. 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): Let's be clear; the discussion in that thread was contrib vs. core. Most of the points you mention below are not related to that. == contrib vs. core == This is the only point relevant to contrib vs. core: - 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. It will never happen. I already argued against it[1], multiple times. Essentially making the tests optional removes any possibility of blockage (pluse many more arguments). This is the crux of the problem, because as far as I know, it's the only suppsed argument against contrib vs. core. An argument very weak and already refuted. I repeatedly asked Junio to clarify his reasoning, because it can't possibly be that this is the only reason, and that's the full rationale. If this is it. Then it's very clear: core wins. == bundle vs. unbundle == The rest of the arguments are *not* related to contrib vs. core. They are a red herring, but I'll answer anyway. - 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). I am the maintainer I told you that wasn't the way to go and I'm telling you again. - 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. I already argued against this (and so did you[2]); the same argument applies to git-p4, git-cvs, git-svn, git-archimport, etc. We are not seeing efforts to unbundle those. Why? Because it would be detrimental to our users, for many reasons, starting by the fact that there's no good visibility of out-of-tree tools. - 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. That is not true. Distributions mostly put everything in contrib/ into /usr/share/git without much care about what does what. If something is missing the users might notice, but the packages wouldn't. It would require different packagers that care to create the new packages, if it happens at all. The new packages might be created in a ppa, or some other third-party place not very visible. If proper packages manage to end up in the main distribution repositories, it will take a long time, and in the meantime users will be left with a bad taste in their mouth. It will take even more time if these tools remain in contrib/ because nobody will notice anything, until bugs start to pile up. - 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. Users don't care much about being on the bleeding edge. They care that their tools keep working and in the same way. For that it's more important that the maintainers have as many eyes as possible no the patches. And sending the patches on git@vger.kernel.org has certain helped in that regard. You want to take that away from them. Additionally, they care that the tools are easy to set up. Being able to clone Mercurial repositories from an out-of-the-box version of Git is much more important to them than being on the bleeding edge. Plus this also applies got
Re: [PATCH v2 01/17] contrib: remove outdated README
On Wed, May 14, 2014 at 7:28 PM, Felipe Contreras felipe.contre...@gmail.com wrote: Do we no longer have to be afraid of that? WHY? All the responses from the contrib cleanup patches seem to suggest that pretty much *everyone* The responses also been clear in that you are toxic. You've hijacked this mailing list on a personal crusade over a particular point over which Junio has discretion. We get it. You disagree with the maintainer. It is clear now. Learn to live with it; or at least let everyone else be. Can we call Hitler on this one and close these threads now? You sent a nice email saying bridges are burned. We get the point. It's over. Bridges burned. NO CARRIER. Bye now. m -- martin.langh...@gmail.com - ask interesting questions - don't get distracted with shiny stuff - working code first ~ http://docs.moodle.org/en/User:Martin_Langhoff -- 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
Re: [PATCH v2 01/17] contrib: remove outdated README
Martin Langhoff wrote: On Wed, May 14, 2014 at 7:28 PM, Felipe Contreras felipe.contre...@gmail.com wrote: Do we no longer have to be afraid of that? WHY? All the responses from the contrib cleanup patches seem to suggest that pretty much *everyone* The responses also been clear in that you are toxic. You are replying to a mail about a *TECHNICAL* reason. Junio made a good job of concentrating on the technical side. If you are not willing or unable to concentrate on the technical side, reply to something else, you are just tainting the discussion. If you are willing to concede that Junio made a wrong technical decision, I'd be willing to discuss about the social issues that happened *after* that with you. But I doubt you are interested in doing either one of those, so I don't don't see what's the point of you even replying. -- Felipe Contreras -- 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
Re: [PATCH v2 01/17] contrib: remove outdated README
On Fri, May 9, 2014 at 5:54 PM, Felipe Contreras felipe.contre...@gmail.com wrote: You are once more twisting the sequence of events. Found this gem looking for background to the proposed removal to code of mine. Felipe, if you are wanting to have a war of words with Junio, go have it, with him. I don't know (nor care) who's right, I'll just buy popcorn. If you are going to bother every maintainer under contrib over a problem they have nothing to do with, you'll make an enemy of the whole group. I think you're doing fantastic on that track. Right now, you're acting as a remarkable troll. m -- martin.langh...@gmail.com - ask interesting questions - don't get distracted with shiny stuff - working code first ~ http://docs.moodle.org/en/User:Martin_Langhoff -- 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
Re: [PATCH v2 01/17] contrib: remove outdated README
Martin Langhoff martin.langh...@gmail.com writes: On Fri, May 9, 2014 at 5:54 PM, Felipe Contreras felipe.contre...@gmail.com wrote: You are once more twisting the sequence of events. Found this gem looking for background to the proposed removal to code of mine. Felipe, if you are wanting to have a war of words with Junio, go have it, with him. Please don't feed the troll. I was happy to be done with it. -- 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
Re: [PATCH v2 01/17] contrib: remove outdated README
Junio C Hamano wrote: Martin Langhoff martin.langh...@gmail.com writes: On Fri, May 9, 2014 at 5:54 PM, Felipe Contreras felipe.contre...@gmail.com wrote: You are once more twisting the sequence of events. Found this gem looking for background to the proposed removal to code of mine. Felipe, if you are wanting to have a war of words with Junio, go have it, with him. Please don't feed the troll. I was happy to be done with it. I was going to let this comment go (as I let the endless stream of ad hominem attacks go), but this just one ridiculous. I've contributed 400 patches, changed 12700 lines, sent 4200 mails on the list. Then I'm not happy with a decision you made, and I ask you *one* question to clarify your rationale, and I'm still waiting for an answer. I think after this insane amount of work I'm entitled to an answer for this *one* question. Instead you passive aggressively label me as a troll? This is really disquieting. Junio, do you honestly think I am a troll? Have at least the decency of telling it to me. -- Felipe Contreras -- 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
Re: [PATCH v2 01/17] contrib: remove outdated README
Felipe Contreras felipe.contre...@gmail.com writes: Junio, do you honestly think I am a troll? You certainly are acting like one, aren't you? -- 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
Re: [PATCH v2 01/17] contrib: remove outdated README
Felipe, someone can contribute positively, and also be very destructive. Your positive contributions, nobody will deny. However, you have to tame the other part to be good company. 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. But these are NOT good reasons to make a big scene. It is reasonable to be upset, it is reasonable to think that Junio is wrong or unfair; walk away, take some time off, cool down your own mind, give others time to cool down as well. cheers, m On Tue, May 13, 2014 at 5:05 PM, Junio C Hamano gits...@pobox.com wrote: Felipe Contreras felipe.contre...@gmail.com writes: Junio, do you honestly think I am a troll? You certainly are acting like one, aren't you? -- martin.langh...@gmail.com - ask interesting questions - don't get distracted with shiny stuff - working code first ~ http://docs.moodle.org/en/User:Martin_Langhoff -- 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
Re: [PATCH v2 01/17] contrib: remove outdated README
Martin Langhoff 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. -- Felipe Contreras -- 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
Re: [PATCH v2 01/17] contrib: remove outdated README
Junio C Hamano wrote: Felipe Contreras felipe.contre...@gmail.com writes: Junio, do you honestly think I am a troll? You certainly are acting like one, aren't you? I'm deeply offended by the fact that would think that I'm purposely intent on provoking people, or disrupting more important discussions. I understand how my style of communication can upset people, mainly because people are not used to frankness. But I thought you of all people would see how much effort I've put into so many areas of Git, and therefore that my primary objective is to improve Git, not offend people. That you would understand that me offending people is a side-effect of me trying to improve Git, not that I improve Git just so I can offend people. I understand why you would choose not to reply to some mails that might be too flammable, or unimportant, or difficult. But in this case, the culmination of countless hours of work, what I had in mind since the beginning; that the tools graduate into the core, was finally there, and you took it away. And then you didn't give an explanation, and then you ignored me. I thought you would understand that most of the code that arrived to the mailing list had different versions behind, experiments, discussion in different channels, tests, and that was the reason why most of the code I submitted to remote-hg and remote-bzr simply worked, and it was simple. And why when other people did the same, the results were not so satisfactory. But no, apparently you didn't value my work at all. Maybe you thought each line I sent took me the time it takes to write a tweet, maybe you thought because it's in Python even kids in primary school could write it. In fact it's worth so little to you that it's not even worth the time to respond *one* question, not even in consideration of all these years of effort. And then you have the nerve to call me a troll on top of that? I'm done with you. Consider the bridge burned. Good bye. -- Felipe Contreras -- 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
[PATCH v2 01/17] contrib: remove outdated README
There is no guideline as for what should be part of contrib. Some tools are actively maintained, others consist of a single commit. Some tools have active user-base, some aren't used by anyone. Some tools are on the path towards the core, others will never get there. Some tools are already out-of-tree and simply mirrored, others probably wouldn't survive out-of-tree. Some tools are production-ready, others don't even run. Some tools have tests, most don't. Junio has explained that he wrote this a long time ago, when Git was a different beast, now this no longer applies. The only way to find out if a tool belongs in contrib or not is to as Junio. Cc: Junio C Hamano gits...@pobox.com Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- contrib/README | 43 --- 1 file changed, 43 deletions(-) delete mode 100644 contrib/README diff --git a/contrib/README b/contrib/README deleted file mode 100644 index 05f291c..000 --- a/contrib/README +++ /dev/null @@ -1,43 +0,0 @@ -Contributed Software - -Although these pieces are available as part of the official git -source tree, they are in somewhat different status. The -intention is to keep interesting tools around git here, maybe -even experimental ones, to give users an easier access to them, -and to give tools wider exposure, so that they can be improved -faster. - -I am not expecting to touch these myself that much. As far as -my day-to-day operation is concerned, these subdirectories are -owned by their respective primary authors. I am willing to help -if users of these components and the contrib/ subtree owners -have technical/design issues to resolve, but the initiative to -fix and/or enhance things _must_ be on the side of the subtree -owners. IOW, I won't be actively looking for bugs and rooms for -enhancements in them as the git maintainer -- I may only do so -just as one of the users when I want to scratch my own itch. If -you have patches to things in contrib/ area, the patch should be -first sent to the primary author, and then the primary author -should ack and forward it to me (git pull request is nicer). -This is the same way as how I have been treating gitk, and to a -lesser degree various foreign SCM interfaces, so you know the -drill. - -I expect that things that start their life in the contrib/ area -to graduate out of contrib/ once they mature, either by becoming -projects on their own, or moving to the toplevel directory. On -the other hand, I expect I'll be proposing removal of disused -and inactive ones from time to time. - -If you have new things to add to this area, please first propose -it on the git mailing list, and after a list discussion proves -there are some general interests (it does not have to be a -list-wide consensus for a tool targeted to a relatively narrow -audience -- for example I do not work with projects whose -upstream is svn, so I have no use for git-svn myself, but it is -of general interest for people who need to interoperate with SVN -repositories in a way git-svn works better than git-svnimport), -submit a patch to create a subdirectory of contrib/ and put your -stuff there. - --jc -- 1.9.2+fc1.28.g12374c0 -- 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
Re: [PATCH v2 01/17] contrib: remove outdated README
Felipe Contreras felipe.contre...@gmail.com writes: There is no guideline as for what should be part of contrib. Some tools are actively maintained, others consist of a single commit. Some tools have active user-base, some aren't used by anyone. Some tools are on the path towards the core, others will never get there. Some tools are already out-of-tree and simply mirrored, others probably wouldn't survive out-of-tree. Some tools are production-ready, others don't even run. Some tools have tests, most don't. Junio has explained that he wrote this a long time ago, when Git was a different beast, now this no longer applies. The only way to find out if a tool belongs in contrib or not is to as Junio. Cc: Junio C Hamano gits...@pobox.com Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- This is wrong. The reason I suggested splitting remote-hg out of my tree does not have anything to do with removal of disused and inactive described in the document. As written elsewhere, it was a response to http://thread.gmane.org/gmane.comp.version-control.git/248063/focus=248457 where you said I don't want to do anything for a contrib tool. and in response I suggested that you have an option to make it a standalone third-party project (and the other option being to stay in contrib/ but then you have to work well with others just like other contributors). With the promotion to the core has already been ruled out as not an ideal direction in the thread that begins at this one: http://thread.gmane.org/gmane.comp.version-control.git/247660/focus=248167 that is one of the only two alternatives I can offer. Given that the Git ecosystem has matured enough to let third-party tools flourish on their own merit, if you do not want to work on a thing in contrib/, that is now a more viable option than it used to be. For tools that are happy to be in contrib/ and are still in use by users, none of the above would apply. And what the text says is still perfectly valid. There is nothing outdated in it. -- 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
Re: [PATCH v2 01/17] contrib: remove outdated README
Junio C Hamano wrote: Felipe Contreras felipe.contre...@gmail.com writes: There is no guideline as for what should be part of contrib. Some tools are actively maintained, others consist of a single commit. Some tools have active user-base, some aren't used by anyone. Some tools are on the path towards the core, others will never get there. Some tools are already out-of-tree and simply mirrored, others probably wouldn't survive out-of-tree. Some tools are production-ready, others don't even run. Some tools have tests, most don't. Junio has explained that he wrote this a long time ago, when Git was a different beast, now this no longer applies. The only way to find out if a tool belongs in contrib or not is to as Junio. Cc: Junio C Hamano gits...@pobox.com Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- This is wrong. The reason I suggested splitting remote-hg out of my tree does not This particular patch has nothing to do with remote-hg. have anything to do with removal of disused and inactive described in the document. As written elsewhere, it was a response to http://thread.gmane.org/gmane.comp.version-control.git/248063/focus=248457 where you said I don't want to do anything for a contrib tool. You are once more twisting the sequence of events. *First* you blocked any progres towards graduation 2014-05-06, even though I told you what John Keeping argued wasn't going to happen. http://thread.gmane.org/gmane.comp.version-control.git/247660/focus=248242 *After* that I decided not touch git-remote-hg/bzr on your tree any more 2014-05-08. http://thread.gmane.org/gmane.comp.version-control.git/248063/focus=248457 Do not attempt to construe the consequence as the cause. You caused it. -- Felipe Contreras -- 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
