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 <[email protected] > (mailto:[email protected])> 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 > > [email protected] (mailto:[email protected]) > > http://rubyforge.org/mailman/listinfo/rubygems-developers > > > _______________________________________________ > RubyGems-Developers mailing list > http://rubyforge.org/projects/rubygems > [email protected] (mailto:[email protected]) > http://rubyforge.org/mailman/listinfo/rubygems-developers _______________________________________________ RubyGems-Developers mailing list http://rubyforge.org/projects/rubygems [email protected] http://rubyforge.org/mailman/listinfo/rubygems-developers
