lucene-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grant Ingersoll <>
Subject Re: Less drastic ways
Date Sun, 14 Mar 2010 16:43:45 GMT
Also, I really don't see what is so drastic about the proposal.  All we're doing is making
it easier for code to be put in the right place.  We're not having Lucene consumed by Solr
nor vice versa.  As you've seen by the Board's indication, they only view that there should
be a single Lucene project.  One committership, one project.

On Mar 14, 2010, at 12:28 PM, Otis Gospodnetic wrote:

> Hi,
> Consider this just an email to clarify things for Otis (and maybe a few other people).
> Are the following the main goals of the recent merge voting thread(s)?
> * Make it easier for Solr to ride the Lucene trunk
> * Make it easier for people to avoid committing new features to Solr when they really
belong to some lower level code - either Lucene core or some Lucene module
> Is the only or main change being proposed that lucene-dev and solr-dev mode to some common-dev
(or lucene-dev)?
> If the above is correct, here is what I don't understand:
> * Why can't Solr riding on Lucene trunk be achieved by getting Lucene trunk build into
Solr lib in svn on a daily/hourly basis?
> * Why can't existing Solr functionality that has been identified as "should really have
been committed to Lucene instead of Solr" be moved to Lucene over the coming months?
> * Why can't Solr developers be required to be subscribed to lucene-dev?
> * Why can't Solr developers be required/urged to commit any new functionality to Lucene
if solr-dev and lucene-dev people think that's where it belongs? i.e. communicate before committing
- the same as "measure twice, cut once".
> Thanks,
> Otis

View raw message