Giving up on Ruby packaging

January 2nd, 2011 by lucas

I have finally reached a decision regarding my involvement in the Debian Ruby packaging efforts. I have decided to stop. This has been a very hard decision to make. I have invested huge amounts of time in that work over the years. I still love the language, and will continue to use it on a daily basis for my own developments. I still hope that it will succeed. I know that some people will be disappointed by that decision (and that others will think “your work was useless anyway, people should use RVM and rubygems”).

But I also know that I won’t be able to push for all the required changes alone. I just don’t have the time, nor the motivation. For the record, here are the changes I would have liked to see in the Ruby community.

The core Ruby development community should mature.
The core Ruby development community is still dominated by Japanese developers. While not a bad thing in itself, it is easily explained by the fact that the main development mailing list, where most of the important decisions are taken, is in japanese. ruby-dev@ should be closed, and all the technical discussions should happen on the english-speaking ruby-core@ list instead.

The release management process should also improve. Currently, it looks like a total mess. The following Ruby development branches are actively maintained:
ruby_1_8 (106 commits over the last six months)
ruby_1_8_6 (4 commits over the last six months)
ruby_1_8_7 (35 commits over the last six months)
ruby_1_9_1 (4 commits over the last six months)
ruby_1_9_2 (227 commits over the last six months)
trunk (1543 commits over the last six months)

While the state of the ruby_1_8_6 and ruby_1_9_1 branches is clear (very important bugfixes only), the state of all of the other branches is rather unclear.
What’s the stable Ruby branch? 1.8 or 1.9? If it’s 1.9, why are people still actively developing in the ruby_1_8 branch? How long will they continue to be maintained in parallel, dividing the manpower? Is a Ruby 1.8.8 release to be expected? Will it be ABI/API compatible with 1.8.7? Is the ruby_1_8_7 branch really bugfixes-only? How much testing of it has been done? If it’s bugfixes-only and regression-free, I should push it to Debian squeeze, due to be released in a few weeks. But would you recommend that? Due to past breakages in the ruby_1_8_7 branch, it’s unlikely that we will do it.
Is the ruby_1_9_2 a regression-free, bugfix-only branch? If yes, isn’t 227 commits over 6 months a lot? What will be the version of the next release of “trunk”? When is it expected? Will it be ABI-compatible with the current ruby_1_9_2 branch? API-compatible?
New releases in the 1.8.7 and 1.9.2 branches were done on december 25th. Why were they no betas or RCs allowing wider testing? How much testing has been done behind the scenes?

Most of those questions have no clear answer. The Ruby development community should build a common understanding of the status of the various branches, and of their release expectations. Releasing on december 25th of each year sounds fun, but is releasing when everybody is on vacation really a good idea?

It would be fantastic to have something similar to Python Enhancement Proposals in the Ruby community. But having open discussions in english about the major issues would already be great.

Ruby is not just the interpreter.
The Ruby development community should clearly define what the Ruby platform is. There are some big players, like Rails, and newer interpreter releases should not be done before ensuring that those big players still work.

Also, since we have alternative Ruby interpreters, like JRuby, Rubinius and MacRuby, we need a clear process on how they integrate with the rest of the ecosystem. For example, having each of them rely on their own outdated fork of the whole stdlib is ridiculous, since it’s not where they compete.

The Ruby community should acknowledge that RVM and Rubygems are not for everybody. People who say so should be laughed at. Of course, RVM and Rubygems are nice tools for some people. But it is completely wrong to believe that compiling from source using RVM should be the standard way of installing Ruby, or that all people interested in installing Redmine should know that Ruby has its own specific packaging system. The Ruby community should work with their target platforms to improve how Ruby is distributed instead of reinventing the wheel. That includes Debian, but also RedHat-based distros, for example. It is likely that it won’t be possible to reach a one-size-fits-all situation. But that’s real life.

Some people in the Ruby community should stop behaving like assholes. As one of the Debian Ruby maintainers, I have been routinely accused of creating crippled packages on purpose (FTR, I don’t think that the Debian packages are crippled, despite what the rumors says). Debian is not the only target of that. Just yesterday, someone called for abandonning YARV (the new Ruby VM in Ruby 1.9), calling it Yet Another Random Vailure. This kind of comments is really hurting the people who are investing their free time in Ruby, and is turning away people who consider getting involved. In Debian, we have had a lot of problems getting people to help with Ruby maintenance since they are getting shit from the community all the time.

So, what’s the future for Ruby in Debian?

  • For the interpreter, the two other maintainers, Akira Yamada and Daigo Moriwaki, are of course free to continue their work, and I wish them good luck.
  • For the pkg-ruby-extras team, which maintains most of the Ruby libraries and applications, the future is less clear. The team was already badly understaffed, and I feel that I should probably clean up its status by orphaning/removing the packages that are unmaintained otherwise. This won’t affect all the packages that the team maintains: some packages (like redmine) are actively maintained, and will stay.
  • For me, it just means I will have more time for other things (possibly not Free Software-related). If things improve dramatically, I might also come back to Ruby packaging at some point.

Update: there’s also a number of interesting comments about this post on this site.
Update 2: First, thanks a lot for all the interesting comments. I will make some follow-up posts trying to summarize what was said. It seems that this post also triggered some reactions on ruby-core@, with Charles Olivier explaining the JRuby stdlib fork, and Yui Naruse clarifying that all questions are welcomed on ruby-core@. This is great, really.

