3 ms·

James makes a great appeal for Loren in this post, and there's no denying that SlimGems has made us all think, and brought many interesting issues to light. How

by sandal 15y ago

James makes a great appeal for Loren in this post, and there's no denying that SlimGems has made us all think, and brought many interesting issues to light. However, it's hard to realistically expect one to go from being the maintainer of a hostile fork to the maintainer of the project they forked overnight. But that having been said, Loren is one of the few people qualified to really speak on these issues. He's studied the internals of RubyGems, he is aware of many of the problems with the previous ways of doing things. In particular, he's a proponent for stable APIs so that breakage becomes a thing of the past. I've spoken with literally hundreds of people over the last two weeks about this issue, and I'll be the first to admit it's one that needs to be solved. The question now is not whether it must be done, but when and how the changes need to be introduced. These are questions that I feel I must at least strongly consider the opinions of the current maintainers of RubyGems on, because for example, Eric Hodel has been the core team for 4 years and knows more about RubyGems than anyone on the planet. There is no denying that Eric+Ryan have had personal conflicts with Loren, which would make an immediate appointment of Loren on the core team unrealistic. However, Evan Phoenix (another of RubyGems maintainers) and I are trying to see if we can find a way to solve this problem outside of RubyGems first through a compatibility gem, in a minimally invasive way to users. We have already talked with Loren some, but I hope that dialogue continues so that he can possibly help us with our ideas and build something that everyone can be happy with. This to me would be much better than the division that would be caused by a fork, and is something I think we should at least try before we make any sweeping changes in leadership. I've promised to back off the diplomacy and start hacking to solve the problem, and that's what I'll do in the coming weeks. But I felt it was necessary to share my thoughts here simply because I've been listening to so many people about what their concerns are with RubyGems, and that makes me really want to find a solution that works. If Loren can be part of that solution, I'd love to see him working for RubyGems rather than against it, for sure.

