A new vote, that slightly changes proposal from last vote (adding only
that Lucene can cut a release even if Solr doesn't):

 * Merging the dev lists into a single list.

 * Merging committers.

 * When any change is committed (to a module that "belongs to" Solr or
   to Lucene), all tests must pass.

 * Release details will be decided by dev community, but, Lucene may
   release without Solr.

 * Modulariize the sources: pull things out of Lucene's core (break
   out query parser, move all core queries & analyzers under their
   contrib counterparts), pull things out of Solr's core (analyzers,
   queries).

These things would not change:

 * Besides modularizing (above), the source code would remain factored
   into separate dirs/modules the way it is now.

 * Issue tracking remains separate (SOLR-XXX and LUCENE-XXX
   issues).

 * User's lists remain separate.

 * Web sites remain separate.

 * Release artifacts/jars remain separate.

Mike

I forgot my vote: +1

Mike

On Thu, Mar 4, 2010 at 4:33 PM, Michael McCandless
<[EMAIL PROTECTED]> wrote:
> A new vote, that slightly changes proposal from last vote (adding only
> that Lucene can cut a release even if Solr doesn't):
>
>  * Merging the dev lists into a single list.
>
>  * Merging committers.
>
>  * When any change is committed (to a module that "belongs to" Solr or
>   to Lucene), all tests must pass.
>
>  * Release details will be decided by dev community, but, Lucene may
>   release without Solr.
>
>  * Modulariize the sources: pull things out of Lucene's core (break
>   out query parser, move all core queries & analyzers under their
>   contrib counterparts), pull things out of Solr's core (analyzers,
>   queries).
>
> These things would not change:
>
>  * Besides modularizing (above), the source code would remain factored
>   into separate dirs/modules the way it is now.
>
>  * Issue tracking remains separate (SOLR-XXX and LUCENE-XXX
>   issues).
>
>  * User's lists remain separate.
>
>  * Web sites remain separate.
>
>  * Release artifacts/jars remain separate.
>
> Mike
>

+1

On 03/04/2010 04:34 PM, Michael McCandless wrote:
> I forgot my vote: +1
>
> Mike
>
> On Thu, Mar 4, 2010 at 4:33 PM, Michael McCandless
> <[EMAIL PROTECTED]>  wrote:
>    
>> A new vote, that slightly changes proposal from last vote (adding only
>> that Lucene can cut a release even if Solr doesn't):
>>
>>   * Merging the dev lists into a single list.
>>
>>   * Merging committers.
>>
>>   * When any change is committed (to a module that "belongs to" Solr or
>>    to Lucene), all tests must pass.
>>
>>   * Release details will be decided by dev community, but, Lucene may
>>    release without Solr.
>>
>>   * Modulariize the sources: pull things out of Lucene's core (break
>>    out query parser, move all core queries&  analyzers under their
>>    contrib counterparts), pull things out of Solr's core (analyzers,
>>    queries).
>>
>> These things would not change:
>>
>>   * Besides modularizing (above), the source code would remain factored
>>    into separate dirs/modules the way it is now.
>>
>>   * Issue tracking remains separate (SOLR-XXX and LUCENE-XXX
>>    issues).
>>
>>   * User's lists remain separate.
>>
>>   * Web sites remain separate.
>>
>>   * Release artifacts/jars remain separate.
>>
>> Mike
>>
>>      
--
- Mark

http://www.lucidimagination.com

+1