82 Responses to “Giving up on Ruby packaging”

  1. FFms wrote on 01/2/11 at 10:08 am :

    “ruby-dev@ should be closed, and all the technical discussions should happen on the english-speaking ruby-core@ list instead.”

    Imperialists never change.

  2. Lucas wrote on 01/2/11 at 10:44 am :

    This is not about imperialism. This is about finding methods that doesn’t force some contributors to stay second-class contributors. English is not my native language either (I’m french), but I’m very fine with using english where it is necessary to allow collaboration. At some point, one need to decide whether the project should stay a little project between friends, or if it should open up to the wider world. You can’t have it both ways.
    Another example of a similar problem is with VCSes. There are some projects that insist on using a specific, rather unknown VCS (for example, monotone, mercurial, darcs). This is an additional entry barrier for potential contributors, though it’s probably less severe for software developers to say “you have to learn $VCS” than to say “you have to learn japanese”.

  3. nona wrote on 01/2/11 at 10:53 am :

    @FFms: what makes you think Lucas is a native English speaker? Like it or not, having ruby-dev in japanese is excluding a large number of developers – I’m willing to bet there’s way more potential ruby developers that don’t speak Japanese, than those who don’t speak English.

    @Lucas: sad to read this. I had hoped that Ruby in Debian (and other distros) would improve Ruby; I don’t get why there was so much pushback. I think the Ruby developers forget there’s users out there too. (Building from source isn’t an appropriate install experience for users, no matter how “easy” it might be).

  4. Thomas Koch wrote on 01/2/11 at 11:08 am :

    Thank you Lucas for taking such a hard decision. It isn’t easy to give up on something when you have invested so much time.

    Now I wonder, which of your reasons do also apply for PHP? :-)

  5. anonymous wrote on 01/2/11 at 11:29 am :

    Surprised you held on this long. I would’ve given up years ago. Dunno if mercurial is considered niche though..?

  6. anonymous wrote on 01/2/11 at 11:29 am :

    Also English is the lingua franca (as it were) of technical discussion. There’s a reason Torvalds never even considered writing the kernel in Finnish. You get the most possible contributors if you write in English.

  7. Lucas wrote on 01/2/11 at 11:31 am :

    @anonymous: mercurial is not niche is some communities, like Python. But if you write something not related to Python, it’s probably not a good idea to use mercurial if attracting contributors is one of your goals.

  8. Mycroft wrote on 01/2/11 at 12:37 pm :

    For what it worth, I have just removed RVM this week end and installed Ubuntu package instead, and it works perfectly. Thanks for your work Lucas.

  9. frozy wrote on 01/2/11 at 1:59 pm :

    Sample from my life, few years ago I have written a couple of scripts and then publish them. I just thought that maybe there is someone that would like to execute the same code as I have written. I have used my own native language (non-English) for variables and I just ignored all the comments in code (I thought, who needs comments). I thought they are excellent scripts working like a charm, I was very proud of my code. I received comment or two from local language community, but one of them purposed to change all non-English variables/comments to English language and I checked his work for consistency and program was working fine. I immediately got wider community around code. A lot of testers got reported tens of bugs in some situations that I have never thought about. I start getting patches, for users using older versions of Ubuntu that this scripts were not working, I also got suggestions from non-Ubuntu distributions and got a patches for them and how to write a script code multi-distribution working etc. Got some requests to add features and from other users got a code for that. I never expected to get such a response just from changing non-English to English. What is the best is? I invested huge time to get first version. But invested so little time to get all others versions, a lot of code maintained by others, learned so much more about how to write good code etc. Now I know what a great power is free software and what a power is if lingua franca is used.

  10. ankur sethi wrote on 01/2/11 at 4:12 pm :

    Sorry to hear this, your work is much appreciated. I also don’t bother with RVM, most people just want the stable version.

  11. Janne wrote on 01/2/11 at 4:23 pm :

    Imperialist or not is beside the point. Most core contributors are Japanese and for most of them their English ranges from bad to nonexistent. If you were to insist on English as the development language you would completely shut out many of the current developers.

  12. David N. Welton wrote on 01/2/11 at 4:25 pm :

    Thanks for your work and perseverance in the face of some particularly nasty people, Lucas. I hope you find things to work on that provide a bit more happiness.

  13. Chris wrote on 01/2/11 at 4:44 pm :

    The funny thing is that ruby, java, python, ALL LANGUAGES are written using “English”. Good developers typically know English pretty well and that goes for not only Japanese developers, world wide. Assuming the core contributors can’t speak English is lame… Sorry to see you leave @lucas.

  14. Lucas wrote on 01/2/11 at 5:01 pm :

    @Janne: you seem to assume that I’d like developers to write correct english. Honestly, I don’t care if the english is grammatically correct or not. The point is to understand each other, not to write a novel. I know that it is harder to write in a foreign language (it’s harder for me to write in english than in french). But that’s an effort that most serious projects have been making.

    Also, I’d like to point out that the language issue is not my main problem with Ruby. I’m quite sure that, even if I knew japanese, most of the other issues would still apply.

  15. yasuhiro araki wrote on 01/2/11 at 5:14 pm :

    First of all, I say “thank you” for your working overtime for ruby on Debian.

    What is the source of the this blog article?

    My knowledge about discussion for ruby on Debian is limited, which came from some ruby related package maintainer in Debian.
    I think Lucas, Akira and Daigo’s direction of ruby on Debian are in perfect harmony.

  16. Janne wrote on 01/2/11 at 5:39 pm :

    “Honestly, I don’t care if the english is grammatically correct or not. The point is to understand each other, not to write a novel. I know that it is harder to write in a foreign language (it’s harder for me to write in english than in french). But that’s an effort that most serious projects have been making.”

    Lucas, my experience with Japanese software developers and engineering-oriented academics is that they don’t do English at all. As in, how well does your typical American or British software engineer do French or German?

    The typical developer is somebody who, after all, excelled in school doing math, science and programming, not studying foreign languages (or history, or social science or home economics). There’s lots of Japanese with good foreign language skills of course. There’s lots with great software expertise. But the intersection is fairly small.

    Software people from small language areas like the Scandinavian countries tend to do English well. They don’t have the luxury of translations so they all have to come to grips with foreign languages or give up their profession.

    But people in a large country like Japan can count on having most foreign stuff translated outright (I believe most or all of O’Reilly’s entire catalogue is available in Japanese) and having lots of good original works appearing for every conceivable subject.

    If you are a Japanese software developer then no, you really do not need English. And if you’re going to learn a second language professionally you may well elect to start on Mandarin instead.

  17. Ollivier Robert wrote on 01/2/11 at 5:40 pm :

    While I agree on the core Ruby interpreter and the ess of the various branches (and more importantly what gets committed in each!) and I’ve said it several times on ruby-talk, I will strongly object to the Rubygems comment.

    Ruby being a language for several platforms, each with its specific packaging systems, all incompatibles between Debian, FreeBSD, Redhat and others, need Rubygems. It works rather well across all platforms and I think it is easier than to shoehorn gems into the Debian system (even if FreeBSD has managed to get gems registered in both the system and gems).

    Thanks for your work (even though I do not use Debian nor agrees with the way the Ruby ecosystem is managed in Debian…).

  18. wrote on 01/2/11 at 5:54 pm :

    Sad news and thanks for your work !

  19. Seivan wrote on 01/2/11 at 6:25 pm :

    Decided you can’t compete against RVM and decided to give up with a useless rant. Thank you. You made my day.

    Since RVM came out I have never bothered to use your stuff. Even in production I use RVM which is quite production ready (with gitpusshuten gem)

  20. Andrew F wrote on 01/2/11 at 6:48 pm :

    @Seivan: wow, well done for proving at least one of Lucas’ points right by being so obnoxious.

    These are all really difficult problems, exacerbated by the sheer speed of releases in the Ruby environment versus Debian’s slow and measured approach. Both of which have problems!

    I think a hybrid is always going to be the solution. I still use the stock interpreter from Debian but am thinking of switching to RVM even though I hate locally compiled stuff.

    Thanks for your work Lucas.

  21. Val wrote on 01/2/11 at 6:50 pm :

    @Seivan: glad to see you playing rvm and rubygems in production environments, may be you have time and money for that. Who care ?

    Many thanks for your work Lucas, I wish you a happy new year!
    Hope the situation will evolve in a more mature way too.

  22. Brian Cardarella wrote on 01/2/11 at 7:48 pm :

    The entire point of RVM is to manage multiple Ruby installations. As well as keep clean Gemsets. As a developer this makes it very easy for me to test against multiple versions and branches. In a deployment scheme I no longer have to limit my production box to a single copy of Ruby. To my knowledge Ubuntu’s package system does not provide this functionality.

    Comparing RVM to the Ubuntu package is not a fair argument. If you’re only using RVM to install Ruby then you’re doing it wrong.

  23. Joe wrote on 01/2/11 at 7:49 pm :

    Reliable repeatability is essential to successful development of large and complex systems. The best tool stacks allow us to automate build, test and deployment on top of components with mature development processes. When we finish we need to be able to leave things in a maintainable state, for they will be maintained for years, decades, by people who did not build the thing and are not of the same mindset.

    It appears the Ruby community has some maturing to do. The last few years have shown the great promise of Ruby for broader adoption, now the question is can it be delivered.

  24. Martin Soušek wrote on 01/2/11 at 7:56 pm :

    If Ruby developers don’t know english, why ruby language is like “if tlah then mlah end” when it could be like “tlahしmlah末尾の場合”?

    I agree with all your comments to Ruby. I came to Ruby from PHP but I don’t know which core developers are worse and more arrogant.

  25. Andris wrote on 01/2/11 at 8:51 pm :

    In a deployment scheme I no longer have to limit my production box to a single copy of Ruby. To my knowledge Ubuntu’s package system does not provide this functionality.

    @Brian Cardarella see Debian Alternatives

  26. lucas wrote on 01/2/11 at 9:00 pm :

    @Andris: Note that Debian’s Ruby doesn’t use alternatives at the moment. The main problem is that alternatives are for software that provide very similar functionality, and can be used interchangeably. That’s not the case: you cannot use ruby 1.9 instead of ruby 1.8 and expect that all your (Debian packaged-)applications will still work.

  27. joost wrote on 01/2/11 at 9:42 pm :

    Lucas, I think Debian’s mission flies in the face of Ruby’s mission at this time. You can’t have both stability and rapid development; you can’t have both a reference implementation and documented stable API; you can’t have a relatively closed group of Japanese developers vs a relatively open group of Debian users world wide. I am not passing judgement on any side: we have to acknowledge that Ruby has strong Japanese roots; and that has both strengths and weaknesses. In my opinion, the BEST thing you could do is throw in the towel and not package Ruby with Debian *at all*. This way it’s up to everyone to install their own Ruby. I know for a face that most developers and admins do this anyway. By not wasting your valuable time re-packaging every Ruby out there, you are making it clear that Ruby is just not stable enough to be included with Debian. To me that sends the perfect message. I am more than happy to run a ./configure && make && sudo make install, in fact prefer it immensely over the system-packaged Ruby. Maybe in a few year’s time the situation will have stabilized and you can rethink packacking it all up. In the mean time I really think nobody will blame you for just getting out of harms way.

  28. nona wrote on 01/2/11 at 10:39 pm :

    while I really don’t think users should be building their rubies and gems with native extensions, I do feel there’s a mismatch in what dpkg can offer and ruby & gems need.

    dpkg doesn’t allow to install different versions of the same package, which is something that is probably more or less required for different ruby applications. So mapping gems to debian packages is difficult, without complex naming schemes and a lot of effort.

    maybe in the (very) long term debian should think about enabling dpkg to allow parallel installation of multiple versions of the same package, just like how Nix or NixOS do, at which point more or less automatic conversions from gem to deb would be possible (with a bit of cooperation on the gem side too)?

  29. Meneer R wrote on 01/2/11 at 10:41 pm :

    To bad to hear this, Lucas.

    I think the comment on Y Combinator about the perspective of a system administrator vs the perspective of a developper was spot on.

    These issues are not just about Ruby, they are about Python, LUA, Haskell and Perl as well.

    However, it mostly affects interpreted languages. For languages that produce binaries, the production requirements are different from the development requirements.Also, in thpse cases, you can always opt-in to statically link unsupported libraries.

    For interpreted languages, it is quite crucial that these environments are very similar. Then comes the discussion who gets to decide the platform: the developer or the system administrator.

    What you see, is that PHP is so common, that people use shared hosting, and the system administrators rule the platform choices. For Rails, there are much less options out there, so developers tend to run their own VPS per application or something.

    I don’t think anybody had the right to mean to you. And i’m sorry if people were. But i was never going to use the distro provided ruby packages.

    We need to make sure that the ruby environment is the same on OS-X, Windows and Linux. That’s the highest priority, and we pick a distro for production to suit that goal. The developers are free to choose a distrobution or OS that suits their needs.

    Perhaps the best strategy for debian, is to embrace upstream and separate the needs of developers from those of system administrators.

    The debian philosophy makes a lot of sense in the context of desktop applications: providing a consistent user experience. But it’s counter productive for developpers.

    We don’t write rails applications that target a specific version of Debian. Nobody is ever going to do that.

    If the applications we were writing would be opensource applications, that would be included in Debian, it would make sense to lock us into the versions and libraries and patches of Debian. But we’re not distrobuting our application as a debian-package.

    And I think the Debian philosphy needs to change. (but without all the hate please). Just separate the needs of the developer from the system administrator.

    What would be perfect is there would be simple script to install ruby/rubygems/rvm from upstream. And to have packages that are debian-ruby-version. That version is used for other debian packages dependent on Ruby. Like puppet, or Diakonos.

  30. Anonymous wrote on 01/2/11 at 11:01 pm :

    Applications must not require different versions of the same gem (unless major number change). If it is required for Ruby applications those gems are not mature enough to be used.

  31. Steven Obua wrote on 01/2/11 at 11:19 pm :

    In order to become a good programmer, you need some sort of tech-english. It is as simple as that. As for your small-countries argument: Do you seriously think that Germany is smaller than Japan or has less of a language tradition? Nevertheless EVERY german programmer worth his/her salt knows some sort of pidgin-english.

  32. Matthew Bloch wrote on 01/3/11 at 12:26 am :

    Hi Lucas, I’m really sorry to hear about it – I think the hardest thing must have been trying to apply (or even adequately communicate) the rigid goals that Debian adhere to onto the general swamp of Ruby development.

    We took a compromise route at Bytemark and have a (not very well publicised, because we’re not trying to serve anyone else – yet ) server which serves lots of auto-converted gems as Debian packages. rubygems is gone from our production environments; we think gems are anathema to a stable system, and happily live without it. I’ve even got a bridge library that turns gem gymnastics into no-ops, and run Rails on top of it.

    I agree with Joost, Debian doesn’t need stale packages and if you’re not sure your colleagues are willing to fill the breach, it might be more sensible to remove them. Is there anyone at Ubuntu who is working on Ruby packaging? I do find a few useful ones in their ‘multiverse’ repository but I’m not sure of the discipline behind it.

    We’ll carry on building our own server which currently backs onto Debian/lenny and Ubuntu/karmic, and I’ll see whether there’s anything we can offer. The system we’ve built tries to do the job automatically but helps us to build patches to send upstream to remove some of the really heinous stuff that gem authors like to do – relative path references, mixed up namespaces and so on.

    We’ll certainly be talking about this development next week when we get back to work – good luck with refocussing your efforts.

  33. Ricardo Panaggio wrote on 01/3/11 at 12:47 am :

    @Lucas, thanks for the awesome work! We’ll miss it a lot. It is and will continue to be as necessary as python, lua, … packages. Hope someone gets it soon and that s/he do it as well as you did all this time.

    Comparing RVM to the Ubuntu package is not a fair argument. If you’re only using RVM to install Ruby then you’re doing it wrong.

    @Brian Cardarella If you’re only using RVM to install Ruby then you’re doing it wrong [2]. Absolutely right.

    @Seivan .deb packages are more than necessary in Debian-based systems. If there not available, users of ruby-based applications would never install them, due to dependency problems.

    @Lucas I’m afraid @Janne has a point when talking about the core development. You both have a good view of it. My recent attempt to get some patches into the core can show your correct views.

    I was one of the guys that have participated on Rubysoc last year, and I’ve been thinking of how to make my patches go to the core for a long time, wondering what I’d have to do to get my patches there. One day, I’ve met @tenderlove at rubyconfBR, and he gave me a lot of awesome tips on how I’d have to evolve my code to get to the core, and specially, what it’d be necessary to make it into the core: someone from inside the core community, that could speak both english and japanese, would have to give a help.

    It’s true that keeping all the communication in Japanese, potential non-Japanese commiters are being lost. On the other hand, doing it all in Japanese would kick most of the core developers off the community.

    An intermediate solution, ruby-core, exist. And that’s good. But it could (and should) be way better. I don’t think that transferring all the talk to ruby-core would be good at all. But it should receive much more attention.

  34. Steven wrote on 01/3/11 at 1:56 am :

    @Lucas: Thanks for all your hard work. I hope things change enough for you to want to return to the scene soon. Ruby is a great language, but it is frustrating trying to keep things up to date. Anyone who claims you don’t need deb packages have not tried to keep applications working across multiple machines for years at a time. Good luck!

  35. James Healy wrote on 01/3/11 at 2:27 am :

    Lucas – thanks for all your work. Your decision is unfortunate for the rest of us, but understandable.

    I’ve long used the Debian packages for ruby and rubygems and still prefer them to RVM.

    As I just said over on HN, there are a multitude of cultural differences between the Debian and the Ruby communities that gives the ruby packaging team a particularly challenging job. Your efforts to bridge the two communities were selfless.

    In the end, I guess something had to give.

  36. Yuki Sonoda (Yugui) wrote on 01/3/11 at 3:45 am :

    I always post ruby-core rather than ruby-dev. However, I sometimes need to post it to ruby-dev in Japanese because some of core committers tend to overlook a mail in ruby-core. I agree the benefit of closing ruby-dev, however, it will make us loose win32/64 support, rational, complex, date, openssl, druby, REXML and irb. That’s why I hav e not proposed to close ruby-dev and I continue to sometimes post to ruby-dev.

    To keep Ruby maintained, I need contributions to the libraries from ruby-core before closing ruby-dev. But it might be a problem about egg and chicken.

  37. Robert Berger wrote on 01/3/11 at 4:10 am :

    Sorry to hear you got so much Hate. I think its the few rotten apples that are the spewers, but that does not reduce the pain….

    The language issue is a problem. The only human language I know is English. I’m glad/spoiled that its generally the lingua franca of the Internet. But I’m wondering what’s going to happen when there are way more Chinese speakers/writers than English on the Internet. There are already 400+ Million Chinese on the Internet and growing. There are also a lot of Chinese tech folks and growing…. And most of them don’t know English and have no need to learn it. And we can expect a lot of Open Source software to come from China as well…

    Hopefully translation tools will get much better :-)

  38. Matz wrote on 01/3/11 at 4:26 am :

    Although I respect your decision, I think some of your problems could have been improved (or resolved) by communication. Maintaining software is a series of compromise between different needs from people with various background. Of course, we core developers and Debian maintainer have different demand.

    As for ruby-dev, most of core developers do understand English, and appear in the core mailing list. All of documents, ChangeLog entries are in English. So you don’t have to consider English-speaking developers second class, despite the existence of Japanese-speaking ruby-dev mailing list. I don’t think we have to remove it.

    For versions, as you know, 1.9 was a huge jump. So we had to keep 1.8 for far longer period. But as a Debian package manager,
    you can safely ignore 1.8.6 and 1.9.1. They are only for maintenance. We have virtually three versions, 1.8.7, 1.9.2, and trunk. Having versions for development (trunk), stable (1.9.2) is not unusual. Having 1.8 is a bit exceptional.

    RVM and gems. Conflict between packaging system for the language, and general purpose packaging system like Debian is common problem; Perl has CPAN, PHP has PEAR and Ruby has RubyGems. I am not yet sure there’s good solution for it. Probably we can work together.

    Assholes. I feel sorry. I also have been sick of trolls for last 15 years.


  39. no wrote on 01/3/11 at 4:28 am :

    People don’t need one dominated national language they need have an international auxiliary language — something like Esperanto

  40. links for 2011-01-02 « SILOPOLIS Blog wrote on 01/3/11 at 6:12 am :

    [...] Lucas Nussbaum’s Blog » Blog Archive » Giving up on Ruby packaging RT @planetdebian: Lucas Nussbaum: Giving up on #Debian #Ruby packaging (tags: [...]

  41. bix wrote on 01/3/11 at 8:43 am :

    @no, yes sure Esperanto is good, but I suggest to use Latin instead. :)

  42. U.Nakamura wrote on 01/3/11 at 10:30 am :

    I express an emotional opinion first of all.
    If you don’t want us Japanese to read and to write Japanese,
    the United Nations should have forced us to using English in
    Yes, you know, they did not do so (thanks MacArthur!).
    So you should complain to them.

    OK, let’s go calmly.
    Well, all important announcements about the future of Ruby
    are sent in English, to ruby-core for the developers and to
    ruby-list for the average users.
    The reporters are often Japanese, so they send same announcements
    to ruby-dev and/or ruby-list, but they often omit to translate
    them to Japanese, so we read them in English :(
    In the issue, especially about important announcements, English
    readers receive same informations as Japanese readers.
    I feel dissatisfied that we Japanese readers should read English
    messages in Japanese ML.
    But, from this fact, you can understand that English readers have
    not received the disadvantage.

    BTW, I who dislikes English most in ruby committers object in
    What is hoped for any further? :)

  43. Lucas wrote on 01/3/11 at 11:15 am :

    It is not about announcements, but about discussions about the future of the language. For us non-japanese-speakers, only the outcome is available, while some of us would like to participate in the discussions, or at least know the reasoning behind some decisions.

    Basically, at some point, the decision must be taken: should ruby stay a japanese project, or should it become an international project? If the decision is that it stays a japanese project, it would make sense for frustrated non-japanese developers to fork it.

    > BTW, I who dislikes English most in ruby committers object in
    > English.
    > What is hoped for any further? :)

    heh! :-) for the record, that’s really appreciated.

  44. anonymous wrote on 01/3/11 at 11:37 am :

    Fucking gaijins. Ah… Shikata ga nai, deshou? Fuck it, I’m going to rewatch K-ON!.

  45. U.Nakamura wrote on 01/3/11 at 1:26 pm :

    > For us non-japanese-speakers, only the outcome is available

    You have misunderstood it.
    The conclusion is only mostly sent as for Japanese ML.
    Us and you are looking only at same information.
    So, if you have some questions, you must ask it
    (of course, in English, if you like it).
    And if you have some proposals, you must send it
    and start the discussion (of course, in English,
    if you like it).

    I strongly agree that the decision making process
    in Ruby is indistinct.
    But it’s not because of Japanese.
    The process is in someone’s head.
    Nobody except them can observe it.

    For their honor, of course, they are not
    intentionally concealing something.
    Their proposals might be only seen the conclusion
    in case of almost.

  46. Np237 wrote on 01/3/11 at 3:41 pm :

    @nona, what you (and many Python/Ruby developers) don’t understand is that installing several versions of the same module at once is not a solution. Quite the opposite, even: this is the problem.

    You cannot turn a system into a production without stable versions for each of its components, and you cannot expect long-term maintenance of each of those versions. As such, you can prototype your applications with a language like Ruby, but you cannot put them into production in decent conditions.

    This is true for Ruby, this is also often true of Python, unless you use a contained set of modules with emphasis on long-term compatibility and support, such as Django.

  47. Brian Jones wrote on 01/3/11 at 4:20 pm :

    Your pain is understandable lucas, you’ve put a lot of effort into maintaining something borderline unmaintainable. However, I think some of the comments people have made make a lot of sense, and should be considered in a followup post. It’s easy to get caught up in the heat of the moment, right?

    As someone else pointed out, you are trying to shoehorn a rapidly changing environment into a stability oriented OS packaging system. While something like RVM doesn’t fit everyone’s needs, it fits most needs in my opinion. It adds order to the chaos that is the Ruby community, and allows both devs and admins to easily manage the ecosystem. Trying to squeeze that beast into an OS package management system is a nightmare at best, and the fact that you’ve managed to work with it for so long is a testament to your abilities. Unfortunately, it’s just been an uphill battle trying to pound a square peg into a round hole.

    In regards to the Japanese/English “problem”. I work in Japan for a game company (this blog post was pointed out to me by a coworker, I’m the only English speaker here), so I have a slightly moderate level of insight into the feelings of Japanese I believe. The truth is, Ruby is a globally used programming language that was mostly built and supported in Japan. From what I’ve seen Japanese people in the technology realm do their best to work with people in English, but the truth is Japan doesn’t use English at the level most bilingual European countries do. Sadly most people outside of Japan assume that they are fully bilingual, but the truth is the level isn’t really all that high except in regards to people that have studied abroad in an English speaking country. There are going to be huge gaps in communication, and that’s just a cultural related fact that won’t go away.

    I do not mean anything bad in regards to Japanese when I say this, it’s just how their culture operates, but trying to get them to change something is like trying to pull teeth. As someone working in the tech industry this can be immensely frustrating, but as an outsider I have to understand that this is just how things are done here, and no amount of singular effort will make any huge impacts in regards to change.

    Ultimately if the English speaking community wants the development process to change, they’re going to have to fork the project. As long as everyone uses the RSpec’s, then there technically shouldn’t even be a problem beyond differences in implementation. If the EnglishRuby team still takes the time to work with the JapaneseRuby team, I am fairly sure that over time the project will be remerged back together with EnglishRuby and English language management working on the core.

  48. Lucas wrote on 01/3/11 at 5:17 pm :

    I agree that a followup post is needed. I will probably make several of them, separating the different issues. This will take some time, though.

  49. thinman wrote on 01/3/11 at 5:24 pm :

    It’s easy for folks to stand behind walls and lob rocks. That’s what makes criticism so popular: anyone can do it relatively safely. Constructive criticism means shutting one’s mouth, rolling up sleeves and producing thoughtful insights and difficult truth with maturity and care. It also means attempting to come up with viable alternatives. Specifics. Not generalities. And Not too many critical people want to put their own work up alongside something they’re criticizing, opening themselves up to scrutiny, evaluation, and yes, even criticism. And given their behavior, they’d not to be on the receiving end of such scorn, no matter how ignorant or ill-informed it is.

    When we put our work out here, we get opinions, informed opinions, and hogwash. Distinguishing between them is sometimes an exercise in futility distracting us from the work and bogging us down in defensive ego-driven posturing. That only serves one thing: ego. Not the work, not the greater community. Small minded wannabes have it easy: they can benfit from excellent work, pass it off as their own, in many cases, and simultaneously take toss rocks at it or worse, personally attack those who actually deliver the value that naysayers so greedily benefit from.

    Sad to hear that back biting fools would rather feed the fire of their ego by flaming the good hard work of folks like you. Just know there’s legions of us less noisy folks out here who are humbled and deeply grateful for your efforts and contributions, your vision, and your results.

  50. Anonymous wrote on 01/3/11 at 5:53 pm :

    @Brian Jones:

    >While something like RVM doesn’t fit everyone’s needs, it fits most needs in my opinion.

    Do you have any statistics to back up your claim?

  51. Zeno Davatz wrote on 01/3/11 at 5:57 pm :

    I think it is good, that the ruby-dev is still mainly in Japanese. Keeps Ruby clean. Not everybody has to learn English. Why not just learn Japanese?

  52. Paul Brannan wrote on 01/3/11 at 6:04 pm :

    I am one of the original authors of Rubygems who committed to the cvs repository on Jim Weirich’s usb keychain at the back of the bar in the middle of rubyconf. We didn’t think of what we were doing as reinventing the wheel; one of the major problems with existing packaging systems at the time was distribution to multiple platforms. There existed no user-friendly way for one of the popular packaging systems to be deployed on a platform that used a competing system (e.g. deploying a slack tarball on redhat or vice versa). In particular, we were concerned with Windows users, who don’t even know what a deb or rpm is.

    We wanted developers to be able to publish their Ruby software without having to repackage the software for each target platform. We wanted the publishing process to be easy, to encourage developers to build new and interesting software. And we wanted to make the software accessible to users, without an intermediate packager or approver, since that would mean each piece of software must reach critical mass before it can enter the ecosystem. In these things I think we succeeded.

    There are a number of areas in which we failed. From the beginning, Matz wanted Rubygems to allow a system administrator to install and uninstall packages using the tools with which he is familiar. Thus a gem should be easily convertible to a deb or rpm with minimal effort. Given the widespread usage of tools such as cpan2rpm, we expected that this would be easily solvable; we did not anticipate that this would be as difficult a problem as it has proven to be.

    I’m also afraid that I am responsible for the design which caused heated discussion over whether rubygems conforms to the LFS. We wanted to build a working prototype in two hours. This meant we could spend time figuring out where to dump stuff, how to convince the interpreter to look for scripts/extensions there, how to save those install locations so that packages can be uninstalled, how to handle failure in the middle of the install, etc. Alternatively, we could dump everything in a single directory and the uninstall operation is simply removal of that directory (much like many admins treat /opt). I felt this was a reasonable way to get something up and running in a short amount of time, so I argued for it, and after some discussion, the group finally agreed. I think we made the right decision at the time, but without a packaging expert present, it was impossible to foresee the long-term consequences.

    I still feel that a gem2deb or gem2rpm tool is feasible, but as I am no longer an active ruby developer, I cannot say specifically what is involved here. At a minimum I suspect it would require 1) adding metadata to the gemspec required by each target packaging system, and 2) building a mapping of package names so that package requirements are handled properly (e.g. does the ruby extension depend on sdl-dev, libsdl-dev, sdl-devel, or libsdl-devel? different platforms unfortunately name their packages very differently).

    Lastly, please do not judge the behavior of the entire Ruby community solely on the actions of Ryan Davis (zenspider). Same goes for Austin Ziegler. These two people are well known for being harsh and blunt. The rest of us really are quite pleasant.

    I think you’ll find that any online community of sufficient size has a couple of people like this, and the only way to deal with it is to either live with it or be exclusive. (the problem becomes more difficult when the people involved aren’t just trolls, but instead do positively contribute to the community, as Ryan and Austin do).

    In particular, some of _your_ comments come across a little harsh as well. You also come across as somewhat uninformed (have you watched Matz’s keynote? did you know that he plans to submit Ruby to ISO?). Instead of judging the community based on online behavior, come to one of the regional or international conferences and see what the community is really about. I think you’ll be pleasantly surprised.

    (If you have been to one of the conferences, then I apologize, and I regret that you and I have not met. Perhaps in the future?)

  53. Lucas wrote on 01/3/11 at 7:28 pm :

    To several people who commented about submitting patches to Rubygems:

    it’s a bit naive to think that you can fix everything with patches. Yes, there
    are problems that can be fixed with patches. But fixing fundamental design
    decisions with patches is often not possible.
    Regarding the fact that gem update –system is disabled with Debian, I was not
    a big fan of this decision (which I did not originally make), and I actually
    reverted that to a compromise solution a few months ago: now, it’s still
    disabled by default, but you can override it if you set an environment

    @Paul Brannan:
    I agree that I’m probably a bit misinformed. I’ve never been to a Ruby
    conference (the fact that I’m doing all my Ruby work as a volunteer, and that
    most of the conferences require travel and registration, makes this a bit

    Regarding the online community, I think that it’s important to stand up when
    facing offensive behaviour, because a minority will destroy the image of the
    whole community. We used to have a difficult community in Debian, and it has
    improved a lot over the recent years.

  54. mirabilos wrote on 01/3/11 at 9:20 pm :

    I tried to comment this on the other site, but it wouldn’t let me use LP OpenID:

    I’m half a sysadmin and half an (inhouse) developer at my
    current workplace. We use FusionForge (aka GForge aka Source-
    forge) there, which is written in PHP. It has taken me quite
    a while to get us moved from some version put there and then
    updated / hacked on in-place to a _packaged_ version (from a
    local repository), but I don’t regret it and, while the
    cow-orkers hate the overhead and additional work, they see
    the benefit. You have the same version (not version*s*!) on
    all instances/systems, can easily upgrade stuff (to fix that
    was also quite some work), etc.

    Furthermore, if you use a packaged version and dist-upgrade
    regularily, you get security upgrades automatically. Espe-
    cially for “web development”, you DO WANT that. So, everyone
    who installs NOT from a distro packaging on a production sy-
    stem is bringing himself into risk and his own fault.

    I can only say, guess we’re lucky to *not* have switched to
    Redmine some time ago…

  55. Tino Gomes wrote on 01/3/11 at 10:28 pm :


    First, thanks for your work!

    IMO! Let’s make a simple choice, instead of removing Ruby from Debian.

    See at and use the proposed stable version, so today, 1.9.2

  56. George Mauer wrote on 01/3/11 at 10:53 pm :

    Interesting read. An aside on the mercurial comment – for what it’s worth it’s starting to get decent traction in the .Net world due to it’s simplicity of set-up on windows

  57. nona wrote on 01/4/11 at 4:31 am :

    @Np237: You’re quite right, it’s problematic to depend on different versions of the same library. The whole point of libraries is to share them, preserving memory (or at least they should) and reducing the maintenance burden (security updates, etc).

    However, the real world has a tendency of messing up the best laid plans. If you have gems or libraries that are used by a lot of projects, chances are some projects will be faster in moving on to the newest (major) releases than others. This happens not just in the ruby world. I seem to remember with the transition from libgtk1.2 to libgtk2.0 that there were some stragglers for years (GnuCash was it?). It looks like the same will happen with libgtk2.0 -> libgtk3.0. So Debian plays games (don’t mean this in a bad way) with package names, and enables parallel installs of libraries already.

    It seems that with dynamic languages like Python and Ruby, there’s less discipline with respect to APIs, in that things evolve more quickly. But I’m hoping (and I think, starting to see) that these developer communities will soon be using better version numbering (, so at least we know what to expect.

    That being said, I still think multiple versions will always be needed. Ruby or not, there’s always transitions going on between major versions of libraries.

    Try installing redmine on lenny with lenny-backports right now for instance (you can’t: redmine needs rails 2.2, lenny has 2.1 and lenny-backports has 2.3 ). And that’s with just one rails project in the pool. I’ve got 22 rails projects running on my servers right now (without rvm, just debian ruby+rubgems), and they need rails 2.1.x, 2.2.x, 2.3.x, and 3.0.x. Forward porting only happens within minor or patch versions (short term that means everything to 2.3.x and 3.0.x). Even a maintained project like Redmine won’t move to 3.0.x anytime soon.

    It’s a shame you seem to be arguing that multiple versions shouldn’t happen at all. Clearly it’s already happening in Debian (even with C or C++ libs), even more so in the Ruby community. If dpkg had better support for it, we would probably have easier Debian release management (there’s a lot of flag days now where everything needs to be re-uploaded at the same time), and be able to support Ruby better. I agree multiple versions should still be discouraged, but having dpkg support is better than pretending it doesn’t happen at all.

  58. Paul Brannan wrote on 01/4/11 at 4:59 am :

    @Lucas: you should make a proposal for a talk! Presenters get a reduced rate for registration. Regional conferences often waive the fee altogether (and I would imagine travel would be cheaper to a regional conference).

    @mirabilos: different production systems have different requirements. In our systems we are less concerned about security holes and bugs than we are about subtle changes in behavior. Even a minor revision change involves risk, which means testing before deployment, which costs time money. For that reason we don’t upgrade _anything_ except when necessary.

    Our use case isn’t common, and you make a good point that many users _do_ want the automatic updates that the system packaging gives them. Unfortunately no distribution supports every conceivable piece of software out there;
    what should a sysadmin do if he wants an update for software that his distribution doesn’t support?

    (it’s a difficult problem which IMO lies partially outside the scope of either debian or rubygems)

  59. eamcet*[SEO対策調査自動更新ブログ] | DebianのRubyパッケージ管理者、Ruby開発コミュニティに不満を持ち辞任 wrote on 01/4/11 at 10:49 am :

    [...] DebianでRubyのパッケージングを行っていたLucas Nussbaum氏がパッケージメンテナの役を辞任した。Ruby開発コミュニティへの不満が原因のようだ(Lucas氏のブログ)。 [...]

  60. Np237 wrote on 01/4/11 at 11:29 am :

    @nona, the comparison to GTK+ is so irrelevant that it makes you look silly. You cannot compare a library which has not changed its API/ABI for 8 years to modules that change it at every single minor release. Especially when the transition to GTK+ 3.0 was well coordinated and the library was designed from the start for parallel installations, with everything in the build tools being able to pick the right one. If you want a comparison in the C/C++ world, pick up the Boost nightmare. Yet even with Boost, we manage to have only one version in the distribution at the same time.

    You are right that these issues could be fixed by proper API and ABI versioning, but the best way we know to do that is the build system: with pkg-config, you can pick the correct API version and pass the build flags relevant to the version being used in the source. With proper soname versioning, you can have the binary pick the correct library and know when it won’t be able to find it. The same goes for .Net with its GAC. Unfortunately, in Python and Ruby, there is no build process. And what is a strength when you want to do a script or prototype an application becomes a weakness when you build a large scale project. Whenever the interface of a dependency changes, you just don’t know it, and you have to wait for the crash (which happens at runtime, of course).

  61. Anonymous wrote on 01/4/11 at 11:32 am :

    @nona: You don’t seem to understand a difference between API and behavior change for major number change and minor one, do you?

  62. Anonymous wrote on 01/4/11 at 12:34 pm :


  63. A Japanese wrote on 01/4/11 at 3:07 pm :

    It’s sad to see this kind of post as #62, which is written by a person whose mother language is not one of Indo-European languages since he/she forgot to put “a” in front of the last word. I guess he/she did not distinguish Japanese language from Japanese people.

    Thanks Lucas, and other contributors who make this world happier, at least in my opinion.

    As for the language issue, yes, it’s pretty tough to switch my brain-working-mode and write in English while talking in Japanese and the same is true for writing in Japanese while working in English-speaking environment. When I had been in the US working in English-speaking environment, the first 10-20 minutes of my conversation with my wife in Japanese was really tough while the first 10-20 minutes of my conversation with my close friends at work was really tough. The switching of my brain is the core of the problem as for the language, not languages themselves. The problem is not that tough when I was in China where I needed to speak Chinese languages, whether Mandarin or Cantonese (many words have been imported to Japanese, though grammar is totally different). The same is true for my days (without my wife) in France and Germany: I had very little difficulty in speaking English at work while speaking French and German out of work.

    Recently, working in Japan, I receive and reply many e-mails, 30% in Japanese and 60% in English. But I make it a rule not to use both languages at the same time (without a separation of an hour), in order to avoid unfruitful hardwork of switching brain-working-mode. I read and reply all the e-mails in Japanese by 3pm and do so for all the e-mails in English after 3pm.

    Since I’m a scholar working in world-wide communities as well as an educator working in a university in Japan, this is inevitable in my case. No way. I’ve accepted the fact that English sentences look as if they were written in Devanagari when I happen to read e-mails in English.

    But, I can see no point doing like me for Ruby. Why core members does not separate issues into a domestic part and an international part? It would be true that reports from reporters in Japanese are valuable, and thus it should be in the domestic part while all the development should be carried out in the international part. Synchronizing both brings about not only strong headache like mine but also fruitless work (switching brain-mode).

    For that reason, I’ve been avoiding to write my own technical paper in Japanese since it’s tougher, though my Japanese is far better than my English.

    Other, more important issues for Ruby, let me just read others’ opinion. Again, thanks for your time and contributions, every bit, for happier world, at least in my opinion.

  64. Ken Collins (MetaSkills) wrote on 01/4/11 at 4:57 pm :

    Leaving a comment so I can get notifications. A great discussion!

  65. nona wrote on 01/4/11 at 9:05 pm :

    @Np237: I used GTK+ as an example, because I wanted to show that even with a extremely well-maintained API/ABI, the archive still contained multiple (major) versions of GTK+. My point is that (even well-coordinated) transitions (between major versions) don’t usually happen in one flag day.

    @Anonymous is right that I glossed over the differences between what’s OK in minor and major releases, and certainly the stuff that’s been going on in even _patch_ releases of Rails is so not OK; but that’s why I mentioned, and my hope that the Ruby guys are starting to realize the importance of proper versioning, even if we end up with rails 5.0.0 in a very short time.

    If I understand correctly, you guys seem to be arguing that Debian would need separate packages for major versions (so f.e. a rails2 and rails3 package – not the case right now), and count on the developers to be disciplined enough to use proper versioning, ie. no API/ABI or behaviour changes in minor versions. Something that as @Np237 said is harder to verify with dynamic languages where everything happens at runtime. But if developers can’t stick to these rules, others shouldn’t be using their lib.

    I guess I’d personally want to be more accomodating to users and developers wanting to use something despite API/behaviour “accidents” – which are harder to avoid in Ruby and Python. And I’d also like to avoid namespace pollution of the archive -something Debian historically doesn’t seem to worry too much about for major versions.

  66. Matthew Bloch wrote on 01/4/11 at 9:19 pm :

    Also – you can cut the problem down in Debian by focussing on *applications* rather than *libraries*. Many Ruby developers are never intending to publish their apps, but want to sell access to them instead – Debian shouldn’t be jumping through more hoops just to provide a production environment for closed software. Especially when those hoops are pretty much impossible within its conservative packaging framework.

    So the next version of Debian would only have Rails 2.3, or whatever – not a problem. Rails at least *is* stabilising and after another release or two, the old libraries will be good enough for lots of applications.

    I just don’t think Debian should, or can, worry about the problems of applications that reference their dependencies through github version tags! Those applications are just not ready for out-of-the-box deployment on any long-term OS release. They will always need another, riskier layer of systems administration on top, without the kinds of guarantees that Debian’s security team can provide.

  67. anon wrote on 01/4/11 at 10:26 pm :

    Regarding the ability of ruby core developpers to speak english, dont forget that *all* commit messages to the ruby interpreter are in english

  68. Charles Oliver Nutter wrote on 01/4/11 at 11:17 pm :

    I posted my description of JRuby’s stdlib maintenance policy before I saw your posts. I just wanted to preempt any questions about why JRuby now ships the Ruby 1.9 singleton.rb for Ruby 1.8 mode.

    I agree with most of your comments in principal. On the JRuby project, we have released dozens of releases over the past few years, always forcing major version numbers to their own branches and not making breaking changes (or even drastic feature additions) on those branches. We’ve been very careful about updating stdlib and other libraries, and we make great efforts to ensure we’re as backward-compatible as possible even across major releases.

    In my opinion, what’s missing most from ruby core is a feeling of responsibility to keep everything working on all platforms with *every single commit*. On the JRuby project, we run as many as 5 different test suites on every commit, and another couple every night across various configuration settings. We run tests on OS X, Linux, and Windows on every commit. And we consider it a point of pride that JRuby runs consistently across so many platforms.

    JRuby runs more tests than any other Ruby implementation. JRuby runs more CI builds on more platforms than any other implementation. I think we’re doing it right.

    Of course I’d also like to see “ruby-core” include other implementations by default, since decisions for “C Ruby” have drastic effects on JRuby and friends. C Ruby is now just one implementation among many, even if it is the “reference implementation”, and as a result there needs to be more consideration for how the future of Ruby will affect and be represented by other implementations.

  69. DebianのRubyパッケージ管理者、Ruby開発コミュニティに不満を持ち辞任 | 目指せ!!サーバマスター wrote on 01/5/11 at 1:29 am :

    [...] DebianでRubyのパッケージングを行っていたLucas Nussbaum氏がパッケージメンテナの役を辞任した。Ruby開発コミュニティへの不満が原因のようだ(Lucas氏のブログ)。 [...]

  70. Fernanda Lopes wrote on 01/5/11 at 2:39 am :

    The whole world deals with legacy applications and static libraries in production. At the same time creates and develops new applications. It is necessary to mature the way of versioning in Ruby community of course, but to say “I’m tired” and go away does not help.

    I’m a brazilian programmer. I develop applications for two servers, one with Debian Stable and some other Red Hat much, much older version. Thanks to the RVM and Rubygems I can combine both jobs in one development environment.

    No matter who is responsible for decisions on the production environment. What really matters is that at some time are taken, the developer must take this into account but should not limit its development environment for it.

    Rubygems and RVM might not be for everyone, but all we have to adapt to circumstances. Transforming the gems on distribution-specific packages definitely is not a good idea; may be useful for gems compiled locally, but not for the entire ecosystem.

  71. Brad McConahay » Blog Archive » Learning Ruby - Original Music, Web Development, and Amateur Radio wrote on 01/6/11 at 6:09 am :

    [...] the remote Ruby Gems, it produced a fairly cryptic error.  Researching the error eventually led to this post from one of the Debian package maintainers. The reputation of Ruby’s instability was [...]

  72. Andrew Grimm wrote on 01/7/11 at 1:28 am :

    I suspect that even if ruby developers only spoke English, it’d still be dominated by people from Japan. Many open source projects have network effects, where it’s more popular in one country than another.

    If you want people to be mature, please don’t use the word “asshole”.

    “FTR, I don’t think that the Debian packages are crippled, despite what the rumors says)”

    You don’t link to a comment by Matz saying they aren’t crippled, or a comment by James Earl, you link to a comment by a newbie. And newbie only says they’ve heard that there’s these problems.

    If people high up in the community are saying incorrect things, then you could claim a smear campaign. If the incorrect claims are coming from relative newbies, then it’s probably not a smear campaign, but genuine misunderstandings.

    (To be honest, I did get a little suspicious when I heard that Rubygems on Debian had problems, and that the Debian community tells you to use Debian packages rather than rubygems. It seemed to be a bit of a coincidence. I also get the impression the Debian community tends to say “Don’t use rubygems” when I’d rather them say “Sure, you can use Rubygems, but here’s some added benefits of using Debian packages”. But I’m not a expert on these things, and ruby works perfectly well on our Ubuntu box.)

    @Steven Obua:

    The difference between Indo-European languages is much less than the difference between English and Japanese.

    When I was learning a bit of Norwegian, I noticed that much of the time, it was just saying English words with a different accent. I doubt that learning Japanese will be that easy.

  73. Andrew Grimm wrote on 01/7/11 at 1:35 am :

    @A Japanese

    “You are racist” is perfectly good English – in this case, “racist” is being used as an adjective rather than a noun.

  74. Ruby Development Woes « Programming and Prose wrote on 01/9/11 at 9:17 am :

    [...] put something up on my blog. A few days ago one of the Debian ruby package maintainers quit with a post detailing what he found to be some current problems with the Ruby community. As someone who works [...]

  75. jrochkind wrote on 01/12/11 at 1:55 am :

    I think you make a good point about release management, and it being really confusing to figure out what the status of various version numbers present past and future is.

    I think that’s pretty much the only good point up there, but it is a good one.

    I don’t see a problem with rubygems being an integral part of ruby, it works well.

  76. Ranjib wrote on 01/12/11 at 5:27 pm :

    Sad to hear this lucas. But i do agree with your point, RVM & rubygems cannot be accepted as the only way of managing ruby as a platform. The release management process is also screwed i agree, after all we should have learned something from Perl/Python development, the pain of maintaining multiple branches. This also exponentially increases the effort required for maintaining stable ports ans libs.

  77. anyonymouse wrote on 01/27/11 at 9:00 am :

    Ruby is Japan’s baby, after all. Let them grow it on their own (they haven’t really grown out of their isolationist policy in the last 500 years ;)

    As for the rest of the English-LOLing world, let them use Perl.

  78. Debian and Ruby Packaging wrote on 01/28/11 at 1:03 pm :

    [...] looks like there is trouble brewing with Ruby packaging in Debian. Two maintainers have recently stepped down, citing disappointment with the general Ruby [...]

  79. Elijah wrote on 01/29/11 at 11:47 am :

    Many of the technologies that ruby programmers are working with move very fast. It is a red herring for people to insult ruby programmers for their versioning. Even if every single gem followed perfect versioning practice, you will everyday as a ruby programmer encounter entirely valid reasons why you need three different versions of a particular gem installed at once.

    This is entirely valid and necessary for ruby programming AND deployment. Debian folks are threatened by the pace that ruby moves and feel it violates the prime directive of debian to be stable and secure. I understand that, but I still need my code to be able to specify which version gem I want to use. That is not negotiable.

    In my collective, we have three debian developers and as many ruby programmers. We love each other, but we still fight internally over how to handle ruby in debian. So, the debian/ruby blood feud has hit close to home.

    I think (commercial and proprietary packaging of gems) is the sad and monstrous outcome from the unresolved feud.

    Maybe at the next debconf there can be a peace summit?

  80. Azithromycin. wrote on 03/14/11 at 8:05 pm :


    Zithromax azithromycin. Taking penicillin and azithromycin. Azithromycin 250mg. Azithromycin….

  81. John P. wrote on 04/11/11 at 5:42 pm :

    I have been using and developing on the standard debian packages for many years across a boatload of machines. They are great. Sometimes I will compile from source and sometimes use rvm. As many have pointed out, these are different solutions for different problems. The great thing is that they can coexist (at least they coexist in my world). Thanks for years of hard work Lucas!

  82. Nike FreeRuns wrote on 08/2/11 at 12:03 pm :

    On Nike Free design inspiration, Toby said: “We have found that the original grasslands in Africa and the Caribbean, the people running barefoot, their legs stronger, powerful and flexible, which makes us believe that the natural movement way make athletes stronger. “NIKE FREE family’s goal is to bring people’s feet from the traditional sports shoes fetters, use your feet to control shoes and enjoy the sport the most realistic feel. NIKE FREE series for the first time since last year designated in the world has been running supplies shop for sale, get a lot of sports fans.