[#25936] [Bug:1.9] [rubygems] $LOAD_PATH includes bin directory — Nobuyoshi Nakada <nobu@...>

Hi,

10 messages 2009/10/05

[#25943] Disabling tainting — Tony Arcieri <tony@...>

Would it make sense to have a flag passed to the interpreter on startup that

16 messages 2009/10/05

[#26028] [Bug #2189] Math.atanh(1) & Math.atanh(-1) should not raise an error — Marc-Andre Lafortune <redmine@...>

Bug #2189: Math.atanh(1) & Math.atanh(-1) should not raise an error

14 messages 2009/10/10

[#26222] [Bug #2250] IO::for_fd() objects' finalization dangerously closes underlying fds — Mike Pomraning <redmine@...>

Bug #2250: IO::for_fd() objects' finalization dangerously closes underlying fds

11 messages 2009/10/22

[#26244] [Bug #2258] Kernel#require inside rb_require() inside rb_protect() inside SysV context fails — Suraj Kurapati <redmine@...>

Bug #2258: Kernel#require inside rb_require() inside rb_protect() inside SysV context fails

24 messages 2009/10/22

[#26361] [Feature #2294] [PATCH] ruby_bind_stack() to embed Ruby in coroutine — Suraj Kurapati <redmine@...>

Feature #2294: [PATCH] ruby_bind_stack() to embed Ruby in coroutine

42 messages 2009/10/27

[#26371] [Bug #2295] segmentation faults — tomer doron <redmine@...>

Bug #2295: segmentation faults

16 messages 2009/10/27

[ruby-core:26400] Re: suggestion: gems.ruby-lang.org

From: Yusuke ENDOH <mame@...>
Date: 2009-10-29 00:00:30 UTC
List: ruby-core #26400
Hi,

2009/10/29 John Barnette <jbarnette@gmail.com>:
> On Wed, Oct 28, 2009 at 3:20 AM, Yusuke ENDOH <mame@tsg.ne.jp> wrote:
>> I'm surprised to hear that gems.rubyforge.org will be stood down.
>> ...
>> The default repository of rubygems should be dependable because
>> it is now a part of ruby.  It should not be changed so easily.
>
> The default repository would never be changed without a careful migration plan.
>
> Gemcutter will be the official RubyGems source. It will live at
> rubygems.org. gems.rubyforge.org will not stop working, it will be
> transparently migrated to the new source.

I don't talk about url nor hostname.  The operation policy and principle
will be changed, won't it?  As a result, both of quantitatively and
qualitatively of gems that can be installed from gems.rubyforge.org will
be also changed widely.
I think we can say that "traditional rubyforge will disapper."

This is a good chance to review the policy of rubygems.

Even so, I have no idea if gems.rubyforge.org should be removed from
default repositories of rubygems or not.


After I have sent my mail, I found this is not a new idea.  A similar
idea was discussed when rubygems was imported.  [ruby-dev:31320]
The discussion seems to include other various topics and to be quite
confused.  I will read it later.

-- 
Yusuke ENDOH <mame@tsg.ne.jp>

In This Thread