On Feb 13, 2007, at 8:11 PM, Coda Hale wrote:
On 2/13/07, Erik Hatcher <[EMAIL PROTECTED]> wrote:
I personally am currently -0 to -1 on releasing solrb at rubyforge.
I know its the "Ruby Way", but we're at Apache and I'd like to do
this the "Apache Way". Making releases available elsewhere is
frowned upon.
I have no objections, for the time being, to us checking in packages
(.gem/.tar/etc) under the pkg directory as "release candidates" and
allowing folks to "gem install -source ... " them. I think the
additional -source switch gives Ed heartburn, though I really want to
make sure we do this the Apache way as much as possible.
Hosting gems outside of Rubyforge means that I don't get to type 'gem
update' and have the latest version of solrb installed.
Really? If you install a gem from another source, "gem update"
doesn't work? Is this documented somewhere I can learn more about?
We have a direct line to the rubygems developers, so if we need to
get rubygems changed to work with other sources more naturally, and
even have a built-in search path for apache.org then we can do it.
So I'm at a
loss as to why "the Apache way" should mean more complicated systems
maintenance for me.
It won't, ideally. I wouldn't want it to be more complicated. If it
is (and again I plead a lot of ignorance when it comes to rubygems)
then let's fix it somehow. Having RubyForge as the only blessed open
source rubygems site smells bad to me.
I mean, I don't go to apache.org and download,
compile, and install a src tarball every time there's an update to the
HTTP server -- I type 'apt-get upgrade'.
Good point, for sure. But, let's just assume we get the
infrastructure at apache.org set up to serve gems including the
worldwide mirroring capabilities, and have rubygems look at the gem
index at apache.org... "gem install solrb" should just work then, eh?
Again, I'm open to doing this all sorts of ways, and I play devil's
advocate in discussions often to explore the other side of
arguments. I'm interested in exploring more about making apache.org
be as simple as rubyforge with rubygems. What's needed that isn't
already there?
If it were complicated to add gems to Rubyforge, I could understand,
but it's the work of a few minutes every release.
Cool enough. And if we can automate the pushing of the gems to
wherever we deploy them to from the build process then even better.
hoe does this, right?
Ok, speaking of releases... is solrb ready for a release? What's
missing?
Getting a release out before Feb. 26 would be nice for me, and
perhaps we can deploy both to apache.org as a release candidate
(either just checking it into pkg, or pushing it to a nightly build
area) and to RubyForge and experiment with "gem install" both ways
and see what the hurdles are.
Erik
