From: Charles Oliver Nutter <headius@...>
Date: 2011-01-19T15:29:05+09:00
Subject: [ruby-core:34590] Re: Importing rubygems 1.5.0 (release candidate) into trunk.

On Tue, Jan 18, 2011 at 11:22 PM, NARUSE, Yui <naruse@airemix.jp> wrote:
> But on our side, who live with ruby-trunk, we don't want to live with
> broken library.
> It makes our life worse.
> Moreover we run chkbuild, autotest for CRuby, so we want to keep the
> result enough clean.
> We need workaround.
>
> Yeah, new feature for rubygems should make it into rubygems repo first.
> But workaround bug ��fixes are not acceptable.
> # Of course you can merge workaround as better fixed one with test.
>
> If you can think rubygems in CRuby's repo as a stable branch,
> you and we can make acceptable policy.

Perhas JRuby's approach would work well here? JRuby maintains a forked
RubyGems with our (minor) changes, based directly on the original
RubyGems git repository. Merging in upstream changes is easy. Managing
our set of patches is easy.

We do this for stdlib as well, and we've managed to keep our patchset
applied to the latest stdlib for both 1.8.7 and 1.9.2.

As a result, JRuby 1.6 ships with current 1.8.7 stdlib, current 1.9.2
stdlib, and current RubyGems for *both* modes.

Imagine JRuby's situation, where we are not authorized to directly fix
either stdlib *or* RubyGems. We've managed to find a system that
works. You only have to worry about RubyGems (and perhaps Rake, though
I think that's largely stable now). If we can do it for all of stdlib
and RubyGems combined, surely ruby-core can do it for RubyGems alone?
:)

FWIW, I'd love to see stdlib moved to a separate repository we all
pull from and contribute to, since it has become a common resources
for all implementations. At least we on JRuby are trying to stay in
sync and share our changes, but it would be easier if we could work
directly with ruby-core on stdlib.

- Charlie