lucene-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Miller <>
Subject Re: [VOTE] merge lucene/solr development (take 3)
Date Tue, 09 Mar 2010 05:37:50 GMT
Just to clarify - reading back, I see Mike put some examples of what 
could be pulled into Lucene core - I personally don't see that as a 
binding part of the vote - they are what we hope to do and are examples 
of things that are not controversial. I think quite obviously, anything 
after the merge would be taken as we normally take it - we would make 
issues, someone would have to actually do the work, etc. Mike listed 
some things that make sense to go into Lucene, and I doubt anyone is 
going to argue, but it would be weird to say the result of this Vote 
demands we move all queries from Solr into Lucene. It will just allow us 
to do so and it would make sense to do so.

Mike took that from an earlier email proposing the merge - its not 
really a "road plan" that we are voting for in terms of what goes where 
- we are voting for the merge of development. What goes where should be 
determined like we normally do that stuff.

- Mark

On 03/09/2010 12:26 AM, Mark Miller wrote:
> On 03/09/2010 12:14 AM, Michael Busch wrote:
>> On 3/8/10 8:24 PM, Grant Ingersoll wrote:
>>> I don't think any of it's a showstopper,
>> I'm surprised here after reading the Apache voting page. This 
>> proposal contains points that involve code restructurings.
> The veto is reserved for "code modifications" not reorganizations of 
> development. And the veto requires a valid technical reason against a 
> specific code change.
> Also, we have decided on no code restructurings - the hope is to allow 
> them (and in the past you have championed some of the ones we hope to 
> see), but there are no restructurings that are part of the vote. The 
> change says nothing about what will happen regarding the code - the 
> community would decide that as we go. If you have to pick one of the 3 
> buckets, this is procedural.
> -- 
> - Mark

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message