Hi,

2010/9/9 Aaron Patterson <aaron / tenderlovemaking.com>:
>>  pros:
>>   1) advantage for users: they can use "gem update" if stdlib has
>>      an update.  Users can also use "gem remove".
>
> I hope this this advantage is not understated.  When stdlib has a bug,
> we have to *live with that bug* until the next release of Ruby.  To work
> around, people are forced to monkey patch stdlib.
>
> Even worse is the disadvantage to people who are stuck with a particular
> Ruby version in production.  Many people can update gems at will, but
> not Ruby versions.  Those unfortunate people have to live with the bug
> _even longer_ than Ruby's release cycle.


I can't understand your point.

When a stdlib has a fatal bug (which causes security issue), we've
released security package.  Users can rebuild and use it.
If stdlib is also distributed as a gem, users have easier way: "gem
update".  This is the advantage I mentioned.

If a user is using ruby installed via system-dependent packaging
system (such as apt or SUSE's), the user should not use "gem update",
but wait the distributor to update ruby package.

Anyway, users don't have to live with that bug, I think.


>>  cons:
>>   1) disadvantage for the core team: developping style will get
>>      complex.  The core team must care multiple entities: Ruby
>>      package and stdlib gems.
>
> I don't think this con is true.  Development of these gems could stay in
> the Ruby svn repository.  There is no reason to keep them in separate
> repositories.  Gem releases could be made from the Ruby source itself.
> Gem releases would only happen with the ruby-core member in charge of
> that stdlib gem deems appropriate.

I agree.  Almost all developers will not be affected by this change,
except release managers :-)

-- 
Yusuke Endoh <mame / tsg.ne.jp>