On Fri, Sep 10, 2010 at 12:13 PM, James Tucker <jftucker / gmail.com> wrote:
>
> 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.
>
>
> There's really no reason I can see that these things /must/ be shipped wi=
th ruby, if we really want to provide an "all in one bundle" that could jus=
t as easily be provided as a separate tarball that contains a number of pre=
fetched .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 g=
ems, 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 h=
ave them 'bundled by default', and it would further make system provisionin=
g very trivial. Less patches, more options.
>

The problem Ruby-Core is complaining about this is the separate
codebase. things like json, rubygems and rake grow in their out
timeline.

When Ruby-Core needs to patch things into Ruby bundled libraries, they
just modify the files and svn commit. Adding gemdist/*.gem will not
solve these issues.

This is of course the maintainer of the library is not the ruby
committer. If maintainer =3D=3D committer then doing a gem release and
updating the gemdist definitely could work.

--=20
Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exup=E9ry