Issue #2033 has been updated by Run Paint Run Run.


It would be a real shame if after all this discussion and enthusiasm we just maintained the status quo.

A possible compromise is to incrementally move to Git by splitting the stdlib into one Git repository per library. They could either be periodically merged back into SVN or, ideally, distributed as gems. This would:

* Begin the process of opening up Ruby development by bringing these libraries to the community.
* Encourage new maintainers by establishing a sense of ownership for libraries. This responsibility could be predicated on the creation of a full test suite and documentation.  
* Drastically reduce the workload of the core maintainers by freeing them from many bug reports and maintenance headaches.
* Significantly lower the barrier to entry for would-be contributors. 
* Reduce the number of people who need SVN access, thus benefiting security.
* Enable the core developers to retain current working practices.
* Free up resources to focus on how the stdlib should change for Ruby 2.
* Leave Ruby leaner.

This wouldn't need to be an all-or-nothing move. Libraries with active maintainers could remain in SVN at their discretion. Nor would it wrest anybody of control. Core developers would have commit access to each component and full control over what gets merged/bundled before a release. They would also exercise control over significant changes to the libraries, should they wish.

This thread shows that their is significant interest in making Ruby's development distributed and open. The Unmaintained Code thread shows that there are volunteer maintainers for want of asking, and that was without any publicity outside of ruby-core. RubyGems, Rake, and MiniTest show the utility of this approach. 

There's passion here. Feed it.
----------------------------------------
http://redmine.ruby-lang.org/issues/show/2033

----------------------------------------
http://redmine.ruby-lang.org