The chef-solr gem, which embeds Solr, is also one of the offenders. We wouldn't 
have a problem hosting the gem on S3 ourselves. The only issue I foresee is 
that many of our users are new to Ruby and its ecosystem, so I hope that the 
transition can be made as painless as possible for end users. 


Thanks, 

-- 
Dan DeLeo


On Thursday, January 19, 2012 at 7:57 AM, Charles Oliver Nutter wrote:

> It would also be good to allow re-pushing an existing (identical) gem
> with a new remote URL, to allow users to actively offload current
> giants rather than waiting for new releases. That could immediately
> reduce the size and bandwidth load for RG.org (http://RG.org).
> 
> For example, JRuby team could re-push all jruby-jars gems using S3
> URLs at a moment's notice.
> 
> - Charlie
> 
> On Thu, Jan 19, 2012 at 1:48 AM, Trans <transf...@gmail.com 
> (mailto:transf...@gmail.com)> wrote:
> > Allow developers to mark old versions as "unmaintained" and then delete
> > such versions after a specific period of time without download.
> > 
> > If there is a desire to keep them for posterity or perhaps for just-in-case
> > support reasons, these deleted gems could be archived to someone's
> > dedicated local machine for an extended period.
> > 
> > 
> > _______________________________________________
> > RubyGems-Developers mailing list
> > http://rubyforge.org/projects/rubygems
> > RubyGems-Developers@rubyforge.org (mailto:RubyGems-Developers@rubyforge.org)
> > http://rubyforge.org/mailman/listinfo/rubygems-developers
> 
> 
> _______________________________________________
> RubyGems-Developers mailing list
> http://rubyforge.org/projects/rubygems
> RubyGems-Developers@rubyforge.org (mailto:RubyGems-Developers@rubyforge.org)
> http://rubyforge.org/mailman/listinfo/rubygems-developers



_______________________________________________
RubyGems-Developers mailing list
http://rubyforge.org/projects/rubygems
RubyGems-Developers@rubyforge.org
http://rubyforge.org/mailman/listinfo/rubygems-developers

Reply via email to