[#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:26405] Re: suggestion: gems.ruby-lang.org

From: Yusuke ENDOH <mame@...>
Date: 2009-10-29 03:50:20 UTC
List: ruby-core #26405
Hi,

2009/10/29 Luis Lavena <luislavena@gmail.com>:
> Right now the only difference between gemcutter and RubyForge is that
> RubyForge requires approval of the project, but anyone can publish a
> gem, any type of gem.

I know, so I said:

> Though this distinction was not strict because it may have been
> made by accident, it was actually useful (for me, at least).

I wonder if only I felt and liked this difference?


> Quoting your original email:
>
> "GemCutter will play a role in development gem repository.  So
> stable gem repository is needed."
>
> That is not true. Gemcutter do not plan to replace the chaotic
> workflow gems.github.com introduced.

Gemcutter does NOT?  If Gemcutter DOES, it's a good news.  But,

> Gem publishing and workflow for existing project will still be in the
> hands of the original team.

I'm calling the situation `development gem' repository.
I could say that more strict and stable repository than traditional
rubyforge is wanted.


> Right now Ruby embeds Rake and RubyGems, and that means when those
> packages get a "blessing" they get updated in Ruby itself.
>
> Thinking on a "blessed" repository will mean more stagnated versions
> of gems that users will not updated because rubygems.org will not be
> in that list and because RubyForge lacks the ability to install gems
> from across repositories.

Sorry I can't get your point.
Do you worry that development of gem in "blessed" repository will
become inactive?  I said that only already-stable gems are put in
the repository.


> This situation can be also extended to projects that work on platforms
> not fully blessed or supported by Ruby (ehem, Windows) and will make
> things more difficult for new comers (so many repositories to choose!)
>
> Now that GitHub as gem hosting is fading away, we have the opportunity
> to syndicate and consolidate one true gem repository source, should we
> segmented it again?

I think so.  You said "so many repositories to choose!", but just two
repositories.  The stable, official and default repository, and actively
developped one.  I hate to choose so many wheat and chaff gems from one
gem repository, like CPAN.

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

In This Thread