lucene-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mattmann, Chris A (388J)" <>
Subject Re: Less drastic ways
Date Sun, 14 Mar 2010 16:51:35 GMT
Hey Grant,

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

Along those lines, rather than just give the solr-devs karma to lucene and
vice versa with the lucene-devs, might it make sense to start discussing
giving all PMC members and all committers on sub projects (perhaps modulo
Tika and modulo Mahout since they are on the way into TLP-ville it seems)
karma to a single Lucene code base that we are now moving towards?

This might make sense since folks who've earned committer rights know what
to touch and what not to, and also it might pool together resources of
people that all are contributing towards the overall Lucene TLP.


> 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

Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA

View raw message