lucene-ruby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Hatcher <e...@ehatchersolutions.com>
Subject Re: solrb/flare in action?
Date Wed, 14 Feb 2007 02:32:29 GMT

On Feb 13, 2007, at 8:11 PM, Coda Hale wrote:
> On 2/13/07, Erik Hatcher <erik@ehatchersolutions.com> 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


Mime
View raw message