Hello,

2011/10/25 Hiroshi Nakamura <nakahiro / gmail.com>:
> Sure, I will. But please don't wait to post your comment now. I should
> be still missing some issues like 'autoload'. I'll try to summarize
> per-role advantages/disadvantages once I collected initial responses.


Who will upload stdlib gems to rubygems.org? The release manager?
Each stdlib gem developer?

When a security issue of stdlib gems is reported to the security
team (security / ruby-lang.org), how should it be handled?
If a new tarball of ruby distribution and a new gem file is both
released, the release (and announce) time lag must be minimized.

What is the version policy of stdlib gems?  Any new feature or
even incompatibility may be included in the forth digit update?
I'm concerned about a relationship with the policy of patch
release.

Is no factor that prevent us from releasing Ruby increased, even
when stdlib gem developer is too busy to work for Ruby?



Small questions to your proposal follows:


2011/10/25 Hiroshi Nakamura <nakahiro / gmail.com>:
> == Motivation
>  * When releasing we should give independence equally to all stdlibs, but in a consistent and controllable way.

I cannot understand this point.  Could you erabolate?


> == Proposal
> Note:
>
>  * Moving stdlibs repository location is not a target of this proposal. The implementation details of stdlib gems should hide this from ruby committers.

I cannot understand the context of the second sentence.
What do you mean?


> == ToDo

NaHi-san will do (or coordinate) all the Todos, right? :-)


>  * Find a way to allow autoloading stdlib gems.
>   * It's because autoload does not respect require overwriting now. When we install 'default gems' as a real gem, it needs some care to work.

I recommend you create another ticket about autoload, with a
focus on what feature you need in the ruby core.

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