On Thu, Mar 4, 2010 at 10:35 PM, Mark Miller <[EMAIL PROTECTED]> wrote:
> +1
>
> On 03/04/2010 04:34 PM, Michael McCandless wrote:
>>
>> I forgot my vote: +1
>>
>> Mike
>>
>> On Thu, Mar 4, 2010 at 4:33 PM, Michael McCandless
>> <[EMAIL PROTECTED]>  wrote:
>>
>>>
>>> A new vote, that slightly changes proposal from last vote (adding only
>>> that Lucene can cut a release even if Solr doesn't):
>>>
>>>  * Merging the dev lists into a single list.
>>>
>>>  * Merging committers.
>>>
>>>  * When any change is committed (to a module that "belongs to" Solr or
>>>   to Lucene), all tests must pass.
>>>
>>>  * Release details will be decided by dev community, but, Lucene may
>>>   release without Solr.
>>>
>>>  * Modulariize the sources: pull things out of Lucene's core (break
>>>   out query parser, move all core queries&  analyzers under their
>>>   contrib counterparts), pull things out of Solr's core (analyzers,
>>>   queries).
>>>
>>> These things would not change:
>>>
>>>  * Besides modularizing (above), the source code would remain factored
>>>   into separate dirs/modules the way it is now.
>>>
>>>  * Issue tracking remains separate (SOLR-XXX and LUCENE-XXX
>>>   issues).
>>>
>>>  * User's lists remain separate.
>>>
>>>  * Web sites remain separate.
>>>
>>>  * Release artifacts/jars remain separate.
>>>
>>> Mike
>>>
>>>
>
>
> --
> - Mark
>
> http://www.lucidimagination.com
>
>
>
>

+1

-Yonik

On Thu, Mar 4, 2010 at 4:33 PM, Michael McCandless
<[EMAIL PROTECTED]> wrote:
> A new vote, that slightly changes proposal from last vote (adding only
> that Lucene can cut a release even if Solr doesn't):
>
>  * Merging the dev lists into a single list.
>
>  * Merging committers.
>
>  * When any change is committed (to a module that "belongs to" Solr or
>   to Lucene), all tests must pass.
>
>  * Release details will be decided by dev community, but, Lucene may
>   release without Solr.
>
>  * Modulariize the sources: pull things out of Lucene's core (break
>   out query parser, move all core queries & analyzers under their
>   contrib counterparts), pull things out of Solr's core (analyzers,
>   queries).
>
> These things would not change:
>
>  * Besides modularizing (above), the source code would remain factored
>   into separate dirs/modules the way it is now.
>
>  * Issue tracking remains separate (SOLR-XXX and LUCENE-XXX
>   issues).
>
>  * User's lists remain separate.
>
>  * Web sites remain separate.
>
>  * Release artifacts/jars remain separate.
>
> Mike
>

I am fine with that. +1

-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: [EMAIL PROTECTED]

> -----Original Message-----
> From: Michael McCandless [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, March 04, 2010 10:33 PM
> To: [EMAIL PROTECTED]
> Subject: [VOTE] Merge the development of Solr/Lucene (take 2)
>
> A new vote, that slightly changes proposal from last vote (adding only
> that Lucene can cut a release even if Solr doesn't):
>
>  * Merging the dev lists into a single list.
>
>  * Merging committers.
>
>  * When any change is committed (to a module that "belongs to" Solr or
>    to Lucene), all tests must pass.
>
>  * Release details will be decided by dev community, but, Lucene may
>    release without Solr.
>
>  * Modulariize the sources: pull things out of Lucene's core (break
>    out query parser, move all core queries & analyzers under their
>    contrib counterparts), pull things out of Solr's core (analyzers,
>    queries).
>
> These things would not change:
>
>  * Besides modularizing (above), the source code would remain factored
>    into separate dirs/modules the way it is now.
>
>  * Issue tracking remains separate (SOLR-XXX and LUCENE-XXX
>    issues).
>
>  * User's lists remain separate.
>
>  * Web sites remain separate.
>
>  * Release artifacts/jars remain separate.
>
> Mike

On Fri, Mar 5, 2010 at 3:03 AM, Michael McCandless <
[EMAIL PROTECTED]> wrote:

> A new vote, that slightly changes proposal from last vote (adding only
> that Lucene can cut a release even if Solr doesn't):
>
>  * Merging the dev lists into a single list.
>
>  * Merging committers.
>
>  * When any change is committed (to a module that "belongs to" Solr or
>   to Lucene), all tests must pass.
>
>  * Release details will be decided by dev community, but, Lucene may
>   release without Solr.
>
>  * Modulariize the sources: pull things out of Lucene's core (break
>   out query parser, move all core queries & analyzers under their
>   contrib counterparts), pull things out of Solr's core (analyzers,
>   queries).
>
> These things would not change:
>
>  * Besides modularizing (above), the source code would remain factored
>   into separate dirs/modules the way it is now.
>
>  * Issue tracking remains separate (SOLR-XXX and LUCENE-XXX
>   issues).
>
>  * User's lists remain separate.
>
>  * Web sites remain separate.
>
>  * Release artifacts/jars remain separate.
>

