First let me thank everyone who responded. Some of the comments were very helpful and I will take stock of them in the future. I may yet respond to some of them, but I would like to respond to Eric now, since he took the time to make a point by point reanalysis of our conversations. Just to clear, my overall issues with this have more to do with Ryan than anyone else. I think thats obvious, but I do still think there were some discouraging factors with some of the other conversations too.
On Dec 10, 1:55 am, Eric Hodel <drbr...@segment7.net> wrote: > 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 did. I actually attempted to delete the all the commits altogether, but it turns out that is not possible. It gets to a point were I would rather delete them and forget the whole affair. > 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. That request came only after I may a snarky remark about no one commenting on the patch. From my perspective it appeared that when I did something acceptable, it was being ignored. When I did something that wasn't it was an opportunity to "attack" (of course that perception almost entirely has to do with Ryan). > > 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. And I explained that it is as type-safe b/c the format is parsed by the code. Putting a type `!` line in the YAML doesn't make an iota of difference. But you never explained to me how it would. Of course there is always maintenance, but in the scheme of things, this one is pretty small. What was it about 20-30 lines of code? > 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. You are asking for something that can't exist b/c there is no such thing as a plain YAML gemspec. I was trying to create such a thing so such tools could exist. I gave you three use cases, two where it could be helpful if loading Rubygems were unnecessary (a web search app gathering info about projects and a web-app to edit the YAML gemspec), and a case where it can't be loaded (Setup.rb is an alternative installer, it does not make any sense for it to load rubygems, but it could utilize a pure YAML gemspec). > 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. The thing is that you dismissed those use cases so quickly and so summarily, that it seemed to me that you weren't really giving it that much thought. I also made it very clear that good bit of the motivation for this patch came from the fact that the Bundler folks have been pushing people to move to hand-edited gemspecs. I was actually surprised to learn that I was mistaken in thinking that was also the stance of the Rubygems team. > 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. Actually, I argued that it wasn't any less safe then it was already. I only made a passing parenthetical comment that if type safety is a concern that improvement could be made --but that applied to the current design in general, not this particular feature. > 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?). Again, I did show you and you simply dismissed those cases as people "refusing to conform to best practices". Ore was the most obvious example --it was so important for that developer that they went out of their way to create a whole project devoted to doing it. > 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. This is unreasonable argument. I can't provide examples of something that CAN'T exist. Both Ore and my own tools took many man-hours to make it possible --so that's not something one can reasonably expect of the common community. Clearly most people are not going to do that. The community is not getting much of an option. Ore is brand new. So it's not really a fair indication. > 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. No. I only clarified my argument b/c some of your statements indicated that you may not have understood a particular aspect of the intent. I was not saying "you did not", but "if you you did not". > 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. That's a fair argument. And I can accept that. That's not to say their aren't disadvantages to the lack of mainstream support, but its enough. And thanks to Gems plugin support it is very doable. > 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. I mostly agree. My only complaint with our conversation is what I mentioned above. You seemed very short with me, as if you were annoyed to have to discuss this, along with a rush to judgment --actually more than that, the judgment seemed predetermined, so your end of conversation always seemed stilted --it didn't feel like an earnest conversation/debate. > Again, your request for plain-YAML gemspecs is not suitable for inclusion in > RubyGems Well, if you want to reiterate... > It is not type-safe. I don't see how that is true. > It benefits a single user. Not a fair assessment. > It is adequately covered by functionality outside of RubyGems Okay. > It increases the maintenance burden of RubyGems. It's small. But at this point it doesn't matter any way ;-) > 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. I am not saying you would not. I had no problem with your assessments. However I suspect you would have discussed the topic with them in a more open-minded manner. > > 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. I didn't refuse. I was discussing it. This is what I mean about a rush to judgment. > 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. Yes. And for the record that was partly b/c I was already tired from the previous discussion. I wasn't even sure I'd bother with it at all at that point. But I decided to go ahead and test the water with what I had so far. I specifically did not expect the push to be accepted AS IS, only to get the ball rolling and get feedback. I admitted that I prematurely pushed the commit. So what was the point of berating me for obviously unfinished things, like an empty comment or a TODO (clearly commented) to add URL validation? > 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. What? You are confused. I gave an example of a failing test when I deleted the #hash method. All you said was "there must be some other bug". Well that was less than two days ago. How fast do you think I work? When did I have time to "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. Honestly, I could care less about the exact implementation. I just wanted to discuss the features I was attempting to address with it. It may be possible to address those with a different implementation. Again why is there such a rush? The aliases were for convenience of short forms. I know you don't take much stock in it, but the idea was simply to make specifying these resource very easy. E.g. It might look like: resources :mail => ..., :chat => ..., :docs => ... Rather then the less orderly resources :mailing_list => '...', :chatroom => '...', :documentation => '...' The sort forms are much easier to remember. So I don't so much care about having many various aliases, but I do care about the short forms. Clarifying that, I was hoping a compromise could be found. But you up and closed the ticket before I have time to relay that (and Ryan had further killed my desire to even try any more). The other issue was arbitrary entries. Ryan seems to be against those (though it's hard to tell b/c he wouldn't actually say what his problem was half the time, only that my code was "wrong".) A hash would allow that, but if that's not desirable either, then you may as well simply add a entry to the gemspec for each url, akin to homepage. e.g. maling_list '...; chatroom '...' documentation '...' Personally, I think the lack of ability to add arbitrary entries would be regrettable. > 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. Is it clearer now? > > 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. I never expected that, and this topic has nothing to do with that. > It is unreasonable to believe that an patch submitted to RubyGems would not > undergo a thorough and critical review. Indeed! "thorough" and "critical", not "summarily" and "disrespectful". > 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. Does he say "fuck" all the time to them? > 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. Ha Ha. That's rich. Does that just prove your expectation? > 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. But what about the purpose of a conversation? Is this a one way street where you tell me what you don't want and I run off and code for you? Is it not important to converse and come to a conclusion? I am not unreasonable. I may be somewhat suborn, but I do relent to logic. But I expect an openness to possibilities in discussion. That's what I mean by a project I don't want to contribute to. > > 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. My apologies. I shouldn't not have used that term but at the time I felt a need to be a more forceful than saying literally "inconsiderate and rude". (And again I emphasis that almost entirely applies to Ryan). > > 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. That's what is unfair to me. How can two days be enough time to discuss something when this is only a part time, volunteer activity? What about other people getting in on the conversation? My RDoc patch sat there 5 days and no one said word one. Why wasn't two days enough there? I'll just reiterate my point from before, two days seems fair to you, b/c you already decided. "tough shit" is how you put it on another topic. There was little intent of real discussion. You have also made it clear that you were focusing more on the implementation then the design goals. I was still trying to assess exactly what would and would not be acceptable. B/c of this you have wholly mistaken my further discussion as a "refusal to acknowledge". Don't you see how that indicates the "yes sire!" attitude that I felt? > 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? Actually I earnestly wanted to see how much my perception was being blurred by my interaction with Ryan. As I said this has 10 times more to do with my interaction with him then with you. I also wanted others to see how Ryan behaves b/c I don't know how else to try to effect Ryan. I think others need to be aware of it b/c it is effects the development of a project. > > 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. Well, I tried to defend my design "hopes" for the project, if you will. I don't think defending ones ideas should be considered "defensive" in the sense that it was wrong of me to do so. Why wouldn't you expect me to defend them? > 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. You completely misunderstood then. I have no indication that you would do such a thing (with the possible exception of your association with Ryan. Though I actually did not know you worked with him daily). I do not get any indication from your comments that anything like that is going on. But I believe I have explained my perceptions above. (Of course, Ryan is a different story. I know that he purposefully attacks me and has proven his vindictive nature time and again.) > 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. Yes and no. I found it so frustrating dealing with Ryan, that at one point I just said "hell with it". It was late, I was tired, and I just wanted to forget about it at that point, and so attempted to just delete it all and walk away. That didn't work of course. This post was not about throwing a fit though. It was about respect. Not just what others were giving (or not) to me, but I to them. I felt the conversations had gotten away from were they should be and putting it out for others would help bring perspective. Again this had vastly more to do with Ryan then you. > 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. Well, I actually appreciate you taking the time. I hope my reply offers some clarity about our different perspectives. > 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! I understand of course. It's the same way that I would just like to delete all the commits, forget about it and and move on. You don't need to reply. I think it's been flushed out enough and we can just take our respective lessons from it as we see fit. _______________________________________________ Rubygems-developers mailing list http://rubyforge.org/projects/rubygems Rubygems-developers@rubyforge.org http://rubyforge.org/mailman/listinfo/rubygems-developers
