> 
> RubyGems already has code to pull from various gem repositories.  Just
> set up a second repository, and if people want to add it, they can.
> 

Starting a 1.9 gem repository is reasonable, but the problem is not the
publication and
distribution of gem packages -- it's managing the code deltas in the packages.

If we don't have a mostly-automated way to pull in
each others deltas, from some common ancestry,
we are back again with the same problem as the main gems.rubyforge.org: fragmented
source revision control, time-consuming patch application, packaging and
distribution.  The reason why gem developers aren't accepting patches fast
enough is:

1) it's difficult to release a prototype version, without inflicting harm to
those using latest-and-greatest gems by default.
2) it's time-consuming to integrate patches from 3rd parties, roll new gem
versions and publish them to a central server.

It's just as difficult to contribute/publish fixes, because the gem package is
disconnected from the revision control of its source.

Having a separate 1.9 gem repo solves #1, but it does not solve #2.  Pointing
at a new 1.9 gem repo is easy, solving #2 is hard.  Perhaps its time to have
a standardized "proposed" gem repo?

My idea is not to spend time "rolling" gems packages into a new repository,
but pulling deltas from short-lived, distributed source branches through the
common "gem install" distribution/install API.

I propose: the act of "gem install" creates a new distributed version control
repo from which other can pull deltas from into their own gem installation.
The source revision control repo *is* the gem installation, *is* the gem package.

Make the publication and distribution of gems closer to the task of managing
source code deltas in a decentralized manner.

Kurt Stephens