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

On Wed, Oct 28, 2009 at 9:00 PM, Yusuke ENDOH <[e-mail]> wrote:
> Hi,
>
>> [...]
>>
>> 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. he operation policy and principle
> will be changed, won't it? s 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."

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.

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

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 (to become rubygems.org) will play the role of
gems.rubyforge.org, exactly the same, with owners of each gem and
contributor pushing new releases as that fit their release schedule.

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

GitHub has discontinued the gem building and hosting and a "subdomain"
approach will live in *.gemcutter.org, not interfering with
rubygems.org

Further down, you suggest:

"Why don't we prepare gems.ruby-lang.org as the default and official
source of rubygems?  It provides `ruby semi-standard libraries'
under the following two rules:

- only stable and well-selected gems are put there

- the gems will be tested by the core team before releasing ruby"

This will create more confusion.

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.

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?

Just my two cents.

Regards,
-- 
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駻y