4 ms·

> Then it's the kind of lesson that can be learned from and fixed. No need for forks. I agree. But, to be fair, it's hard to hope for the project to be improve

by holman 15y ago

> Then it's the kind of lesson that can be learned from and fixed. No need for forks. I agree. But, to be fair, it's hard to hope for the project to be improved and fixed when someone responsibly brings up the issue on the RubyGems issue tracker and gets the following response from a RubyGems developer: > Really? Don't you have anything better to do than to post inflammatory shit to this tracker?

sandal 15y ago
There have been personal conflicts abound in this drama around RubyGems, and that's a big part of the problem. The solution that I've come up with in my talks with the RubyGems maintainers is that anyone who feels that they can't work with Eric and Ryan (or vice versa) will be able to talk to Evan, who has less of a track record of difficult interactions with users. No, that's not a great solution. But neither is supporting a fork by someone who's been working on this for three weeks when the current RubyGems core team has members on it with over 4 years of experience with the codebase. At the very least, this needs to stop being emotional and the technical points need to be laid out cleanly on white paper.
saurik 15y ago
Did you read the way that issue was worded? Whether you agree with what that issue reported or not is irrelevant: it was intentionally written in a way to be "inflammatory", and I have nothing but respect for someone (the developer) that will call people (the reporter) out like that (although part of me wants to say "don't feed trolls"). (Note: I read your message, know nothing of these people involved, and simply searched to find the issue as I wanted to actually see what had "gone down" for myself: that bug report, despite the fact that I don't even /use/ Ruby, "riled me up", which says something pretty bad about its intent.)
- holman 15y ago
  I think he had a valid issue and brought it forward in a responsible manner. He's trying to teach Ruby to a classroom of beginners and the first thing you have to tell them is to ignore hundreds of lines of scary-looking deprecation notices every time they run a valid and correct command. That's not what should be happening. The title may have been a bit facetious, admittedly (I didn't notice it at first due to the mess that is RubyForge), but the actual issue body was straightforward.

by holman 15y ago

sandal 15y ago

There have been personal conflicts abound in this drama around RubyGems, and that's a big part of the problem. The solution that I've come up with in my talks with the RubyGems maintainers is that anyone who feels that they can't work with Eric and Ryan (or vice versa) will be able to talk to Evan, who has less of a track record of difficult interactions with users. No, that's not a great solution. But neither is supporting a fork by someone who's been working on this for three weeks when the current RubyGems core team has members on it with over 4 years of experience with the codebase. At the very least, this needs to stop being emotional and the technical points need to be laid out cleanly on white paper.

saurik 15y ago

Did you read the way that issue was worded? Whether you agree with what that issue reported or not is irrelevant: it was intentionally written in a way to be "inflammatory", and I have nothing but respect for someone (the developer) that will call people (the reporter) out like that (although part of me wants to say "don't feed trolls"). (Note: I read your message, know nothing of these people involved, and simply searched to find the issue as I wanted to actually see what had "gone down" for myself: that bug report, despite the fact that I don't even /use/ Ruby, "riled me up", which says something pretty bad about its intent.)

holman 15y ago
I think he had a valid issue and brought it forward in a responsible manner. He's trying to teach Ruby to a classroom of beginners and the first thing you have to tell them is to ignore hundreds of lines of scary-looking deprecation notices every time they run a valid and correct command. That's not what should be happening. The title may have been a bit facetious, admittedly (I didn't notice it at first due to the mess that is RubyForge), but the actual issue body was straightforward.