+1

--
Regards,
Shalin Shekhar Mangar.

+1

Andi..

On Thu, 4 Mar 2010, Michael McCandless wrote:

> A new vote, that slightly changes proposal from last vote (adding only
> that Lucene can cut a release even if Solr doesn't):
>
> * Merging the dev lists into a single list.
>
> * Merging committers.
>
> * When any change is committed (to a module that "belongs to" Solr or
>   to Lucene), all tests must pass.
>
> * Release details will be decided by dev community, but, Lucene may
>   release without Solr.
>
> * Modulariize the sources: pull things out of Lucene's core (break
>   out query parser, move all core queries & analyzers under their
>   contrib counterparts), pull things out of Solr's core (analyzers,
>   queries).
>
> These things would not change:
>
> * Besides modularizing (above), the source code would remain factored
>   into separate dirs/modules the way it is now.
>
> * Issue tracking remains separate (SOLR-XXX and LUCENE-XXX
>   issues).
>
> * User's lists remain separate.
>
> * Web sites remain separate.
>
> * Release artifacts/jars remain separate.
>
> Mike
>

+1

On Thu, Mar 4, 2010 at 5:29 PM, Andi Vajda <[EMAIL PROTECTED]> wrote:
>
> +1
>
> Andi..
>
> On Thu, 4 Mar 2010, Michael McCandless wrote:
>
>> A new vote, that slightly changes proposal from last vote (adding only
>> that Lucene can cut a release even if Solr doesn't):
>>
>> * Merging the dev lists into a single list.
>>
>> * Merging committers.
>>
>> * When any change is committed (to a module that "belongs to" Solr or
>>  to Lucene), all tests must pass.
>>
>> * Release details will be decided by dev community, but, Lucene may
>>  release without Solr.
>>
>> * Modulariize the sources: pull things out of Lucene's core (break
>>  out query parser, move all core queries & analyzers under their
>>  contrib counterparts), pull things out of Solr's core (analyzers,
>>  queries).
>>
>> These things would not change:
>>
>> * Besides modularizing (above), the source code would remain factored
>>  into separate dirs/modules the way it is now.
>>
>> * Issue tracking remains separate (SOLR-XXX and LUCENE-XXX
>>  issues).
>>
>> * User's lists remain separate.
>>
>> * Web sites remain separate.
>>
>> * Release artifacts/jars remain separate.
>>
>> Mike
>>
>

--
Robert Muir
[EMAIL PROTECTED]

+1

Bill

On Thu, Mar 4, 2010 at 4:33 PM, Michael McCandless <
[EMAIL PROTECTED]> wrote:

> A new vote, that slightly changes proposal from last vote (adding only
> that Lucene can cut a release even if Solr doesn't):
>
>  * Merging the dev lists into a single list.
>
>  * Merging committers.
>
>  * When any change is committed (to a module that "belongs to" Solr or
>   to Lucene), all tests must pass.
>
>  * Release details will be decided by dev community, but, Lucene may
>   release without Solr.
>
>  * Modulariize the sources: pull things out of Lucene's core (break
>   out query parser, move all core queries & analyzers under their
>   contrib counterparts), pull things out of Solr's core (analyzers,
>   queries).
>
> These things would not change:
>
>  * Besides modularizing (above), the source code would remain factored
>   into separate dirs/modules the way it is now.
>
>  * Issue tracking remains separate (SOLR-XXX and LUCENE-XXX
>   issues).
>
>  * User's lists remain separate.
>
>  * Web sites remain separate.
>
>  * Release artifacts/jars remain separate.
>
> Mike
>

Hi All,

