* 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 <otis_gospodne...@yahoo.com> > To: general@lucene.apache.org > 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: general@lucene.apache.org > > 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
