On 9 Sep 2010, at 18:53, Ryan Davis wrote:
> Then we need to change Urabe's mind. I think his argument does more =
harm than good by delaying fixes in order to coordinate full releases. =
If ruby+gem installs do an automated update at the end of install, then =
there is NO reason why security fixes should be delayed for full =
releases.

It seems to me that this is a prime reason to not ship excess code with =
ruby. It adds workload all over the place and results in lots of extra =
patching and different code bases all over the place. I know Eric isn't =
unhappy about it, but I feel very uncomfortable that there is for =
example, two different released code bases for RubyGems 1.3.7 out there, =
the one that ships with 1.9.2 and the one that ships in the =
distribution. This kind of thing gets particularly messy when it's =
passed down to package authors for OS packages, and whilst we may all =
have opinions on the matter, rational thought clearly shows that it =
would be easier on everyone if there was less to even consider splitting =
up.

There's really no reason I can see that these things /must/ be shipped =
with ruby, if we really want to provide an "all in one bundle" that =
could just as easily be provided as a separate tarball that contains a =
number of prefetched .gem files and a small rule in the makefile that =
installs these if they are present in for example, gemdist/*.gem. To me =
this also seems like a KISS solution that doesn't require further =
foreign modifications to the gems, RubyGems, or Ruby by both ruby-core =
and packagers. It also means that packagers merely add or remove cached =
.gems in this directory in order to have them 'bundled by default', and =
it would further make system provisioning very trivial. Less patches, =
more options.=