El 28/10/10 10:13, Michael Stahnke escribió:
> I would imagine that most ruby end-users simply don't need
multiple versions
They should not even bother or know there are multiples versions.
> However, it should be possible to install rvm if required, and
the rvm
> packaging should either work in parallel with the system ruby, or should
> obsolete it and work seamlessly.
Actual Fedora Ruby Developers probably just do
# yum instal rubygems
and then
# gem instal mygem
Why, simple, gem can manage multiple versions withouth any hazzle, we
know. Developers usually can deal with it, and we should lead them on
the right path, yes, they(we) do commit unholly sins.
Then when moving to a production stage, would verify/manage/decide to
use Fedora (OS) provided rubygems or not. Maybe they are not available,
and that's where rpm-packaging-gems comes to play a major role.
If we package most of the usefull, latest and stable gems, then Fedora
would be an appealing platform for ruby developers. Maybe at somepoint
they could just start developing not using gems from source and then
push back the pressure to upstream gems/apps developers to keepup and
update/upgrade for no regresions or compat issues. Avoid "specific"
version to run, its not a feature, its a panfull mess to manage
multiples gem versions.
I'd say there is quite a different audience between ruby user
(puppet,
redmine or something) vs a ruby developer.
Im still missing redmine not being part of fedora...
Yet, Somehow we need to appeal to ruby developers, at least as a
platform for production deployments. This would probably be done by
having things like ruby application servers, and deployment tools
available.
+1
There are also some cases where we might want to maintain
parallel gem installations when both branches are still being
maintained (rails 2 vs 3, rspec 1.3 vs 2.0, etc).
This case takes me back to the Apache 1.3 vs Apache 2, as far as i
recall, Fedora never shipped Apache 1.3, is not in our nature to that
kind of things. Someone please correct me if im wrong. We should focus
on pushing upstreams, using the latests, package them, and move on.
Maitained is no reason enough for Fedora for shipping it, but my guess
is no sin either to do it.
If you look at the rails rumble from 2 weeks ago, less than 2% of
systems used were Fedora/CentOS. That's quite sad. Most used Ubuntu,
and I am guessing just installed ruby gems and built the rest from
source, as Ubuntu's ruby stack IMHO, is in worse shape than that of
Fedora.
I thinks this just proove that its not related to the ruby stack state
in Fedora. But yes, still sad.
The other problem with using 'latest' is that ruby 1.9 really
isn't in
use for many big application yet. I mean, it will be, but I don't
know if Amarok works with it yet. I know puppet/facter still have
bugs open for 1.9 compatibility. Going to 1.9 and obsoleting 1.8 is a
pretty big step.
We should track that, and then take a decision early enough for f15. We
have the opportunity to switch from 1.8 to 1.9 kind of easily since
there are NOT hundreds/thousands of apps being used in Fedora.
In fact we should promote and help this transition for developers. We
should build a plan ;) Im not yet at 1.9 level, but my guess is, 1.9 is
better, then why keep my apps at 1.8? As a developer i should move on
and release under 1.9 umbrella. Being a 1.8 developer is becoming
history and we should face the fact in the Fedora way.
As some take-aways:
* We should be working to get more and more gems into the Fedora
world, and this should include EPEL as that's where most production
applications get targeted for deployment.
+1
* The ruby 1.9 parallel installation discussion should continue.
RVM
might be answer.
+1
* Market/advertise and discuss any big-time ruby applications
utilizing Centos/Fedora/RHEL as the backing platform.
Hey, did i mention that we should gather at Tempe and do something ?
"Maybe" i wil be doing ruby coding dojo mentored by toshio..
Guillermo
------------------------
http://www.neotechgw.com
http://gomix.fedora-ve.org