From noreply at rubyforge.org Thu Oct 7 17:01:01 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 7 Oct 2010 17:01:01 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Feature Requests-28631 ] Make build process of extension module in sync Message-ID: <20101007210104.2B0A01858346@rubyforge.org> Feature Requests item #28631, was opened at 2010-10-08 06:01 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=578&aid=28631&group_id=126 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Mamoru Tasaka (mtasaka) Assigned to: Nobody (None) Summary: Make build process of extension module in sync Initial Comment: (I am using 1.8.7 patchlevel 302) With using rubygems 1.3.7, when installing gem containing C extension, once rubygems shows --------------------------------------------------------- Building native extensions. This could take a while... --------------------------------------------------------- rubygems will show nothing until compiling / installing C extension gets finished. Then suddenly rubygems flushes all messages received during build process (when $ gem install -V is used). This is annoying when compiling C extension takes not a few time, $ gem install should show messages received during build process simultaneously. The attached patch attempts to show messages during build process in sync. Please consider to apply the attached patch to your tree, thank you. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=578&aid=28631&group_id=126 From luislavena at gmail.com Sun Oct 10 21:38:17 2010 From: luislavena at gmail.com (Luis Lavena) Date: Sun, 10 Oct 2010 22:38:17 -0300 Subject: [Rubygems-developers] is this thing on? Message-ID: Hey guys, Over the past months things have been very quiet in the RubyGems front. Nothing has been planned beyond 1.3.7 release and several new bug reports, patches, pull request and others have been entered in RubyForge and GitHub without a single reply from you guys. In case some of you missed, I've tried bring to attention 2 pull request, but nobody except James or John replied to them. So I've been wondering: what is going on? -- this goes specially to Eric, who is lead and maintainer of RubyGems -- are you too busy? Perhaps your work, life or dunno what is not letting you do anything, but will be great we know about it so we can take a bit more responsibility and take out the pressure of your shoulders. We all have our projects and we drive them as we want, but I believe RubyGems differs from those pet projects since is now considered part of Ruby. I'm reluctant to introduce changes to RubyGems without your blessing or at least a Roadmap/plan for the project. This differs from my pet projects where I can take things in any direction. I know you don't owe us anything, but please take 5 minutes to let us know what are your thoughts on this. Pressure on RubyGems might start building up as newer 1.9.2-p0 release start taking shape. I personally would like to avoid what happen with 0.9.5 and what almost happen with final 1.9.2-p0 Thank you for your time. -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exup?ry From ryand-ruby at zenspider.com Mon Oct 11 05:06:41 2010 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Mon, 11 Oct 2010 02:06:41 -0700 Subject: [Rubygems-developers] is this thing on? In-Reply-To: References: Message-ID: <8827E153-D9A9-4295-BD70-88C48361F434@zenspider.com> On Oct 10, 2010, at 18:38 , Luis Lavena wrote: > So I've been wondering: what is going on? -- this goes specially to > Eric, who is lead and maintainer of RubyGems -- are you too busy? This is just how Eric is. Frustrating as it may be at times, Eric works on what he wants to work on when he wants to work on it. It keeps him sane. Currently his focus is on rdoc. He'll cycle back around to rubygems before long. I through all my years of working with him have not found an effective means of escalating an issue to him when he doesn't want to pay attention to it. From jftucker at gmail.com Mon Oct 11 07:55:33 2010 From: jftucker at gmail.com (James Tucker) Date: Mon, 11 Oct 2010 08:55:33 -0300 Subject: [Rubygems-developers] is this thing on? In-Reply-To: References: Message-ID: <5F75F937-91D7-4067-B3D5-2A9274B6B239@gmail.com> On 10 Oct 2010, at 22:38, Luis Lavena wrote: > Hey guys, > > Over the past months things have been very quiet in the RubyGems front. > > Nothing has been planned beyond 1.3.7 release and several new bug > reports, patches, pull request and others have been entered in > RubyForge and GitHub without a single reply from you guys. It's on my list, but I have to do some rack stuff first and time is limited. > In case some of you missed, I've tried bring to attention 2 pull > request, but nobody except James or John replied to them. > > So I've been wondering: what is going on? -- this goes specially to > Eric, who is lead and maintainer of RubyGems -- are you too busy? I certainly am, I can't talk for others. > Perhaps your work, life or dunno what is not letting you do anything, > but will be great we know about it so we can take a bit more > responsibility and take out the pressure of your shoulders. > > We all have our projects and we drive them as we want, but I believe > RubyGems differs from those pet projects since is now considered part > of Ruby. Yes, and there are things that are critical to that which need to be addressed immediately that are not being addressed in the pull requests. See my notes on the wiki and in the various discussions on ruby-core. Things like progress bars really don't concern me in light of these issues I'm afraid. > I'm reluctant to introduce changes to RubyGems without your blessing > or at least a Roadmap/plan for the project. This differs from my pet > projects where I can take things in any direction. Well, the critical thing in my opinion is that we try to reduce the volume of recent breakage. I'm also still concerned that we're releasing multiple code bases under the same version. I don't like having to check backtraces from customers by asking them to do a "wc -l `gem which rubygems`". > I know you don't owe us anything, but please take 5 minutes to let us > know what are your thoughts on this. > > Pressure on RubyGems might start building up as newer 1.9.2-p0 release > start taking shape. I personally would like to avoid what happen with > 0.9.5 and what almost happen with final 1.9.2-p0 Actually, with the way that integration works (another thing I'd like to address), upgrading rubygems seems to have some errors. This also reaches back into gemcutter, whereby I am concerned that we cannot continue to make sweeping changes like just turning off indexes without breaking versions. If this becomes the case for 1.9.2 before it's even in use as a mainstream version, that would be very sad. This is also (personally) my concern with opening up the project too fast, patches need to have some serious thought put into them with regard to portability and longevity. As you note yourself, this project services quite a wide scope, and that should be addressed. > Thank you for your time. HTH From thewoolleyman at gmail.com Mon Oct 11 15:17:45 2010 From: thewoolleyman at gmail.com (Chad Woolley) Date: Mon, 11 Oct 2010 12:17:45 -0700 Subject: [Rubygems-developers] is this thing on? In-Reply-To: <5F75F937-91D7-4067-B3D5-2A9274B6B239@gmail.com> References: <5F75F937-91D7-4067-B3D5-2A9274B6B239@gmail.com> Message-ID: On Mon, Oct 11, 2010 at 4:55 AM, James Tucker wrote: >> I'm reluctant to introduce changes to RubyGems without your blessing >> or at least a Roadmap/plan for the project. This differs from my pet >> projects where I can take things in any direction. > > Well, the critical thing in my opinion is that we try to reduce the volume of recent breakage. I'm also still concerned that we're releasing multiple code bases under the same version. I don't like having to check backtraces from customers by asking them to do a "wc -l `gem which rubygems`". > >> I know you don't owe us anything, but please take 5 minutes to let us >> know what are your thoughts on this. >> >> Pressure on RubyGems might start building up as newer 1.9.2-p0 release >> start taking shape. I personally would like to avoid what happen with >> 0.9.5 and what almost happen with final 1.9.2-p0 > > Actually, with the way that integration works (another thing I'd like to address), upgrading rubygems seems to have some errors. This also reaches back into gemcutter, whereby I am concerned that we cannot continue to make sweeping changes like just turning off indexes without breaking versions. If this becomes the case for 1.9.2 before it's even in use as a mainstream version, that would be very sad. This is also (personally) my concern with opening up the project too fast, patches need to have some serious thought put into them with regard to portability and longevity. As you note yourself, this project services quite a wide scope, and that should be addressed. The correct way to address these risks and concerns is to have adequate integration tests and continuous integration environments, which allow you to be confident that any given change, in any branch, will not [severely] break any environment which you care about. Having a sophisticated CI environment such as this is a very hard problem. Ironically, my limited personal OSS activities are focused on making this easier, which is why I don't attempt to do much on RubyGems anymore - among other reasons. Peace, long live RubyGems. This will get sorted out. It must, RubyGems is one of the unique strengths of Ruby compared to other languages. -- Chad From jftucker at gmail.com Mon Oct 11 16:34:14 2010 From: jftucker at gmail.com (James Tucker) Date: Mon, 11 Oct 2010 17:34:14 -0300 Subject: [Rubygems-developers] is this thing on? In-Reply-To: References: <5F75F937-91D7-4067-B3D5-2A9274B6B239@gmail.com> Message-ID: <148B5D18-AEF8-4A23-BA27-ADCA26E6A80F@gmail.com> On 11 Oct 2010, at 16:17, Chad Woolley wrote: > On Mon, Oct 11, 2010 at 4:55 AM, James Tucker wrote: >> >> Actually, with the way that integration works (another thing I'd like to address), upgrading rubygems seems to have some errors. This also reaches back into gemcutter, whereby I am concerned that we cannot continue to make sweeping changes like just turning off indexes without breaking versions. If this becomes the case for 1.9.2 before it's even in use as a mainstream version, that would be very sad. This is also (personally) my concern with opening up the project too fast, patches need to have some serious thought put into them with regard to portability and longevity. As you note yourself, this project services quite a wide scope, and that should be addressed. > > The correct way to address these risks and concerns is to have > adequate integration tests and continuous integration environments, > which allow you to be confident that any given change, in any branch, > will not [severely] break any environment which you care about. Features were removed from production servers. That was a conscious human choice. What I'm saying is that if this happens again, the affect to 1.9.2 will be even worse. At least old 1.8.x systems can relatively happily upgrade rubygems to a working version (albeit probably outside their package manager). My point is that kind of indiscretion won't be recoverable in future unless these (process) issues are addressed. History proves that at least a while ago, my views were not shared. We should try to keep a reasonable support time on older versions. I know the ruby community moves fast, but that doesn't really make it acceptable to break production "stable" systems within a year of release, IMO. From darix at web.de Mon Oct 11 17:18:49 2010 From: darix at web.de (Marcus Rueckert) Date: Mon, 11 Oct 2010 23:18:49 +0200 Subject: [Rubygems-developers] is this thing on? In-Reply-To: <148B5D18-AEF8-4A23-BA27-ADCA26E6A80F@gmail.com> References: <5F75F937-91D7-4067-B3D5-2A9274B6B239@gmail.com> <148B5D18-AEF8-4A23-BA27-ADCA26E6A80F@gmail.com> Message-ID: <20101011211849.GE3170@nordisch.org> On 2010-10-11 17:34:14 -0300, James Tucker wrote: > On 11 Oct 2010, at 16:17, Chad Woolley wrote: > > > On Mon, Oct 11, 2010 at 4:55 AM, James Tucker wrote: > >> > >> Actually, with the way that integration works (another thing I'd > >> like to address), upgrading rubygems seems to have some errors. > >> This also reaches back into gemcutter, whereby I am concerned that > >> we cannot continue to make sweeping changes like just turning off > >> indexes without breaking versions. If this becomes the case for > >> 1.9.2 before it's even in use as a mainstream version, that would > >> be very sad. This is also (personally) my concern with opening up > >> the project too fast, patches need to have some serious thought put > >> into them with regard to portability and longevity. As you note > >> yourself, this project services quite a wide scope, and that should > >> be addressed. > > > > The correct way to address these risks and concerns is to have > > adequate integration tests and continuous integration environments, > > which allow you to be confident that any given change, in any branch, > > will not [severely] break any environment which you care about. > > Features were removed from production servers. That was a conscious > human choice. What I'm saying is that if this happens again, the > affect to 1.9.2 will be even worse. At least old 1.8.x systems can > relatively happily upgrade rubygems to a working version (albeit > probably outside their package manager). My point is that kind of > indiscretion won't be recoverable in future unless these (process) > issues are addressed. History proves that at least a while ago, my > views were not shared. We should try to keep a reasonable support time > on older versions. I know the ruby community moves fast, but that > doesn't really make it acceptable to break production "stable" systems > within a year of release, IMO. some people would be happy if they would only need to support old versions for one year. :p some package manager have to do 5-7years. :) darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org From nick at quaran.to Mon Oct 11 17:53:03 2010 From: nick at quaran.to (Nick Quaranto) Date: Mon, 11 Oct 2010 17:53:03 -0400 Subject: [Rubygems-developers] is this thing on? In-Reply-To: <148B5D18-AEF8-4A23-BA27-ADCA26E6A80F@gmail.com> References: <5F75F937-91D7-4067-B3D5-2A9274B6B239@gmail.com> <148B5D18-AEF8-4A23-BA27-ADCA26E6A80F@gmail.com> Message-ID: James, Is there anything we're missing now? I tried pretty hard to test older versions, and having a good CI suite would have helped. If there's something we're missing now I'd like to get it filled in. On Mon, Oct 11, 2010 at 4:34 PM, James Tucker wrote: > > On 11 Oct 2010, at 16:17, Chad Woolley wrote: > > > On Mon, Oct 11, 2010 at 4:55 AM, James Tucker > wrote: > >> > >> Actually, with the way that integration works (another thing I'd like to > address), upgrading rubygems seems to have some errors. This also reaches > back into gemcutter, whereby I am concerned that we cannot continue to make > sweeping changes like just turning off indexes without breaking versions. If > this becomes the case for 1.9.2 before it's even in use as a mainstream > version, that would be very sad. This is also (personally) my concern with > opening up the project too fast, patches need to have some serious thought > put into them with regard to portability and longevity. As you note > yourself, this project services quite a wide scope, and that should be > addressed. > > > > The correct way to address these risks and concerns is to have > > adequate integration tests and continuous integration environments, > > which allow you to be confident that any given change, in any branch, > > will not [severely] break any environment which you care about. > > Features were removed from production servers. That was a conscious human > choice. What I'm saying is that if this happens again, the affect to 1.9.2 > will be even worse. At least old 1.8.x systems can relatively happily > upgrade rubygems to a working version (albeit probably outside their package > manager). My point is that kind of indiscretion won't be recoverable in > future unless these (process) issues are addressed. History proves that at > least a while ago, my views were not shared. We should try to keep a > reasonable support time on older versions. I know the ruby community moves > fast, but that doesn't really make it acceptable to break production > "stable" systems within a year of release, IMO. > _______________________________________________ > Rubygems-developers mailing list > http://rubyforge.org/projects/rubygems > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers > From noreply at rubyforge.org Tue Oct 12 15:08:22 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 12 Oct 2010 15:08:22 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Patches-28644 ] File.read in source_index.rb uses Ruby 1.9 syntax, breaks in 1.8 Message-ID: <20101012190822.9885B185836B@rubyforge.org> Patches item #28644, was opened at 2010-10-12 15:08 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=577&aid=28644&group_id=126 Category: other Group: None Status: Open Resolution: None Priority: 3 Submitted By: Matt Savona (loopforever) Assigned to: Nobody (None) Summary: File.read in source_index.rb uses Ruby 1.9 syntax, breaks in 1.8 Initial Comment: One of our users noted the following issue after an upgrade to RubyGems 1.3.7: => Booting Mongrel (use 'script/server webrick' to force WEBrick) => Rails 2.1.0 application starting on http://0.0.0.0:9296 => Call with -d to detach => Ctrl-C to shutdown server ** Starting Mongrel listening at 0.0.0.0:9296 ** Starting Rails with development environment... ** Rails loaded. ** Loading any Rails specific GemPlugins Exiting /usr/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:89:in `read': can't convert Hash into Integer (TypeError) from /usr/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:89:in `load_specification' from /usr/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:153:in `load_gems_in' from /usr/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:152:in `each' from /usr/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:152:in `load_gems_in' from /usr/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:149:in `reverse_each' from /usr/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:149:in `load_gems_in' from /usr/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:345:in `refresh!' from /usr/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:78:in `from_gems_in' ... 23 levels... from /usr/lib64/ruby/gems/1.8/gems/rails-2.1.0/lib/commands/server.rb:39 from /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require' from /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `require' from script/server:3 The reason for this is because source_index.rb:89 uses the following syntax for File.read when the Encoding constant is defined: 88 spec_code = if defined? Encoding then 89 File.read file_name, :encoding => 'UTF-8' 90 else 91 File.read file_name 92 end.untaint This syntax appears to only be valid in Ruby 1.9. Our environment is: ruby 1.8.6 (2008-08-11 patchlevel 287) [x86_64-linux] I made a very small patch to source_index.rb, which is attached. It will only utilize the Ruby 1.9 File.read syntax if the Encoding constant is defined and RUBY_VERSION.to_f >= 1.9. Please apply upstream if you find this to be an appropriate workaround. Thank you! ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=577&aid=28644&group_id=126 From luislavena at gmail.com Sat Oct 16 15:50:18 2010 From: luislavena at gmail.com (Luis Lavena) Date: Sat, 16 Oct 2010 16:50:18 -0300 Subject: [Rubygems-developers] is this thing on? In-Reply-To: <8827E153-D9A9-4295-BD70-88C48361F434@zenspider.com> References: <8827E153-D9A9-4295-BD70-88C48361F434@zenspider.com> Message-ID: On Mon, Oct 11, 2010 at 6:06 AM, Ryan Davis wrote: > > On Oct 10, 2010, at 18:38 , Luis Lavena wrote: > >> So I've been wondering: what is going on? -- this goes specially to >> Eric, who is lead and maintainer of RubyGems -- are you too busy? > > This is just how Eric is. Frustrating as it may be at times, Eric works on what he wants to work on when he wants to work on it. It keeps him sane. Currently his focus is on rdoc. He'll cycle back around to rubygems before long. I through all my years of working with him have not found an effective means of escalating an issue to him when he doesn't want to pay attention to it. > Hmn, Can we get Eric's schedule, perhaps in a Calendar so every people coming with problems, sending patches and waiting for feedback know when he is available? Like business times (from 9 to 5, Mon-Fri) for Eric will be "Ask this in 2 weeks, see his calendar [here]". -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exup?ry From jon.forums at gmail.com Sun Oct 17 12:39:31 2010 From: jon.forums at gmail.com (Jon) Date: Sun, 17 Oct 2010 12:39:31 -0400 Subject: [Rubygems-developers] is this thing on? In-Reply-To: References: <8827E153-D9A9-4295-BD70-88C48361F434@zenspider.com> Message-ID: <20101017123931.e157af70.jon.forums@gmail.com> > >> So I've been wondering: what is going on? -- this goes specially to > >> Eric, who is lead and maintainer of RubyGems -- are you too busy? > > > > This is just how Eric is. Frustrating as it may be at times, Eric works on what he wants to work on when he wants to work on it. It keeps him sane. Currently his focus is on rdoc. He'll cycle back around to rubygems before long. I through all my years of working with him have not found an effective means of escalating an issue to him when he doesn't want to pay attention to it. > > This response, while informative, is both unhelpful and may fuel existing perceptions that needlessly undermines both the project and Eric-as-Lead. I'm not saying this to start a flame, but the response misses the root issue and does nothing to better perceptions. As a RubyGems user all I really want to see is that the project is managed so that key fixes and features don't linger any longer than needed to create robust solutions. How this is implemented isn't (and shouldn't be) my business. IMO, the root issue appears simply to be that a trusted backup lead/maintainer hasn't been identified who works closely with the lead and who's primary role is to keep things from stagnating when the primary lead/maintainer is unavailable. This has nothing specifically to do with Eric. It's simply a practical acknowledgement that all RubyGems contributors are (a) working for free, (b) have lives/passions outside of Rubygems, and (c) need "me time" to keep sane and passionate. Bluntly, I think the "fix" is for Eric and the contributors to take some time and go offline to quickly figure out a more flexible and realistic way to manage the project. Jon From jftucker at gmail.com Sun Oct 17 15:14:22 2010 From: jftucker at gmail.com (James Tucker) Date: Sun, 17 Oct 2010 16:14:22 -0300 Subject: [Rubygems-developers] is this thing on? In-Reply-To: <20101017123931.e157af70.jon.forums@gmail.com> References: <8827E153-D9A9-4295-BD70-88C48361F434@zenspider.com> <20101017123931.e157af70.jon.forums@gmail.com> Message-ID: <4DCF400E-28DC-46E7-9474-8A7823820C74@gmail.com> On 17 Oct 2010, at 13:39, Jon wrote: >>>> So I've been wondering: what is going on? -- this goes specially to >>>> Eric, who is lead and maintainer of RubyGems -- are you too busy? >>> >>> This is just how Eric is. Frustrating as it may be at times, Eric works on what he wants to work on when he wants to work on it. It keeps him sane. Currently his focus is on rdoc. He'll cycle back around to rubygems before long. I through all my years of working with him have not found an effective means of escalating an issue to him when he doesn't want to pay attention to it. >>> > > This response, while informative, is both unhelpful and may fuel existing perceptions that needlessly undermines both the project and Eric-as-Lead. I'm not saying this to start a flame, but the response misses the root issue and does nothing to better perceptions. Ok. > As a RubyGems user all I really want to see is that the project is managed so that key fixes and features don't linger any longer than needed to create robust solutions. How this is implemented isn't (and shouldn't be) my business. IMO rushing in features is not a good idea for a project of this scope. Not sure if you've looked, but a lot of the patches we receive have platform or design issues, or lack of tests. As for key issues, well the key issues no one seems to supply patches for, and they aren't always trivial to approach cross-platform (that is both platform wise, and interpreter wise, etc). > IMO, the root issue appears simply to be that a trusted backup lead/maintainer hasn't been identified who works closely with the lead and who's primary role is to keep things from stagnating when the primary lead/maintainer is unavailable. This has nothing specifically to do with Eric. It's simply a practical acknowledgement that all RubyGems contributors are (a) working for free, (b) have lives/passions outside of Rubygems, and (c) need "me time" to keep sane and passionate. People who supply good patches with tests get on the team if they ask. That's why Eric gave me a commit bit, hell, one of my patches even had some re-arrangement details for win32, so, there's not even an expectation of perfection at all, just that you supply committable patches often enough for the devs to want to "get out of your way". Honestly, we don't get many people fall into that category. > Bluntly, I think the "fix" is for Eric and the contributors to take some time and go offline to quickly figure out a more flexible and realistic way to manage the project. What exactly is it that you think is so wrong? Maybe if you can explain what the actual specific problem is, I can address it. From thewoolleyman at gmail.com Sun Oct 17 16:19:55 2010 From: thewoolleyman at gmail.com (Chad Woolley) Date: Sun, 17 Oct 2010 13:19:55 -0700 Subject: [Rubygems-developers] is this thing on? In-Reply-To: <4DCF400E-28DC-46E7-9474-8A7823820C74@gmail.com> References: <8827E153-D9A9-4295-BD70-88C48361F434@zenspider.com> <20101017123931.e157af70.jon.forums@gmail.com> <4DCF400E-28DC-46E7-9474-8A7823820C74@gmail.com> Message-ID: On Sun, Oct 17, 2010 at 12:14 PM, James Tucker wrote: > What exactly is it that you think is so wrong? Maybe if you can explain what the actual specific problem is, I can address it. I'm kinda vague on what is wrong as well. If we are talking about regressions for certain scenarios (e.g. feature 'a' breaks when upgrading rubygems from version x to version y on platform/environment/interpreter z), then again I would say that continuous integration is the proper way to mitigate those risks. Whatever that scenario is, have an integration test which sets up that environment, performs the scenario, and asserts that it does not fail. For interpreter-specific issues, RVM makes this much easier than it used to be (and we've always had multi-ruby). This is complex and not easy to do, but it is possible, especially in an EC2 environment with a distributed-build CI tool such as Hudson/Teamcity where you can completely automate the spin-up of boxes for specific distro/environment (including windows). Even better, you can make this type of CI environment easily available to anyone who wishes to hack on Rubygems (e.g. via pre-packaged AMIs), and make green tests across the board a condition of patch acceptance. Is it unattainable pie in the sky dreaming to have this level of automated regression testing? In the short term, yes. But, we can start thinking along these lines - such as creating a official checklist of "things which must not regress for a non-major release", and having concerned volunteers (such as the ones voicing concern on this thread) manually test them and sign off before a release. So, yes, we need to be careful not to break "production" systems, but the way to achieve that goal is to have more rigorous regression testing for important scenarios. Criticizing the current developer leads (de-facto or otherwise) for past breakages is less productive way to approach the problem which does not address the root cause. Taking proactive actions, even if it is just documenting a manual pre-release checklist, is a more productive way to approach the problem. -- Chad From luislavena at gmail.com Sun Oct 17 17:08:01 2010 From: luislavena at gmail.com (Luis Lavena) Date: Sun, 17 Oct 2010 18:08:01 -0300 Subject: [Rubygems-developers] is this thing on? In-Reply-To: References: <8827E153-D9A9-4295-BD70-88C48361F434@zenspider.com> <20101017123931.e157af70.jon.forums@gmail.com> <4DCF400E-28DC-46E7-9474-8A7823820C74@gmail.com> Message-ID: Hey guys, Going to top post on this because: - The original thread is going way to far from my original question. - The trend seems to be defensive/aggressive - It is turning into OT the whole CI/regression conversation. I thought my original question was simple, but going to rephrase it since seems is not: Is anyone leading this thing? And if so, in the case of Eric, when RubyGems will be in his attention-field? Asking this because last time I missed his attention field and 0.9.5 got released turning the following weeks of that a nightmare of support for Ruby on Windows (ala: me). It happen again in one of 1.2.x releases. I don't want to reach strike 3. As Eric, I want to schedule my time properly, and for that I need to know what is going on and where are we headed to. You can bring your whole CI/regression conversation in a new thread if you want, but I have 12 open source project and juggling time for them is turning a bit complicated. Thank you. -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exup?ry From jbarnette at gmail.com Sun Oct 17 22:52:25 2010 From: jbarnette at gmail.com (John Barnette) Date: Sun, 17 Oct 2010 19:52:25 -0700 Subject: [Rubygems-developers] is this thing on? In-Reply-To: References: <8827E153-D9A9-4295-BD70-88C48361F434@zenspider.com> <20101017123931.e157af70.jon.forums@gmail.com> <4DCF400E-28DC-46E7-9474-8A7823820C74@gmail.com> Message-ID: <776A1BF4-CB41-4346-A48F-0CC9466740D9@gmail.com> On Oct 17, 2010, at 2:08 PM, Luis Lavena wrote: > I thought my original question was simple, but going to rephrase it > since seems is not: > > Is anyone leading this thing? And if so, in the case of Eric, when > RubyGems will be in his attention-field? > > Asking this because last time I missed his attention field and 0.9.5 > got released turning the following weeks of that a nightmare of > support for Ruby on Windows (ala: me). It happen again in one of 1.2.x > releases. I don't want to reach strike 3. Thanks for bringing this back to topic. Many of us (Eric and Ryan (I assume), me, Evan, others?) will be down at RubyConf here in a few weeks. I think we can hammer out a bit of a plan for the next release over a drink or two. ~ j. From nick at quaran.to Sun Oct 17 23:06:15 2010 From: nick at quaran.to (Nick Quaranto) Date: Sun, 17 Oct 2010 23:06:15 -0400 Subject: [Rubygems-developers] is this thing on? In-Reply-To: <776A1BF4-CB41-4346-A48F-0CC9466740D9@gmail.com> References: <8827E153-D9A9-4295-BD70-88C48361F434@zenspider.com> <20101017123931.e157af70.jon.forums@gmail.com> <4DCF400E-28DC-46E7-9474-8A7823820C74@gmail.com> <776A1BF4-CB41-4346-A48F-0CC9466740D9@gmail.com> Message-ID: I'll be there, we should definitely get the team together. On Sun, Oct 17, 2010 at 10:52 PM, John Barnette wrote: > On Oct 17, 2010, at 2:08 PM, Luis Lavena wrote: > > I thought my original question was simple, but going to rephrase it > > since seems is not: > > > > Is anyone leading this thing? And if so, in the case of Eric, when > > RubyGems will be in his attention-field? > > > > Asking this because last time I missed his attention field and 0.9.5 > > got released turning the following weeks of that a nightmare of > > support for Ruby on Windows (ala: me). It happen again in one of 1.2.x > > releases. I don't want to reach strike 3. > > Thanks for bringing this back to topic. Many of us (Eric and Ryan (I > assume), me, Evan, others?) will be down at RubyConf here in a few weeks. I > think we can hammer out a bit of a plan for the next release over a drink or > two. > > > ~ j. > > _______________________________________________ > Rubygems-developers mailing list > http://rubyforge.org/projects/rubygems > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers > From thewoolleyman at gmail.com Mon Oct 18 00:38:06 2010 From: thewoolleyman at gmail.com (Chad Woolley) Date: Sun, 17 Oct 2010 21:38:06 -0700 Subject: [Rubygems-developers] is this thing on? In-Reply-To: <776A1BF4-CB41-4346-A48F-0CC9466740D9@gmail.com> References: <8827E153-D9A9-4295-BD70-88C48361F434@zenspider.com> <20101017123931.e157af70.jon.forums@gmail.com> <4DCF400E-28DC-46E7-9474-8A7823820C74@gmail.com> <776A1BF4-CB41-4346-A48F-0CC9466740D9@gmail.com> Message-ID: On Sun, Oct 17, 2010 at 7:52 PM, John Barnette wrote: > Thanks for bringing this back to topic. Many of us (Eric and Ryan (I assume), me, Evan, others?) will be down at RubyConf here in a few weeks. I think we can hammer out a bit of a plan for the next release over a drink or two. Sounds like a great plan. I hope it also results in an on-list follow up with items to address the concerns raised in this thread (release plan visibility, how to avoid regressions on windows and other environments, etc). You know, for the benefit of those who can't come to the bayou and drink beers with you all... -- Chad From jftucker at gmail.com Mon Oct 18 07:57:25 2010 From: jftucker at gmail.com (James Tucker) Date: Mon, 18 Oct 2010 08:57:25 -0300 Subject: [Rubygems-developers] is this thing on? In-Reply-To: <776A1BF4-CB41-4346-A48F-0CC9466740D9@gmail.com> References: <8827E153-D9A9-4295-BD70-88C48361F434@zenspider.com> <20101017123931.e157af70.jon.forums@gmail.com> <4DCF400E-28DC-46E7-9474-8A7823820C74@gmail.com> <776A1BF4-CB41-4346-A48F-0CC9466740D9@gmail.com> Message-ID: On 17 Oct 2010, at 23:52, John Barnette wrote: > On Oct 17, 2010, at 2:08 PM, Luis Lavena wrote: >> I thought my original question was simple, but going to rephrase it >> since seems is not: >> >> Is anyone leading this thing? And if so, in the case of Eric, when >> RubyGems will be in his attention-field? >> >> Asking this because last time I missed his attention field and 0.9.5 >> got released turning the following weeks of that a nightmare of >> support for Ruby on Windows (ala: me). It happen again in one of 1.2.x >> releases. I don't want to reach strike 3. > > Thanks for bringing this back to topic. Many of us (Eric and Ryan (I assume), me, Evan, others?) will be down at RubyConf here in a few weeks. I think we can hammer out a bit of a plan for the next release over a drink or two. I'll be there too. From jftucker at gmail.com Mon Oct 18 08:04:08 2010 From: jftucker at gmail.com (James Tucker) Date: Mon, 18 Oct 2010 09:04:08 -0300 Subject: [Rubygems-developers] is this thing on? In-Reply-To: References: <8827E153-D9A9-4295-BD70-88C48361F434@zenspider.com> <20101017123931.e157af70.jon.forums@gmail.com> <4DCF400E-28DC-46E7-9474-8A7823820C74@gmail.com> Message-ID: On 17 Oct 2010, at 18:08, Luis Lavena wrote: > Hey guys, > > Going to top post on this because: > > - The original thread is going way to far from my original question. > - The trend seems to be defensive/aggressive > - It is turning into OT the whole CI/regression conversation. > > I thought my original question was simple, but going to rephrase it > since seems is not: > > Is anyone leading this thing? And if so, in the case of Eric, when > RubyGems will be in his attention-field? > > Asking this because last time I missed his attention field and 0.9.5 > got released turning the following weeks of that a nightmare of > support for Ruby on Windows (ala: me). It happen again in one of 1.2.x > releases. I don't want to reach strike 3. > > As Eric, I want to schedule my time properly, and for that I need to > know what is going on and where are we headed to. > > You can bring your whole CI/regression conversation in a new thread if > you want, but I have 12 open source project and juggling time for them > is turning a bit complicated. As it happens, not currently having the ability to test on win32 is the exact reason I personally haven't merged the progressbars patches. That and scripted installs, there's a few other platform / use case oddities that need to be checked out. I want to get to it, but I'm not rushing as it's the kind of thing that doesn't work properly on non/bad ttys. As far as making testing on win32 easier is concerned, that'd help, but I'm not sure if anyones willing to fork out for a win32 CI box. I actually do have space on a server I have knocking around, but in my case, time and simple remote access are the annoying factors. From jftucker at gmail.com Mon Oct 18 08:05:34 2010 From: jftucker at gmail.com (James Tucker) Date: Mon, 18 Oct 2010 09:05:34 -0300 Subject: [Rubygems-developers] is this thing on? In-Reply-To: References: <8827E153-D9A9-4295-BD70-88C48361F434@zenspider.com> <20101017123931.e157af70.jon.forums@gmail.com> <4DCF400E-28DC-46E7-9474-8A7823820C74@gmail.com> Message-ID: <3063AAE2-7C8C-4868-ADC4-533FE0968637@gmail.com> My last also goes for chef, which is typically peering into random bits of internals and much of the UI in ways that's a bit of a pain to maintain. I'd love to have the time to support them better too. From jftucker at gmail.com Mon Oct 18 08:36:35 2010 From: jftucker at gmail.com (James Tucker) Date: Mon, 18 Oct 2010 09:36:35 -0300 Subject: [Rubygems-developers] is this thing on? In-Reply-To: References: <5F75F937-91D7-4067-B3D5-2A9274B6B239@gmail.com> <148B5D18-AEF8-4A23-BA27-ADCA26E6A80F@gmail.com> Message-ID: <98616B4C-6025-4B1B-9568-BA7E206CBD89@gmail.com> On 11 Oct 2010, at 18:53, Nick Quaranto wrote: > James, > > Is there anything we're missing now? I tried pretty hard to test older > versions, and having a good CI suite would have helped. If there's something > we're missing now I'd like to get it filled in. AFAIK, the 302s basically stop older versions from working. I haven't checked this out since you fixed the old index though, and I don't know of an old version CI suite for the server side, ideologically speaking, that would have been put together before making major changes. From jon.forums at gmail.com Mon Oct 18 11:04:59 2010 From: jon.forums at gmail.com (Jon) Date: Mon, 18 Oct 2010 11:04:59 -0400 Subject: [Rubygems-developers] is this thing on? In-Reply-To: <4DCF400E-28DC-46E7-9474-8A7823820C74@gmail.com> References: <8827E153-D9A9-4295-BD70-88C48361F434@zenspider.com> <20101017123931.e157af70.jon.forums@gmail.com> <4DCF400E-28DC-46E7-9474-8A7823820C74@gmail.com> Message-ID: <20101018110459.f2ba5d9f.jon.forums@gmail.com> > What exactly is it that you think is so wrong? Maybe if you can explain what the actual specific problem is, I can address it. After reading this morning's responses, I disagree with Luis's comment that "The trend seems to be defensive/aggressive." While I see direct, non-PC feedback, frankly I see no evidence of either defensiveness or aggressiveness. Thank you for the non-defensiveness, and if I've accidently offended anyone with my feedback, that wasn't my intent. While I agree that threads that devolve should be brought back in line, it's a two-edged sword. Potentially productive (and difficult) discussions can be cut off too early. Specific process areas I see that are ripe for improvement: 1) Increased communication and a tweaking of contributor roles. I think perceptions such as [1] with phrases like "..he looks like ineligible for a maintainer" and "...the very poor maintenance status of rubygems..." are warning signs that the issue level has outpaced the project's ability to respond in a timely manner. This thread's issues and responses also appear (at least to me) to be warning signs. To me, these warnings indicate a need to review how RubyGems best utilizes it's contributors skills. As a User developer (outsider), I fully appreciate the fact that I don't have all the facts, but I think ideas like Backup Lead and/or Next Release Wrangler could help offload Eric when needed, enable much needed contributor "me time", take better advantage of the contributor horsepower you have, and minimize perceptions and emails like [1]. In a nutshell, evolution in the face of RubyGems central role. While the suggestions may sound good on paper, at the end of the day, you're in the best position to know what's sustainable by you. 2) Increased issue prioritization visibility. What are the key issues preventing the next release? There's no Issues at http://github.com/rubygems/rubygems (not really a problem) and the 59 open issues at [2] (sorted by Priority) don't really indicate which of those are viewed as "must fix" for the next release. Maybe this list lives somewhere and I'm missing it? I think a wiki page similar to [3] listing the just the key issues preventing the *next* RubyGems release is both maintainable and has tremendous benefits including: * Focusing contributor efforts to the highest priority issues. * Enables easier Drive-by-Contributions for folks having a limited amount of time to contribute, but wanting to contribute in the high value-add places. * Better expectation management. For example, if someone posted a bug, noticed it wasn't considered enough of an issue for the next release (and felt strongly about it), they could try to be more persuasive as to the risks if the issue remains unresolved. While I have my own favorites I'd like to see fixed, the issue I currently feel most strongly about is the RubyGems 1.3.7 differences between the one embedded in 1.9.2-p0 and standalone...both for technical and precedent reasons. Jon [1] http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/31236 [2] http://rubyforge.org/tracker/index.php?group_id=126&atid=575 [3] http://github.com/rubygems/rubygems/wiki/Summary-of-major-issues From jftucker at gmail.com Mon Oct 18 13:32:20 2010 From: jftucker at gmail.com (James Tucker) Date: Mon, 18 Oct 2010 14:32:20 -0300 Subject: [Rubygems-developers] is this thing on? In-Reply-To: <20101018110459.f2ba5d9f.jon.forums@gmail.com> References: <8827E153-D9A9-4295-BD70-88C48361F434@zenspider.com> <20101017123931.e157af70.jon.forums@gmail.com> <4DCF400E-28DC-46E7-9474-8A7823820C74@gmail.com> <20101018110459.f2ba5d9f.jon.forums@gmail.com> Message-ID: On 18 Oct 2010, at 12:04, Jon wrote: > > 1) Increased communication and a tweaking of contributor roles. I think perceptions such as [1] with phrases like "..he looks like ineligible for a maintainer" and "...the very poor maintenance status of rubygems..." are warning signs that the issue level has outpaced the project's ability to respond in a timely manner. This thread's issues and responses also appear (at least to me) to be warning signs. To me, these warnings indicate a need to review how RubyGems best utilizes it's contributors skills. Sure, it'd be nice if we had someone paid to work on this full time, but that's not the case. I don't see anyone stepping forward, all I see are complaints about the fact that people are saying they're busy. I don't even see critical issues being addressed by patches, I mostly see patches for trivial UI changes, or specific mal-usecases. There is a great history of real bugs in the rubyforge backlog, and quite a few patches that need someone to read, think, and rewrite. > As a User developer (outsider), I fully appreciate the fact that I don't have all the facts, but I think ideas like Backup Lead and/or Next Release Wrangler could help offload Eric when needed, enable much needed contributor "me time", take better advantage of the contributor horsepower you have, and minimize perceptions and emails like [1]. In a nutshell, evolution in the face of RubyGems central role. While the suggestions may sound good on paper, at the end of the day, you're in the best position to know what's sustainable by you. This is all very well and good, but who's stepping up? > 2) Increased issue prioritization visibility. What are the key issues preventing the next release? There's no Issues at http://github.com/rubygems/rubygems (not really a problem) and the 59 open issues at [2] (sorted by Priority) don't really indicate which of those are viewed as "must fix" for the next release. Maybe this list lives somewhere and I'm missing it? There aren't any "must fix", the critical issues are that of integration points and feature enhancements. They're also quite tied to required feedback to ruby-core which takes some thought. In that regard, other patches for UI and so on are quite acceptable, but their acceptance requires testing time, which is boring and requires diligence in order to not break use cases the original author may not have thought about. > I think a wiki page similar to [3] listing the just the key issues preventing the *next* RubyGems release is both maintainable and has tremendous benefits including: > > * Focusing contributor efforts to the highest priority issues. > * Enables easier Drive-by-Contributions for folks having a limited amount of time to contribute, but wanting to contribute in the high value-add places. > * Better expectation management. For example, if someone posted a bug, noticed it wasn't considered enough of an issue for the next release (and felt strongly about it), they could try to be more persuasive as to the risks if the issue remains unresolved. This is basically all done on the bug tracker right now. Erik Hollensbe persuaded me to start collating some of the issues wrt platform and plugin stuff that I'm working on over on that wiki, which is fine, but the reality is, time spent working on that meant I didn't get the code done for the plugin stuff. I'm hoping I can do that at Rubyconf. What you're asking is that I write down all my thoughts in great detail, which takes much longer than writing the code or doing the due dilligence and research, basically multiplying my workload by 4x. I'd agree with this if it would result in patches and better thinking from people, indeed that's what I hoped when I put the details up on the wiki at Eriks request. Thus far, that's proven to be a complete pipe dream. I'd really like to know what you're even expecting out of this? Have you tested these expectations? Are they realistic? Drive-by contributions tend to be limited to a single developer, operating on a single platform, running their tests in a single context on a single interpreter. That adds almost as much load as it "saves". > While I have my own favorites I'd like to see fixed, the issue I currently feel most strongly about is the RubyGems 1.3.7 differences between the one embedded in 1.9.2-p0 and standalone...both for technical and precedent reasons. What is done to the Rubygems that's in core is almost inexcusable. Every single developer I've spoken to about what these patches actually do (changing the code base without changing the version, changing the manner in which code is loaded, alter load order semantics in certain cases, etc) they all agree. Sure it'd be nice to educate the whole world, hell I'd like it if I could just dump my and many other peoples brains into a book and force feed it to all new developers. That feeling of mine is arrogant and unacceptable though. The fact is, people either do great work in their patches or they don't. They either understand platforms or they don't and they either look for edge cases or they don't. The edge cases around even "trivial" things like --format-executable are really numerous and somewhat complex social and technical issues. I've seen recommendations going every which way on these topics, and none of them are well suited for a wider variety of user contexts. In order to hit that sweet spot, you've got to practice. Marcus keeps telling me I can use OBS as a kind of CI environment for a lot of *n*x platforms, and that would be great, but I've got to learn OBS too in order to start utilising this. Loads of people seem to come forward with a lot of energy to build the initial spike test of an idea, but always end up disappearing or falling back at the platform issues and such. There is only so much hand-holding available, and until someone steps up who's willing to do that work, your words are merely just documenting the situation in a way that makes everyone slightly uneasy. You want more contributors, but are you going to step up? Are you willing to pay for a CI system that has a VM for a few major linux platforms, BSD, OSX and Windows? Are you willing to build up an OBS attachment so we can do cross-package cross-version testing? Would you build a server testing CI to test rubygems.org against older rubygems release versions as well as master? Will you grab the current pull requests and give us a report of ruby versions and major interpreters and platforms in an easy to understand matrix of output showing where it causes failures? Will you then test that against chef and bundler too, to ensure it doesn't break those? And finally what about against plugins, geminstaller, isolate, gem2rpm, etc? Step up please, because that's all that will really help. From thewoolleyman at gmail.com Mon Oct 18 14:09:13 2010 From: thewoolleyman at gmail.com (Chad Woolley) Date: Mon, 18 Oct 2010 11:09:13 -0700 Subject: [Rubygems-developers] is this thing on? In-Reply-To: References: <8827E153-D9A9-4295-BD70-88C48361F434@zenspider.com> <20101017123931.e157af70.jon.forums@gmail.com> <4DCF400E-28DC-46E7-9474-8A7823820C74@gmail.com> <20101018110459.f2ba5d9f.jon.forums@gmail.com> Message-ID: On Mon, Oct 18, 2010 at 10:32 AM, James Tucker wrote: > You want more contributors, but are you going to step up? Are you willing to pay for a CI system that has a VM for a few major linux platforms, BSD, OSX and Windows? Are you willing to build up an OBS attachment so we can do cross-package cross-version testing? Would you build a server testing CI to test rubygems.org against older rubygems release versions as well as master? Will you grab the current pull requests and give us a report of ruby versions and major interpreters and platforms in an easy to understand matrix of output showing where it causes failures? Will you then test that against chef and bundler too, to ensure it doesn't break those? And finally what about against plugins, geminstaller, isolate, gem2rpm, etc? I will step up to this task, and it is the main focus of my long-term OSS efforts. I also want to do it for Rails and Ruby itself. Unfortunately, it is a very large and complicated task, and getting anything usable is probably still at least a year or so out (my OSS work moves at glacial speed compared to others). -- Chad From jon.forums at gmail.com Mon Oct 18 15:34:35 2010 From: jon.forums at gmail.com (Jon) Date: Mon, 18 Oct 2010 15:34:35 -0400 Subject: [Rubygems-developers] is this thing on? In-Reply-To: References: <8827E153-D9A9-4295-BD70-88C48361F434@zenspider.com> <20101017123931.e157af70.jon.forums@gmail.com> <4DCF400E-28DC-46E7-9474-8A7823820C74@gmail.com> <20101018110459.f2ba5d9f.jon.forums@gmail.com> Message-ID: <20101018153435.f5025a6b.jon.forums@gmail.com> > Sure, it'd be nice if we had someone paid to work on this full time, but that's not the case. I don't see anyone stepping forward, all I see are complaints about the fact that people are saying they're busy. Perhaps an existing contributor has extra cycles to be Next Release Wrangler if they saw *exactly* what should be addressed for the next release and could determine whether they can make the commitment. That's not to say this person is responsible for implementing all the fixes. Odds are probably against it though, but I see value in explicitly stating the v.next Fix List and seeing where things go. > There is a great history of real bugs in the rubyforge backlog, and quite a few patches that need someone to read, think, and rewrite. >....[SNIP].... > There aren't any "must fix", the critical issues are that of integration points and feature enhancements. Throw up a target by explicitly prioritizing the big issues in the backlog. What in your view are the 3-5 bugs currently in the rubyforge tracker that, if fixed, would cause you to green light a 1.3.8? > What you're asking is that I write down all my thoughts in great detail, which takes much longer than writing the code or doing the due dilligence and research, basically multiplying my workload by 4x. No, I only want to know the "official" top issues to resolve for a 1.3.8 release. > I'd agree with this if it would result in patches and better thinking from people, indeed that's what I hoped when I put the details up on the wiki at Eriks request. Thus far, that's proven to be a complete pipe dream. Unfortunately, I have to agree with you on this. That said, there are often non-immediate serendipities (?) that occur that always surprise me. For example, as part of the RubyInstaller project, the effort to make it easier for Windows users to build native extensions has recently led someone to work on porting Redis to Windows -> http://groups.google.com/group/rubyinstaller/browse_thread/thread/ba6bac3df60fefdb > You want more contributors, but are you going to step up? Are you willing to pay for a CI system that has a VM for a few major linux platforms, BSD, OSX and Windows? > >....[SNIP].... > > Step up please, because that's all that will really help. Sadly, I don't have the time to commit to doing any of these in a sustainable, value-add manner so I'm not going to lie to you, say I might, jump in and then disappear. What I currently have time to do is maintaining wiki documentation that might jump start others to help with these efforts and offer to help offload you on documentation stuff. Your expertise and limited time is best used solving the hard issues. I'm thinking of two key pages: Next Release Showstoppers (short-n-sweet listing and links back to the current 3-5 top rubyforge bugs), and RubyGems Project Needs (CI, OBS, etc). With the project needs clearly identified, shopping for project sponsors, starting a Pledgie for financing CI/VM needs, etc makes more sense. I admit these sound trivially underwhelming given all that you've identified, but if this micro-step-up could add any value, I'll do it. Jon From jftucker at gmail.com Mon Oct 18 17:03:03 2010 From: jftucker at gmail.com (James Tucker) Date: Mon, 18 Oct 2010 18:03:03 -0300 Subject: [Rubygems-developers] is this thing on? In-Reply-To: References: <8827E153-D9A9-4295-BD70-88C48361F434@zenspider.com> <20101017123931.e157af70.jon.forums@gmail.com> <4DCF400E-28DC-46E7-9474-8A7823820C74@gmail.com> <20101018110459.f2ba5d9f.jon.forums@gmail.com> Message-ID: <6A2E2FA8-1E97-4B43-9FEE-5B28D3F7876D@gmail.com> On 18 Oct 2010, at 15:09, Chad Woolley wrote: > On Mon, Oct 18, 2010 at 10:32 AM, James Tucker wrote: >> You want more contributors, but are you going to step up? Are you willing to pay for a CI system that has a VM for a few major linux platforms, BSD, OSX and Windows? Are you willing to build up an OBS attachment so we can do cross-package cross-version testing? Would you build a server testing CI to test rubygems.org against older rubygems release versions as well as master? Will you grab the current pull requests and give us a report of ruby versions and major interpreters and platforms in an easy to understand matrix of output showing where it causes failures? Will you then test that against chef and bundler too, to ensure it doesn't break those? And finally what about against plugins, geminstaller, isolate, gem2rpm, etc? > > I will step up to this task, and it is the main focus of my long-term > OSS efforts. I also want to do it for Rails and Ruby itself. > Unfortunately, it is a very large and complicated task, and getting > anything usable is probably still at least a year or so out (my OSS > work moves at glacial speed compared to others). That would be awesome Chad thank you, I know you've run CI for us in the past too, and that was a great help at various times (IMO). Thank you for stepping up, if I can help with specifics at any time, please feel free to get in contact. From noreply at rubyforge.org Mon Oct 18 17:08:06 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 18 Oct 2010 17:08:06 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-27154 ] Computed hash is sometimes too large. Message-ID: <20101018210806.7723D197828C@rubyforge.org> Bugs item #27154, was opened at 2009-09-21 14:42 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27154&group_id=126 Category: `gem install` command Group: None Status: Open Resolution: None Priority: 3 Submitted By: Ryan Riley (panesofglass) Assigned to: Nobody (None) Summary: Computed hash is sometimes too large. Initial Comment: The current hash algorithm in dependency.rb (line 138) and specification.rb (line 658) can sometimes create a hash that is too large. This is also possible with Array#hash in MRI, which can also misbehave if one of the array elements returns a large hash value: class C def hash 100000000000000000000 end end [C.new].hash # => in `hash': bignum too big to convert into `long' (RangeError) REXML has a similar issue. http://redmine.ruby- lang.org/issues/show/1883 tracks the issue, and MRI will be fixing the issue. Suggested fixes are: edit: c:/ruby/libs/ruby/site_ruby/1.8/rubygems/dependency.rb;C840659 File: dependency.rb =================================================================== --- c:/ruby/libs/ruby/site_ruby/1.8/rubygems/dependency.rb;C840659 (server) 6/23/2009 1:21 PM +++ c:/ruby/libs/ruby/site_ruby/1.8/rubygems/dependency.rb @@ -112,7 +112,7 @@ end def hash # :nodoc: - name.hash + type.hash + version_requirements.hash + name.hash ^ type.hash ^ version_requirements.hash end end =================================================================== edit: c:/ruby/libs/ruby/site_ruby/1.8/rubygems/specification.rb;C908357 File: specification.rb =================================================================== --- c:/ruby/libs/ruby/site_ruby/1.8/rubygems/specification.rb;C908357 (server) 6/23/2009 1:24 PM +++ c:/ruby/libs/ruby/site_ruby/1.8/rubygems/specification.rb @@ -661,9 +661,8 @@ private :same_attributes? def hash # :nodoc: - @@attributes.inject(0) { |hash_code, (name, default_value)| - n = self.send(name).hash - hash_code + n + @@attributes.inject(612553) { |hash_code, (name, default_value)| + hash_code ^ self.send(name).hash } end =================================================================== ---------------------------------------------------------------------- Comment By: Craig Cook (ccook) Date: 2010-10-18 21:08 Message: Hello, I tried this patch, but I am still getting the error, at the same place in the code. The error is the same with or without the patch to specification.rb; dependency.rb was already like the patched part shown above. This happened when installing using bundler, executed via capistrano. We had been using hpricot, it wasn't needed, it was giving this error first. I took it out, but then the same RangeError happened with mysql. I've seen it before also with nokogiri. (Always with native gems, though). Here's the relevant part of the log: ----------- begin log ---------------------------- ** [out :: 192.168.10.63] Installing mysql (2.8.1) ** [out :: 192.168.10.63] with native extensions ** [out :: 192.168.10.62] /usr/lib/ruby/site_ruby/1.8/rubygems/requirement.rb:109:in `hash' ** [out :: 192.168.10.62] : ** [out :: 192.168.10.62] bignum too big to convert into `long' ** [out :: 192.168.10.62] ( ** [out :: 192.168.10.62] RangeError ** [out :: 192.168.10.62] ) ** [out :: 192.168.10.62] from /usr/lib/ruby/site_ruby/1.8/rubygems/requirement.rb:109:in `hash' ** [out :: 192.168.10.62] from /usr/lib/ruby/site_ruby/1.8/rubygems/specification.rb:675:in `hash' ** [out :: 192.168.10.62] from /usr/lib/ruby/1.8/fileutils.rb:243:in `inject' ** [out :: 192.168.10.62] from /usr/lib/ruby/site_ruby/1.8/rubygems/specification.rb:674:in `each' ** [out :: 192.168.10.62] from /usr/lib/ruby/site_ruby/1.8/rubygems/specification.rb:674:in `inject' ** [out :: 192.168.10.62] from /usr/lib/ruby/site_ruby/1.8/rubygems/specification.rb:674:in `hash' ** [out :: 192.168.10.62] from /usr/lib/ruby/1.8/tsort.rb:205:in `include?' ** [out :: 192.168.10.62] from /usr/lib/ruby/1.8/tsort.rb:205:in `each_strongly_connected_component_from' ** [out :: 192.168.10.62] ... 22 levels... ** [out :: 192.168.10.62] from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.2/lib/bundler/vendor/thor/base.rb:389:in `start' ** [out :: 192.168.10.62] from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.2/bin/bundle:13 ** [out :: 192.168.10.62] from /usr/bin/bundle:19:in `load' ** [out :: 192.168.10.62] from /usr/bin/bundle:19 ----------- end cap output ------------------- running: ------------ system & ruby info ------------------ [ccook at ev2-stage ~]$ ruby -v ruby 1.8.7 (2010-08-16 patchlevel 302) [i686-linux] [ccook at ev2-stage ~]$ gem -v 1.3.7 [ccook at ev2-stage ~]$ uname -a Linux ev2-stage 2.6.18-194.11.4.el5xen #1 SMP Tue Sep 21 06:28:04 EDT 2010 i686 i686 i386 GNU/Linux ------ end system / ruby info ---------- Gemfile: ----------- begin Gemfile ----------------- source :gemcutter gem 'rails', '2.3.8' gem 'mysql', '2.8.1' gem "geokit" gem "geokit-rails" gem "builder" gem 'chronic' gem 'whenever' gem 'database_cleaner' gem 'apn_on_rails' gem 'factory_girl' gem 'net-sftp' gem 'will_paginate' # dependency for squirrel & jqgrid gem 'nokogiri' # only for test/functional/auth_controller_test.rb gem 'cucumber' gem 'cucumber-rails' gem 'webrat' gem 'rspec' ---------- end Gemfile ----------------- So, is this the same issue? It sure looks like it to me. I hope not to have to dive into the innards of rubygems if possible. But we need to be able to deploy. The app is working and passing tests on development, but hard to say on staging as we can't get it over there with cap. I suppose it could all be done by hand once anyway, but we (other dev on my team and I ) need to be able to do this over again. Thanks for your time in this! Cheers, Craig ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27154&group_id=126 From jon.forums at gmail.com Mon Oct 18 17:38:50 2010 From: jon.forums at gmail.com (Jon) Date: Mon, 18 Oct 2010 17:38:50 -0400 Subject: [Rubygems-developers] is this thing on? In-Reply-To: <20101018153435.f5025a6b.jon.forums@gmail.com> References: <8827E153-D9A9-4295-BD70-88C48361F434@zenspider.com> <20101017123931.e157af70.jon.forums@gmail.com> <4DCF400E-28DC-46E7-9474-8A7823820C74@gmail.com> <20101018110459.f2ba5d9f.jon.forums@gmail.com> <20101018153435.f5025a6b.jon.forums@gmail.com> Message-ID: <20101018173850.caab0ab9.jon.forums@gmail.com> Looking over this discussion James, I should have changed the subject before my last reply to your last message. There's no need to respond, but my micro-offer still stands. Luis, I appologize for threadjacking and would also like to see answers to your questions. Sorry :( Jon From jftucker at gmail.com Mon Oct 18 18:30:42 2010 From: jftucker at gmail.com (James Tucker) Date: Mon, 18 Oct 2010 19:30:42 -0300 Subject: [Rubygems-developers] is this thing on? In-Reply-To: <20101018153435.f5025a6b.jon.forums@gmail.com> References: <8827E153-D9A9-4295-BD70-88C48361F434@zenspider.com> <20101017123931.e157af70.jon.forums@gmail.com> <4DCF400E-28DC-46E7-9474-8A7823820C74@gmail.com> <20101018110459.f2ba5d9f.jon.forums@gmail.com> <20101018153435.f5025a6b.jon.forums@gmail.com> Message-ID: <78497D41-D661-4025-9580-41ABDA1C6142@gmail.com> On 18 Oct 2010, at 16:34, Jon wrote: >> Sure, it'd be nice if we had someone paid to work on this full time, but that's not the case. I don't see anyone stepping forward, all I see are complaints about the fact that people are saying they're busy. > > Perhaps an existing contributor has extra cycles to be Next Release Wrangler if they saw *exactly* what should be addressed for the next release and could determine whether they can make the commitment. That's not to say this person is responsible for implementing all the fixes. > > Odds are probably against it though, but I see value in explicitly stating the v.next Fix List and seeing where things go. I'm trying to understand what you're getting at here. It seems to me that you're skipping around not actually saying that you want a release "next week" or "next month" and you want someone you can call out if this doesn't happen. I'm really interested to know what it is that needs direct attention to you, and why this pressure is being applied and you want to set some target in stone. What's the value? Where is this coming from? >> There is a great history of real bugs in the rubyforge backlog, and quite a few patches that need someone to read, think, and rewrite. >> ....[SNIP].... >> There aren't any "must fix", the critical issues are that of integration points and feature enhancements. > > Throw up a target by explicitly prioritizing the big issues in the backlog. What in your view are the 3-5 bugs currently in the rubyforge tracker that, if fixed, would cause you to green light a 1.3.8? I'm not really worried about 1.3.8, I'm actually more looking toward something that would be a 1.4 with the changes I want to make. Plugin API changes have been documented both on the ML and in the Wiki entries. Longer term changes to get platform integration stuff done, I'm looking at a February target. I've scheduled it that far out so that I have the chance to schedule some time for this, even if it requires me booking time off work to really focus on it. I'd rather not do that, but I may need to. I'm also still researching as time allows, what is required by each platform, there are lots of steps to this task, and those require lots of writing to other people if someone else wants to take it on. I'm not going to waste those hours unless someone is actually realistically putting at least 20 or so hours on the table (for someone with real experience, more for someone who has less - which would also take more of my time away from other things). >> What you're asking is that I write down all my thoughts in great detail, which takes much longer than writing the code or doing the due dilligence and research, basically multiplying my workload by 4x. > > No, I only want to know the "official" top issues to resolve for a 1.3.8 release. 1.3.8 would be a bugfix release. Most critical bugs have been tackled in master already, but there are more outstanding in the tracker. I'd try to clear the tracker next time I sit down to do maintenance work, or at least get through a major chunk of it. >> I'd agree with this if it would result in patches and better thinking from people, indeed that's what I hoped when I put the details up on the wiki at Eriks request. Thus far, that's proven to be a complete pipe dream. > > Unfortunately, I have to agree with you on this. That said, there are often non-immediate serendipities (?) that occur that always surprise me. For example, as part of the RubyInstaller project, the effort to make it easier for Windows users to build native extensions has recently led someone to work on porting Redis to Windows -> http://groups.google.com/group/rubyinstaller/browse_thread/thread/ba6bac3df60fefdb I really don't see how this applies. The statement is really along the lines of "doing anything could cause anything else to happen", that's great, but it's not a target. >> You want more contributors, but are you going to step up? Are you willing to pay for a CI system that has a VM for a few major linux platforms, BSD, OSX and Windows? >> >> ....[SNIP].... >> >> Step up please, because that's all that will really help. > > Sadly, I don't have the time to commit to doing any of these in a sustainable, value-add manner so I'm not going to lie to you, say I might, jump in and then disappear. Then I think this discussion needs to end, because it too is dissolving available time. > What I currently have time to do is maintaining wiki documentation that might jump start others to help with these efforts and offer to help offload you on documentation stuff. Your expertise and limited time is best used solving the hard issues. I'm thinking of two key pages: Next Release Showstoppers (short-n-sweet listing and links back to the current 3-5 top rubyforge bugs), and RubyGems Project Needs (CI, OBS, etc). You want to write documentation, but you don't have the info in your head. If you are willing to take a mass flood of info over skype, research it until you can communicate it more clearly, then contact me off list and I will rant at you for an hour or so. If you believe this will be useful, and you have the time to do it, fantastic, please do so. I'd encourage any contributions in that way. Alternatively, if you want less stressful documentation to do, the articles on docs.rubygems.org still need updating and improving, so please, have at it. One section that immediately comes to mind is the section on gemspecs. > With the project needs clearly identified, shopping for project sponsors, starting a Pledgie for financing CI/VM needs, etc makes more sense. Most of us (from what I can gather, this is at least true for myself), don't need money, we need time. Sponsorship for rubygems is unlikely to pay for someone to go part time or full time. > I admit these sound trivially underwhelming given all that you've identified, but if this micro-step-up could add any value, I'll do it. Eric is really in control of this, being the current maintenance head, and the longest standing active committer on the project (afaik). In light of that, I would say that this is his call, or if he can't do so, then really you want to talk to RubyCentral to push this through. From thewoolleyman at gmail.com Tue Oct 19 01:06:21 2010 From: thewoolleyman at gmail.com (Chad Woolley) Date: Mon, 18 Oct 2010 22:06:21 -0700 Subject: [Rubygems-developers] Canonical Repo and Forks? Message-ID: I was considering applying this one-character and (seemingly) obvious bugfix pull request which just came in: http://github.com/rubygems/rubygems/pull/5 http://github.com/sampierson/rubygems/commit/cf35d780d26eb8d6294786badf72c7e8b5e76744 However, I'm unclear on the current state of things, especially in context of the recent thread discussing regressions. Questions: * Where is the canonical repo? The one on Github? Is the rubyforge repo dead now? Can we delete it? I've got both on CI for now [1], [2]. * If I commit to master branch on github, do I need to apply the patch to any other branches or forks? * Are there any forks which to which I might not have access (e.g. 1.9)? If so, what do I need to do in this case? Put in a ticket and/or patch to Ruby? * Against which forks/branches should I run unit tests (whether I can commit or not?) * Are the answers to these questions documented anywhere other than other committer's heads? [1] http://ci.pivotallabs.com:3333/builds/RubyGems [2] http://ci.pivotallabs.com:3333/builds/RubyGemsGitHub From jbarnette at gmail.com Tue Oct 19 11:49:33 2010 From: jbarnette at gmail.com (John Barnette) Date: Tue, 19 Oct 2010 08:49:33 -0700 Subject: [Rubygems-developers] Canonical Repo and Forks? In-Reply-To: References: Message-ID: On Oct 18, 2010, at 10:06 PM, Chad Woolley wrote: > I was considering applying this one-character and (seemingly) obvious > bugfix pull request which just came in: > > http://github.com/rubygems/rubygems/pull/5 > http://github.com/sampierson/rubygems/commit/cf35d780d26eb8d6294786badf72c7e8b5e76744 Lluis, Raggi, and I have been keeping a decently close eye on these as I come in, so I wouldn't worry about managing pull requests unless you have a real excitement about a specific one. > > However, I'm unclear on the current state of things, especially in > context of the recent thread discussing regressions. Questions: > > * Where is the canonical repo? The one on Github? Is the rubyforge > repo dead now? Can we delete it? I've got both on CI for now [1], > [2]. The RubyForge repo is dead. rubygems/rubygems on GitHub is The Real Thing. > * If I commit to master branch on github, do I need to apply the patch > to any other branches or forks? Nope, not at the moment. > * Are there any forks which to which I might not have access (e.g. > 1.9)? If so, what do I need to do in this case? Put in a ticket > and/or patch to Ruby? Not that you need to care about for applying changes. For the moment, at least, the differences between RubyGems-the-product and RubyGems-the-feature-of-1.9 are resolved near release time for each. I'd like very much to change this in the future, but we have a mountain or three to climb before then. > * Against which forks/branches should I run unit tests (whether I can > commit or not?) At the moment the most useful would be master on GitHub and head from Ruby's Subversion, I'd think. > * Are the answers to these questions documented anywhere other than > other committer's heads? Now, luckily, they're searchable in the email archive. :) > > [1] http://ci.pivotallabs.com:3333/builds/RubyGems > [2] http://ci.pivotallabs.com:3333/builds/RubyGemsGitHub > _______________________________________________ > Rubygems-developers mailing list > http://rubyforge.org/projects/rubygems > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers ~ j. From noreply at rubyforge.org Tue Oct 19 13:36:28 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 19 Oct 2010 13:36:28 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-28597 ] setup.rb with rubygems1.3.7 fails on running with ruby version 1.9.2, see traceback. Message-ID: <20101019173628.5400D19782D9@rubyforge.org> Bugs item #28597, was opened at 2010-09-23 17:57 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28597&group_id=126 Category: RubyGems installer (setup.rb) Group: v1.3.x Status: Closed Resolution: Rejected Priority: 3 Submitted By: Dinesh Arora (dinesharora) Assigned to: Nobody (None) Summary: setup.rb with rubygems1.3.7 fails on running with ruby version 1.9.2, see traceback. Initial Comment: C:\RubyGems\rubygems-1.3.7>ruby -v ruby 1.9.2p0 (2010-08-18) [i386-mingw32] C:\RubyGems\rubygems-1.3.7> C:\RubyGems\rubygems-1.3.7>ruby setup.rb C:/RubyGems/rubygems-1.3.7/lib/rubygems/source_index.rb:68:in `installed_spec_di rectories': undefined method `path' for Gem:Module (NoMethodError) from C:/RubyGems/rubygems-1.3.7/lib/rubygems/source_index.rb:58:in `from _installed_gems' from C:/RubyGems/rubygems-1.3.7/lib/rubygems.rb:883:in `source_index' from C:/RubyGems/rubygems-1.3.7/lib/rubygems/gem_path_searcher.rb:81:in `init_gemspecs' from C:/RubyGems/rubygems-1.3.7/lib/rubygems/gem_path_searcher.rb:13:in `initialize' from C:/RubyGems/rubygems-1.3.7/lib/rubygems.rb:841:in `new' from C:/RubyGems/rubygems-1.3.7/lib/rubygems.rb:841:in `block in searche r' from :10:in `synchronize' from C:/RubyGems/rubygems-1.3.7/lib/rubygems.rb:840:in `searcher' from C:/RubyGems/rubygems-1.3.7/lib/rubygems.rb:479:in `find_files' from C:/RubyGems/rubygems-1.3.7/lib/rubygems.rb:983:in `load_plugins' from C:/RubyGems/rubygems-1.3.7/lib/rubygems.rb:1139:in `' from :29:in `require' from :29:in `require' from setup.rb:24:in `
' C:\RubyGems\rubygems-1.3.7> ---------------------------------------------------------------------- Comment By: Brian Rabbit (xuinkrbin) Date: 2010-10-19 12:36 Message: Wait, then, if One is trying to build Shoes, for example, and One builds Ruby 1.9.2, as described at http://github.com/shoes/shoes/wiki/BuildingShoesOnOSX (step #11), should One skip step #12, which is to compile RubyGems? ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2010-09-23 18:20 Message: Ah, I see I would recommend you open a ticket with Ruby on Rails website maintainers to improve these pages. RubyGems is needed for 1.8.x version of Ruby. A clear omission in the step. (And that is not 100% true as RubyInstaller actually bundle it for you ;-) Regards. ---------------------------------------------------------------------- Comment By: Dinesh Arora (dinesharora) Date: 2010-09-23 18:16 Message: Thank you Luis for the quick reply. The documentation at rubyonrails.org is incorrect. It says to install ruby and then rubygems. Does not differentiate between versions 1.8.x or 1.9.x. See http://rubyonrails.org/download ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2010-09-23 18:07 Message: You should not be attempting to install RubyGems on Ruby 1.9.1 or 1.9.2 RubyGems is bundled with Ruby since 1.9.1 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28597&group_id=126 From noreply at rubyforge.org Tue Oct 19 13:40:21 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 19 Oct 2010 13:40:21 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-28597 ] setup.rb with rubygems1.3.7 fails on running with ruby version 1.9.2, see traceback. Message-ID: <20101019174021.910B019782D9@rubyforge.org> Bugs item #28597, was opened at 2010-09-23 19:57 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28597&group_id=126 Category: RubyGems installer (setup.rb) Group: v1.3.x Status: Closed Resolution: Rejected Priority: 3 Submitted By: Dinesh Arora (dinesharora) Assigned to: Nobody (None) Summary: setup.rb with rubygems1.3.7 fails on running with ruby version 1.9.2, see traceback. Initial Comment: C:\RubyGems\rubygems-1.3.7>ruby -v ruby 1.9.2p0 (2010-08-18) [i386-mingw32] C:\RubyGems\rubygems-1.3.7> C:\RubyGems\rubygems-1.3.7>ruby setup.rb C:/RubyGems/rubygems-1.3.7/lib/rubygems/source_index.rb:68:in `installed_spec_di rectories': undefined method `path' for Gem:Module (NoMethodError) from C:/RubyGems/rubygems-1.3.7/lib/rubygems/source_index.rb:58:in `from _installed_gems' from C:/RubyGems/rubygems-1.3.7/lib/rubygems.rb:883:in `source_index' from C:/RubyGems/rubygems-1.3.7/lib/rubygems/gem_path_searcher.rb:81:in `init_gemspecs' from C:/RubyGems/rubygems-1.3.7/lib/rubygems/gem_path_searcher.rb:13:in `initialize' from C:/RubyGems/rubygems-1.3.7/lib/rubygems.rb:841:in `new' from C:/RubyGems/rubygems-1.3.7/lib/rubygems.rb:841:in `block in searche r' from :10:in `synchronize' from C:/RubyGems/rubygems-1.3.7/lib/rubygems.rb:840:in `searcher' from C:/RubyGems/rubygems-1.3.7/lib/rubygems.rb:479:in `find_files' from C:/RubyGems/rubygems-1.3.7/lib/rubygems.rb:983:in `load_plugins' from C:/RubyGems/rubygems-1.3.7/lib/rubygems.rb:1139:in `' from :29:in `require' from :29:in `require' from setup.rb:24:in `
' C:\RubyGems\rubygems-1.3.7> ---------------------------------------------------------------------- >Comment By: Luis Lavena (luislavena) Date: 2010-10-19 14:40 Message: Correct, Ruby 1.9.2-p0 already have latest version available of RubyGems. ---------------------------------------------------------------------- Comment By: Brian Rabbit (xuinkrbin) Date: 2010-10-19 14:36 Message: Wait, then, if One is trying to build Shoes, for example, and One builds Ruby 1.9.2, as described at http://github.com/shoes/shoes/wiki/BuildingShoesOnOSX (step #11), should One skip step #12, which is to compile RubyGems? ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2010-09-23 20:20 Message: Ah, I see I would recommend you open a ticket with Ruby on Rails website maintainers to improve these pages. RubyGems is needed for 1.8.x version of Ruby. A clear omission in the step. (And that is not 100% true as RubyInstaller actually bundle it for you ;-) Regards. ---------------------------------------------------------------------- Comment By: Dinesh Arora (dinesharora) Date: 2010-09-23 20:16 Message: Thank you Luis for the quick reply. The documentation at rubyonrails.org is incorrect. It says to install ruby and then rubygems. Does not differentiate between versions 1.8.x or 1.9.x. See http://rubyonrails.org/download ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2010-09-23 20:07 Message: You should not be attempting to install RubyGems on Ruby 1.9.1 or 1.9.2 RubyGems is bundled with Ruby since 1.9.1 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28597&group_id=126 From noreply at rubyforge.org Thu Oct 21 14:01:57 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 21 Oct 2010 14:01:57 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-28661 ] gem pristine does not observe installer options Message-ID: <20101021180157.D0A2C1858387@rubyforge.org> Bugs item #28661, was opened at 2010-10-21 13:01 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28661&group_id=126 Category: `gem` commands (other) Group: None Status: Open Resolution: None Priority: 3 Submitted By: Charles Nutter (headius) Assigned to: Nobody (None) Summary: gem pristine does not observe installer options Initial Comment: In pristine_command.rb, there are the following lines: # TODO use installer options installer = Gem::Installer.new gem, :wrappers => true, :force => true installer.install Obviously it was intended that this code eventually propagate installer options, but it has never been done. Unfortunately rvm's gemset support uses "gem pristine --all", which on JRuby will lose the --env-shebang default we require to allow using jruby's bash-based startup script in shebang likes for installed gem executables. This led to the following bug report: http://jira.codehaus.org/browse/JRUBY-5031 After a short exploration, I could not find the proper way to propagate installer options for pristine installs, so I ended up going with the following patch. RubyGems should be fixed to propagate installer options appropriately. diff --git a/lib/ruby/site_ruby/1.8/rubygems/commands/pristine_command.rb b/lib/ruby/site_ruby/1.8/rubygems/commands/pristine_command.rb index ef11129..61897cc 100644 --- a/lib/ruby/site_ruby/1.8/rubygems/commands/pristine_command.rb +++ b/lib/ruby/site_ruby/1.8/rubygems/commands/pristine_command.rb @@ -82,7 +82,11 @@ revert the gem. end # TODO use installer options - installer = Gem::Installer.new gem, :wrappers => true, :force => true + # Modified for JRUBY-5031, to propagate --env-shebang if set + installer = Gem::Installer.new gem, + :wrappers => true, + :force => true, + :env_shebang => !Gem::ConfigFile::PLATFORM_DEFAULTS['install'].to_s['--env-shebang'].nil? installer.install say "Restored #{spec.full_name}" ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28661&group_id=126 From noreply at rubyforge.org Mon Oct 25 13:05:12 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 25 Oct 2010 13:05:12 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-25826 ] Uninstalling executables created with --format-executable Message-ID: <20101025170512.7391E185839E@rubyforge.org> Bugs item #25826, was opened at 2009-05-07 04:43 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=25826&group_id=126 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Sven Schwyn (sschwyn) Assigned to: Nobody (None) Summary: Uninstalling executables created with --format-executable Initial Comment: Here's an example: gem install --format-executable rake ==> Installs executable "rake18". ln -s rake18 rake ==> This step is performed by most Linux distros. gem uninstall rake ==> Asks whether to uninstall "rake", but not "rake18". ---------------------------------------------------------------------- Comment By: Matthew Kent (mattkent) Date: 2010-10-25 11:05 Message: We are migrating from ruby 1.8 and I'd love to see this as a config option so gem removal works as expected. ---------------------------------------------------------------------- Comment By: James Tucker (raggi) Date: 2010-07-19 07:32 Message: Indeed, this should not be used on a per command basis at all. I'm thinking about removing it to avoid these problems, and maintaining support purely by config file. ---------------------------------------------------------------------- Comment By: Sven Schwyn (svoop) Date: 2010-01-14 11:51 Message: In fact, just add --format-executable to the uninstall command and the case is closed as those using this option most likely won't use it on a "per command" basis. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=25826&group_id=126