Ben Giddings said:
> The ones that most interest me are:
>
> == A way of differentiating "stable" and "unstable" packages ==
>
> I don't think this should be a property of the gem, but maybe a
> meta-property of some kind.  The way Debian, Gentoo and the various BSDs
> do things is an example.  Someone determines which packages are stable
> and which are not, and the user can choose to install the stable version
> or the unstable one.

Part of this can be resolved by the ability to list different Gem sources.
 This source (identified by URL) contains stable packages and that source
(a different URL) containts unstable packages.  Gems can manage different
sources today, although the interface is primitive.  The gems team is
thinking about how to make this more flexible (e.g. get gems from this
source, unless its not available, then get them from that source). This is
certainly something that the Seattle team could work on if they decided
to.

Beyond that, you need a team of people who are willing to test gems,
catogorized them, and then migrate them from unstable to stable.

> (as an aside, what is the current RubyGems method of removing a gem?)

gem uninstall GEMNAME

(http://docs.rubygems.org/read/chapter/10#page38)

-- 
-- Jim Weirich     jim / weirichhouse.org    http://onestepback.org
-----------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)