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 >
