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