On Feb 13, 2007, at 2:15 PM, Edward Summers wrote: > On Feb 13, 2007, at 8:30 AM, Erik Hatcher wrote:
>> 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.
> That's fine...it just isn't optimal.
I spoke with Tom Copeland and Chad Fowler a bit about this topic at
the Rails Edge event a few weeks ago. Serving gems from the Apache
mirroring environment would work just fine, and once it records a
source, it doesn't need to be specified for "gem update" I don't
I don't really know much about gems myself, so I'm mainly going on
gut feel here. I'm not the final say in this matter, I'm merely
expressing my opinion. What I want is for us to discuss all the pros/
cons to how to deploy gems and plugins. RubyForge is cool, for sure,
but I would like to see us work towards Apache being a first class
open source Ruby citizen, and having Solr and solrb/Flare all version
and release together has a lot of appeal to me. > I also don't like being reduced to submitting patches all the time.
> Honestly, that's limited my degree of involvement. Perhaps that's
> the apache way too :-)
Indeed it is. The bar is certainly high for committership, but quite
open to contributors. And I've applied every patch you've submitted,
typically within less than a day. So you have had one of the
smoothest possible contributor roles ever. You're used to a lot more
control on the repository than you've currently got with Solr's
svn. That can change in good time. No hurry though - your patches
are given consideration ASAP and have to-date always been applied
Knowing what you're up to professionally, I'd tend to think you're
busy with other things and not fiddling with solrb daily, so that
might have more to do with your slowing down on it. It'd be a shame
for you to feel that submitting patches is a drag... but it is a
necessary step to have community vetting of contributions before they
get committed. Look at how well that has worked for Solr itself.
Ryan's recent refactoring of request handlers and paths iterated ad
naseum via JIRA with very solid and detailed discussions from both
committers and contributors, and the design improved thanks to those
The Apache Way, more than anything, is about community over code.
Just like the agile manifesto says, its not that the items on the
right are not important, its that we value the ones on the left more.
And on that note... > And that isn't a plea to get commit rights btw--just an
> observation. I'm not sure I really want commit rights and may
> perhaps just develop my own minimalist solr gem over at rubyforge
> since the space is already there.
What a shame to have you fork at this early stage because of "--
source" or having to submit patches.
Minimal API is here: <http://wiki.apache.org/solr/SolRuby
> Just talk
Net::HTTP... but let's work together to make solrb be the preferred
Ruby way to speak to Solr. And all the other details of code,
deployment, etc can continue to be discussion. I'm not dogmatic on
not releasing via RubyForge, or any other technical details (heh, I
committed your code after all :).