atom feed19 messages in org.apache.lucene.generalRe: [VOTE] Merge the development of S...
FromSent OnAttachments
Michael McCandlessMar 4, 2010 1:32 pm 
Michael McCandlessMar 4, 2010 1:34 pm 
Mark MillerMar 4, 2010 1:35 pm 
Simon WillnauerMar 4, 2010 1:40 pm 
Yonik SeeleyMar 4, 2010 1:42 pm 
Uwe SchindlerMar 4, 2010 1:45 pm 
Shalin Shekhar MangarMar 4, 2010 2:18 pm 
Andi VajdaMar 4, 2010 2:28 pm 
Robert MuirMar 4, 2010 2:42 pm 
Bill AuMar 4, 2010 3:06 pm 
Mattmann, Chris A (388J)Mar 4, 2010 3:11 pm 
Michael BuschMar 4, 2010 3:13 pm 
Chris HostetterMar 4, 2010 3:26 pm 
Koji SekiguchiMar 4, 2010 3:37 pm 
Grant IngersollMar 5, 2010 6:50 am 
Grant IngersollMar 5, 2010 11:14 am 
Ryan McKinleyMar 8, 2010 4:13 pm 
Chris HostetterMar 9, 2010 2:38 pm 
Erik HatcherMar 10, 2010 4:52 am 
Subject:Re: [VOTE] Merge the development of Solr/Lucene (take 2)
From:Grant Ingersoll (gsin@apache.org)
Date:Mar 5, 2010 6:50:14 am
List:org.apache.lucene.general

On Mar 4, 2010, at 6:26 PM, Chris Hostetter wrote:

: Subject: [VOTE] Merge the development of Solr/Lucene (take 2) : : A new vote, that slightly changes proposal from last vote (adding only : that Lucene can cut a release even if Solr doesn't):

-1

I still don't like that we're voting on a "Goal"

I don't quite understand what you mean here. As I read it, the proposal from
Michael is pretty specific on details.

I still think that we should approach something like this iteratively and incrementally -- preferably starting with some basic refactoring/merging of specific components/modules (akin to McCandless'ss original suggestion) and adjusting committers/mailinglists/build-processes however it makes sense as we go along.

I just don't see how specific components will work. Say we spin out analyzers
but Solr doesn't move up to 3.0.x immediately. What incentive is there for a
Solr committer to work on a new Analyzer in the Analyzers project as opposed to
Solr?

-Grant