On Thu, Jan 8, 2009 at 11:55 PM, Ben Bleything <ben / bleything.net> wrote:
> On Wed, Jan 7, 2009 at 5:26 PM, Daniel Berger <djberg96 / gmail.com> wrote:
>> I'm not sure how division in the community over where projects live matters
>> in any practical sense, except for Rubygems and your GEM_PATH setting. Even
>> then, Tom could make it so that you wouldn't need to change anything, as he
>> could script where the gems actually live.
>
> Those are good points.  I guess it's a matter of whether or not this
> theoretical RubyForge replacement would actually take over
> rubyforge.org or not.  If it would, then what is done with all of the
> projects on RubyForge now that can't or don't want to transition?

old.rubyforge.org  ?

:)

> I'm also not excited about having to go to four or five different
> sites to find the library that I'm looking for.  There's already
> enough problem with trying to find the "canonical" gem when you've got
> GitHub's source enabled... imagine if there was even one more gem
> source in common usage.

Yes, I agree here.

>> Oh, yeah? Who's gonna build it? And even _if_ someone undertook the project,
>> no one is going to agree on how it should look, feel and act anyway, so it
>> will _still_ result in division no matter how you slice it.
>
> Maybe... the division I'm concerned about is having a lot of sites
> crop up that are trying to do what RubyForge does.  If the idea is to
> replace RubyForge with something better, my opinion is that RubyForge
> as it is today should be shut down at the end of the process.  No
> division, just new infrastructure serving the same purpose.

But if you close support for creating new projects and make RubyForge
for archival / legacy projects only, what's the problem with that?

-greg

-- 
Technical Blaag at: http://blog.majesticseacreature.com
 Non-tech stuff at: http://metametta.blogspot.com
"Ruby Best Practices"  Book now in O'Reilly Roughcuts:
http://rubybestpractices.com