-1 for the same reasons I mentioned previously. Again, I'm wearing my I'm-interested-in-this-discussion-but-not-a-Lucene/Solr-committer hat.

Cheers,
Chris

On 3/4/10 1:33 PM, "Michael McCandless" <[EMAIL PROTECTED]> wrote:

A new vote, that slightly changes proposal from last vote (adding only
that Lucene can cut a release even if Solr doesn't):

 * Merging the dev lists into a single list.

 * Merging committers.

 * When any change is committed (to a module that "belongs to" Solr or
   to Lucene), all tests must pass.

 * Release details will be decided by dev community, but, Lucene may
   release without Solr.

 * Modulariize the sources: pull things out of Lucene's core (break
   out query parser, move all core queries & analyzers under their
   contrib counterparts), pull things out of Solr's core (analyzers,
   queries).

These things would not change:

 * Besides modularizing (above), the source code would remain factored
   into separate dirs/modules the way it is now.

 * Issue tracking remains separate (SOLR-XXX and LUCENE-XXX
   issues).

 * User's lists remain separate.

 * Web sites remain separate.

 * Release artifacts/jars remain separate.

Mike

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: [EMAIL PROTECTED]
WWW:   http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

+1. This compromise is what I was hoping for.

  Michael

On 3/4/10 1:33 PM, Michael McCandless wrote:
> A new vote, that slightly changes proposal from last vote (adding only
> that Lucene can cut a release even if Solr doesn't):
>
>   * Merging the dev lists into a single list.
>
>   * Merging committers.
>
>   * When any change is committed (to a module that "belongs to" Solr or
>     to Lucene), all tests must pass.
>
>   * Release details will be decided by dev community, but, Lucene may
>     release without Solr.
>
>   * Modulariize the sources: pull things out of Lucene's core (break
>     out query parser, move all core queries&  analyzers under their
>     contrib counterparts), pull things out of Solr's core (analyzers,
>     queries).
>
> These things would not change:
>
>   * Besides modularizing (above), the source code would remain factored
>     into separate dirs/modules the way it is now.
>
>   * Issue tracking remains separate (SOLR-XXX and LUCENE-XXX
>     issues).
>
>   * User's lists remain separate.
>
>   * Web sites remain separate.
>
>   * Release artifacts/jars remain separate.
>
> Mike
>
>

