On Dec 8, 2010, at 15:12, Trans wrote: > I would like some constructive appraisal. I recently offered some > patches to RubyGems. I feel I was making my best effort to contribute > some functionality to the code base that would be useful to > developers. But in this process, rather then feel a part of a > community effort, even if only a minor part, I felt rather skewered…
To begin with I would like to point out that you have deleted several of your comments forcing me to respond from memory and leaving their contents at the risk of "he-said, she-said". I have reordered these pull requests chronologically. > https://github.com/rubygems/rubygems/pull/8 I'm not sure what your complaint is here. The request is reasonable but you have not acted on it. It is your job to make your pull requests acceptable for contribution. > https://github.com/rubygems/rubygems/pull/12 Since you have deleted your comment stream I'll have to reconstruct your counter-arguments from memory. I have them out of order because this email is already up to 5K of text and I don't think it's worth my time to order them properly. I rejected plain-YAML gemspecs because it is not a type-safe data format, and that it increases maintenance burden of future RubyGems versions for the benefit of a small minority of users. I don't see anything unfair about this assessment. I asked if there were any non-ruby tools that used a YAML gemspec. If such a tool existed it might be a reason to consider this feature. You did not name any non-ruby tools that used a YAML gemspec, but you came up with some hypothetical ruby tools that could use this feature. You claimed that this feature was important because either RubyGems consumed too many resources or that it would not be available. In brief, I responded that if it's a ruby tool it can use RubyGems and that RubyGems resource burden is not too large. As of Ruby 1.9 RubyGems is always available. (Adding a feature to RubyGems specifically for Ruby 1.8 requires an overwhelming need.) I believe this is where I closed the ticket as you could not come up with a satisfactory reason for including plain-YAML gemspecs. You persisted, however and I continued to respond. You argued that it could be made "safer" and I referenced the past history of junk data in gemspecs and Jeremy Hindegardener's talk at RubyConf 2010 as a demonstration that it probably can't be made safer. You said it would be "more convenient" and I responded that I could not find a gem that used YAML in its .gemspec file in a few minutes of searching. I pointed out that the community has decided that the de-facto format for gemspec files is Ruby. I thought you would take my lack of discovery of YAML .gemspec files as an opportunity to show me a single project that used YAML in its gemspecs. This would demonstrate there was even a handful of RubyGems users who would benefit from this feature but you did not (or could not?). You pointed out ore which uses plain-YAML to create gemspecs and gems and used it as an argument in your favor. I responded that if ore supports this you should use ore as it does what you want already and requires no changes to RubyGems. Since you did not demonstrate that there was another RubyGems user who desires plain-YAML gemspecs I responded that there is only one person that wants this feature and that was not enough users to include it. I reiterated that the community has decided they prefer ruby. If you look at the download counts, people overwhelmingly prefer to use ruby to build gems. Hoe has 690,000 and Jeweler has 56,000. Ore has 453. You claimed that I did not understand the intent of your feature, but I was perfectly clear on that as both your initial description and the content of your patch were perfectly clear. For a feature to be added to RubyGems one of the requirements is that it cannot be implemented outside RubyGems. Ore shows that it is possible to implement this feature outside of RubyGems. I now have a full page and over 1.5k of summary in this email of our conversation past the point where I closed the issue. We had a long and thorough discussion of the issue but you could not bring up any reason for inclusion of plain-YAML gemspecs. I believe that my conduct in our conversation was fair and reasonable and that any unbiased reader would find it so. Again, your request for plain-YAML gemspecs is not suitable for inclusion in RubyGems It is not type-safe. It benefits a single user. It is adequately covered by functionality outside of RubyGems It increases the maintenance burden of RubyGems. If it were Dave Thomas, Chad Fowler, Jim Weirich or anyone else who had suggested this feature I would reject it for exactly these reasons as well. > https://github.com/rubygems/rubygems/pull/14 I gave you a frank assessment, approving your idea but rejecting your implementation, specifically of Gem::Resource. I recommended a Hash instead as it avoids the high run-time cost (which must be paid every time an installed gem is activated): > It appears that a resources Hash on Gem::Specification would be a better > solution. This implementation requires triple-dispatch. > (Gem::Specification#add_resource => Gem::Resource#add_resource => > #resource_name => Hash#[]= vs Gem::Specification#add_resource => Hash#[]=) You refused to budge on Gem::Resource saying the aliases were provided for convenience. You said your patch was not 100% complete. I rejected aliases again, I explained how to perform a feature-check for #add_resource (which is currently implemented for several things in #to_ruby) and pointed out that your tests do not require what you claimed to. I asked why you created a pull request if your code wasn't ready for commit. If you wish to have your idea reviewed you should come here to the mailing list. If you wish to have your incomplete implementation reviewed you should come here to the mailing list. You also continued to claim that Gem::Resource#hash and #eql? were required despite my statement that I had applied your patch, deleted these methods and had a successful run. In all, despite rejecting aliases and the implementation that required them you continued to fight for them, refusing to come to any compromise. Now that I have reviewed this again I have another reason to reject your implementation, the Ruby gemspec is run at gem load time and the creation of a new object and multiple-dispatch to set fields in it will be too slow in comparison to a simple hash. As I stated, your idea is great and had been discussed prior to submitted your pull request. Your implementation of Gem::Resource is rejected. It is too slow compared to a Hash and does not provide enough benefit. Gem::Specification#add_resource is great and fits well with existing Gem::Specification methods. At this point it's hard for me to determine what you are expecting. > I'm not sure why anyone would contribute to a Ruby project if it transpires > like this. But then maybe thats the way it is? As I said in pull request 12: RubyGems is a core component of the ruby community. Due to its core position it needs to have a conservative policy towards improvements and those improvements that are accepted need to have simple, concise and easy to maintain implementations. It is unreasonable to expect an admittedly incomplete patch would be accepted immediately. It is unreasonable to believe that an patch submitted to RubyGems would not undergo a thorough and critical review. When given a review it is your obligation to come to a compromise but you refuse to budge. You claim you were not given enough time to budge, but you were amply active in replying to my commentary for the past two days, and I have spent 10s of kilobytes and hours of time attempting to explain why your patches were rejected and what would make them acceptable. I will now respond to the remainder of the last comment on pull request 12: https://github.com/rubygems/rubygems/pull/12#issuecomment-601579 > What do you mean I didn't budge? I was trying to discuss the issue, and you > all get in a dither over it. (I mean really, consider one of the first things > you did was make a sharply worded remark about not changing style because I > dropped a then from an if. Which I later discover, btw, isn't a RubyGems code > style at all b/c then isn't used in many places. It is not worth our time to update the style on every file. If you check the history you will see that older RubyGems codes does not use then. It is required now. I believe there is another pull request mentioning this but it has been over three hours since I started writing this email now and I am can't be bothered to find it. > And don't even get me started on Ryan. That asshole spends his time cursing > at me on every other line for anything at all, like using inject (heaven > forbid!) or putting a blank comment line which I use as a device as a > reminder to go back and write docs. It's absolutely ridiculous. And unworthy > of an important project like Rubygems. Ryan may have been harsh in his critique of your code, but I don't recall he gave you any less critique than he did for the students he taught at the UW extension course. I don't recall that Ryan has ever called you an asshole. I'm know you are aware that Ryan and I work together on a daily basis, and I am certain that you have formed opinions of Ryan's opinion of you. I will clarify that this includes any private conversations we have had. (Knowing Ryan as we both do, however, this will change tomorrow when we meet.) > The fact is I was only ever providing my take on the matter, why I was > seeking to do it that way, I worked on it as part of what I'd like to see in > RubyGems. I don't work for you. You are not my employer. I submitted patches > that were geared toward use cases that I would make of RubyGems. Why would I > do anything else? I don't doubt the sincerity of your commits. I gave what I felt was a fair consideration of your ideas and responded appropriately. > Right or wrong, you guys didn't even allow for appropriate time to "budge". I consider two days of response on pull request 12 to be adequate time. I consider your frequent responses on pull request 14 to be adequate time. > All you and Ryan wanted to do was for me to say "yes sir, sorry sir! Hop to, > sir. I'll have those "fixes" to you by morning". I don't care how long you take. If you wish to stop and think about something then go ahead. I'm not sure what you wish to imply with your quotes around "fixes". Perhaps you mean my reasoning was illogical, but I believe I gave you logical reasons for rejection. Perhaps you are mocking me, I find that amusing. Perhaps you just don't understand that your code was not acceptable despite me going to great pains to explain how and why it was not. > We'll forget it. You all can enjoy YOUR "open source" project. I do not > "contribute to open source" project run by assholes. And now you have insulted me. > And honestly I am sorry if I am putting more of this on you right now then > you probably deserve. Ryan really is ten times worse. None the less this has > been a wholly frustrating experience. And I can only think that ultimately > these kinds of things will be very bad for Ruby in general. You are putting more of this on me than I deserve, and it's unfair. I've spent hours of my time trying to show you what was unacceptable in your patches and you have refused to acknowledge a single point. Now you're sending an email to the list to garner sympathy. I've now spent nearly four hours writing this response. You think you're frustrated? > Go ahead and blame we all you want. I don't calm to be wholly innocent. But I > do know that all I did was earnestly try to contribute to the improvement of > Gems and was essentially eviscerated for my troubles. No, you did not try to earnestly contribute. As soon as you sensed the slightest bit of resistance you immediately became defensive. You refused to budge on anything. This is not how you behave if you want to contribute. I did not eviscerate you, I gave your patches and ideas a critical review. It seems that you do not understand what a critical review is. You may not like it. I have gone through many and I did not like them either, but they have helped me become a better programmer. > Is this really what one should expect? It appears you have decided my rejection of 12 and 14 was because I have some personal vendetta against you. I believe I gave your ideas a fair consideration and commented on them accordingly. Not every change submitted can be included in RubyGems. In one of your comments on pull request 12 you said something like: > Necessity is the mother of invention, but everyone who has used a remote > control knows that convenience is where it's at. To which I responded: > PS: Restrict yourself to technical merits and avoid editorializing. The pull > request comments are here for the discussion of utility, usability and > maintainability of proposed changes. They are not to make undecipherable > editorial comments centered on necessity, invention and remote controls. It appears you don't actually want to have a discussion on the grounds of utility, usability or maintainability but instead you wish to be right and you wish to get your way. Whenever I would counter one of your arguments you would shift to a new different argument. When I exhausted all those you claimed I didn't understand you despite understanding you perfectly clearly. Finally you attempt to appeal to this list to garner sympathy. Your evasive behavior and martyrdom are exceptionally frustrating. Despite the deletion of the majority of your commentary in the pull requests which should reasonably explain the reasons for my frustration, I am again going to say that when you don't get your way you present yourself as a martyr and throw a fit as you have done in this instance. Throwing a fit when you don't get your way is a behavior most people have grown out of by the time they're 10. You're three times that age now. I tried to give you the benefit of the doubt when you submitted your pull requests. I hope that my comments here and on the pull requests adequately show that to the other readers of this email and this list. You've reacted exactly this way before and, unfortunately, you will probably continue to do so. Based on your behavior I'm not certain I wish to continue to review your contributions without rejecting them outright. It certainly isn't worth my time as I've lost an entire day of productive work dealing with your attempt at martyrdom (four hours on this email alone). I can only hope that you will actually stop contributing. Sincerely, Eric Hodel The "asshole" PS: I'm not going to respond to any of your further emails on this thread, so feel free to call me whatever additional names you like! _______________________________________________ Rubygems-developers mailing list http://rubyforge.org/projects/rubygems Rubygems-developers@rubyforge.org http://rubyforge.org/mailman/listinfo/rubygems-developers
