On Jun 23, 2006, at 22:28, Eric Hodel wrote:

> On Jun 23, 2006, at 8:45 AM, David Pollak wrote:
>
>> I know it's also a large time suck to build a developer's project  
>> management
>> and code management web site... but imagine building the next  
>> generation (oh
>> no, buzzwords) Web 2.0 developer site in Ruby.  It would be a  
>> great way to
>> demonstrate that Ruby can be used to build very complex projects  
>> that scale
>> well (37 Signals is an excellent example, but more is better.)   
>> Imagine a
>> 'show source' link on each page that would show someone how the  
>> page was
>> created so that they see the beauty of R & R code.  Think of the  
>> benefit of
>> a Ruby-based development and project management tool that can be  
>> used in
>> businesses rather than bugzilla, etc.
>>
>> Please let me know your thoughts.  Am I taking drugs or would this  
>> be the
>> kind of project we could build in order to build excitement?
>
> Lots of people use GForge and submit patches to GForge and make it  
> better.  Writing an RForge would reduce the amount of developers  
> submitting patches, so Tom would have to fix bugs all by himself,  
> or hope somebody fixed them for him.
>
> I don't want to speak for Tom, but he's got enough on his plate  
> that he shouldn't need to be maintaining an in-development RForge.
>
> In other words, a GForge clone will be a very hard project to  
> build, you have to integrate mailman, cvs, svn, a bug tracker, file  
> uploads, ...

My suggestion would be something to complement RubyForge rather than  
something to replace it.  In addition to the the other arguments, I'd  
add the fact that while it *sounds* great to have websites about  
language X implemented in language X, it's beginning to remind me of  
the golden oldie "has it been used for anything apart from its own  
compiler yet?"  The fact that a language can be used to write a  
website just doesn't seem that surprising anymore, and it's extra  
boring when the site is just a port-rewrite of an existing service in  
another language.

So, rather than re-implementing all the stuff that Eric mentions,  
what else could we add?  Something I'd dearly like to see for the  
Ruby world is an indication of which libraries modify core classes,  
preferably with an indication of whether any two might be  
incompatible w.r.t. their modifications.

The inverse is probably true as well - an indication in the core  
classes of which libraries extend them could be very helpful when  
you're looking for a library that performs a specific task.

Even as part of a general replacement for RubyForge, attention to  
Ruby-specific features such as those would make the project a lot  
more interesting than if it were to simply be a reimplementation.

matthew smillie.