Re: Should git-remote-hg/bzr be part of the core?
Linus Torvalds wrote: On May 12, 2014 8:35 AM, Felipe Contreras felipe.contre...@gmail.com wrote: This move is already under way, but suddenly Junio changed his mind. That suddenly wouldn't have anything to do with you being an ass and difficult as usual, arguing about everything and just generally being contrary? No, here's where the thread started (A): http://thread.gmane.org/gmane.comp.version-control.git/247660/focus=248167 Here I wasn't being an ass: http://thread.gmane.org/gmane.comp.version-control.git/247660/focus=248186 Here I wasn't being an ass either: http://thread.gmane.org/gmane.comp.version-control.git/247660/focus=248171 Neither here: http://thread.gmane.org/gmane.comp.version-control.git/247660/focus=248146 Nor here: http://thread.gmane.org/gmane.comp.version-control.git/247660/focus=248195 Nor here: http://thread.gmane.org/gmane.comp.version-control.git/247660/focus=248205 Not an ass here: http://thread.gmane.org/gmane.comp.version-control.git/247660/focus=248213 And not here either: http://thread.gmane.org/gmane.comp.version-control.git/247660/focus=248236 Then Junio *suddenly* changed his mind (B): http://thread.gmane.org/gmane.comp.version-control.git/247660/focus=248242 That is the sequence of mails (A..B) where I responded, and I wasn't an ass in eithe one of those, so whatever made Junio change his mind happened in that interum, and it wasn't me being an ass. I bet you made that statement without even botherting to read the thread. Go on, read the thread, tell where exactly me being an ass made Junio change his mind from A, to B. Nah, you wouldn't do that, backing up your claims take time, and you are not willing to spend time on this issue. Even if you were to try to back up your claim, you couldn't, becasue it's not true. It's much easier to just throw good sounding baseless claims and walk away. Felipe, stop this stupid blaming of everybody but yourself. Show me evidence that this decision was my fault. Junio certainly hasn't said so. You just have no idea what we are talking about. You make absolutely everything be this horrible disaster, you redefine words (regression) to be whatever you need/want them to be to be git-remote-hg and git-remote-bzr will likely break in Git v2.0 in certain situations where they wouldn't in v1.9, or v1.8. Call it whatever you want. I call that a regression. Seriously. Don't try to make this about Junio somehow being the problem. So Junio is perfect. Got it. If you don't have the time to actually read the rationale behind Junio's decision, how would you even know he made the right one? You are just blindly assuming he is right, and therefore he is not the problem. What if he was wrong? Nah, that's impossible. Right? -- 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: Should git-remote-hg/bzr be part of the core?
Felipe Contreras wrote: Linus Torvalds wrote: Felipe, stop this stupid blaming of everybody but yourself. Show me evidence that this decision was my fault. Junio certainly hasn't said so. You just have no idea what we are talking about. Here, let me show you. Junio, can you answer these questions? 1) What is missing from git-remote-hg/bzr in order for them to be considered to be merged to the core? 2) If a different maintainer steps up, would you consider reconsider merging them to the core? 3) Is there any chance that in the future you would consider them after they are more mature, and/or perhaps with a different maintainer? Unless Junio changes his mind again, the answers to those questions should be clear already to the people following the discussion (i.e. not you). -- 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: Should git-remote-hg/bzr be part of the core?
On 05/12/2014 01:34 AM, Felipe Contreras wrote: Recently Junio said he was willing to hear the opinion of other people regarding the move from contrib to the core[1]. This move is already under way, but suddenly Junio changed his mind. I agree with Junio. There are good technical arguments for and against moving git-remote-hg out of contrib. Those arguments were discussed at length and I think their weight is on the side of not moving it. But there are two other (in my opinion, stronger) reasons for keeping git-remote-hg out of the core: 1. That subproject has not been maintained to the standards of the Git project; specifically, Git project standards include good commit messages and a willingness to engage with the community on a friendly and constructive way and to welcome feedback. Because of your confrontational and nit-picking style, Felipe, many people who have tried to help you improve your work are rebuffed and end up giving up out of frustration or exhaustion. Because of this, your commits do not benefit from the usual amount of help from the community and therefore their quality is not as high as required for commits to core Git. 2. Moving git-remote-hg into the core would require even *more* of your presence on the Git mailing list. But your very presence is detrimental to the rest of the community. You insult and frustrate people who are trying to help you. You attribute malign motivations to people who are trying to be scrupulously fair. You string out enormous threads of nit-picking, legalistic argumentativeness that have little to do with the real issues at hand. The last big Felipe eruption in the summer of 2013 caused an enormous amount of strife, wasted an inordinate amount of time of other community members, and caused at least one valued contributor to temporarily rage-quit the community. That episode only ended when Junio asked you to leave the community [1], which, thankfully, you did for a while. After you left, the atmosphere of the mailing list soon returned to its usual friendly, collegial, and efficient norm. Recently you returned to the mailing list. In my opinion everybody on the list, including especially Junio, interacted with you in a very polite and businesslike manner. I believe you were given an honest chance at a fresh start in the community. I wish you had taken it. The Git project could really benefit from the help of a skilled and energetic developer like you! But it didn't take long before you started the same theatrics again. And now again, dealing with your caustic attitude is wasting an order of magnitude more time of the other core developers than your contributions could possibly bring in benefits. For me, the conclusion is unfortunate but clear: Felipe Contreras is (by far) a net liability to the Git project. Specifically: * The Git project will progress faster without you because the other contributors will have to waste less time dealing with your antics. * The Git community will grow faster without you, because your presence will not cause existing contributors to withdraw and dissuade new contributors from joining. * The community will be a lot more pleasant without you. Therefore, I am happy that you have apparently decided to split git-remote-hg into a separate project. I wish you success with the project and I see no reason that it shouldn't continue to be successful. But I am glad that I will not have to interact with you anymore. [...] Does it make sense to you that you get thrown in jail for a crime you haven't committed merely because someone thinks it's likely you will? Being the leader of your own valuable open-source project is nothing like jail. It is an opportunity for you to shine in an environment that is more suited to your personality. Given the huge amount of work I've put in these remote helpers, and the fact that Junio said since day 1 he wanted these in the core[5] (and I was operating under that assumption), I think the demotion back to the contrib area (and therefore out-of-tree) should be made carefully, and not from one day to he next as it happened. None of the work was wasted. git-remote-hg can live on. This email is written in sorrow, not in anger. Felipe, you seem to have so much potential. If you would put as much effort in conducting social interactions as you do in coding, the whole balance would change entirely, and any software project would be happy to have you. With all my heart I truly wish you the best in your future endeavors. Michael [1] http://article.gmane.org/gmane.comp.version-control.git/227750 -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- 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: Should git-remote-hg/bzr be part of the core?
2014-05-12 10:12 GMT+02:00 Felipe Contreras felipe.contre...@gmail.com: Felipe Contreras wrote: Linus Torvalds wrote: Felipe, stop this stupid blaming of everybody but yourself. Show me evidence that this decision was my fault. Junio certainly hasn't said so. You just have no idea what we are talking about. Here, let me show you. I suspect Linus had a reason not to include the mailing lists in the first place and make a huge public discussion, but instead wrote to you personally. I guess this is just Linus desire not to waste the time of everybody as he learned that these discussions are fruitless sometimes. Junio C Hamano wrote [in another thread]: I would not mind asking the others, as your discussion tactic seems to be repeated voices start sounding like a chorus, and a chorus is project concensus. Those who are observing from the sideline, please raise your hand if you think the three-line Clarification Felipe gave us is a fair and accurate clarification. Anybody? I also do not mind seeing hands raised of those who do not agree, even though I already know that they would be a silent majority. I think Junio is behaving very professional unlike you, Felipe. This includes being polite and very patient. Also this includes weighting different reasons to make informed rational decisions. Git being a project widely used and people trusting it for their work needs to have high quality and cannot go left today and go right tomorrow, but most of the decisions are done long-term. Felipe, this may be the reason, why you think nothing changes. It's just slower than you'd like, but with more thoughts weighted. Junio, I think you're doing an awesome job in maintaining Git and leading the community. Stefan -- 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: Should git-remote-hg/bzr be part of the core?
Michael, Thank you for writing this, I have to see I agree completely. As a mostly lurker on this list, I tend to skip any thread Felipe is participating in, as it tends to quickly spiral out of control. This is also the main reason for me not to actively participate a bit more, I prefer reasonable discussions over fighting. On ma, 2014-05-12 at 11:42 +0200, Michael Haggerty wrote: On 05/12/2014 01:34 AM, Felipe Contreras wrote: Recently Junio said he was willing to hear the opinion of other people regarding the move from contrib to the core[1]. This move is already under way, but suddenly Junio changed his mind. I agree with Junio. There are good technical arguments for and against moving git-remote-hg out of contrib. Those arguments were discussed at length and I think their weight is on the side of not moving it. But there are two other (in my opinion, stronger) reasons for keeping git-remote-hg out of the core: 1. That subproject has not been maintained to the standards of the Git project; specifically, Git project standards include good commit messages and a willingness to engage with the community on a friendly and constructive way and to welcome feedback. Because of your confrontational and nit-picking style, Felipe, many people who have tried to help you improve your work are rebuffed and end up giving up out of frustration or exhaustion. Because of this, your commits do not benefit from the usual amount of help from the community and therefore their quality is not as high as required for commits to core Git. 2. Moving git-remote-hg into the core would require even *more* of your presence on the Git mailing list. But your very presence is detrimental to the rest of the community. You insult and frustrate people who are trying to help you. You attribute malign motivations to people who are trying to be scrupulously fair. You string out enormous threads of nit-picking, legalistic argumentativeness that have little to do with the real issues at hand. The last big Felipe eruption in the summer of 2013 caused an enormous amount of strife, wasted an inordinate amount of time of other community members, and caused at least one valued contributor to temporarily rage-quit the community. That episode only ended when Junio asked you to leave the community [1], which, thankfully, you did for a while. After you left, the atmosphere of the mailing list soon returned to its usual friendly, collegial, and efficient norm. Recently you returned to the mailing list. In my opinion everybody on the list, including especially Junio, interacted with you in a very polite and businesslike manner. I believe you were given an honest chance at a fresh start in the community. I wish you had taken it. The Git project could really benefit from the help of a skilled and energetic developer like you! But it didn't take long before you started the same theatrics again. And now again, dealing with your caustic attitude is wasting an order of magnitude more time of the other core developers than your contributions could possibly bring in benefits. For me, the conclusion is unfortunate but clear: Felipe Contreras is (by far) a net liability to the Git project. Specifically: * The Git project will progress faster without you because the other contributors will have to waste less time dealing with your antics. * The Git community will grow faster without you, because your presence will not cause existing contributors to withdraw and dissuade new contributors from joining. * The community will be a lot more pleasant without you. Therefore, I am happy that you have apparently decided to split git-remote-hg into a separate project. I wish you success with the project and I see no reason that it shouldn't continue to be successful. But I am glad that I will not have to interact with you anymore. [...] Does it make sense to you that you get thrown in jail for a crime you haven't committed merely because someone thinks it's likely you will? Being the leader of your own valuable open-source project is nothing like jail. It is an opportunity for you to shine in an environment that is more suited to your personality. Given the huge amount of work I've put in these remote helpers, and the fact that Junio said since day 1 he wanted these in the core[5] (and I was operating under that assumption), I think the demotion back to the contrib area (and therefore out-of-tree) should be made carefully, and not from one day to he next as it happened. None of the work was wasted. git-remote-hg can live on. This email is written in sorrow, not in anger. Felipe, you seem to have so much potential. If you would put as much effort in conducting social interactions as you do in coding, the whole balance would change entirely, and any software project would be happy to have you. With all my heart I truly wish you the
Re: Should git-remote-hg/bzr be part of the core?
Michael Haggerty wrote: On 05/12/2014 01:34 AM, Felipe Contreras wrote: Recently Junio said he was willing to hear the opinion of other people regarding the move from contrib to the core[1]. This move is already under way, but suddenly Junio changed his mind. I agree with Junio. There are good technical arguments for and against moving git-remote-hg out of contrib. Saying you agree with Junio is content-free. You have to say *why* you agree. You mention there are good technical arguments against the graduation of the tools. Surely if you have analyzed those arguments enough to form an opinion aligned with Junio's, it should be easy to provide a short summary of those good technical arguments. Can you do that? 1. That subproject has not been maintained to the standards of the Git project; The quality of the subjproject has not been called into question, stop taiting the discussion with red herrings. 2. Moving git-remote-hg into the core would require even *more* of your presence on the Git mailing list. That's not true. I sent my patches at my own pace, it doesn't matter if they are in contrib or in the core, I would have kept sending them at the same pace. I have addressed all issues and responded to all questions as if they were already part of the core, which is why they have more quality than other tools already in the core. I only stopped doing that when Junio changed the direction we had since day one. Also a red herring. [...] Does it make sense to you that you get thrown in jail for a crime you haven't committed merely because someone thinks it's likely you will? Being the leader of your own valuable open-source project is nothing like jail. It is an opportunity for you to shine in an environment that is more suited to your personality. Don't be ridiculous. There is no out-of-tree tool that could possibly compete in popularity against core tools. If you think being out-of-tree is not a negative, lets throw out git-archimport, git-quiltimport, git-p4, git-cvs, git-svn. Let us give them an opportunity to shine. You know that those tools do better in the core, and you know git-remote-hg/bzr would do better in the core. Don't act as if you didn't. This email is written in sorrow, not in anger. Felipe, you seem to have so much potential. If you would put as much effort in conducting social interactions as you do in coding, the whole balance would change entirely, and any software project would be happy to have you. With all my heart I truly wish you the best in your future endeavors. Let's see how sincere you are in your sentiment. I'll reply to you personally about the points that I consider to be red herrings and ad hominem attacks so we don't taint the dicussion. If you don't reply I'll know you were not being sincere. Cheers. -- 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: Should git-remote-hg/bzr be part of the core?
Michael Haggerty mhag...@alum.mit.edu writes: This email is written in sorrow, not in anger. Felipe, you seem to have so much potential. If you would put as much effort in conducting social interactions as you do in coding, [...] I think that's where you are mistaken. We are not talking about a lack of effort here. It is just not spent conducively. -- David Kastrup -- 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: Should git-remote-hg/bzr be part of the core?
On 05/12/2014 12:37 PM, Felipe Contreras wrote: Michael Haggerty wrote: On 05/12/2014 01:34 AM, Felipe Contreras wrote: Recently Junio said he was willing to hear the opinion of other people regarding the move from contrib to the core[1]. This move is already under way, but suddenly Junio changed his mind. I agree with Junio. There are good technical arguments for and against moving git-remote-hg out of contrib. Saying you agree with Junio is content-free. You have to say *why* you agree. Actually, I don't have to, not even if you tell me to. And anyway, I think the small technical advantages/disadvantages of the possible different locations for git-remote-hg are dwarfed by the social considerations so I think dwelling on technical considerations would sidetrack this discussion. [...] 1. That subproject has not been maintained to the standards of the Git project; The quality of the subjproject has not been called into question, stop taiting the discussion with red herrings. On the contrary. I just called the quality of the subproject into question, and I stated exactly which aspects of its quality I find to be inadequate in the text that you omitted from your response: [...] specifically, Git project standards include good commit messages and a willingness to engage with the community on a friendly and constructive way and to welcome feedback. Because of your confrontational and nit-picking style, Felipe, many people who have tried to help you improve your work are rebuffed and end up giving up out of frustration or exhaustion. Because of this, your commits do not benefit from the usual amount of help from the community and therefore their quality is not as high as required for commits to core Git. Commit quality very definitely includes the quality of log messages and the quality of the discussion on the mailing list that can inform people working on those areas of the code in the future. 2. Moving git-remote-hg into the core would require even *more* of your presence on the Git mailing list. That's not true. I sent my patches at my own pace, it doesn't matter if they are in contrib or in the core, I would have kept sending them at the same pace. I have addressed all issues and responded to all questions as if they were already part of the core, which is why they have more quality than other tools already in the core. I only stopped doing that when Junio changed the direction we had since day one. Also a red herring. OK, maybe you are technically correct there. There is indeed a difference between and =. Let me amend my claim: 2. Moving git-remote-hg into the core would require you to continue your presence on the Git mailing list. [...] Does it make sense to you that you get thrown in jail for a crime you haven't committed merely because someone thinks it's likely you will? Being the leader of your own valuable open-source project is nothing like jail. It is an opportunity for you to shine in an environment that is more suited to your personality. Don't be ridiculous. There is no out-of-tree tool that could possibly compete in popularity against core tools. I never made that claim. I claimed that it was nothing like jail, and I stand by that claim. I also think that the Git community is a place unsuited to someone with your personality, and that you might truly shine more in an independent project. If you think being out-of-tree is not a negative, lets throw out git-archimport, git-quiltimport, git-p4, git-cvs, git-svn. Let us give them an opportunity to shine. In my opinion, the technical issues for moving importers are not overwhelming. Therefore, I don't have a strong opinion about the future of these other tools, because their presence in the Git tree is not coupled to the continued presence of a problematic subproject maintainer. You know that those tools do better in the core, and you know git-remote-hg/bzr would do better in the core. Don't act as if you didn't. I maintain cvs2svn/cvs2git outside of the Git core. In fact, one of cvs2git's competitors, git cvsimport *is* in Git core. Nevertheless, users have no problem finding cvs2git, and I think it's safe to say that its reputation exceeds that of git cvsimport, even though some people accidentally use git cvsimport out of laziness. People who need to do a conversion from A to B only have to Google for A B and they will find the best conversion tools pretty easily. If the tools are packaged for their OS then they are just an apt-get install away from happiness. And given that tools like cvs2git or git-remote-hg, don't even need to be compiled, users can install them pretty easily themselves. This email is written in sorrow, not in anger. Felipe, you seem to have so much potential. If you would put as much effort in conducting social interactions as you do in coding, the whole balance would change entirely, and any software project would be happy
Re: Should git-remote-hg/bzr be part of the core?
Stefan Beller wrote: 2014-05-12 10:12 GMT+02:00 Felipe Contreras felipe.contre...@gmail.com: Felipe Contreras wrote: Linus Torvalds wrote: Felipe, stop this stupid blaming of everybody but yourself. Show me evidence that this decision was my fault. Junio certainly hasn't said so. You just have no idea what we are talking about. Here, let me show you. I suspect Linus had a reason not to include the mailing lists in the first place Huh? He did include the mailing lists in the first place[1]. Either something is wrong with the mailing list, or somebody is removing the mails. You can see the full thread in the git-fc mailing list, and there you can see the git ml is included in all the mails, including the one you just sent, where you included the git ml, and it doesn't show in the archives. and make a huge public discussion, but instead wrote to you personally. I guess this is just Linus desire not to waste the time of everybody as he learned that these discussions are fruitless sometimes. Don't you agree that including transparent bridges for Mercurial and Bazaar distributed by default would be benefitial to the project? If a discussion could potentially lead to them being included, I'd say that wouldn't be fruitless, but it's *precisely* what our end users would like us to be discussing right now. Junio C Hamano wrote [in another thread]: I would not mind asking the others, as your discussion tactic seems to be repeated voices start sounding like a chorus, and a chorus is project concensus. Those who are observing from the sideline, please raise your hand if you think the three-line Clarification Felipe gave us is a fair and accurate clarification. Anybody? I also do not mind seeing hands raised of those who do not agree, even though I already know that they would be a silent majority. I think Junio is behaving very professional unlike you, Felipe. This includes being polite and very patient. Also this includes weighting different reasons to make informed rational decisions. Where is he weighting the different reasons? I've asked him multiple times to provide those reasons. He mensions there's one, but he doesn't say which one it is. If I haven't see this reason, how do you know he is weighing different ones? Git being a project widely used and people trusting it for their work needs to have high quality and cannot go left today and go right tomorrow, but most of the decisions are done long-term. Yes. What is right, and what is left in this example? Presumably going right would be to include these tools in the core, but that would imply that he plans to go left in the future. But he hasn't said that. So what makes you think the project would go left in the future? Felipe, this may be the reason, why you think nothing changes. It's just slower than you'd like, but with more thoughts weighted. Really? I'll issue the same challenge I've issued to many people. Name a single important change in Git (was one way before, it's another way now) that has happened in the last 5 years. And by important I mean for starters users noticed it. You won't be able to, because nothing ever changes. Junio, I think you're doing an awesome job in maintaining Git and leading the community. Maintaining, yes, but leading? Leading it where? [1] https://groups.google.com/forum/#!original/git-fc/Clhss-fXS2k/9UtiilJ2WQ4J -- 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: Should git-remote-hg/bzr be part of the core?
Michael Haggerty wrote: On 05/12/2014 12:37 PM, Felipe Contreras wrote: Michael Haggerty wrote: On 05/12/2014 01:34 AM, Felipe Contreras wrote: Recently Junio said he was willing to hear the opinion of other people regarding the move from contrib to the core[1]. This move is already under way, but suddenly Junio changed his mind. I agree with Junio. There are good technical arguments for and against moving git-remote-hg out of contrib. Saying you agree with Junio is content-free. You have to say *why* you agree. Actually, I don't have to, Then there's no point in reading what else you have to say. Whatever reasons you might have to agree with Junio are known only to you, thus your agreement is opaque and meaningless. The quality of the subjproject has not been called into question, stop taiting the discussion with red herrings. On the contrary. I just called the quality of the subproject into question, and I stated exactly which aspects of its quality I find to be inadequate in the text that you omitted from your response: I'll wait until somebody else calls into question the quality. Preferably somebody who backs up his claims with evidence. OK, maybe you are technically correct there. There is indeed a difference between and =. Let me amend my claim: 2. Moving git-remote-hg into the core would require you to continue your presence on the Git mailing list. That is another red herring. Moving them back to the contrib/ area which is what Junio proposed would also require my presence on the list. Is that what you want? And there's the transport helper, and bash completion, and the zsh completion. [...] Does it make sense to you that you get thrown in jail for a crime you haven't committed merely because someone thinks it's likely you will? Being the leader of your own valuable open-source project is nothing like jail. It is an opportunity for you to shine in an environment that is more suited to your personality. Don't be ridiculous. There is no out-of-tree tool that could possibly compete in popularity against core tools. I never made that claim. I claimed that it was nothing like jail, and I stand by that claim. In the context of the Git project what is the *worst* thing the maintainer can do to a piece of code but delete it? So I think you are right, the jail analogy is not correct; it's *execution*. You know that those tools do better in the core, and you know git-remote-hg/bzr would do better in the core. Don't act as if you didn't. People who need to do a conversion from A to B only have to Google for A B and they will find the best conversion tools pretty easily. Let's test that hypothesis: Google: how to conver mercurial to git * Convert Mercurial project to Git - Stack Overflow (NOPE) * Converting a Mercurial repository to Git (YEAP: one among many) Oh, but would you look at that: This script will actually be shipping with git at some point, which gives it some credibility in my book. * frej/fast-export ยท GitHub (NOPE) * Hg-Git Mercurial Plugin (NOPE) * Converting Hg repositories to Git (NOPE) * Converting from Mercurial to Git - Hivelogic (NOPE) * Converting Repositories From Git to Mercurial (NOPE) * hg-fast-export: convert Mercurial repositories (NOPE) * Converting Mercurial (Hg) to Git Repository on Mac (NOPE) * Bitbucket: Converting Hg repositories to Git (NOPE) So pretty much hypoethesis failed. That fact that you would even think people would quickly find about git-remote-hg shows exactly how detached you are from the problem. If the tools are packaged for their OS then they are just an apt-get install away from happiness. Oh, they are packaged already (as part of Git). Moving them out-of-tree will make it much more difficult for users to find them, and install them. It will take time for them to be packaged, if it happens at all. Let's see how sincere you are in your sentiment. I'll reply to you personally about the points that I consider to be red herrings and ad hominem attacks so we don't taint the dicussion. If you don't reply I'll know you were not being sincere. Jumping at your every demand is not a prerequisite for being sincere. I spent a lot of time writing that mail. Not sincere it is then. -- 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: Should git-remote-hg/bzr be part of the core?
Paolo Ciarrocchi wrote: On Mon, May 12, 2014 at 11:42 AM, Michael Haggerty mhag...@alum.mit.eduwrote: Felipe, you seem to have so much potential. If you would put as much effort in conducting social interactions as you do in coding, the whole balance would change entirely, and any software project would be happy to have you. With all my heart I truly wish you the best in your future endeavors. I really *love* this paragraph. Felipe, you are a brilliant developer and you put a lot of work trying to improve GIT. Thanks. While I agree with you the this project is managed in a bit conservative way Only a bit? I don't think I've been involed in a more conservative open source project. you should really improve how you communicate with other developers, it's such a pity your contributions are some times not included in git.git just because of your attitude. But that's a theory. You don't *know* that they would have been included had I used a different attitude. In fact, people have contacted me privately saying similar things, and I'll give you the same challenge I gave them. If you think a different attitude would get my patches in, how about *you* write the commit messages and the discussions for one of my stuck patch series. I'll send the mails as if I had written the content. If you are right, the different attitude would make the patches land in no time. I still think it's not right for patches to be rejected simply because of attitude, but I would accept you were right. But I think you already know that won't happen, the patches still won't get in, not because of the attitude, but because of what they are trying to do: change things. So if I *know* certain feature would be useful for Git users, I've listened to all the comments, and addressed all the problems, why would I give up on those patches? Why would I work on something more boring that won't benefit users as much but would have higher chances of getting in? I'm doing this on my own free time, I can choose to do whatever I want, in whatever way I want, so no, I'll keep working on what I think is important. If you really think the patches can be accepted with a different attitude, by all means, let's do the experiment and find out. -- 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: Should git-remote-hg/bzr be part of the core?
Felipe Contreras felipe.contre...@gmail.com writes: Michael Haggerty wrote: On 05/12/2014 12:37 PM, Felipe Contreras wrote: Michael Haggerty wrote: On 05/12/2014 01:34 AM, Felipe Contreras wrote: Recently Junio said he was willing to hear the opinion of other people regarding the move from contrib to the core[1]. This move is already under way, but suddenly Junio changed his mind. I agree with Junio. There are good technical arguments for and against moving git-remote-hg out of contrib. Saying you agree with Junio is content-free. You have to say *why* you agree. Actually, I don't have to, Then there's no point in reading what else you have to say. Whatever reasons you might have to agree with Junio are known only to you, thus your agreement is opaque and meaningless. Let me spell it out for you. Michael states I agree with Junio. There are good technical arguments for and against moving git-remote-hg out of contrib. Since there are arguments for both sides, the decision boils down to a judgment call. Michael states that he condones the choice Junio made, based on the reasoning he gave. Does that mean that he examined the choice with equal detail and remembers every detail? No. In such a decision, both technical expertise as well as trust based on a past record factor in. The quality of the subjproject has not been called into question, stop taiting the discussion with red herrings. On the contrary. I just called the quality of the subproject into question, and I stated exactly which aspects of its quality I find to be inadequate in the text that you omitted from your response: I'll wait until somebody else calls into question the quality. Preferably somebody who backs up his claims with evidence. The evidence for the toxicity of dealing with subprojects maintained by you is all over the mailing list. You are obviously blind to it yourself. Feel free to print out a few salient threads where you argue in favor of your points and ask someone you trust about his impression about how you come across. Let's see how sincere you are in your sentiment. I'll reply to you personally about the points that I consider to be red herrings and ad hominem attacks so we don't taint the dicussion. If you don't reply I'll know you were not being sincere. Jumping at your every demand is not a prerequisite for being sincere. I spent a lot of time writing that mail. Not sincere it is then. That kind of exchange is what you should show some of your personal friends and ask them whether it will likely lead to the desired understanding and ultimately reaction in the reader. Because that is what communication is about. Of course, one can try bypassing understanding and directly aim for a particular reaction: that is being manipulative. You are hardly in danger of being manipulative: that would require a basic understanding of people. So all you can really aim for is understanding: presenting your best case. Forget about rhetorics and the like: you suck at them, and a technical audience is easily annoyed by them even when they are employed well. And if a calm presentation does not lead others to the same conclusion that you would draw, deal with the consequences. Throwing tantrums will only bias people against you when you have the next case to present. -- David Kastrup -- 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: Should git-remote-hg/bzr be part of the core?
On 05/12/2014 02:29 PM, Felipe Contreras wrote: Michael Haggerty wrote: [...] 2. Moving git-remote-hg into the core would require you to continue your presence on the Git mailing list. That is another red herring. Moving them back to the contrib/ area which is what Junio proposed would also require my presence on the list. Is that what you want? No, actually my preference is that git-remote-hg be separated from the Git project altogether, for the reasons that I stated earlier. Michael -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- 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: Should git-remote-hg/bzr be part of the core?
On Mon, May 12, 2014 at 2:48 PM, Felipe Contreras felipe.contre...@gmail.com wrote: Paolo Ciarrocchi wrote: On Mon, May 12, 2014 at 11:42 AM, Michael Haggerty mhag...@alum.mit.eduwrote: While I agree with you the this project is managed in a bit conservative way Only a bit? I don't think I've been involed in a more conservative open source project. you should really improve how you communicate with other developers, it's such a pity your contributions are some times not included in git.git just because of your attitude. But that's a theory. You don't *know* that they would have been included had I used a different attitude. Well, you could at least try to act and communicate differently. In fact, people have contacted me privately saying similar things, and I'll give you the same challenge I gave them. If you think a different attitude would get my patches in, how about *you* write the commit messages and the discussions for one of my stuck patch series. I'll send the mails as if I had written the content. No, sorry but I'm NOT interested in lying to git community. Ciao, -- Paolo -- 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: Should git-remote-hg/bzr be part of the core?
2014-05-12 15:45 GMT+02:00 Paolo Ciarrocchi paolo.ciarroc...@gmail.com: No, sorry but I'm NOT interested in lying to git community. It's not lying. See the Helped-By: lines in git.git commits. Often the help was formulating a correct and easy-to-understand commit message. -- 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: Should git-remote-hg/bzr be part of the core?
Paolo Ciarrocchi wrote: On Mon, May 12, 2014 at 2:48 PM, Felipe Contreras felipe.contre...@gmail.com wrote: Paolo Ciarrocchi wrote: On Mon, May 12, 2014 at 11:42 AM, Michael Haggerty mhag...@alum.mit.eduwrote: While I agree with you the this project is managed in a bit conservative way Only a bit? I don't think I've been involed in a more conservative open source project. you should really improve how you communicate with other developers, it's such a pity your contributions are some times not included in git.git just because of your attitude. But that's a theory. You don't *know* that they would have been included had I used a different attitude. Well, you could at least try to act and communicate differently. I have, it doesn't make a difference. In fact, people have contacted me privately saying similar things, and I'll give you the same challenge I gave them. If you think a different attitude would get my patches in, how about *you* write the commit messages and the discussions for one of my stuck patch series. I'll send the mails as if I had written the content. No, sorry but I'm NOT interested in lying to git community. Yeah, that's what I thought. I know what the result of such experiment would be though. -- 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: Should git-remote-hg/bzr be part of the core?
Michael Haggerty wrote: On 05/12/2014 02:29 PM, Felipe Contreras wrote: Michael Haggerty wrote: [...] 2. Moving git-remote-hg into the core would require you to continue your presence on the Git mailing list. That is another red herring. Moving them back to the contrib/ area which is what Junio proposed would also require my presence on the list. Is that what you want? No, actually my preference is that git-remote-hg be separated from the Git project altogether, for the reasons that I stated earlier. Exactly. So your point 2. is completely irrelevant to the contrb/ vs. core debate. -- 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
