[Rubygems-developers] Contributing to Ruby Projects

Trans transfire at gmail.com
Sat Dec 11 16:07:05 EST 2010


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... at 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.



More information about the Rubygems-developers mailing list