: Subject: [VOTE] Merge the development of Solr/Lucene (take 2)
:
: A new vote, that slightly changes proposal from last vote (adding only
: that Lucene can cut a release even if Solr doesn't):

-1

I still don't like that we're voting on a "Goal"

I still think that we should approach something like this iteratively and
incrementally -- preferably starting with some basic refactoring/merging
of specific components/modules (akin to McCandless'ss original suggestion)
and adjusting committers/mailinglists/build-processes however it makes
sense as we go along.
-Hoss

Michael McCandless wrote:
> A new vote, that slightly changes proposal from last vote (adding only
> that Lucene can cut a release even if Solr doesn't):
>
>  * Merging the dev lists into a single list.
>
>  * Merging committers.
>
>  * When any change is committed (to a module that "belongs to" Solr or
>    to Lucene), all tests must pass.
>
>  * Release details will be decided by dev community, but, Lucene may
>    release without Solr.
>
>  * Modulariize the sources: pull things out of Lucene's core (break
>    out query parser, move all core queries & analyzers under their
>    contrib counterparts), pull things out of Solr's core (analyzers,
>    queries).
>
> These things would not change:
>
>  * Besides modularizing (above), the source code would remain factored
>    into separate dirs/modules the way it is now.
>
>  * Issue tracking remains separate (SOLR-XXX and LUCENE-XXX
>    issues).
>
>  * User's lists remain separate.
>
>  * Web sites remain separate.
>
>  * Release artifacts/jars remain separate.
>
> Mike
>
>  
+1

Koji

--
http://www.rondhuit.com/en/

On Mar 4, 2010, at 6:26 PM, Chris Hostetter wrote:

>
> : Subject: [VOTE] Merge the development of Solr/Lucene (take 2)
> :
> : A new vote, that slightly changes proposal from last vote (adding only
> : that Lucene can cut a release even if Solr doesn't):
>
> -1
>
> I still don't like that we're voting on a "Goal"

I don't quite understand what you mean here.  As I read it, the proposal from Michael is pretty specific on details.

>
> I still think that we should approach something like this iteratively and
> incrementally -- preferably starting with some basic refactoring/merging
> of specific components/modules (akin to McCandless'ss original suggestion)
> and adjusting committers/mailinglists/build-processes however it makes
> sense as we go along.

I just don't see how specific components will work.  Say we spin out analyzers but Solr doesn't move up to 3.0.x immediately.  What incentive is there for a Solr committer to work on a new Analyzer in the Analyzers project as opposed to Solr?
-Grant

On Mar 4, 2010, at 6:26 PM, Chris Hostetter wrote:

>
> : Subject: [VOTE] Merge the development of Solr/Lucene (take 2)
> :
> : A new vote, that slightly changes proposal from last vote (adding only
> : that Lucene can cut a release even if Solr doesn't):
>
> -1
>
> I still don't like that we're voting on a "Goal"

I would add that we vote on "goals" all the time.  We vote to incubate projects with the goal of bringing them into Lucene and them becoming successful (that doesn't always work).  We vote on adding committers/PMC members with the goal of them contributing to our project (there have been a fair number of cases where we make someone a committer/PMC member and they hardly do anything after being elected.)  We vote on artifacts w/ the "goal" that the community will find them useable.  ;-)

Somewhat tongue in cheek, I know, but I don't see how we can take on incremental changes if they are fundamentally dead in the water b/c no one agrees on the end "goal".  I'd be hard pressed to volunteer to work on such a thing if it didn't have some chance of being accepted.

-Grant

Wow...  i've been offline for a while (new baby, yaaaay!) and am now
skimming through the various lists...
On Thu, Mar 4, 2010 at 4:33 PM, Michael McCandless
<[EMAIL PROTECTED]> wrote:
> A new vote, that slightly changes proposal from last vote (adding only
> that Lucene can cut a release even if Solr doesn't):
>
>  * Merging the dev lists into a single list.
>
>  * Merging committers.
>
>  * When any change is committed (to a module that "belongs to" Solr or
>   to Lucene), all tests must pass.
>
>  * Release details will be decided by dev community, but, Lucene may
>   release without Solr.
>
>  * Modulariize the sources: pull things out of Lucene's core (break
>   out query parser, move all core queries & analyzers under their
>   contrib counterparts), pull things out of Solr's core (analyzers,
>   queries).
>

+1

this would be a big advantage to solr, and I don't see any real
downside to lucene-only folks.
> These things would not change:
>
>  * Besides modularizing (above), the source code would remain factored
>   into separate dirs/modules the way it is now.
>
>  * Issue tracking remains separate (SOLR-XXX and LUCENE-XXX
>   issues).
>
>  * User's lists remain separate.
>
>  * Web sites remain separate.
>
>  * Release artifacts/jars remain separate.
>
> Mike
>

: > I still don't like that we're voting on a "Goal"
:
: I don't quite understand what you mean here.  As I read it, the proposal
: from Michael is pretty specific on details.

We are not voting on commiting a specific patch, or releasing a particular
bundle of source code, or on select a logo from a finite set of entries,
or on giving a person commit karma -- we are voting largely on the 'idea'
that development should be merged.

Only two aspects of "the proposal" are concrete and actionable: merging
the dev lists, and merging the commiter lists -- those are the only two
bullet points that can be voted on and pass with a clear and obvious
immediate ction an effect.  To anyone with knowledge of knowledge of the
ASF, those bullet points are almost completley unambiguoius.

The rest of the proposal is vague and subject to interpretation -- at best
it articulates "things that we would like to see happen" without any
indication of how these things should/will happen.

Casting a vote in favor of "When any change is committed (to a module that
"belongs to" Solr or to Lucene), all tests must pass." is meaningless.  
If Solr didn't exist, We could just as easily vote that "All
Lucene-Java tests should pass whenever a commit is made to Lucene-Java."
-- so fucking what? ... It sure seems like a good idea, but what does it
mean to vote on it?  Doees it mean that you lose your commit privliges if you
commit code that causes a test to fail?

Even if we all agree 100% with the "goal" that nothing should be committed
to either Lucene-Java or Solr that would break a test in either code base,
so what? ... how to we enforce that?  What types of (concrete and
actionable) approaches do people suggest to making sure that changes in
one code base don't break tests in another code base?

Let's hear proposals for how to *implement* that goal, and then lets vote
one those.

Likewise for "Modulariize the sources ...."  Modularization is a hot
buzzword, so i'm all in favor of this idea, i'll totally vote for that.  

Now what?

The next step is probably to have a discussions about what exactly we want
to modularize out first, and how we want to do it, and where it shoudl
live in svn, and how it should fit into the build system, and which way
the dependencies should go, and what API changes might be needed to make
this work in a generic way, and why the fuck can't we just have this
conversation independent of a big as "let's vote on something" thread?

The shear number of "wait, i thought this part of the proposal ment
that ..." comments in the "take3"
thread should be evidence enough of my point about ths VOTE being
too "goal" orriented when we should be talking about what identifiable,
incremental steps we can take towards solving the problems we see.

: > incrementally -- preferably starting with some basic refactoring/merging
: > of specific components/modules (akin to McCandless'ss original suggestion)
: > and adjusting committers/mailinglists/build-processes however it makes
: > sense as we go along.
:
: I just don't see how specific components will work.  Say we spin out
: analyzers but Solr doesn't move up to 3.0.x immediately.  What incentive
: is there for a Solr committer to work on a new Analyzer in the Analyzers
: project as opposed to Solr?

I have no idea ... what incentive does a Solr commiter have to work on
anything in the Lucene-jaava code base once this VOTE passes?  What
incentive does any committer have to do anything?

We seem to have me confused with someone who has said "I percieve a
problem, here is a goal i think we should set out for it, let's vote on
that" w/o hasing out the steps i think we need to reach that goal.

I'm not suggesting a goal, I'm not even suggesting any particular actions.  
I'm suggesting that if there are people who percieve problem (and there
seem to be plenty of these folks) then we should discuss what those
problems are (seem to have a good start on this part) and then discuss
actionable, *technical* solutions to those problems (ie: if
duplication/divergent code is a problem, then let's talk about what
specific refactoring/modularization can help) and then let's try one or
more of those specific actions and see if it improves the situation and
iterate from there.

-Hoss

I suppose I'm overdue for chiming in.  Though I'm still working to  
comprehend what this all really means.

On Mar 9, 2010, at 5:38 PM, Chris Hostetter wrote:
> We are not voting on commiting a specific patch, or releasing a  
> particular
> bundle of source code, or on select a logo from a finite set of  
> entries,
> or on giving a person commit karma -- we are voting largely on the  
> 'idea'
> that development should be merged.

And this is what has had me scratching my head here.  Voting for an  
idea... how about giving us something concrete to vote on.  Ok...

> Only two aspects of "the proposal" are concrete and actionable:  
> merging
> the dev lists, and merging the commiter lists -- those are the only  
> two
> bullet points that can be voted on and pass with a clear and obvious
> immediate ction an effect.

And on these points, I'm +0.  All the rationale for why we need to  
merge those two just doesn't make a lot of sense to me, especially  
given the overlap.  The Solr committers could have been aggressive  
about pushing function queries, analyzers, etc down into Lucene.  No  
merging of lists/committers is necessary, just good ol' fashioned  
cooperation and elbow grease.

The Lucene community certainly won't object to having proven  
goodnesses pushed into it from Solr.  And Solr most definitely  
benefits from the improvements made to Lucene.  And forcing Lucene-
only folks to care about Solr working with the lower-level changes  
isn't going to work.  If you're not using Solr, you're simply not  
going go the extra distance to keep its tests happy.

> Let's hear proposals for how to *implement* that goal, and then lets  
> vote
> one those.

Hear hear.

I am +1 on more cooperation and working together, no question.  But we  
need true action items to vote on.

Erik