lucene-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grant Ingersoll <gsing...@apache.org>
Subject Re: Less drastic ways
Date Sun, 14 Mar 2010 16:40:51 GMT

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?

I just don't see that working.

> * 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?

First up is analysis, I suspect.

> * Why can't Solr developers be required to be subscribed to lucene-dev?

They should.  That's the immediate step going forward until the various infra gyrations are
undertaken.

> * 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".

Of course they will.  This is how committing works on any and all projects anyway.
Mime
View raw message