> * I think Grant may be right. We don't need this discussion. Because the > Solr/Lucene developer overlap is excellent, why not just start moving > selected Solr code to new Lucene modules, just like Mike proposed we move > Analysis from Lucene core to a new Lucene module?
The underlying hesitation could be that the initial proposal sounds like a press release. With all the discussing, a few modules could already have been moved (given the number of keys pressed to enter the emails). On Tue, Mar 9, 2010 at 9:38 AM, Otis Gospodnetic <[email protected]> wrote: > * Re poaching (aka cross-project refactoring) - I think this is the way to > go. I think this is normal evolution of OSS projects. I think this should > be done if the functionality was not committed to the best (lowest common > denominator?) project from the beginning, as in all the Solr/Lucene examples > brought up > > * I think Grant may be right. We don't need this discussion. Because the > Solr/Lucene developer overlap is excellent, why not just start moving > selected Solr code to new Lucene modules, just like Mike proposed we move > Analysis from Lucene core to a new Lucene module? > > * What do people think about doing what I wrote above as step 1 in this whole > process? When that is done in N months, we can see if we can improve on it? > This would also fit "progress, not perfection" mantra. > > Otis > > > > > ----- Original Message ---- >> From: Otis Gospodnetic <[email protected]> >> To: [email protected] >> Sent: Tue, March 9, 2010 12:23:59 PM >> Subject: Re: [VOTE] merge lucene/solr development (take 3) >> >> Hello, >> >> (just using Yonik's email to reply, but my comments are more general) >> >> >> ----- Original Message ---- >> > From: Yonik Seeley >> > To: [email protected] >> > Sent: Tue, March 9, 2010 10:04:20 AM >> > Subject: Re: [VOTE] merge lucene/solr development (take 3) >> > >> > On Tue, Mar 9, 2010 at 9:48 AM, Mattmann, Chris A (388J) >> > wrote: >> > > I have built 10s of projects that >> > > have simply used Lucene as an API and had no need for Solr, and I've >> > > built >> > > 10s of projects where Solr made perfect sense. So, I appreciate their >> > > separation. >> > >> > As does everyone - which is why there will always be separate >> > downloads. As a user, the only side affect you should see is an >> > improved Lucene and Solr. >> > >> > Saying that Solr should move some stuff to Lucene for Lucene's >> > benefit, without regard to if it's actually benefitial to Solr, is a >> > non-starter. The lucene/solr committers have been down that road >> > before. The solution that most committers agreed would improve the >> > development of both projects is to merge development. >> >> * I'd completely understand the "non-starter" part if Lucene and Solr had >> disjoint sets of committers. But that's not the case. >> >> * Which is why I (like a few others) don't see why this whole thing cannot be >> solved by "better discussion of what to develop where from the get-go" >> >> * Whenever people listed features built in Solr that really should have been >> in >> Lucene, I wondered "so why were not they developed in Lucene in the first >> place?" Again, this should be possible because the same person can commit to >> both projects. >> >> * I hear Grant's explanation on wanting something in Solr ASAP and not >> wanting >> to commit that something to Lucene (even though it logically belongs there) >> because Solr is not on Lucene trunk, but isn't this just a matter of getting >> "Lucene trunk nightly -> Solr trunk lib in svn" process going? >> >> * Ian is 100% right. This stuff clearly requires more discussion and a >> proper >> VOTE should wait a week or so. >> >> Otis > >
