lucene-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Otis Gospodnetic <otis_gospodne...@yahoo.com>
Subject Re: [VOTE] merge lucene/solr development (take 3)
Date Tue, 09 Mar 2010 17:38:02 GMT
* 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_gospodnetic@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


Mime
View raw message