(2010/09/10 23:48), James Cox wrote:
> Urabe,

Hi.

>> 1) Being able to do "gem update" on stdlibs seems to be a good thing to have.
>> I'm not against on that point now.

May I emphasize this again?  I think I'm not your enemy.

>> 2-1) Not all of ruby users use gem.  A Linux system without internet
>> connection might not be practical, but a ruby installation without one is a
>> real usage today.
>>
> 
> But, our make script can gather the gems - perhaps a call to
> rubygems.org and grab  a manifest or package of blessed libs, then put
> them into the release tarball. As Ryan and others have pointed out,
> it's then a matter of calling gem install blessed/*.gem - not an
> operation that should require the internet.

Yes, that's exactly what I need to distribute on our site.  Creating one is
fairly easy as you wrote.  I don't understand why people are against for core
team to have such things.

>> 2-2) I don't think we (core team) can handle occasional updates of such gems
>> like Debian does.  We ought to miss something.
>>
> I think the core team can do what a good core team should: delegate.
> Once there's a list of blessed gems, it's up to those maintainers to
> ensure that their code is ready to release as per the RM's
> instructions. This sort of thing could easily be built into
> rubygems.org if desired - a tool to track gems ready for packaging.

Excuse me, but (at least) I'm talking about a security issue.

As far as we distribute a lib its security issue shall be reported to us, and
will be handed in a carefully built secure channel to a reporter of it.  Open
collaboration tools such as rubygems.org are not suited for this purpose.
Delegation wouldn't help this area.  That's the headache I'm talking about;
it's not a technical hurdle but a matter of communication cost (in a
cryptographically strict way).