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

From: Aaron Patterson <aaron@...>
Date: 2009-10-29 16:43:09 UTC
List: ruby-core #26411
On Thu, Oct 29, 2009 at 12:50:20PM +0900, Yusuke ENDOH wrote:
> > 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.

Who would choose those gems?  Presumably not the author.  That means it
will take time for an author to request that their gem become part of
the "stable" repository, then time for the gem to become approved.

Increasing the difficulty for gem publishing will cause stagnation.  Why
would I try to get my gem in the stable repository if it takes more work?
Why send updates to the stable repository if it takes more work?

> > 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.

Who will do the work to determine stability?  Would you trust that
person?  Will that person be looking for new and better gems to add to
the stable repository?  How will authors make sure their gem updates
get added to the stable repository?  What are the criteria for
determining that a gem is "good enough" to join the stable repository.

This sounds like a lot of work that (in my opinion) no one would want to
do.

Picking wheat from chaff is the price you pay for competition among
libraries.

</2cents>

-- 
Aaron Patterson
http://tenderlovemaking.com/

In This Thread