emiller829 15y ago
Greg, I'm nobody special, to the Ruby community, so I'm not going to claim my opinion carries a lot of weight, here. That being said, you have to see how characterizing Loren's work as a "hostile fork" isn't the most neutral thing to say. It would appear to me that you've definitely moved past the role of mediator, but when you say things like "I must at least strongly consider the opinions of the current maintainers of RubyGems" it sounds as though you're now casting yourself in the role of judge, instead. You're doing great things with RMU -- we thank you for it, and I'd hate to see the fallout from the role you're attempting to play here overshadow your great contributions to our community thus far.
- mberning 15y ago
  It was forked in anger. A fair assumption is that there is at the very least some animosity on one side of the equation.
  - wfarr 15y ago
    It was forked because while performance improvements are great to have, API breakage with no replacement for long-standing APIs is not. At the end of the day, people need a working environment and not everyone has the time of day to be updating every library out there that used a previously stable RubyGems API to use the new "better" ones (though I've yet to see a case where the API changes were little more than renaming a class and adding a couple class methods).
    - nirvdrum 15y ago
      I know little about the API changes, but have been burned by just about every single release since 1.3.7. So much so that I now have to patch RVM every time I bring up a server so I can lock down the version. One could argue I should have been doing this right along, but I don't think it's entirely unreasonable to believe that new versions of your library loading software will continue to load your libraries.
      - sandal 15y ago
        We're working on ways to solve this problem. Did you check out the new release policies?
        nirvdrum 15y ago
        I sure did. And then 1.8.5 came out and my Rails app broke again.
- sandal 15y ago
  As a mediator, I never intended to cast myself as non-biased about SlimGems. I started my involvement by specifically calling SlimGems a really bad idea, and I still stand by that point. Here's my first post: http://blog.majesticseacreature.com/rubygems-nerd-rage-is-optional-and-discourage http://blog.majesticseacreature.com/rubygems-nerd-rage-is-op... What I said is that I'd collect the concerns of the Ruby community and present them to the maintainers and try to get changes made on their behalf. I've done that, and will keep doing that. As for no longer being a mediator, I also already made it clear that I can't be unbiased about this, because after investigating, I've seen enough to form some strong opinions: http://blog.majesticseacreature.com/the-rubygems-drama-continues http://blog.majesticseacreature.com/the-rubygems-drama-conti... In the end, I'm not worried about how this makes people who think a hostile fork is a good idea feel about me. I've received more thanks than criticism, but most of it was quiet and private, rather than loud and public. I believe in the work I'm doing, and will keep it up, but hopefully through more code and less talking.
jamesgolick 15y ago
> hostile fork What's hostile about proving points with code? > ...the division that would be caused by a fork... You still haven't explained what the problem with this "division" is. Why will this be different than the rails/merb fork? Honest question: are you afraid of division or of your friends losing control of the project? > There is no denying that Eric+Ryan have had personal conflicts with Loren... As well as just about anybody else who has tried to work with them. > However, Evan Phoenix... Evan is a great and brilliant guy, but let's be honest here. He's another personal friend of the current maintainers and (former?) Seattle.rb member. We need fresh blood.
- sandal 15y ago
  To qualify my friendship with Ryan and Eric, it consists of meeting them at conferences once in a while and having some positive conversations with them. That said, I am absolutely biased here, I like them despite their flaws in the way they manage projects and their tendency to easily get embroiled in unnecessary personal conflicts. I left a more detailed comment on your blog, but I don't think we need to have a meta-personal conflict, so I'll leave this rest here.
- nplusone 15y ago
  I'm hoping for a friendly SlimGems/RubyGems merger for Christmas 2011.
- dudleyf 15y ago
  Merb was never a fork of Rails. It was a separate project, initially created to address a particular shortcoming of Rails (file uploads, IIRC), and grew into a competing implementation that solved a lot of the same problems that Rails did in a simpler, more elegant way. The Rails core team realized that Merb did a lot of things better and absorbed most of that goodness. SlimGems isn't Merb. It's not new, it's not doing anything better. The only thing it has going for it is "Hey, it's not being run by these same assholes." Well, that doesn't help me much. SlimGems isn't going to ship with Ruby 1.9.3, and it doesn't solve any problems that RubyGems doesn't solve. Loren could be making a better RubyGems, but instead he's making an older RubyGems.
zmoazeni 15y ago
You posted something similar at http://jamesgolick.com/2011/6/1/why-rubygems-needs-loren-segal.html#comment-217524976 http://jamesgolick.com/2011/6/1/why-rubygems-needs-loren-seg... and I've checked a few other posts of yours surrounding the context. I'm not sure why you're giving Loren grief. > If Loren can be part of that solution, I'd love to see him working for RubyGems rather than against it, for sure. I know you're trying to be a diplomatic bridge for the RubyGems team, however saying things like that just makes me shake my head. I appreciate James' appeal. As an outsider to the situation, I wonder why not just let Loren do his thing without comments like that? I'm also saying this with respect to Eric and Ryan's work.
- sandal 15y ago
  I've been giving slimgems grief but not Loren, I've actually been in regular, productive dialogue with Loren since this started. But actually, you're right, my public presence may not reflect that and it's time for me to change strategies. Here's what I plan to do instead now: http://blog.majesticseacreature.com/rubygems-peace-rally-vs-anti-war-rally http://blog.majesticseacreature.com/rubygems-peace-rally-vs-... Sorry if I don't reply to this comment, but I just wanted to make sure that folks here see that I've heard their thoughts and decided to act on them.
nirvdrum 15y ago
Having seen other comments you've made throughout this process, I really think you're overstating the importance of having been involved with something for 4 years. Seniority does not and never has demanded respect in all but the most draconian of organizations. On the other hand, being at the head of a failing organization usually means you need to be removed in order for proper recovery to occur. Simply put, the quality of one's work should be judged by the quality of the outcome, not the time put in. Otherwise you end up in a situation where newcomers are never welcomed. You end up in the situation we're in now. And I've yet to come across a project that hasn't benefited by a smart, driven guy providing new insight and perspective. Marginalizing that feedback to save an ego is a major disservice to all.
- bcardarella 15y ago
  Well put
- sandal 15y ago
  You missed the point. It's not about seniority at all. It's about knowledge of a very complex system. I don't want to see that fly out the window so that we can spend another couple years learning what Eric has. Rescue projects suck, and this doesn't have to be one.
  - jamesgolick 15y ago
    > ...a very complex system Auto-pilot on a 747 is a very complex system. RubyGems is not.
jamesbritt 15y ago
However, it's hard to realistically expect one to go from being the maintainer of a hostile fork ... Greg, "hostile fork"? I read Loren's blog post about the release of SlimGems and the motivations, and really got no sense at all of any hostilty. As best I can tell, much like with YARD Loren decided he wanted to see some key part of the Ruby dev environment behave a certain way and wrote working code to make it so. I can only applaud that. Having spent at least a little time chatting with Loren about YARD (he was terrific in clearing up dozens of questions at a MWRC) I'd be surprised if there was any anger or malice behind any of his projects. It may be that the offering of these things in turn creates some annoyance for some people, but I doubt that's the intent. I would much prefer to see more people code out their issues than complain on a mailing list or HN. Code talks, bullshit walks.

by sandal 15y ago

emiller829 15y ago

Greg, I'm nobody special, to the Ruby community, so I'm not going to claim my opinion carries a lot of weight, here. That being said, you have to see how characterizing Loren's work as a "hostile fork" isn't the most neutral thing to say. It would appear to me that you've definitely moved past the role of mediator, but when you say things like "I must at least strongly consider the opinions of the current maintainers of RubyGems" it sounds as though you're now casting yourself in the role of judge, instead. You're doing great things with RMU -- we thank you for it, and I'd hate to see the fallout from the role you're attempting to play here overshadow your great contributions to our community thus far.

mberning 15y ago
It was forked in anger. A fair assumption is that there is at the very least some animosity on one side of the equation.
- wfarr 15y ago
  It was forked because while performance improvements are great to have, API breakage with no replacement for long-standing APIs is not. At the end of the day, people need a working environment and not everyone has the time of day to be updating every library out there that used a previously stable RubyGems API to use the new "better" ones (though I've yet to see a case where the API changes were little more than renaming a class and adding a couple class methods).
  - nirvdrum 15y ago
    I know little about the API changes, but have been burned by just about every single release since 1.3.7. So much so that I now have to patch RVM every time I bring up a server so I can lock down the version. One could argue I should have been doing this right along, but I don't think it's entirely unreasonable to believe that new versions of your library loading software will continue to load your libraries.
    - sandal 15y ago
      We're working on ways to solve this problem. Did you check out the new release policies?
      - nirvdrum 15y ago
        I sure did. And then 1.8.5 came out and my Rails app broke again.
sandal 15y ago
As a mediator, I never intended to cast myself as non-biased about SlimGems. I started my involvement by specifically calling SlimGems a really bad idea, and I still stand by that point. Here's my first post: http://blog.majesticseacreature.com/rubygems-nerd-rage-is-optional-and-discourage http://blog.majesticseacreature.com/rubygems-nerd-rage-is-op... What I said is that I'd collect the concerns of the Ruby community and present them to the maintainers and try to get changes made on their behalf. I've done that, and will keep doing that. As for no longer being a mediator, I also already made it clear that I can't be unbiased about this, because after investigating, I've seen enough to form some strong opinions: http://blog.majesticseacreature.com/the-rubygems-drama-continues http://blog.majesticseacreature.com/the-rubygems-drama-conti... In the end, I'm not worried about how this makes people who think a hostile fork is a good idea feel about me. I've received more thanks than criticism, but most of it was quiet and private, rather than loud and public. I believe in the work I'm doing, and will keep it up, but hopefully through more code and less talking.

jamesgolick 15y ago

> hostile fork What's hostile about proving points with code? > ...the division that would be caused by a fork... You still haven't explained what the problem with this "division" is. Why will this be different than the rails/merb fork? Honest question: are you afraid of division or of your friends losing control of the project? > There is no denying that Eric+Ryan have had personal conflicts with Loren... As well as just about anybody else who has tried to work with them. > However, Evan Phoenix... Evan is a great and brilliant guy, but let's be honest here. He's another personal friend of the current maintainers and (former?) Seattle.rb member. We need fresh blood.

sandal 15y ago
To qualify my friendship with Ryan and Eric, it consists of meeting them at conferences once in a while and having some positive conversations with them. That said, I am absolutely biased here, I like them despite their flaws in the way they manage projects and their tendency to easily get embroiled in unnecessary personal conflicts. I left a more detailed comment on your blog, but I don't think we need to have a meta-personal conflict, so I'll leave this rest here.
nplusone 15y ago
I'm hoping for a friendly SlimGems/RubyGems merger for Christmas 2011.
dudleyf 15y ago
Merb was never a fork of Rails. It was a separate project, initially created to address a particular shortcoming of Rails (file uploads, IIRC), and grew into a competing implementation that solved a lot of the same problems that Rails did in a simpler, more elegant way. The Rails core team realized that Merb did a lot of things better and absorbed most of that goodness. SlimGems isn't Merb. It's not new, it's not doing anything better. The only thing it has going for it is "Hey, it's not being run by these same assholes." Well, that doesn't help me much. SlimGems isn't going to ship with Ruby 1.9.3, and it doesn't solve any problems that RubyGems doesn't solve. Loren could be making a better RubyGems, but instead he's making an older RubyGems.

zmoazeni 15y ago

You posted something similar at http://jamesgolick.com/2011/6/1/why-rubygems-needs-loren-segal.html#comment-217524976 http://jamesgolick.com/2011/6/1/why-rubygems-needs-loren-seg... and I've checked a few other posts of yours surrounding the context. I'm not sure why you're giving Loren grief. > If Loren can be part of that solution, I'd love to see him working for RubyGems rather than against it, for sure. I know you're trying to be a diplomatic bridge for the RubyGems team, however saying things like that just makes me shake my head. I appreciate James' appeal. As an outsider to the situation, I wonder why not just let Loren do his thing without comments like that? I'm also saying this with respect to Eric and Ryan's work.

sandal 15y ago
I've been giving slimgems grief but not Loren, I've actually been in regular, productive dialogue with Loren since this started. But actually, you're right, my public presence may not reflect that and it's time for me to change strategies. Here's what I plan to do instead now: http://blog.majesticseacreature.com/rubygems-peace-rally-vs-anti-war-rally http://blog.majesticseacreature.com/rubygems-peace-rally-vs-... Sorry if I don't reply to this comment, but I just wanted to make sure that folks here see that I've heard their thoughts and decided to act on them.

nirvdrum 15y ago

Having seen other comments you've made throughout this process, I really think you're overstating the importance of having been involved with something for 4 years. Seniority does not and never has demanded respect in all but the most draconian of organizations. On the other hand, being at the head of a failing organization usually means you need to be removed in order for proper recovery to occur. Simply put, the quality of one's work should be judged by the quality of the outcome, not the time put in. Otherwise you end up in a situation where newcomers are never welcomed. You end up in the situation we're in now. And I've yet to come across a project that hasn't benefited by a smart, driven guy providing new insight and perspective. Marginalizing that feedback to save an ego is a major disservice to all.

bcardarella 15y ago
Well put
sandal 15y ago
You missed the point. It's not about seniority at all. It's about knowledge of a very complex system. I don't want to see that fly out the window so that we can spend another couple years learning what Eric has. Rescue projects suck, and this doesn't have to be one.
- jamesgolick 15y ago
  > ...a very complex system Auto-pilot on a 747 is a very complex system. RubyGems is not.

jamesbritt 15y ago

However, it's hard to realistically expect one to go from being the maintainer of a hostile fork ... Greg, "hostile fork"? I read Loren's blog post about the release of SlimGems and the motivations, and really got no sense at all of any hostilty. As best I can tell, much like with YARD Loren decided he wanted to see some key part of the Ruby dev environment behave a certain way and wrote working code to make it so. I can only applaud that. Having spent at least a little time chatting with Loren about YARD (he was terrific in clearing up dozens of questions at a MWRC) I'd be surprised if there was any anger or malice behind any of his projects. It may be that the offering of these things in turn creates some annoyance for some people, but I doubt that's the intent. I would much prefer to see more people code out their issues than complain on a mailing list or HN. Code talks, bullshit walks.