[Rubygems-developers] is this thing on?

Chad Woolley thewoolleyman at gmail.com
Mon Oct 11 15:17:45 EDT 2010

On Mon, Oct 11, 2010 at 4:55 AM, James Tucker <jftucker at gmail.com> 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

More information about the Rubygems-developers mailing list