On Oct 24, 2011, at 8:49 PM, Yusuke Endoh wrote:
> Hello,
>=20
> Could you summarize advantages (if any) and disadvantages
> (or additional work) from POV of each person?

I will describe my thoughts=20

>  - user

Users can obtain improvements to parts of ruby without waiting for a new =
release.

No need to `gem 'rdoc'`, `gem 'psych'`, etc. to use the latest installed =
version of a gem.

With the current implementation default gems are special.  This proposal =
will make them stop being special.

>  - default gem developer

Default gem developers won't have to educate users to do something =
special to use the latest version of the library.

Default gem developers may need to support multiple versions of ruby in =
their gem or backport one fix to multiple releases (like backport =
requests to Ruby 1.9.3 and Ruby 1.9.2).

Default gem developers can release improvements between ruby release =
cycles.

>  - rubygems developer

We may need to implement better RubyGems platform support, but the idea =
is applicable beyond just improving stdlib gems.

>  - rubygems.org admin

The rubygems.org admin should not need to do anything special.

>  - ruby committer       <=3D I'm personally concerned about these

This proposal leaves the organization of the standard library the same.

There will be changes in tool/ to support turning parts of stdlib into =
gems when `make install` is run, but most committers will not need to =
care.

>  - ruby release manager <=3D

The release manager will need to upload gems to rubygems.org when =
releases are made.  This process can be fully automated.

>  - ruby security team   <=3D

I don't think I'm qualified to answer this one.=