You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@lucene.apache.org by Yonik Seeley <ys...@gmail.com> on 2010/03/09 03:11:46 UTC
[VOTE] merge lucene/solr development (take 3)
Apoligies in advance for calling yet another vote, but I just wanted
to make sure this was official.
Mike's second VOTE thread could probably technically stand on it's own
(since it included PMC votes), but given that I said in my previous
VOTE thread that I was just polling Lucene/Solr committers and would
call a second PMC vote, that may have acted to suppress PMC votes on
Mike's thread also.
Please vote for the proposal quoted below to merge lucene/solr development.
Here's my +1
-Yonik
Mike's call for a VOTE (amongst lucene/solr committers +11 to -1):
http://search.lucidimagination.com/search/document/a400ffe62ae21aca/vote_merge_the_development_of_solr_lucene_take_2#22d7cd086d9c5cf0
> Subject: 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.
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Andi Vajda <va...@apache.org>.
+1
Andi..
On Mar 9, 2010, at 3:11, Yonik Seeley <ys...@gmail.com> wrote:
> Apoligies in advance for calling yet another vote, but I just wanted
> to make sure this was official.
> Mike's second VOTE thread could probably technically stand on it's own
> (since it included PMC votes), but given that I said in my previous
> VOTE thread that I was just polling Lucene/Solr committers and would
> call a second PMC vote, that may have acted to suppress PMC votes on
> Mike's thread also.
>
> Please vote for the proposal quoted below to merge lucene/solr
> development.
> Here's my +1
>
> -Yonik
>
> Mike's call for a VOTE (amongst lucene/solr committers +11 to -1):
> http://search.lucidimagination.com/search/document/a400ffe62ae21aca/vote_merge_the_development_of_solr_lucene_take_2#22d7cd086d9c5cf0
>> Subject: 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.
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Tue, Mar 9, 2010 at 3:11 AM, Yonik Seeley <ys...@gmail.com> wrote:
> Please vote for the proposal quoted below to merge lucene/solr development.
+0 with my PMC member hat on, as I think this matter is up to the
Lucene and Solr developers to decide.
That said, I generally think having multiple distinct development
communities under one PMC is a bit troublesome (as we're seeing in
this discussion), so consolidating the community seems like a good
direction given that the technical synergies are there. On the other
hand I share Chris' concern about the massive scope of this vote. All
the proposed changes could IMHO just as well be handled as separate
and more easily reversible steps.
BR,
Jukka Zitting
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Mark Miller <ma...@gmail.com>.
+1
This tally is not official, but here is my count of how people voted on
this merge. A couple people that voted +1 on the first vote did not take
the time to vote again. I've counted them as +1 as I assume they did not
change their mind. Take that for what you will. This is not an official
tally of the vote. If you think your counted wrong, fell free to correct
me. In my mind, its hard to believe that all of these people on the
front lines of Lucene/Solr development don't know what they are doing in
regards to the project.
Bill Au : +1
Doug Cutting
Otis Gospodnetić : +1
Erik Hatcher
Chris Hostetter : -1
Grant Ingersoll : +1
Mike Klaas
Shalin Shekhar Mangar : +1
Ryan McKinley : +1
Mark Miller : +1
Noble Paul : +1
Yonik Seeley : +1
Koji Sekiguchi : +1
Michael Busch : +1
Doron Cohen
Mike McCandless : +1
Bernhard Messer
Robert Muir : +1
Uwe Schindler : +1
Wolfgang Hoschek
Patrick O'Leary
Andi Vajda : +1
Karl Wettin
Simon Willnauer : +1
On 03/08/2010 09:11 PM, Yonik Seeley wrote:
> Apoligies in advance for calling yet another vote, but I just wanted
> to make sure this was official.
> Mike's second VOTE thread could probably technically stand on it's own
> (since it included PMC votes), but given that I said in my previous
> VOTE thread that I was just polling Lucene/Solr committers and would
> call a second PMC vote, that may have acted to suppress PMC votes on
> Mike's thread also.
>
> Please vote for the proposal quoted below to merge lucene/solr development.
> Here's my +1
>
> -Yonik
>
> Mike's call for a VOTE (amongst lucene/solr committers +11 to -1):
> http://search.lucidimagination.com/search/document/a400ffe62ae21aca/vote_merge_the_development_of_solr_lucene_take_2#22d7cd086d9c5cf0
>
>> Subject: 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.
>>
--
- Mark
http://www.lucidimagination.com
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Michael McCandless <lu...@mikemccandless.com>.
+1
Mike
On Mon, Mar 8, 2010 at 9:11 PM, Yonik Seeley <ys...@gmail.com> wrote:
> Apoligies in advance for calling yet another vote, but I just wanted
> to make sure this was official.
> Mike's second VOTE thread could probably technically stand on it's own
> (since it included PMC votes), but given that I said in my previous
> VOTE thread that I was just polling Lucene/Solr committers and would
> call a second PMC vote, that may have acted to suppress PMC votes on
> Mike's thread also.
>
> Please vote for the proposal quoted below to merge lucene/solr development.
> Here's my +1
>
> -Yonik
>
> Mike's call for a VOTE (amongst lucene/solr committers +11 to -1):
> http://search.lucidimagination.com/search/document/a400ffe62ae21aca/vote_merge_the_development_of_solr_lucene_take_2#22d7cd086d9c5cf0
>> Subject: 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.
>
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Dennis Kubes <ku...@apache.org>.
Michael McCandless wrote:
> On Tue, Mar 9, 2010 at 5:10 AM, Andrzej Bialecki <ab...@getopt.org> wrote:
>
>> Re: Nutch components - those that are reusable in Lucene or Solr
>> contexts eventually find their way to respective projects, witness
>> e.g. CommonGrams.
>
> In fact I think this is a great example -- as far as I can tell,
> CommonGrams was poached from Nutch, into Solr, and then was
> nurtured/improved in both projects separately right?
>
> So.... can/should we freely poach across all our sub projects?
IMO yes. Absolutely. That is exactly what OSS is all about. Find
something useful, improve upon it.
>
> It has obvious downsides (it's essentially a fork that will confuse
> those users that use both Solr & Lucene, in the short term, until
> things "stabilize" into a clean refactoring; it's double the dev; we
> must re-sync with time; etc.).
True. OSS development is messy at times. And it can take longer.
>
> But it has a massive upside: it means we don't rely only on "push"
> (Solr devs to push into Lucene or vice/versa). We can also use "pull"
> (Lucene devs can pull pieces from Nutch/Solr into Lucene). It becomes
> a 2-way street for "properly" factoring our shared code with time.
>
> If we had that freedom ("poaching is perfectly fine"), then,
> interested devs could freely "refactor" across sub projects.
There is nothing stopping any developer, committer or not from making
changes to any apache project including Nutch, Lucene, and Solr.
Merging doesn't change or improve that. At best it makes it more
confusing where responsibilities lie.
Dennis
>
> Not having this freedom today, and not having merged dev, is stunting
> both Solr & Lucene's growth.
>
> Mike
Re: [VOTE] merge lucene/solr development (take 3)
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hi Mike,
>> As someone who works on both, I don't think it is fine. Just look at the
>> function query mess. Just look at the version mess. It's very frustrating
>> as a developer and it makes me choose between two projects that I happen to
>> like equally, but for different reasons. If I worked on Nutch, I would feel
>> the same way.
>
> But... Lucene should poach from external (eg non-Apache) projects, if
> the license works?
>
> Ie if some great analyzer is out there, and Robert spots it, and the
> license works, we should poach it? (In fact he just did this w/
> Andrzej's Polish stemmer ;) ).
Yep. This is what I was talking about before when I was talking about
"insulation". Code duplication is a fact of software development, and
happens all the time in open source, ROTS, GOTS, OTS,
research/academia/whatever. It doesn't suffice to say it's bad in all cases,
nor is it always good either.
In this case, it maintains the separation between projects that are really
layered on top of one another (Lucene being the lower layer, and Solr being
the higher).
In addition, FWIW, I agree with Andrzej that to the best of my knowledge,
there is nothing wrong with doing so at the ASF, with proper attribution and
so long as the licenses are compatible.
>
> So we have something of a double standard...
Yep.
>
> And, ironically, I think it's the fact that there's so much committer
> overlap between Solr and Lucene that is causing this antagonism
> towards poaching.
>
> When in fact I think poaching, at a wider scale (across unrelated
> projects) is a very useful means for any healthy open source software
> to evolve.
Agreed. It allows sound innovative technology infusion and solutions to
develop over time, and then be integrated back into the operational fray
with reduced risk and cost.
>
> Why should Lucene be prevented from having a useful feature just
> because Solr happened to create it first?
IMO, it shouldn't.
Cheers,
Chris
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: Chris.Mattmann@jpl.nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Robert Muir <rc...@gmail.com>.
> besides spatial. Is it simply developers/resources that is lacking in
> Lucene(-java) and time? Or are there other reasons?
While its true my analysis patches to fix solr just sit there in JIRA
because Solr developers
are busy working on other tasks such as spatial, on the other hand,
Chris Male's spatial
patches to lucene just sit there in JIRA because Lucene developers are
busy working on
other tasks such as analysis.
So in my opinion, it would be nice if both projects tried to make the
best of our limited
resources.
--
Robert Muir
rcmuir@gmail.com
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Robert Muir <rc...@gmail.com>.
>
> Can you provide more detail on how it's failed? Did it fail because Solr
> wasn't able to upgrade to a newer Lucene that would fix the deprecations? If
> so, what were the reasons?
>
Its just more work. Besides the duplication functionality itself, in
Lucene we (mostly Uwe) developed code to assist with tasks like this.
For example, we have utility code that makes it easier to maintain
backwards compatibility, test harnesses, etc.
The job still isn't done, but to do it right, it only makes sense to
re-use these resources so its done safely and more effectively. But
this would require even more duplication!!!
>
> With which "hat" on? Where are you converting them? I'm guessing you mean
> one for Solr and one for Lucene(-java), right?
Both Solr and Lucene. I'm not wearing a hat in this case: its just
something that needs to be done and we are in it together.
--
Robert Muir
rcmuir@gmail.com
Re: [VOTE] merge lucene/solr development (take 3)
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hi Robert,
>> There might be, but as a first start, duplication is a quick way to get
>> going and experiment. As solutions that evolve over time are matured, the
>> time can come for integration. Parallel tracks allows projects to move
>> forward operationally, and enforces insulation, loose coupling and other
>> properties.
>
> Unfortunately, this experiment has already happened and has failed.
>
> Instead it just creates more work, especially when it comes time for
> code maintenance. This is one reason why Solr is still using
> deprecated analysis APIs and one reason why they cannot use Lucene
> trunk.
Can you provide more detail on how it's failed? Did it fail because Solr
wasn't able to upgrade to a newer Lucene that would fix the deprecations? If
so, what were the reasons?
>
> If there weren't so much duplication, then doing efforts such as this
> would be easier, instead of having to convert two SynonymFilters we
> would only have to convert one.
With which "hat" on? Where are you converting them? I'm guessing you mean
one for Solr and one for Lucene(-java), right?
I hear you on the duplication of patches/etc. Sadly, it's a trade in SE to
maintain good separation of concerns, which provides other benefits
(identification of load bearing walls; insulation of code changes so that
upstream or downstream providers aren't well affected, etc. etc.)
One potential solution to this was what was originally proposed by Mike: a
shared analyzers, that then Lucene(-java), Solr, and Nutch can choose to
depend on. That might help.
Cheers,
Chris
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: Chris.Mattmann@jpl.nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Robert Muir <rc...@gmail.com>.
> There might be, but as a first start, duplication is a quick way to get
> going and experiment. As solutions that evolve over time are matured, the
> time can come for integration. Parallel tracks allows projects to move
> forward operationally, and enforces insulation, loose coupling and other
> properties.
Unfortunately, this experiment has already happened and has failed.
Instead it just creates more work, especially when it comes time for
code maintenance. This is one reason why Solr is still using
deprecated analysis APIs and one reason why they cannot use Lucene
trunk.
If there weren't so much duplication, then doing efforts such as this
would be easier, instead of having to convert two SynonymFilters we
would only have to convert one.
--
Robert Muir
rcmuir@gmail.com
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Michael Busch <bu...@gmail.com>.
On 3/9/10 8:41 AM, Yonik Seeley wrote:
> On Tue, Mar 9, 2010 at 11:35 AM, Michael Busch<bu...@gmail.com> wrote:
>
>> No matter if this dev-merge vote passes or not, we still
>> want a separate analysis module, right?
>>
> No. That's the point of the dev merge - to allow free movement of
> source code that benefits both projects.
>
> -Yonik
>
>
Now I'm confused. This is part of the proposal:
> 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).
Michael
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Dennis Kubes <ku...@apache.org>.
From what I see I don't think we are going to agree on this. Some of
us believe there should be clear separations, some of us don't. Let's
move on.
My vote is still a -1 on this. If that means I get overruled, so be it.
I have brought up what I believe to be important points in this
discussion. I think we are just looping now.
Dennis
Yonik Seeley wrote:
> On Tue, Mar 9, 2010 at 11:35 AM, Michael Busch <bu...@gmail.com> wrote:
>> No matter if this dev-merge vote passes or not, we still
>> want a separate analysis module, right?
>
> No. That's the point of the dev merge - to allow free movement of
> source code that benefits both projects.
>
> -Yonik
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Yonik Seeley <ys...@gmail.com>.
On Tue, Mar 9, 2010 at 11:35 AM, Michael Busch <bu...@gmail.com> wrote:
> No matter if this dev-merge vote passes or not, we still
> want a separate analysis module, right?
No. That's the point of the dev merge - to allow free movement of
source code that benefits both projects.
-Yonik
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Michael Busch <bu...@gmail.com>.
On 3/9/10 7:35 AM, Robert Muir wrote:
>> 2. duplicate the Lucene code in Solr, address any issues there, and then
>> contribute it back
>>
>>
> Not that I can stop anything, but -1 to any further analysis code
> duplication. There has to be a better way.
>
> Its stupid to duplicate the code. Its also stupid to just move the code.
>
>
I agree with that. No matter if this dev-merge vote passes or not, we
still want a separate analysis module, right? Gathering all the
analyzers from the different projects and putting them into one place
was Mike's first proposal and I believe everyone was excited about it.
So how about we start with that, considering that we want to do it
anyway? It seems like this solves the immediate problem Robert and
others are having with working on the analyzer patches and will help us
learn about what such a re-structuring entails. And then, maybe in a
few weeks or months, we can discuss again if more modules should be
factored out or if we still see the need for merging the Solr and Lucene
devs.
It seems like the analysis house is currently the only one on fire.
Michael
Re: [VOTE] merge lucene/solr development (take 3)
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hi Robert,
>> 2. duplicate the Lucene code in Solr, address any issues there, and then
>> contribute it back
>>
>
> Not that I can stop anything, but -1 to any further analysis code
> duplication. There has to be a better way.
There might be, but as a first start, duplication is a quick way to get
going and experiment. As solutions that evolve over time are matured, the
time can come for integration. Parallel tracks allows projects to move
forward operationally, and enforces insulation, loose coupling and other
properties.
>
> Its stupid to duplicate the code. Its also stupid to just move the code.
I'm not sure anything is "stupid" per-se. There are different approaches
which address different concerns.
>
> In my opinion, if Solr has an analysis feature that belongs in lucene,
> we want not just the code, but improvements, ideas, comments from solr
> developers that have experience with it, we want to pay
> attention to open Solr JIRA tickets against that feature, we want
> things like the Solr example schema to have good "defaults" for any
> potential improvements to it, and we want the wiki to reflect
> additional improvements it supports.
Then I think it's fair to say that those that want this can follow the
normal Apache process to do so:
* subscribe to the mailing lists
* post JIRA issues with patches
* get those patches committed
* become a committer, etc.
Cheers,
Chris
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: Chris.Mattmann@jpl.nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Robert Muir <rc...@gmail.com>.
> 2. duplicate the Lucene code in Solr, address any issues there, and then
> contribute it back
>
Not that I can stop anything, but -1 to any further analysis code
duplication. There has to be a better way.
Its stupid to duplicate the code. Its also stupid to just move the code.
In my opinion, if Solr has an analysis feature that belongs in lucene,
we want not just the code, but improvements, ideas, comments from solr
developers that have experience with it, we want to pay
attention to open Solr JIRA tickets against that feature, we want
things like the Solr example schema to have good "defaults" for any
potential improvements to it, and we want the wiki to reflect
additional improvements it supports.
--
Robert Muir
rcmuir@gmail.com
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Grant Ingersoll <gs...@apache.org>.
On Mar 9, 2010, at 11:28 AM, Grant Ingersoll wrote:
>
> On Mar 9, 2010, at 10:59 AM, Dennis Kubes wrote:
>
>> I agree. Most of those things can/should be moved into Lucene. That doesn't necessitate merging. Separate responsibilities.
>>
>>> For that matter, why do we even need to have this discussion at all? > Most of us Solr committers are Lucene committers. We can simply start
>>> committing Solr code to Lucene such that in 6 months the whole
>>> discussion is moot and the three committers on Solr who aren't Lucene
>>> committers can earn their Lucene merit very quickly by patching the
>>> "Solr" portion of Lucene. We can move all the code to it's
>>> appropriate place, add a contrib module for the WAR stuff and the
>>> response writers and voila, Solr is in Lucene, the dev mailing lists
>>> have merged by the fact that Solr dev would be defunct and all of the
>>> proposals in this vote are implemented simply by employing our commit
>>> privileges in a concerted way.
>>
>> Am I reading you right. Are you are proposing a hostile takeover of the Lucene project? Even being committers there needs to be discussion with the community about the best path. Or are you suggesting we bypass discussion? I am now even more concerned that merging is not the right way to go.
>>
>
> No. Would you please re-read it and not quote me out of context. You left the next sentence off, which is of course the vital one.
Namely:
"Yet, somehow, me thinks that isn't a good solution either, right? Yet it is perfectly "legal" and is just as valid a solution as the "poaching" solution and in a lot of ways seems to be what Chris is proposing."
My point is, if people would just step back for a minute and remove the labels of Solr and Lucene and look at the code, the discussion would be a whole lot different. Furthermore, if they stepped back and looked at the actual people who do the actual work on Lucene and Solr, you would see that these separations are slowing down both Lucene and Solr and hurting them more than helping. This has been expressed time and time again by committers in both Lucene and in Solr and even in Nutch, including many committers who do not even work on Solr.
-Grant
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Grant Ingersoll <gs...@apache.org>.
On Mar 9, 2010, at 10:59 AM, Dennis Kubes wrote:
> I agree. Most of those things can/should be moved into Lucene. That doesn't necessitate merging. Separate responsibilities.
>
> > For that matter, why do we even need to have this discussion at all? > Most of us Solr committers are Lucene committers. We can simply start
> > committing Solr code to Lucene such that in 6 months the whole
> > discussion is moot and the three committers on Solr who aren't Lucene
> > committers can earn their Lucene merit very quickly by patching the
> > "Solr" portion of Lucene. We can move all the code to it's
> > appropriate place, add a contrib module for the WAR stuff and the
> > response writers and voila, Solr is in Lucene, the dev mailing lists
> > have merged by the fact that Solr dev would be defunct and all of the
> > proposals in this vote are implemented simply by employing our commit
> > privileges in a concerted way.
>
> Am I reading you right. Are you are proposing a hostile takeover of the Lucene project? Even being committers there needs to be discussion with the community about the best path. Or are you suggesting we bypass discussion? I am now even more concerned that merging is not the right way to go.
>
No. Would you please re-read it and not quote me out of context. You left the next sentence off, which is of course the vital one.
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Dennis Kubes <ku...@apache.org>.
I agree. Most of those things can/should be moved into Lucene. That
doesn't necessitate merging. Separate responsibilities.
> For that matter, why do we even need to have this discussion at all?
> Most of us Solr committers are Lucene committers. We can simply start
> committing Solr code to Lucene such that in 6 months the whole
> discussion is moot and the three committers on Solr who aren't Lucene
> committers can earn their Lucene merit very quickly by patching the
> "Solr" portion of Lucene. We can move all the code to it's
> appropriate place, add a contrib module for the WAR stuff and the
> response writers and voila, Solr is in Lucene, the dev mailing lists
> have merged by the fact that Solr dev would be defunct and all of the
> proposals in this vote are implemented simply by employing our commit
> privileges in a concerted way.
Am I reading you right. Are you are proposing a hostile takeover of the
Lucene project? Even being committers there needs to be discussion with
the community about the best path. Or are you suggesting we bypass
discussion? I am now even more concerned that merging is not the right
way to go.
Dennis
Grant Ingersoll wrote:
> I think many of the objections I've seen so far come from the fact that people don't really know what Solr is. Solr is much more than simply a "server" around Lucene.
>
> Look at the other thread. Here's a minimal list of things that a very large chunk of people who writes a Lucene app for production has to do:
>
> 1. Analyzers
> 2. Functions
> 3. Schema (although likely abstracted/reworked)
> 4. Warming/Reopen - this is hard code to get right and I've seen many people do it wrong. It is also yet another area of duplication where something started in Solr b/c for years the Lucene community had no interest in donating code for it (incRef/decRef)
> 5. Faceting
>
> If someone came in and contributed all of those things to Lucene, there would be no objection. Simply the fact that Solr has other things around it doesn't mean people have to use them and no one is proposing some Uber JAR.
>
>
> On Mar 9, 2010, at 10:13 AM, Mattmann, Chris A (388J) wrote:
>
>> Hi Yonik,
>>
>>>> I have built 10s of projects that
>>>> have simply used Lucene as an API and had no need for Solr, and I've built
>>>> 10s of projects where Solr made perfect sense. So, I appreciate their
>>>> separation.
>>> As does everyone - which is why there will always be separate
>>> downloads. As a user, the only side affect you should see is an
>>> improved Lucene and Solr.
>> Developers make downloads. Software processes guide developers who are
>> producing those downloads. Policies guide the direction of a project. They
>> are intimately intertwined.
>>
>>> Saying that Solr should move some stuff to Lucene for Lucene's
>>> benefit, without regard to if it's actually benefitial to Solr, is a
>>> non-starter.
>> I'm not sure it's Solr's decision what the Lucene committers decide to move
>> to Lucene, neither is it Lucene's decision in the opposite direction. These
>> are all Apache projects, subprojects of the Lucene TLP. I'm not sure what
>> the debate is? If Solr wants elements from Lucene that aren't part of Solr
>> yet b/c Solr is relying on an old version of Lucene:
>>
>> 1. upgrade to Lucene trunk and address the issues it brings in Solr
>> 2. duplicate the Lucene code in Solr, address any issues there, and then
>> contribute it back
>>
>> I'd recommend the same to any project, regardless of what TLP it resides in,
>> and in many cases, where it's at the ASF, or Sourceforge, or wherever.
>>
>> It seems kind of incestuous and an abuse of power to make the case that
>> "well because we're all committers on both projects, then this..." I keep
>> hearing a lot of talk about "hats", which in analogy means that though you
>> are one person you have different concerns/projects/etc. This is another
>> example of the need to maintain separate hats.
>>
>> Cheers,
>> Chris
>>
>>
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> Chris Mattmann, Ph.D.
>> Senior Computer Scientist
>> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
>> Office: 171-266B, Mailstop: 171-246
>> Email: Chris.Mattmann@jpl.nasa.gov
>> WWW: http://sunset.usc.edu/~mattmann/
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> Adjunct Assistant Professor, Computer Science Department
>> University of Southern California, Los Angeles, CA 90089 USA
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>
>>
>
> --------------------------
> Grant Ingersoll
> http://www.lucidimagination.com/
>
> Search the Lucene ecosystem using Solr/Lucene: http://www.lucidimagination.com/search
>
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Grant Ingersoll <gs...@apache.org>.
I think many of the objections I've seen so far come from the fact that people don't really know what Solr is. Solr is much more than simply a "server" around Lucene.
Look at the other thread. Here's a minimal list of things that a very large chunk of people who writes a Lucene app for production has to do:
1. Analyzers
2. Functions
3. Schema (although likely abstracted/reworked)
4. Warming/Reopen - this is hard code to get right and I've seen many people do it wrong. It is also yet another area of duplication where something started in Solr b/c for years the Lucene community had no interest in donating code for it (incRef/decRef)
5. Faceting
If someone came in and contributed all of those things to Lucene, there would be no objection. Simply the fact that Solr has other things around it doesn't mean people have to use them and no one is proposing some Uber JAR.
On Mar 9, 2010, at 10:13 AM, Mattmann, Chris A (388J) wrote:
> Hi Yonik,
>
>>> I have built 10s of projects that
>>> have simply used Lucene as an API and had no need for Solr, and I've built
>>> 10s of projects where Solr made perfect sense. So, I appreciate their
>>> separation.
>>
>> As does everyone - which is why there will always be separate
>> downloads. As a user, the only side affect you should see is an
>> improved Lucene and Solr.
>
> Developers make downloads. Software processes guide developers who are
> producing those downloads. Policies guide the direction of a project. They
> are intimately intertwined.
>
>>
>> Saying that Solr should move some stuff to Lucene for Lucene's
>> benefit, without regard to if it's actually benefitial to Solr, is a
>> non-starter.
>
> I'm not sure it's Solr's decision what the Lucene committers decide to move
> to Lucene, neither is it Lucene's decision in the opposite direction. These
> are all Apache projects, subprojects of the Lucene TLP. I'm not sure what
> the debate is? If Solr wants elements from Lucene that aren't part of Solr
> yet b/c Solr is relying on an old version of Lucene:
>
> 1. upgrade to Lucene trunk and address the issues it brings in Solr
> 2. duplicate the Lucene code in Solr, address any issues there, and then
> contribute it back
>
> I'd recommend the same to any project, regardless of what TLP it resides in,
> and in many cases, where it's at the ASF, or Sourceforge, or wherever.
>
> It seems kind of incestuous and an abuse of power to make the case that
> "well because we're all committers on both projects, then this..." I keep
> hearing a lot of talk about "hats", which in analogy means that though you
> are one person you have different concerns/projects/etc. This is another
> example of the need to maintain separate hats.
>
> Cheers,
> Chris
>
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Chris Mattmann, Ph.D.
> Senior Computer Scientist
> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> Office: 171-266B, Mailstop: 171-246
> Email: Chris.Mattmann@jpl.nasa.gov
> WWW: http://sunset.usc.edu/~mattmann/
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Adjunct Assistant Professor, Computer Science Department
> University of Southern California, Los Angeles, CA 90089 USA
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>
--------------------------
Grant Ingersoll
http://www.lucidimagination.com/
Search the Lucene ecosystem using Solr/Lucene: http://www.lucidimagination.com/search
Re: [VOTE] merge lucene/solr development (take 3)
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hi Yonik,
>> I have built 10s of projects that
>> have simply used Lucene as an API and had no need for Solr, and I've built
>> 10s of projects where Solr made perfect sense. So, I appreciate their
>> separation.
>
> As does everyone - which is why there will always be separate
> downloads. As a user, the only side affect you should see is an
> improved Lucene and Solr.
Developers make downloads. Software processes guide developers who are
producing those downloads. Policies guide the direction of a project. They
are intimately intertwined.
>
> Saying that Solr should move some stuff to Lucene for Lucene's
> benefit, without regard to if it's actually benefitial to Solr, is a
> non-starter.
I'm not sure it's Solr's decision what the Lucene committers decide to move
to Lucene, neither is it Lucene's decision in the opposite direction. These
are all Apache projects, subprojects of the Lucene TLP. I'm not sure what
the debate is? If Solr wants elements from Lucene that aren't part of Solr
yet b/c Solr is relying on an old version of Lucene:
1. upgrade to Lucene trunk and address the issues it brings in Solr
2. duplicate the Lucene code in Solr, address any issues there, and then
contribute it back
I'd recommend the same to any project, regardless of what TLP it resides in,
and in many cases, where it's at the ASF, or Sourceforge, or wherever.
It seems kind of incestuous and an abuse of power to make the case that
"well because we're all committers on both projects, then this..." I keep
hearing a lot of talk about "hats", which in analogy means that though you
are one person you have different concerns/projects/etc. This is another
example of the need to maintain separate hats.
Cheers,
Chris
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: Chris.Mattmann@jpl.nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Jason Rutherglen <ja...@gmail.com>.
> * I think Grant may be right. We don't need this discussion. Because the Solr/Lucene developer overlap is excellent, why not just start moving selected Solr code to new Lucene modules, just like Mike proposed we move Analysis from Lucene core to a new Lucene module?
The underlying hesitation could be that the initial proposal sounds
like a press release. With all the discussing, a few modules could
already have been moved (given the number of keys pressed to enter the
emails).
On Tue, Mar 9, 2010 at 9:38 AM, Otis Gospodnetic
<ot...@yahoo.com> wrote:
> * Re poaching (aka cross-project refactoring) - I think this is the way to go. I think this is normal evolution of OSS projects. I think this should be done if the functionality was not committed to the best (lowest common denominator?) project from the beginning, as in all the Solr/Lucene examples brought up
>
> * I think Grant may be right. We don't need this discussion. Because the Solr/Lucene developer overlap is excellent, why not just start moving selected Solr code to new Lucene modules, just like Mike proposed we move Analysis from Lucene core to a new Lucene module?
>
> * What do people think about doing what I wrote above as step 1 in this whole process? When that is done in N months, we can see if we can improve on it? This would also fit "progress, not perfection" mantra.
>
> Otis
>
>
>
>
> ----- Original Message ----
>> From: Otis Gospodnetic <ot...@yahoo.com>
>> To: general@lucene.apache.org
>> Sent: Tue, March 9, 2010 12:23:59 PM
>> Subject: Re: [VOTE] merge lucene/solr development (take 3)
>>
>> Hello,
>>
>> (just using Yonik's email to reply, but my comments are more general)
>>
>>
>> ----- Original Message ----
>> > From: Yonik Seeley
>> > To: general@lucene.apache.org
>> > Sent: Tue, March 9, 2010 10:04:20 AM
>> > Subject: Re: [VOTE] merge lucene/solr development (take 3)
>> >
>> > On Tue, Mar 9, 2010 at 9:48 AM, Mattmann, Chris A (388J)
>> > wrote:
>> > > I have built 10s of projects that
>> > > have simply used Lucene as an API and had no need for Solr, and I've built
>> > > 10s of projects where Solr made perfect sense. So, I appreciate their
>> > > separation.
>> >
>> > As does everyone - which is why there will always be separate
>> > downloads. As a user, the only side affect you should see is an
>> > improved Lucene and Solr.
>> >
>> > Saying that Solr should move some stuff to Lucene for Lucene's
>> > benefit, without regard to if it's actually benefitial to Solr, is a
>> > non-starter. The lucene/solr committers have been down that road
>> > before. The solution that most committers agreed would improve the
>> > development of both projects is to merge development.
>>
>> * I'd completely understand the "non-starter" part if Lucene and Solr had
>> disjoint sets of committers. But that's not the case.
>>
>> * Which is why I (like a few others) don't see why this whole thing cannot be
>> solved by "better discussion of what to develop where from the get-go"
>>
>> * Whenever people listed features built in Solr that really should have been in
>> Lucene, I wondered "so why were not they developed in Lucene in the first
>> place?" Again, this should be possible because the same person can commit to
>> both projects.
>>
>> * I hear Grant's explanation on wanting something in Solr ASAP and not wanting
>> to commit that something to Lucene (even though it logically belongs there)
>> because Solr is not on Lucene trunk, but isn't this just a matter of getting
>> "Lucene trunk nightly -> Solr trunk lib in svn" process going?
>>
>> * Ian is 100% right. This stuff clearly requires more discussion and a proper
>> VOTE should wait a week or so.
>>
>> Otis
>
>
Re: [VOTE] merge lucene/solr development (take 3)
Posted by patrick o'leary <pj...@pjaol.com>.
Sigh...
http://www.surveymonkey.com/
On Tue, Mar 9, 2010 at 2:00 PM, Grant Ingersoll <gs...@apache.org> wrote:
>
> On Mar 9, 2010, at 12:38 PM, Otis Gospodnetic wrote:
>
> >
> >
> > * I think Grant may be right. We don't need this discussion. Because
> the Solr/Lucene developer overlap is excellent, why not just start moving
> selected Solr code to new Lucene modules, just like Mike proposed we move
> Analysis from Lucene core to a new Lucene module?
>
> Note, if you read what I said again you will realize I wasn't actually
> proposing this. I was saying actually, that I think it would not be
> something that people really wanted, even though it is perfectly "legal",
> just like poaching is perfectly "legal", but isn't, in my mind a good
> solution. Sigh. The problem with email, I guess, especially on long
> threads.
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Yonik Seeley <ys...@gmail.com>.
On Sun, Mar 14, 2010 at 2:58 PM, Otis Gospodnetic
<ot...@yahoo.com> wrote:
> Would it make sense to think of Solr as one such Lucene module?
> In other words, don't even bother with merging just the -dev lists, but really just merge everything. In that case Solr's relationship with Lucene core becomes much like the relationship Lucene contribs have with Lucene core today in terms of compatibility, builds, and committers' responsibilities?
>
> That kind of makes sense to me. Of course, because of the sheer volume we may want to keep -user lists separate and possibly even create new ones for Lucene modules that attract enough interest on their own.
Yes, the general gist of that all makes sense. merge-everything is
more along the lines of the original discussion (we just needed to
enumerate some specific action items in the vote). The things we
probably don't merge are just for user convenience. Separate
downloads & websites & user lists. Might have made sense to merge
JIRA, but there are just so many open issues... it prob wouldn't be
practical.
And yes, more user lists in the future could even make sense - say a
separate one for DIH.
-Yonik
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Otis Gospodnetic <ot...@yahoo.com>.
Hi,
----- Original Message ----
> From: Yonik Seeley <ys...@gmail.com>
> To: general@lucene.apache.org
> Sent: Sun, March 14, 2010 3:48:10 PM
> Subject: Re: [VOTE] merge lucene/solr development (take 3)
>
> On Sun, Mar 14, 2010 at 2:36 PM, Otis Gospodnetic
<
> ymailto="mailto:otis_gospodnetic@yahoo.com"
> href="mailto:otis_gospodnetic@yahoo.com">otis_gospodnetic@yahoo.com>
> wrote:
> if I understand things correctly, poaching is only needed
> when the code is not committed in the
> "right" project/location to begin
> with.
That is the problem though - Solr should be allowed to keep
> whatever
code was written under it's control, w/o pressure to put it in
> Lucene
But don't we want DRY?
And don't we want to take some of the goodness that evolved under Solr and modularize it, so that vanilla-Lucene users can benefit from individual pieces?
> (and often out of reach).
Does this remain true if we get Lucene trunk jar -> Solr trunk lib going on a regular (e.g. nightly) basis?
> And Lucene should be able to poach
> what it wants from Solr. But with the projects already half
> overlapping... it was a recipe for conflict.
Poaching - right, it's just that if you build X in project A and then you want to move X to project B, it seems like more work needs to be done than if X was committed to B to begin with.
> We've already had
> conflicts about this in the past. The conflicts were either going to
> get worse over time, esp with Solr not on Lucene's trunk, or we were going to
> merge. We've decided to tear down the artificial wall and work
> together.
> Some people suggest that this could have worked w/o
> merging. I disagreed, as I think the majority of those voting +1
> disagreed.
> Not sure who's following lucene-dev and solr-dev, but the
> committers have already been merged. We're not standing
> still...
Hm.
So there was talk of Lucene core and the new idea of Lucene modules, which are really just standalone libs/APIs/jars, right?
Would it make sense to think of Solr as one such Lucene module?
In other words, don't even bother with merging just the -dev lists, but really just merge everything. In that case Solr's relationship with Lucene core becomes much like the relationship Lucene contribs have with Lucene core today in terms of compatibility, builds, and committers' responsibilities?
That kind of makes sense to me. Of course, because of the sheer volume we may want to keep -user lists separate and possibly even create new ones for Lucene modules that attract enough interest on their own.
Otis
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Yonik Seeley <ys...@gmail.com>.
On Sun, Mar 14, 2010 at 2:36 PM, Otis Gospodnetic
<ot...@yahoo.com> wrote:
> if I understand things correctly, poaching is only needed when the code is not committed in the
> "right" project/location to begin with.
That is the problem though - Solr should be allowed to keep whatever
code was written under it's control, w/o pressure to put it in Lucene
(and often out of reach). And Lucene should be able to poach what it
wants from Solr. But with the projects already half overlapping... it
was a recipe for conflict.
We've already had conflicts about this in the past. The conflicts
were either going to get worse over time, esp with Solr not on
Lucene's trunk, or we were going to merge. We've decided to tear down
the artificial wall and work together.
Some people suggest that this could have worked w/o merging. I
disagreed, as I think the majority of those voting +1 disagreed.
Not sure who's following lucene-dev and solr-dev, but the committers
have already been merged. We're not standing still...
-Yonik
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Otis Gospodnetic <ot...@yahoo.com>.
Hi,
----- Original Message ----
> From: Grant Ingersoll <gs...@apache.org>
> To: general@lucene.apache.org
> Sent: Tue, March 9, 2010 5:00:42 PM
> Subject: Re: [VOTE] merge lucene/solr development (take 3)
>
>
On Mar 9, 2010, at 12:38 PM, Otis Gospodnetic wrote:
>
>
>
> * I think Grant may be right. We don't need this
> discussion. Because the Solr/Lucene developer overlap is excellent, why
> not just start moving selected Solr code to new Lucene modules, just like Mike
> proposed we move Analysis from Lucene core to a new Lucene module?
Note,
> if you read what I said again you will realize I wasn't actually proposing
> this. I was saying actually, that I think it would not be something that
> people really wanted, even though it is perfectly "legal", just like poaching is
> perfectly "legal", but isn't, in my mind a good solution. Sigh. The
> problem with email, I guess, especially on long threads.
My feeling was that majority of people said poaching (in a very positive sense) is the way OSS works.
Why can't we start with poaching/refactoring and then, in N months, evaluate both the outcome and the process and see if things can work that way in the future[*] or something more drastic should be done?
Additionally, if I understand things correctly, poaching is only needed when the code is not committed in the "right" project/location to begin with.
Otis
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Grant Ingersoll <gs...@apache.org>.
On Mar 9, 2010, at 12:38 PM, Otis Gospodnetic wrote:
>
>
> * I think Grant may be right. We don't need this discussion. Because the Solr/Lucene developer overlap is excellent, why not just start moving selected Solr code to new Lucene modules, just like Mike proposed we move Analysis from Lucene core to a new Lucene module?
Note, if you read what I said again you will realize I wasn't actually proposing this. I was saying actually, that I think it would not be something that people really wanted, even though it is perfectly "legal", just like poaching is perfectly "legal", but isn't, in my mind a good solution. Sigh. The problem with email, I guess, especially on long threads.
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Otis Gospodnetic <ot...@yahoo.com>.
* Re poaching (aka cross-project refactoring) - I think this is the way to go. I think this is normal evolution of OSS projects. I think this should be done if the functionality was not committed to the best (lowest common denominator?) project from the beginning, as in all the Solr/Lucene examples brought up
* I think Grant may be right. We don't need this discussion. Because the Solr/Lucene developer overlap is excellent, why not just start moving selected Solr code to new Lucene modules, just like Mike proposed we move Analysis from Lucene core to a new Lucene module?
* What do people think about doing what I wrote above as step 1 in this whole process? When that is done in N months, we can see if we can improve on it? This would also fit "progress, not perfection" mantra.
Otis
----- Original Message ----
> From: Otis Gospodnetic <ot...@yahoo.com>
> To: general@lucene.apache.org
> Sent: Tue, March 9, 2010 12:23:59 PM
> Subject: Re: [VOTE] merge lucene/solr development (take 3)
>
> Hello,
>
> (just using Yonik's email to reply, but my comments are more general)
>
>
> ----- Original Message ----
> > From: Yonik Seeley
> > To: general@lucene.apache.org
> > Sent: Tue, March 9, 2010 10:04:20 AM
> > Subject: Re: [VOTE] merge lucene/solr development (take 3)
> >
> > On Tue, Mar 9, 2010 at 9:48 AM, Mattmann, Chris A (388J)
> > wrote:
> > > I have built 10s of projects that
> > > have simply used Lucene as an API and had no need for Solr, and I've built
> > > 10s of projects where Solr made perfect sense. So, I appreciate their
> > > separation.
> >
> > As does everyone - which is why there will always be separate
> > downloads. As a user, the only side affect you should see is an
> > improved Lucene and Solr.
> >
> > Saying that Solr should move some stuff to Lucene for Lucene's
> > benefit, without regard to if it's actually benefitial to Solr, is a
> > non-starter. The lucene/solr committers have been down that road
> > before. The solution that most committers agreed would improve the
> > development of both projects is to merge development.
>
> * I'd completely understand the "non-starter" part if Lucene and Solr had
> disjoint sets of committers. But that's not the case.
>
> * Which is why I (like a few others) don't see why this whole thing cannot be
> solved by "better discussion of what to develop where from the get-go"
>
> * Whenever people listed features built in Solr that really should have been in
> Lucene, I wondered "so why were not they developed in Lucene in the first
> place?" Again, this should be possible because the same person can commit to
> both projects.
>
> * I hear Grant's explanation on wanting something in Solr ASAP and not wanting
> to commit that something to Lucene (even though it logically belongs there)
> because Solr is not on Lucene trunk, but isn't this just a matter of getting
> "Lucene trunk nightly -> Solr trunk lib in svn" process going?
>
> * Ian is 100% right. This stuff clearly requires more discussion and a proper
> VOTE should wait a week or so.
>
> Otis
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Otis Gospodnetic <ot...@yahoo.com>.
Hello,
(just using Yonik's email to reply, but my comments are more general)
----- Original Message ----
> From: Yonik Seeley <ys...@gmail.com>
> To: general@lucene.apache.org
> Sent: Tue, March 9, 2010 10:04:20 AM
> Subject: Re: [VOTE] merge lucene/solr development (take 3)
>
> On Tue, Mar 9, 2010 at 9:48 AM, Mattmann, Chris A (388J)
> wrote:
> > I have built 10s of projects that
> > have simply used Lucene as an API and had no need for Solr, and I've built
> > 10s of projects where Solr made perfect sense. So, I appreciate their
> > separation.
>
> As does everyone - which is why there will always be separate
> downloads. As a user, the only side affect you should see is an
> improved Lucene and Solr.
>
> Saying that Solr should move some stuff to Lucene for Lucene's
> benefit, without regard to if it's actually benefitial to Solr, is a
> non-starter. The lucene/solr committers have been down that road
> before. The solution that most committers agreed would improve the
> development of both projects is to merge development.
* I'd completely understand the "non-starter" part if Lucene and Solr had disjoint sets of committers. But that's not the case.
* Which is why I (like a few others) don't see why this whole thing cannot be solved by "better discussion of what to develop where from the get-go"
* Whenever people listed features built in Solr that really should have been in Lucene, I wondered "so why were not they developed in Lucene in the first place?" Again, this should be possible because the same person can commit to both projects.
* I hear Grant's explanation on wanting something in Solr ASAP and not wanting to commit that something to Lucene (even though it logically belongs there) because Solr is not on Lucene trunk, but isn't this just a matter of getting "Lucene trunk nightly -> Solr trunk lib in svn" process going?
* Ian is 100% right. This stuff clearly requires more discussion and a proper VOTE should wait a week or so.
Otis
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Yonik Seeley <ys...@gmail.com>.
On Tue, Mar 9, 2010 at 9:48 AM, Mattmann, Chris A (388J)
<ch...@jpl.nasa.gov> wrote:
> I have built 10s of projects that
> have simply used Lucene as an API and had no need for Solr, and I've built
> 10s of projects where Solr made perfect sense. So, I appreciate their
> separation.
As does everyone - which is why there will always be separate
downloads. As a user, the only side affect you should see is an
improved Lucene and Solr.
Saying that Solr should move some stuff to Lucene for Lucene's
benefit, without regard to if it's actually benefitial to Solr, is a
non-starter. The lucene/solr committers have been down that road
before. The solution that most committers agreed would improve the
development of both projects is to merge development.
-Yonik
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Michael McCandless <lu...@mikemccandless.com>.
I'm still +1 for merging Solr/Lucene dev.
I think poaching, when we have so much that needs to be shared, is
going to cause far more problems than it'll solve. It's not the right
tool for [this] job.
I do think poaching is good & legitimate tool when it's less code (eg
the CommonGrams case), so, we should do both ;)
Mike
On Tue, Mar 9, 2010 at 8:49 AM, Grant Ingersoll <gs...@apache.org> wrote:
>
> On Mar 9, 2010, at 8:21 AM, Michael McCandless wrote:
>
>> On Tue, Mar 9, 2010 at 7:21 AM, Grant Ingersoll <gs...@apache.org> wrote:
>>
>>>> If we had that freedom ("poaching is perfectly fine"), then,
>>>> interested devs could freely "refactor" across sub projects.
>>>
>>> As someone who works on both, I don't think it is fine. Just look at the function query mess. Just look at the version mess. It's very frustrating as a developer and it makes me choose between two projects that I happen to like equally, but for different reasons. If I worked on Nutch, I would feel the same way.
>>
>> But... Lucene should poach from external (eg non-Apache) projects, if
>> the license works?
>>
>> Ie if some great analyzer is out there, and Robert spots it, and the
>> license works, we should poach it? (In fact he just did this w/
>> Andrzej's Polish stemmer ;) ).
>
> I'd prefer "donate" to poach, but, realize that isn't always the case.
>
>
>>
>> So we have something of a double standard...
>>
>> And, ironically, I think it's the fact that there's so much committer
>> overlap between Solr and Lucene that is causing this antagonism
>> towards poaching.
>>
>> When in fact I think poaching, at a wider scale (across unrelated
>> projects) is a very useful means for any healthy open source software
>> to evolve.
>>
>> Why should Lucene be prevented from having a useful feature just
>> because Solr happened to create it first?
>
> But why should I be forced to maintain two versions due to some arbitrary code separation? And why should you force a good chunk of us to do a whole lot of extra work simply because of some arbitrary code separation? Here, it is the Lucene PMC that releases code and it is just silly that with all of this overlap at the committer level we still have this duplication. I can't speak for the external projects (I don't believe any of them have even responded here other than Jackrabbit), but if they don't like it, they should get more involved in the community and work to be committers.
>
> At any rate, this is exactly why merging makes sense. You would no longer have this issue of "first". I would no longer have to choose where to add my spatial work based on some arbitrary line that someone drew in the sand that isn't all that pertinent anymore given the desires of most in the community to blur that line. It would be available to everyone.
>
> For that matter, why do we even need to have this discussion at all? Most of us Solr committers are Lucene committers. We can simply start committing Solr code to Lucene such that in 6 months the whole discussion is moot and the three committers on Solr who aren't Lucene committers can earn their Lucene merit very quickly by patching the "Solr" portion of Lucene. We can move all the code to it's appropriate place, add a contrib module for the WAR stuff and the response writers and voila, Solr is in Lucene, the dev mailing lists have merged by the fact that Solr dev would be defunct and all of the proposals in this vote are implemented simply by employing our commit privileges in a concerted way. Yet, somehow, me thinks that isn't a good solution either, right? Yet it is perfectly "legal" and is just as valid a solution as the "poaching" solution and in a lot of ways seems to be what Chris is proposing.
>
> -Grant
>
>
>
>
>
>
>
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Yonik Seeley <ys...@gmail.com>.
I think the problem is political - and that leads to both technical
and political problems.
We came up with a largely political solution that should solve both.
We can't have a one way street of pulling everything interesting out
of Solr for Lucene, or poaching, or expanding Lucene's domain while
shrinking Solr's (just limit to "server stuff", etc). Lucene and Solr
committers are headed down the road toward greater competition - but
with this proposal, we said we'd rather work together instead.
-Yonik
Re: [VOTE] merge lucene/solr development (take 3)
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Haha it dates me too but that's OK I know I'm a young-un! :)
Cheers,
Chris
On 3/9/10 8:35 AM, "Grant Ingersoll" <gs...@apache.org> wrote:
On Mar 9, 2010, at 11:29 AM, Mattmann, Chris A (388J) wrote:
> Hey Yonik,
>
>>> However, like I said it seems to be like
>>> the discussion of the real issues is only happening recently over the past
>>> few days.
>>
>> This certainly isn't new territory for lucene/solr devs though - the
>> issue of what belongs in Solr and what belongs in Lucene, and problems
>> around pulling out schema and faceting and putting it in Lucene have
>> come up before (also in lengthy threads).
>
> I hear ya. I've seen some on solr-{user|dev}@ within the past months.
I know it dates me, but: s/months/years/ :-)
-Grant
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: Chris.Mattmann@jpl.nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Grant Ingersoll <gs...@apache.org>.
On Mar 9, 2010, at 11:29 AM, Mattmann, Chris A (388J) wrote:
> Hey Yonik,
>
>>> However, like I said it seems to be like
>>> the discussion of the real issues is only happening recently over the past
>>> few days.
>>
>> This certainly isn't new territory for lucene/solr devs though - the
>> issue of what belongs in Solr and what belongs in Lucene, and problems
>> around pulling out schema and faceting and putting it in Lucene have
>> come up before (also in lengthy threads).
>
> I hear ya. I've seen some on solr-{user|dev}@ within the past months.
I know it dates me, but: s/months/years/ :-)
-Grant
Re: [VOTE] merge lucene/solr development (take 3)
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hey Yonik,
>> However, like I said it seems to be like
>> the discussion of the real issues is only happening recently over the past
>> few days.
>
> This certainly isn't new territory for lucene/solr devs though - the
> issue of what belongs in Solr and what belongs in Lucene, and problems
> around pulling out schema and faceting and putting it in Lucene have
> come up before (also in lengthy threads).
I hear ya. I've seen some on solr-{user|dev}@ within the past months.
Cheers,
Chris
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: Chris.Mattmann@jpl.nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Yonik Seeley <ys...@gmail.com>.
On Tue, Mar 9, 2010 at 11:00 AM, Mattmann, Chris A (388J)
<ch...@jpl.nasa.gov> wrote:
> However, like I said it seems to be like
> the discussion of the real issues is only happening recently over the past
> few days.
This certainly isn't new territory for lucene/solr devs though - the
issue of what belongs in Solr and what belongs in Lucene, and problems
around pulling out schema and faceting and putting it in Lucene have
come up before (also in lengthy threads).
-Yonik
RE: [VOTE] merge lucene/solr development (take 3)
Posted by "Granroth, Neal V." <ne...@thermofisher.com>.
On Tue, Mar 9, 2010 at 10:01 AM, Mattmann, Chris A (388J)
<ch...@jpl.nasa.gov> wrote:
> I think the point that you and some others are
> missing is that JARs are not the only artifact of a system.
This is the critical point. The Solr and Lucene sources must be kept seprate for those of us that reference the Lucene source but have no use whatsoever for the JARs or the Solr source.
- Neal
Re: [VOTE] merge lucene/solr development (take 3)
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
> On Mar 9, 2010, at 9:48 AM, Mattmann, Chris A (388J) wrote:
>
>> Hey Grant,
>>
>> On 3/9/10 5:49 AM, "Grant Ingersoll" <gs...@apache.org> wrote:
>>
>>> For that matter, why do we even need to have this discussion at all? Most
>>> of
>>> us Solr committers are Lucene committers. We can simply start committing
>>> Solr
>>> code to Lucene such that in 6 months the whole discussion is moot and the
>>> three committers on Solr who aren't Lucene committers can earn their Lucene
>>> merit very quickly by patching the "Solr" portion of Lucene.
>>
>> Sure, if folks agree on those patches and the community finds them useful,
>> and the patches follow the dev process of Lucene(-java), then so be it.
>> However, it seems like this could have been done already, no? Many of the
>> things you and others have discussed merging have been around for a while
>> besides spatial. Is it simply developers/resources that is lacking in
>> Lucene(-java) and time? Or are there other reasons? It sounds to me based on
>> the desire to sync up tests, to follow the same release schedule/etc., that
>> there are in fact, other reasons.
>
> Um, I'm a committer. I've earned the right to apply patches that fit with the
> project and I've earned the merit to make that decision. So have all the
> other committers. Besides the fact, all I would be committing are the things
> people have already expressed an interest in anyway.
Then it's not an issue, right? Additionally, you didn't really answer my
question to what the cause of it not happening is (resources/time/process?)
>
>>
>>> We can move all
>>> the code to it's appropriate place, add a contrib module for the WAR stuff
>>> and
>>> the response writers and voila, Solr is in Lucene, the dev mailing lists
>>> have
>>> merged by the fact that Solr dev would be defunct and all of the proposals
>>> in
>>> this vote are implemented simply by employing our commit privileges in a
>>> concerted way. Yet, somehow, me thinks that isn't a good solution either,
>>> right? Yet it is perfectly "legal" and is just as valid a solution as the
>>> "poaching" solution and in a lot of ways seems to be what Chris is
>>> proposing.
>>
>> Whether or not what you're saying is good or what I'm saying is good or not
>> will be decided by the community within Lucene(-java), as well as the one
>> within Solr. All I'm for is not circumventing that process, in any
>> direction. If what you suggest above happens in a concise, traceable,
>> beneficial way to both projects and communities, then I'm for that.
>
> No one is circumventing any process and the implication is just wrong. We are
> having the discussion. But even so, as a committer, my job is to work within
> community to fix/improve the code. Right now, I see lots of room for
> improvement in Lucene by integrating some of those things from Solr (and
> Nutch) while keeping Lucene, Solr and Nutch whole from an end user
> perspective. At the same time, I want to see Solr and Nutch whole. Any
> other implication is simply wrong.
Sweeping proposals with TBDs leave room for implications. Smaller, concrete
steps do not.
>
>>
>> At the same time, I also favor insulation wherever possible and I personally
>> like the separation of the 2 projects. I have built 10s of projects that
>> have simply used Lucene as an API and had no need for Solr, and I've built
>> 10s of projects where Solr made perfect sense.
>
> And how at all would those 10 projects be affected at all? Please read the
> proposal again. It's not like there is going to be some uber JAR.
I think the point that you and some others are missing is that JARs are not
the only artifact of a system. Just as you develop in Lucene "officially" as
an ASF committer for Lucene(-java), and just as you and others develop in
Solr "officially" as Solr ASF committers, it doesn't mean others don't also
develop using the same code on their own projects. JARs are not the only
artifact that is being reused.
> I won't
> let it happen as I have more than 10 projects that are pure Lucene. Part of
> my day job is supporting Lucene. I've spent the past 5 years of my life
> donating to Lucene, and so have many others. The argument is simply invalid
> and has been refuted so many times now by ALL those who actually do the work
> that I don't understand why you insist on bringing it up over and over again.
It's extremely unclear to me about how you can be so sure about how
something will work when there have been many questions, the proposal itself
includes TBDs or things as Yonik put it that "will be figured out later."
>
>
>> So, I appreciate their
>> separation. I also have a lot of experience in these types of situations as
>> I've been involved in 2-3 of them over the past few years at NASA in terms
>> of maintaining separation and merging projects/etc. There are quite a few
>> lessons learned that I have been trying to share but that have seemingly not
>> really been appreciated and that have been in my mind dismissed, rather than
>> discussed, through this process.
>
> I'd hardly say they've been dismissed. This isn't about you, it's about what
> is best for the project. You have one opinion, that, by the face of the
> votes, is in the minority.
Well I'm sorry you feel that way. However, like I said it seems to be like
the discussion of the real issues is only happening recently over the past
few days. There has been a lot of effort to push this through before then.
> It doesn't make the majority right and you wrong.
Appreciate it, in fact I'm not looking to assign right and wrong.
> In fact, those in the majority are trying to answer your concerns and come up
> with a better suggestion.
The recent discussions have been picked up and I am feeling like we're
starting to discuss the issues so that's a good thing.
Cheers,
Chris
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: Chris.Mattmann@jpl.nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Grant Ingersoll <gs...@apache.org>.
On Mar 9, 2010, at 9:48 AM, Mattmann, Chris A (388J) wrote:
> Hey Grant,
>
> On 3/9/10 5:49 AM, "Grant Ingersoll" <gs...@apache.org> wrote:
>
>> For that matter, why do we even need to have this discussion at all? Most of
>> us Solr committers are Lucene committers. We can simply start committing Solr
>> code to Lucene such that in 6 months the whole discussion is moot and the
>> three committers on Solr who aren't Lucene committers can earn their Lucene
>> merit very quickly by patching the "Solr" portion of Lucene.
>
> Sure, if folks agree on those patches and the community finds them useful,
> and the patches follow the dev process of Lucene(-java), then so be it.
> However, it seems like this could have been done already, no? Many of the
> things you and others have discussed merging have been around for a while
> besides spatial. Is it simply developers/resources that is lacking in
> Lucene(-java) and time? Or are there other reasons? It sounds to me based on
> the desire to sync up tests, to follow the same release schedule/etc., that
> there are in fact, other reasons.
Um, I'm a committer. I've earned the right to apply patches that fit with the project and I've earned the merit to make that decision. So have all the other committers. Besides the fact, all I would be committing are the things people have already expressed an interest in anyway.
>
>> We can move all
>> the code to it's appropriate place, add a contrib module for the WAR stuff and
>> the response writers and voila, Solr is in Lucene, the dev mailing lists have
>> merged by the fact that Solr dev would be defunct and all of the proposals in
>> this vote are implemented simply by employing our commit privileges in a
>> concerted way. Yet, somehow, me thinks that isn't a good solution either,
>> right? Yet it is perfectly "legal" and is just as valid a solution as the
>> "poaching" solution and in a lot of ways seems to be what Chris is proposing.
>
> Whether or not what you're saying is good or what I'm saying is good or not
> will be decided by the community within Lucene(-java), as well as the one
> within Solr. All I'm for is not circumventing that process, in any
> direction. If what you suggest above happens in a concise, traceable,
> beneficial way to both projects and communities, then I'm for that.
No one is circumventing any process and the implication is just wrong. We are having the discussion. But even so, as a committer, my job is to work within community to fix/improve the code. Right now, I see lots of room for improvement in Lucene by integrating some of those things from Solr (and Nutch) while keeping Lucene, Solr and Nutch whole from an end user perspective. At the same time, I want to see Solr and Nutch whole. Any other implication is simply wrong.
>
> At the same time, I also favor insulation wherever possible and I personally
> like the separation of the 2 projects. I have built 10s of projects that
> have simply used Lucene as an API and had no need for Solr, and I've built
> 10s of projects where Solr made perfect sense.
And how at all would those 10 projects be affected at all? Please read the proposal again. It's not like there is going to be some uber JAR. I won't let it happen as I have more than 10 projects that are pure Lucene. Part of my day job is supporting Lucene. I've spent the past 5 years of my life donating to Lucene, and so have many others. The argument is simply invalid and has been refuted so many times now by ALL those who actually do the work that I don't understand why you insist on bringing it up over and over again.
> So, I appreciate their
> separation. I also have a lot of experience in these types of situations as
> I've been involved in 2-3 of them over the past few years at NASA in terms
> of maintaining separation and merging projects/etc. There are quite a few
> lessons learned that I have been trying to share but that have seemingly not
> really been appreciated and that have been in my mind dismissed, rather than
> discussed, through this process.
I'd hardly say they've been dismissed. This isn't about you, it's about what is best for the project. You have one opinion, that, by the face of the votes, is in the minority. It doesn't make the majority right and you wrong. In fact, those in the majority are trying to answer your concerns and come up with a better suggestion. This is in fact the process and it is how the ASF works. This is one of the great things about the Lucene community. We have real discussions about the issues.
-Grant
Re: [VOTE] merge lucene/solr development (take 3)
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hey Grant,
On 3/9/10 5:49 AM, "Grant Ingersoll" <gs...@apache.org> wrote:
> For that matter, why do we even need to have this discussion at all? Most of
> us Solr committers are Lucene committers. We can simply start committing Solr
> code to Lucene such that in 6 months the whole discussion is moot and the
> three committers on Solr who aren't Lucene committers can earn their Lucene
> merit very quickly by patching the "Solr" portion of Lucene.
Sure, if folks agree on those patches and the community finds them useful,
and the patches follow the dev process of Lucene(-java), then so be it.
However, it seems like this could have been done already, no? Many of the
things you and others have discussed merging have been around for a while
besides spatial. Is it simply developers/resources that is lacking in
Lucene(-java) and time? Or are there other reasons? It sounds to me based on
the desire to sync up tests, to follow the same release schedule/etc., that
there are in fact, other reasons.
> We can move all
> the code to it's appropriate place, add a contrib module for the WAR stuff and
> the response writers and voila, Solr is in Lucene, the dev mailing lists have
> merged by the fact that Solr dev would be defunct and all of the proposals in
> this vote are implemented simply by employing our commit privileges in a
> concerted way. Yet, somehow, me thinks that isn't a good solution either,
> right? Yet it is perfectly "legal" and is just as valid a solution as the
> "poaching" solution and in a lot of ways seems to be what Chris is proposing.
Whether or not what you're saying is good or what I'm saying is good or not
will be decided by the community within Lucene(-java), as well as the one
within Solr. All I'm for is not circumventing that process, in any
direction. If what you suggest above happens in a concise, traceable,
beneficial way to both projects and communities, then I'm for that.
At the same time, I also favor insulation wherever possible and I personally
like the separation of the 2 projects. I have built 10s of projects that
have simply used Lucene as an API and had no need for Solr, and I've built
10s of projects where Solr made perfect sense. So, I appreciate their
separation. I also have a lot of experience in these types of situations as
I've been involved in 2-3 of them over the past few years at NASA in terms
of maintaining separation and merging projects/etc. There are quite a few
lessons learned that I have been trying to share but that have seemingly not
really been appreciated and that have been in my mind dismissed, rather than
discussed, through this process.
Cheers,
Chris
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: Chris.Mattmann@jpl.nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Grant Ingersoll <gs...@apache.org>.
On Mar 9, 2010, at 8:21 AM, Michael McCandless wrote:
> On Tue, Mar 9, 2010 at 7:21 AM, Grant Ingersoll <gs...@apache.org> wrote:
>
>>> If we had that freedom ("poaching is perfectly fine"), then,
>>> interested devs could freely "refactor" across sub projects.
>>
>> As someone who works on both, I don't think it is fine. Just look at the function query mess. Just look at the version mess. It's very frustrating as a developer and it makes me choose between two projects that I happen to like equally, but for different reasons. If I worked on Nutch, I would feel the same way.
>
> But... Lucene should poach from external (eg non-Apache) projects, if
> the license works?
>
> Ie if some great analyzer is out there, and Robert spots it, and the
> license works, we should poach it? (In fact he just did this w/
> Andrzej's Polish stemmer ;) ).
I'd prefer "donate" to poach, but, realize that isn't always the case.
>
> So we have something of a double standard...
>
> And, ironically, I think it's the fact that there's so much committer
> overlap between Solr and Lucene that is causing this antagonism
> towards poaching.
>
> When in fact I think poaching, at a wider scale (across unrelated
> projects) is a very useful means for any healthy open source software
> to evolve.
>
> Why should Lucene be prevented from having a useful feature just
> because Solr happened to create it first?
But why should I be forced to maintain two versions due to some arbitrary code separation? And why should you force a good chunk of us to do a whole lot of extra work simply because of some arbitrary code separation? Here, it is the Lucene PMC that releases code and it is just silly that with all of this overlap at the committer level we still have this duplication. I can't speak for the external projects (I don't believe any of them have even responded here other than Jackrabbit), but if they don't like it, they should get more involved in the community and work to be committers.
At any rate, this is exactly why merging makes sense. You would no longer have this issue of "first". I would no longer have to choose where to add my spatial work based on some arbitrary line that someone drew in the sand that isn't all that pertinent anymore given the desires of most in the community to blur that line. It would be available to everyone.
For that matter, why do we even need to have this discussion at all? Most of us Solr committers are Lucene committers. We can simply start committing Solr code to Lucene such that in 6 months the whole discussion is moot and the three committers on Solr who aren't Lucene committers can earn their Lucene merit very quickly by patching the "Solr" portion of Lucene. We can move all the code to it's appropriate place, add a contrib module for the WAR stuff and the response writers and voila, Solr is in Lucene, the dev mailing lists have merged by the fact that Solr dev would be defunct and all of the proposals in this vote are implemented simply by employing our commit privileges in a concerted way. Yet, somehow, me thinks that isn't a good solution either, right? Yet it is perfectly "legal" and is just as valid a solution as the "poaching" solution and in a lot of ways seems to be what Chris is proposing.
-Grant
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Michael McCandless <lu...@mikemccandless.com>.
On Tue, Mar 9, 2010 at 7:21 AM, Grant Ingersoll <gs...@apache.org> wrote:
>> If we had that freedom ("poaching is perfectly fine"), then,
>> interested devs could freely "refactor" across sub projects.
>
> As someone who works on both, I don't think it is fine. Just look at the function query mess. Just look at the version mess. It's very frustrating as a developer and it makes me choose between two projects that I happen to like equally, but for different reasons. If I worked on Nutch, I would feel the same way.
But... Lucene should poach from external (eg non-Apache) projects, if
the license works?
Ie if some great analyzer is out there, and Robert spots it, and the
license works, we should poach it? (In fact he just did this w/
Andrzej's Polish stemmer ;) ).
So we have something of a double standard...
And, ironically, I think it's the fact that there's so much committer
overlap between Solr and Lucene that is causing this antagonism
towards poaching.
When in fact I think poaching, at a wider scale (across unrelated
projects) is a very useful means for any healthy open source software
to evolve.
Why should Lucene be prevented from having a useful feature just
because Solr happened to create it first?
Mike
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Andrzej Bialecki <ab...@getopt.org>.
On 2010-03-09 13:21, Grant Ingersoll wrote:
>
> On Mar 9, 2010, at 5:40 AM, Michael McCandless wrote:
>> If we had that freedom ("poaching is perfectly fine"), then,
>> interested devs could freely "refactor" across sub projects.
>>
>
> As someone who works on both, I don't think it is fine. Just look at
> the function query mess. Just look at the version mess. It's very
> frustrating as a developer and it makes me choose between two
> projects that I happen to like equally, but for different reasons.
> If I worked on Nutch, I would feel the same way.
The mess happened afaik due to a lack of communication and NIH. It's
true that
if Sol had been merged with Lucene then only one version would have won.
This may still happen with enough cooperation on both sides, even
without the merge.
Anyway, my vote hovers near 0 either way, as you said it's different for
Nutch.
--
Best regards,
Andrzej Bialecki <><
___. ___ ___ ___ _ _ __________________________________
[__ || __|__/|__||\/| Information Retrieval, Semantic Web
___|||__|| \| || | Embedded Unix, System Integration
http://www.sigram.com Contact: info at sigram dot com
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Grant Ingersoll <gs...@apache.org>.
On Mar 9, 2010, at 5:40 AM, Michael McCandless wrote:
> On Tue, Mar 9, 2010 at 5:10 AM, Andrzej Bialecki <ab...@getopt.org> wrote:
>
>> Re: Nutch components - those that are reusable in Lucene or Solr
>> contexts eventually find their way to respective projects, witness
>> e.g. CommonGrams.
>
> In fact I think this is a great example -- as far as I can tell,
> CommonGrams was poached from Nutch, into Solr, and then was
> nurtured/improved in both projects separately right?
>
> So.... can/should we freely poach across all our sub projects?
>
> It has obvious downsides (it's essentially a fork that will confuse
> those users that use both Solr & Lucene, in the short term, until
> things "stabilize" into a clean refactoring; it's double the dev; we
> must re-sync with time; etc.).
>
> But it has a massive upside: it means we don't rely only on "push"
> (Solr devs to push into Lucene or vice/versa). We can also use "pull"
> (Lucene devs can pull pieces from Nutch/Solr into Lucene). It becomes
> a 2-way street for "properly" factoring our shared code with time.
>
> If we had that freedom ("poaching is perfectly fine"), then,
> interested devs could freely "refactor" across sub projects.
>
As someone who works on both, I don't think it is fine. Just look at the function query mess. Just look at the version mess. It's very frustrating as a developer and it makes me choose between two projects that I happen to like equally, but for different reasons. If I worked on Nutch, I would feel the same way.
Also, I do look at Solr/Lucene differently. There is almost complete overlap in the committer base. Nutch is not that way, nor is any other project. I simply don't think Lucene will end up being geared toward Solr because there are so many users of Lucene here they will prevent that from happening.
-Grant
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Michael McCandless <lu...@mikemccandless.com>.
On Tue, Mar 9, 2010 at 6:09 AM, Andrzej Bialecki <ab...@getopt.org> wrote:
> On 2010-03-09 11:40, Michael McCandless wrote:
>>
>> On Tue, Mar 9, 2010 at 5:10 AM, Andrzej Bialecki<ab...@getopt.org> wrote:
>>
>> So.... can/should we freely poach across all our sub projects?
>
> In my opinion: with proper attribution, by all means!
+1
I think shifting to this ("poaching is fine") would be healthy for all
subs. Pull & push would let code flow freely two-way across the
projects.
>>> Re: Nutch components - those that are reusable in Lucene or Solr
>>> contexts eventually find their way to respective projects, witness
>>> e.g. CommonGrams.
>>
>> In fact I think this is a great example -- as far as I can tell,
>> CommonGrams was poached from Nutch, into Solr, and then was
>> nurtured/improved in both projects separately right?
>
> Right. In fact, Nutch would like to eventually delegate indexing solely to
> Solr, at which point we will reuse the CommonGrams from Solr.
Exactly -- this is how the refactoring would play out with time.
Begins with poaching but eventually winds up with a single source
again (just "moved" from one sub to another).
Ie, if Lucene poached all Solr analyzers, as well as its own core
analyzers, moving all analyzers into contrib/analyzers, then
eventually Solr/Nutch would just use Lucene's contrib/analyzers as the
single source.
Others (whoever has the itch/time) can poach function queries, facets,
etc.
The freedom to poach gives us a powerful push AND pull tool to make
this refactoring gradually over time.
Something interesting can be born in Solr (just because that's where
the itch first arrived) and then freely poached & refactored later by
someone wearing a Lucene dev hat.
> So, I'm all for the poaching ;) but IMHO this doesn't necessitate the merge,
> just refactoring, push/pull and the right mindset.
In fact in my opinion, if we are free to poach across all subs, we
don't need to merge -- poaching solves the primary pain I feel with
our subs now (splintering of code/dev across the subs,
preventing/frustrating people like Robert who put in tons of effort to
improve our analyzers only to see patches languish).
Mike
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Andrzej Bialecki <ab...@getopt.org>.
On 2010-03-09 11:40, Michael McCandless wrote:
> On Tue, Mar 9, 2010 at 5:10 AM, Andrzej Bialecki<ab...@getopt.org> wrote:
>
>> Re: Nutch components - those that are reusable in Lucene or Solr
>> contexts eventually find their way to respective projects, witness
>> e.g. CommonGrams.
>
> In fact I think this is a great example -- as far as I can tell,
> CommonGrams was poached from Nutch, into Solr, and then was
> nurtured/improved in both projects separately right?
Right. In fact, Nutch would like to eventually delegate indexing solely
to Solr, at which point we will reuse the CommonGrams from Solr.
>
> So.... can/should we freely poach across all our sub projects?
In my opinion: with proper attribution, by all means!
>
> It has obvious downsides (it's essentially a fork that will confuse
> those users that use both Solr& Lucene, in the short term, until
> things "stabilize" into a clean refactoring; it's double the dev; we
> must re-sync with time; etc.).
>
> But it has a massive upside: it means we don't rely only on "push"
> (Solr devs to push into Lucene or vice/versa). We can also use "pull"
> (Lucene devs can pull pieces from Nutch/Solr into Lucene). It becomes
> a 2-way street for "properly" factoring our shared code with time.
>
> If we had that freedom ("poaching is perfectly fine"), then,
> interested devs could freely "refactor" across sub projects.
>
> Not having this freedom today, and not having merged dev, is stunting
> both Solr& Lucene's growth.
Erhm.. don't we have this freedom already??? Another example is
TimeLimitedCollector - poaching _is_ perfectly fine as far as I'm
concerned. All projects are under the same license, often also share the
same people, so I see no reason not to share freely where it makes sense
from technical POV, though we may sometimes succumb to the NIH syndrome ;)
This push/pull between the projects reminds me of discussions with my
clients when I try to convince them to open-source some generic
functionality: long-term you can only benefit greatly from getting rid
of generic code, if there's a lively community with focus just on that
functionality - you don't have to maintain it and you reap the benefits
of external development, and you can focus on developing of what's
unique to your project.
So, I'm all for the poaching ;) but IMHO this doesn't necessitate the
merge, just refactoring, push/pull and the right mindset.
--
Best regards,
Andrzej Bialecki <><
___. ___ ___ ___ _ _ __________________________________
[__ || __|__/|__||\/| Information Retrieval, Semantic Web
___|||__|| \| || | Embedded Unix, System Integration
http://www.sigram.com Contact: info at sigram dot com
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Michael McCandless <lu...@mikemccandless.com>.
On Tue, Mar 9, 2010 at 5:10 AM, Andrzej Bialecki <ab...@getopt.org> wrote:
> Re: Nutch components - those that are reusable in Lucene or Solr
> contexts eventually find their way to respective projects, witness
> e.g. CommonGrams.
In fact I think this is a great example -- as far as I can tell,
CommonGrams was poached from Nutch, into Solr, and then was
nurtured/improved in both projects separately right?
So.... can/should we freely poach across all our sub projects?
It has obvious downsides (it's essentially a fork that will confuse
those users that use both Solr & Lucene, in the short term, until
things "stabilize" into a clean refactoring; it's double the dev; we
must re-sync with time; etc.).
But it has a massive upside: it means we don't rely only on "push"
(Solr devs to push into Lucene or vice/versa). We can also use "pull"
(Lucene devs can pull pieces from Nutch/Solr into Lucene). It becomes
a 2-way street for "properly" factoring our shared code with time.
If we had that freedom ("poaching is perfectly fine"), then,
interested devs could freely "refactor" across sub projects.
Not having this freedom today, and not having merged dev, is stunting
both Solr & Lucene's growth.
Mike
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Andrzej Bialecki <ab...@getopt.org>.
On 2010-03-09 05:24, Grant Ingersoll wrote:
> In the end, for me anyway, the current separation hurts Lucene a good
> deal as much as it hurts Solr, if not more. Likewise, I wish some of
> the Nutch committers would speak up, as I'm sure there are some
> pieces of Nutch that are "core" too, but for a lack of visibility
> down lower in Lucene committer wise, especially as Nutch as looking
> to refactor into more components. Obviously not the crawling stuff,
> but perhaps some of Nutch's analyzer and low level Lucene stuff would
> make sense to be pushed lower in the stack.
With my Nutch hat on, I'm -0 to this current vote.
If the primary devs really insist on going this way, so be it, but I
think that long-term it brings more challenges than it solves, among
them the danger that Lucene ceases to be a general purpose Java search
library (where being Java-centric is nothing wrong) and caters too much
to Solr's needs at the expense of other projects.
Re: Nutch components - those that are reusable in Lucene or Solr
contexts eventually find their way to respective projects, witness e.g.
CommonGrams. Other stuff makes sense only in Nutch and it would be a
mistake to push it by force to become e.g. a contrib module in Lucene if
it's not applicable to a majority of Lucene community. Refactoring to
increase reuse doesn't mean we have to merge Nutch with Lucene, it's
just a cleaner separation of concerns. Anyway, that's not the topic of
the current vote.
--
Best regards,
Andrzej Bialecki <><
___. ___ ___ ___ _ _ __________________________________
[__ || __|__/|__||\/| Information Retrieval, Semantic Web
___|||__|| \| || | Embedded Unix, System Integration
http://www.sigram.com Contact: info at sigram dot com
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Mike Klaas <mi...@gmail.com>.
On Mon, Mar 8, 2010 at 8:24 PM, Grant Ingersoll <gs...@apache.org> wrote:
> It should also be noted that a good chunk of the Solr committers are already Lucene committers, and of the remaining there are: Bill Au, Mike Klaas, Ryan McKinley, Shalin and Noble. Mike has been inactive for quite some time (and has elected to go emeritus even though it's not marked on the page) and and Ryan, Shalin and Noble already contribute to Lucene in various parts (AFAICT), so to me it's not a big stretch to say bring them into the fold. I haven't tracked Bill's involvement, but I also know Bill and trust he knows what it means to be a committer, i.e. he knows as much what not to touch as what to touch. Of course, we can do a separate vote on that if that helps satisfy Chris' issue on the committers.
I don't expect that it makes much of a difference either way, but feel
free to leave me out of the Lucene auto-committership should that be
an issue. I don't expect to become an active committer in the near
future.
> In the end, for me anyway, the current separation hurts Lucene a good deal as much as it hurts Solr, if not more.
Agreed.
The central issue is that Solr committers often work on features which
are core to "full-text search" rather than "an HTTP full-text search
server". The parts of the features related to full-text search would
improve Lucene (the fact that Solr is used by people as a library in
an embedded context provides glaring testament to that). But they
don't end up there, due to the friction of simultaneously developing a
feature in two projects that aren't synchronized.
Does this happen often? It does. I'd say over 50% of my non-trivial
changes to Solr could have been useful in Lucene. (This is probably
not representative of the entire Solr committerdom, of course.) In
fact, the *very first patch* I developed for Solr was adding in hit
highlighting, and I ended up copy&pasting a class from contrib
Highlighter to extend it. Of course, I was a committer for neither
project at the time; I don't want to think about the logistics of
trying to submit patches to both projects which are so inter-dependent
(and would pretty much rely on review by someone who was a committer
on both projects anyway).
I think someone could make an argument that I should have been more
conscientious about submitting patches to Lucene, and they are
probably right. But, I ultimately wasn't, and many other committers
weren't as well (even those who were committers for both projects),
and so we've ended up in this situation where we really have *three*
projects: Lucene, the java search library, Lucene+, the set of
improvements and extensions to Lucene which could be in Lucene itself
and developed by the same people as Lucene, and Solr, the HTTP server
around Lucene.
The Lucene Project as a whole would benefit if this situation were
improved. Auto-syncing Lucene-trunk with Solr would bring an
improvement, but it isn't a fundamental solution and has its own set
of problems. The current proposal seems reasonable, but I worry about
the level of contention it is receiving.
+0
-Mike
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Mark Miller <ma...@gmail.com>.
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.
>
> http://www.apache.org/foundation/voting.html
>
> --
> - Mark
>
>
Re: [VOTE] merge lucene/solr development (take 3)
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hi Dennis,
> It was late when I wrote that, maybe my analogy was not clear. You are
> echoing what I was trying to say that that Hadoop != Nutch and it
> wouldn't have been as useful if it had only ever been viewed that way.
> I think part of this discussion is looking at Lucene as needing things
> that are beyond it. That should be other projects.
>
> Here is my logic FWIW:
>
> Solr depends on Lucene.
> Many other projects depend critically on Lucene
> Not all of those projects depend on Solr
> Solr and Lucene have different responsibilities
> Therefore Solr != Lucene and should not merge dev.
>
> Should Solr work more closely to move some of it pieces into Lucene if
> they are applicable. Yes. To me that doesn't mean merge.
+1, my sentiments exactly.
Cheers,
Chris
>
> Dennis
>
> Ted Dunning wrote:
>> This logic escapes me.
>>
>> Nutch hatched Hadoop. Hadoop was perceived to be of much broader utility
>> than just for nutch so it was made more general and a separate project was
>> formed. Hadoop does not depend on Nutch.
>>
>> Lucene existed. Solr was built to make it easier to use Lucene. The
>> developers of Solr built a bunch of stuff that was specific to server-ness
>> and a bunch of stuff that would have general utility to many Lucene
>> developers. Solr depends critically on Lucene and can be seen as a Lucene
>> wrapper.
>>
>> How does this analogy fit together? Is it supposed to be Hadoop is to Nutch
>> as Solr is to Lucene? That seems so clearly wrong it can't be what you were
>> saying.
>>
>> On Mon, Mar 8, 2010 at 10:10 PM, Dennis Kubes <ku...@apache.org> wrote:
>>
>>>> 3) For new Lucene features, there would be an effort to integrate it
>>>> into Solr.
>>> No. Because by specializing towards Solr, or Nutch, or any of the hundred
>>> other applications that use Lucene, it looses its general applicability.
>>> Where would Hadoop be if it never made it past Nutch?
>>>
>>
>
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: Chris.Mattmann@jpl.nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Dennis Kubes <ku...@apache.org>.
It was late when I wrote that, maybe my analogy was not clear. You are
echoing what I was trying to say that that Hadoop != Nutch and it
wouldn't have been as useful if it had only ever been viewed that way.
I think part of this discussion is looking at Lucene as needing things
that are beyond it. That should be other projects.
Here is my logic FWIW:
Solr depends on Lucene.
Many other projects depend critically on Lucene
Not all of those projects depend on Solr
Solr and Lucene have different responsibilities
Therefore Solr != Lucene and should not merge dev.
Should Solr work more closely to move some of it pieces into Lucene if
they are applicable. Yes. To me that doesn't mean merge.
Dennis
Ted Dunning wrote:
> This logic escapes me.
>
> Nutch hatched Hadoop. Hadoop was perceived to be of much broader utility
> than just for nutch so it was made more general and a separate project was
> formed. Hadoop does not depend on Nutch.
>
> Lucene existed. Solr was built to make it easier to use Lucene. The
> developers of Solr built a bunch of stuff that was specific to server-ness
> and a bunch of stuff that would have general utility to many Lucene
> developers. Solr depends critically on Lucene and can be seen as a Lucene
> wrapper.
>
> How does this analogy fit together? Is it supposed to be Hadoop is to Nutch
> as Solr is to Lucene? That seems so clearly wrong it can't be what you were
> saying.
>
> On Mon, Mar 8, 2010 at 10:10 PM, Dennis Kubes <ku...@apache.org> wrote:
>
>>> 3) For new Lucene features, there would be an effort to integrate it
>>> into Solr.
>> No. Because by specializing towards Solr, or Nutch, or any of the hundred
>> other applications that use Lucene, it looses its general applicability.
>> Where would Hadoop be if it never made it past Nutch?
>>
>
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Ted Dunning <te...@gmail.com>.
This logic escapes me.
Nutch hatched Hadoop. Hadoop was perceived to be of much broader utility
than just for nutch so it was made more general and a separate project was
formed. Hadoop does not depend on Nutch.
Lucene existed. Solr was built to make it easier to use Lucene. The
developers of Solr built a bunch of stuff that was specific to server-ness
and a bunch of stuff that would have general utility to many Lucene
developers. Solr depends critically on Lucene and can be seen as a Lucene
wrapper.
How does this analogy fit together? Is it supposed to be Hadoop is to Nutch
as Solr is to Lucene? That seems so clearly wrong it can't be what you were
saying.
On Mon, Mar 8, 2010 at 10:10 PM, Dennis Kubes <ku...@apache.org> wrote:
> > 3) For new Lucene features, there would be an effort to integrate it
> > into Solr.
>
> No. Because by specializing towards Solr, or Nutch, or any of the hundred
> other applications that use Lucene, it looses its general applicability.
> Where would Hadoop be if it never made it past Nutch?
>
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Dennis Kubes <ku...@apache.org>.
True. There are features that aren't useful for every search. But the
features in Lucene are meant for full text search, not for serving full
text search. Maybe faceting was a bad example, it was the first that
came to mind and defines what many people use Solr for.
Lucene IMO is a full text search *library*. When features are added to
it, that is the perspective that should be taken. Does it work as a
general purpose indexing library?
I am all for adding in *very* useful features, especially when someone
else has done the work, as long as they fall into that boundary. But
Solr isn't a search library, it is a search server. Aren't those
separate responsibilities? Should we take some of the things out of
Solr and put them into Lucene? Absolutely. Should we merge to do this.
No, not IMO.
And Power is good in the right hands, but that is another discussion :)
Dennis
Ted Dunning wrote:
> There are scads of features of Lucene that are not useful for all
> applications (payloads, for one example, back compatibility for another).
>
> The point is that the option to use faceting or not would be *very* useful
> for all search applications. Power is good, especially since somebody else
> has done the work already.
>
> On Mon, Mar 8, 2010 at 10:10 PM, Dennis Kubes <ku...@apache.org> wrote:
>
>> Faceting for example, great feature, but not useful in every full text
>> search.
>>
>
Re: [VOTE] merge lucene/solr development (take 3) - can we take a
pause?
Posted by Ian Holsman <li...@holsman.net>.
guys.. there is a lot of discussion going on.
and a awful lot of voting.
and as a interesting onlooker, I am really confused about what exactly
the vote is for.. there are so many interjections and clarifications
that I'm not sure
what is going on
can we stop calling for a vote for say 72 hours or a week, and just
discuss it a bit, get the proposal on what you want to be done clarified
and then call for a vote?
it's not like there is a house on fire, and this really seems like it is
getting pushed.
On 3/9/10 5:46 PM, Ted Dunning wrote:
> There are scads of features of Lucene that are not useful for all
> applications (payloads, for one example, back compatibility for another).
>
> The point is that the option to use faceting or not would be *very* useful
> for all search applications. Power is good, especially since somebody else
> has done the work already.
>
> On Mon, Mar 8, 2010 at 10:10 PM, Dennis Kubes<ku...@apache.org> wrote:
>
>
>> Faceting for example, great feature, but not useful in every full text
>> search.
>>
>>
>
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Ted Dunning <te...@gmail.com>.
There are scads of features of Lucene that are not useful for all
applications (payloads, for one example, back compatibility for another).
The point is that the option to use faceting or not would be *very* useful
for all search applications. Power is good, especially since somebody else
has done the work already.
On Mon, Mar 8, 2010 at 10:10 PM, Dennis Kubes <ku...@apache.org> wrote:
> Faceting for example, great feature, but not useful in every full text
> search.
>
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Dennis Kubes <ku...@apache.org>.
I believe this is a question of identity. What is Lucene?
IMO Lucene is a full text search library, that is it's purpose. It
isn't trying to be a search server or a search engine. It is easy to
include as a library and is used on everything from embedded servers to
www search engines.
Quoting from Yonik's previous posting:
> Some in Lucene development have expressed a desire to make Lucene more
> of a complete solution, rather than just a core full-text search
> library... things like a data schema, faceting, etc. The Lucene
> project already has an enterprise search platform with these
> features... that's Solr.
So is Lucene a full text search library or is it something different?
And isn't that something different already Solr? Why should they be the
same thing when their goals aren't the same?
> Trying to pull popular pieces out of Solr
> makes life harder for Solr developers, brings our projects into
> conflict, and is often unsuccessful (witness the largely failed
> migration of FunctionQueries from Solr to Lucene).
I feel for you, really. I remember trying to develop in Nutch on Hadoop
0.04. But the logic is not correct. Just because Solr wants X feature
and Solr uses Lucene != everyone who uses Lucene wants X. Faceting for
example, great feature, but not useful in every full text search.
> For Lucene to achieve the ultimate in usability for users, it can't
> require Java experience... it needs higher level abstractions provided
> by Solr.
I don't believe this to be true. If the Lucene community had wanted
very general language agnostic search, it would have happened by now.
Lucene is a Java API. Solr on the other hand is a server and therefore
should be language agnostic.
> The other benefit to Lucene would be to bring features to developers
> much sooner... Solr has had features years before they were developed
> in Lucene, and currently has more developers working with it.
"We have more developers than you do" isn't a valid reason to merge,
especially in open source software. Maybe in the corporate world. IMO
if Solr has more developers and want some architecture changed in Lucene
and it is to the benefit of the entire Lucene community, then those
changes can be proposed and voted upon.
> Esp with Solr not using Lucene trunk, if a Solr developer wants a
> feature quickly, they cannot add it to Lucene (even if it might make
> sense there) since that introduces a big unpredictable lag
Solr has the option of not using Lucene. If something needs to go into
Lucene, it should be voted on and support all of the different uses for
Lucene. As a friend told me recently, specialization is for insects.
> 1) Solr would go back to using Lucene's trunk
Use trunk, don't use trunk. That is up to the Solr project. It
shouldn't influence Lucene's behavior.
> 2) For new Solr features, there would be an effort to abstract it such
> that non-Solr users could use the functionality (faceting, field
> collapsing, etc)
Can you say that every feature would be applicable to a full text search
library. If not then it is beyond the core responsibilities of Lucene.
> 3) For new Lucene features, there would be an effort to integrate it
> into Solr.
No. Because by specializing towards Solr, or Nutch, or any of the
hundred other applications that use Lucene, it looses its general
applicability. Where would Hadoop be if it never made it past Nutch?
> 4) Releases would be synchronized... Lucene and Solr would release at
> the same time.
So synchronize your releases. Communicate.
I am open to listening to your responses, but all of this is to say my
vote is still currently -1.
Dennis
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Simon Willnauer <si...@googlemail.com>.
On Tue, Mar 9, 2010 at 11:54 PM, Chris Hostetter
<ho...@fucit.org> wrote:
>
> : from Solr into Lucene don't need to be in there. All of a sudden I'm agreeing
> : with Hoss about goals rather than actual steps ;) Because those points are not
> : important to this vote at all - they are more examples of what we will be able
> ...
> : This is about merging dev so we can put code where it belongs and do things
> : that can make sense - its not a vote where specific code refactorings matter
>
> This is the point where i say...
>
> AHHHHHHHHHHHHH!!!!!!! HA HA HA HA HAAAAAAA!!!!!
>
> HA!
>
> I've had relationships (with live people that i cared deeply about) that
> recieved less of my attention this all of this, and i just don't give a
> fuck anymore.
>
> I'm -1 to "the proposal" on the grounds that 150+ messages into the
> discusison, it still seems like no one has any fucking clue what it is
> we're voting on.
Thanks Chris for pointing this out! I'm somewhat lost and I can not
keep up with the amount of email regarding this "vote".
IMO if we vote on something a reply should be +1, -1 or +-0. If you
want to discuss, vote -1.
simon
>
> If anyone has any patches, releases, or a potential committers they'd like
> me to vote on please let me know -- otherwise i'm wiping my hands of the
> whole thing. I'm done with this thread, and i don't plan on reading any
> more messages posted to it. (one of the bueatiful things about Lucene:
> the community (and the PMC) are large enough that the wheels will keep
> turning and smart people will make smart choices even if close my eyes and
> stick my fingers in my ears)
>
> if you'll excuse me: i desperately need to go review some patches, and
> answer some questions on the user lists so i can ultimately finish this
> day with some sense of accomplishment.
>
>
> -Hoss
>
>
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Chris Hostetter <ho...@fucit.org>.
: from Solr into Lucene don't need to be in there. All of a sudden I'm agreeing
: with Hoss about goals rather than actual steps ;) Because those points are not
: important to this vote at all - they are more examples of what we will be able
...
: This is about merging dev so we can put code where it belongs and do things
: that can make sense - its not a vote where specific code refactorings matter
This is the point where i say...
AHHHHHHHHHHHHH!!!!!!! HA HA HA HA HAAAAAAA!!!!!
HA!
I've had relationships (with live people that i cared deeply about) that
recieved less of my attention this all of this, and i just don't give a
fuck anymore.
I'm -1 to "the proposal" on the grounds that 150+ messages into the
discusison, it still seems like no one has any fucking clue what it is
we're voting on.
If anyone has any patches, releases, or a potential committers they'd like
me to vote on please let me know -- otherwise i'm wiping my hands of the
whole thing. I'm done with this thread, and i don't plan on reading any
more messages posted to it. (one of the bueatiful things about Lucene:
the community (and the PMC) are large enough that the wheels will keep
turning and smart people will make smart choices even if close my eyes and
stick my fingers in my ears)
if you'll excuse me: i desperately need to go review some patches, and
answer some questions on the user lists so i can ultimately finish this
day with some sense of accomplishment.
-Hoss
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Mark Miller <ma...@gmail.com>.
Frankly, if you guys insist, we could drop the modularize point and take
yet another vote. If that's going to be your veto toehold, we don't need
it cluttering things up. Modularizing Lucene doesn't need to be in there
(though it already is somewhat modularized, and people plan to work
further along those lines regardless of this vote). Specific things we
would like to pull from Solr into Lucene don't need to be in there. All
of a sudden I'm agreeing with Hoss about goals rather than actual steps
;) Because those points are not important to this vote at all - they are
more examples of what we will be able to do than mandates. They are the
goodness that will come, not reasons for vetoes. (nor do I agree they
fall under the "code modication veto for a valid technical reason" anyway)
This is about merging dev so we can put code where it belongs and do
things that can make sense - its not a vote where specific code
refactorings matter at all - we don't develop and organize code with PMC
votes.
On 03/09/2010 12:40 AM, Mark Miller wrote:
> Hey Chris,
>
> see my response to Michael.
>
> But quickly,
>
> the first star is not a code change. Its procedural.
>
> the second star, and I'm sure youll have arguments with this :), is
> not something we are specifically voting on. The reason we are merging
> dev is obviously so that those changes can occur - but this vote is
> not to force those changes. Even those against the merge would like to
> see those changes. Putting more queries, querparsers, and analyzers
> into Lucene is not a controversial change :)
>
> On 03/09/2010 12:33 AM, Mattmann, Chris A (388J) wrote:
>> On 3/8/10 9:26 PM, "Mark Miller"<ma...@gmail.com> wrote:
>>
>>> 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.
>> Ummm, that's not true.
>>
>> Mike's last proposal listed these points:
>>
>> * When any change is committed (to a module that "belongs to" Solr or
>> to Lucene), all tests must pass.
>> * 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).
>>
>> If those don't have to do with code changes, then I'm not sure what
>> they are
>> and would appreciate clarification.
>>
>> Cheers,
>> Chris
>>
>>
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> Chris Mattmann, Ph.D.
>> Senior Computer Scientist
>> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
>> Office: 171-266B, Mailstop: 171-246
>> Email: Chris.Mattmann@jpl.nasa.gov
>> WWW: http://sunset.usc.edu/~mattmann/
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> Adjunct Assistant Professor, Computer Science Department
>> University of Southern California, Los Angeles, CA 90089 USA
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>
>>
>
>
--
- Mark
http://www.lucidimagination.com
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Mark Miller <ma...@gmail.com>.
Hey Chris,
see my response to Michael.
But quickly,
the first star is not a code change. Its procedural.
the second star, and I'm sure youll have arguments with this :), is not
something we are specifically voting on. The reason we are merging dev
is obviously so that those changes can occur - but this vote is not to
force those changes. Even those against the merge would like to see
those changes. Putting more queries, querparsers, and analyzers into
Lucene is not a controversial change :)
On 03/09/2010 12:33 AM, Mattmann, Chris A (388J) wrote:
> On 3/8/10 9:26 PM, "Mark Miller"<ma...@gmail.com> wrote:
>
>
>> 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.
>>
> Ummm, that's not true.
>
> Mike's last proposal listed these points:
>
> * When any change is committed (to a module that "belongs to" Solr or
> to Lucene), all tests must pass.
> * 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).
>
> If those don't have to do with code changes, then I'm not sure what they are
> and would appreciate clarification.
>
> Cheers,
> Chris
>
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Chris Mattmann, Ph.D.
> Senior Computer Scientist
> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> Office: 171-266B, Mailstop: 171-246
> Email: Chris.Mattmann@jpl.nasa.gov
> WWW: http://sunset.usc.edu/~mattmann/
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Adjunct Assistant Professor, Computer Science Department
> University of Southern California, Los Angeles, CA 90089 USA
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>
>
--
- Mark
http://www.lucidimagination.com
Re: [VOTE] merge lucene/solr development (take 3)
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
On 3/8/10 9:26 PM, "Mark Miller" <ma...@gmail.com> wrote:
> 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.
Ummm, that's not true.
Mike's last proposal listed these points:
* When any change is committed (to a module that "belongs to" Solr or
to Lucene), all tests must pass.
* 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).
If those don't have to do with code changes, then I'm not sure what they are
and would appreciate clarification.
Cheers,
Chris
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: Chris.Mattmann@jpl.nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Mark Miller <ma...@gmail.com>.
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.
http://www.apache.org/foundation/voting.html
--
- Mark
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Michael Busch <bu...@gmail.com>.
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.
> but at the same time we should try to address the concerns of those who voted -1 and see if a better solution can be developed so that they hopefully can become at least a 0 if not a +1. The whole point of the move is to build a stronger community, not a weaker one.
>
Yes I totally agree and thanks for saying that, Grant. We should try to
make a decision so that the general mood in this community is good at
the end and that everyone considers the outcome as beneficial for the
whole project. This means that both sides have to be open for compromises.
Michael
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Grant Ingersoll <gs...@apache.org>.
I don't think any of it's a showstopper, but at the same time we should try to address the concerns of those who voted -1 and see if a better solution can be developed so that they hopefully can become at least a 0 if not a +1. The whole point of the move is to build a stronger community, not a weaker one. At the same time, we should also remember that a large part of the motivation for this move comes from people wanting things that are in Solr to be moved to Lucene in the first place (Analyzers, Faceting, Function Queries, Open Bit Set, Spatial, Schema to name a few past and present ones; these constitute a lot of Solr's functionality, BTW.) If there are baby steps that bring the two together, we should consider them. Personally, I think the proposal contains said baby steps, but perhaps some would prefer smaller ones to begin with so they should outline them.
It should also be noted that a good chunk of the Solr committers are already Lucene committers, and of the remaining there are: Bill Au, Mike Klaas, Ryan McKinley, Shalin and Noble. Mike has been inactive for quite some time (and has elected to go emeritus even though it's not marked on the page) and and Ryan, Shalin and Noble already contribute to Lucene in various parts (AFAICT), so to me it's not a big stretch to say bring them into the fold. I haven't tracked Bill's involvement, but I also know Bill and trust he knows what it means to be a committer, i.e. he knows as much what not to touch as what to touch. Of course, we can do a separate vote on that if that helps satisfy Chris' issue on the committers.
In the end, for me anyway, the current separation hurts Lucene a good deal as much as it hurts Solr, if not more. Likewise, I wish some of the Nutch committers would speak up, as I'm sure there are some pieces of Nutch that are "core" too, but for a lack of visibility down lower in Lucene committer wise, especially as Nutch as looking to refactor into more components. Obviously not the crawling stuff, but perhaps some of Nutch's analyzer and low level Lucene stuff would make sense to be pushed lower in the stack.
In the end, I'm still +1 on the current move. We can consider the other moves separately if the community wishes.
On Mar 8, 2010, at 9:52 PM, Yonik Seeley wrote:
> On Mon, Mar 8, 2010 at 9:49 PM, Michael Busch <bu...@gmail.com> wrote:
>> Question: Is it sufficient to have more +1s than -1s for this vote to pass?
> 3 +1s and more +1s than -1s is sufficient.
>
>> I thought for votes as significant as this one a -1 veto is a showstopper?
> It's not really tied to significance - releases, acceptance to
> incubate, etc, all require more +1s than -1s.
>
> -Yonik
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Yonik Seeley <ys...@gmail.com>.
On Mon, Mar 8, 2010 at 9:49 PM, Michael Busch <bu...@gmail.com> wrote:
> Question: Is it sufficient to have more +1s than -1s for this vote to pass?
3 +1s and more +1s than -1s is sufficient.
> I thought for votes as significant as this one a -1 veto is a showstopper?
It's not really tied to significance - releases, acceptance to
incubate, etc, all require more +1s than -1s.
-Yonik
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Mark Miller <ma...@gmail.com>.
On 03/08/2010 09:49 PM, Michael Busch wrote:
>
> Question: Is it sufficient to have more +1s than -1s for this vote to
> pass? I thought for votes as significant as this one a -1 veto is a
> showstopper?
>
Hey Michael - its a good question. And I think the answer is, this is
not a vote that can be vetoed with a single -1. Though I'm not sure its
completely clear.
Quoting the Apache page on voting:
There are essentially three types of vote:
1. Code modifications,
2. Package releases
3. Procedural
Votes on procedural issues follow the common format of majority rule
unless otherwise stated.
Likewise, package release cannot be vetoed. Only Code modifications with
a valid technical reason can be vetoed.
So from what I gather, this is closest to procedural and would be
majority. But that's not entirely clear. But it does appear that Apache
favors for majority for this type of thing (or enough +1's), and saves
vetoes for code changes.
--
- Mark
Re: [VOTE] merge lucene/solr development (take 3)
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hi Michael,
It¹s a good question. I think each side of the fence on this issue has their
own interpretation. Here¹s the Apache page on voting:
http://www.apache.org/foundation/voting.html
I think parts of Mike¹s 2nd proposal [1] (what we¹re voting on) include
elements that are procedural:
* Merging the dev lists into a single list.
* Release details will be decided by dev community, but, Lucene may
release without Solr. (though I¹m not sure why this is included, b/c it¹s
the way that the communities work now?)
But others aren¹t:
* Merging committers.
And these relate directly to code and will effect change:
* When any change is committed (to a module that "belongs to" Solr or
to Lucene), all tests must pass.
* 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).
So, there are parts of this proposal that I believe VETO does in fact apply
to.
Cheers,
Chris
[1] http://bit.ly/bUJAee
On 3/8/10 6:49 PM, "Michael Busch" <bu...@gmail.com> wrote:
> Question: Is it sufficient to have more +1s than -1s for this vote to
> pass? I thought for votes as significant as this one a -1 veto is a
> showstopper?
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: Chris.Mattmann@jpl.nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Michael Busch <bu...@gmail.com>.
+0
I know I had voted +1 in the second vote, because I was happy about the
fact that Lucene can release w/o Solr. But I spent more time thinking
about this last weekend. I still don't really WANT this change, but can
live with the current proposal. Hence, a +0 in this "official" vote
summarizes probably more accurately how I feel about it.
Question: Is it sufficient to have more +1s than -1s for this vote to
pass? I thought for votes as significant as this one a -1 veto is a
showstopper?
Michael
On 3/8/10 6:11 PM, Yonik Seeley wrote:
> Apoligies in advance for calling yet another vote, but I just wanted
> to make sure this was official.
> Mike's second VOTE thread could probably technically stand on it's own
> (since it included PMC votes), but given that I said in my previous
> VOTE thread that I was just polling Lucene/Solr committers and would
> call a second PMC vote, that may have acted to suppress PMC votes on
> Mike's thread also.
>
> Please vote for the proposal quoted below to merge lucene/solr development.
> Here's my +1
>
> -Yonik
>
> Mike's call for a VOTE (amongst lucene/solr committers +11 to -1):
> http://search.lucidimagination.com/search/document/a400ffe62ae21aca/vote_merge_the_development_of_solr_lucene_take_2#22d7cd086d9c5cf0
>
>> Subject: 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.
>>
>
RE: [VOTE] merge lucene/solr development (take 3)
Posted by Uwe Schindler <uw...@thetaphi.de>.
Here my vote:
+1 for the latest proposal to merge the development.
I am still against the requirement that all changes in Lucene need all tests to pass in solr, but that can be discussed later. I would like to simply open an issue then, if a test does not pass and let the Solr people fix it (applies to all bugs in solr's tests). Also releases at the same time for both projects should not be coupled. Each project should be able to release when they think it's time.
Uwe
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: uwe@thetaphi.de
> -----Original Message-----
> From: Yonik Seeley [mailto:yseeley@gmail.com]
> Sent: Tuesday, March 09, 2010 3:12 AM
> To: general@lucene.apache.org
> Subject: [VOTE] merge lucene/solr development (take 3)
>
> Apoligies in advance for calling yet another vote, but I just wanted
> to make sure this was official.
> Mike's second VOTE thread could probably technically stand on it's own
> (since it included PMC votes), but given that I said in my previous
> VOTE thread that I was just polling Lucene/Solr committers and would
> call a second PMC vote, that may have acted to suppress PMC votes on
> Mike's thread also.
>
> Please vote for the proposal quoted below to merge lucene/solr
> development.
> Here's my +1
>
> -Yonik
>
> Mike's call for a VOTE (amongst lucene/solr committers +11 to -1):
> http://search.lucidimagination.com/search/document/a400ffe62ae21aca/vot
> e_merge_the_development_of_solr_lucene_take_2#22d7cd086d9c5cf0
> > Subject: 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.
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Ryan McKinley <ry...@gmail.com>.
+1
On Mon, Mar 8, 2010 at 9:11 PM, Yonik Seeley <ys...@gmail.com> wrote:
> Apoligies in advance for calling yet another vote, but I just wanted
> to make sure this was official.
> Mike's second VOTE thread could probably technically stand on it's own
> (since it included PMC votes), but given that I said in my previous
> VOTE thread that I was just polling Lucene/Solr committers and would
> call a second PMC vote, that may have acted to suppress PMC votes on
> Mike's thread also.
>
> Please vote for the proposal quoted below to merge lucene/solr development.
> Here's my +1
>
> -Yonik
>
> Mike's call for a VOTE (amongst lucene/solr committers +11 to -1):
> http://search.lucidimagination.com/search/document/a400ffe62ae21aca/vote_merge_the_development_of_solr_lucene_take_2#22d7cd086d9c5cf0
>> Subject: 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.
>
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Shalin Shekhar Mangar <sh...@gmail.com>.
On Tue, Mar 9, 2010 at 7:41 AM, Yonik Seeley <ys...@gmail.com> wrote:
>
> Mike's call for a VOTE (amongst lucene/solr committers +11 to -1):
>
> http://search.lucidimagination.com/search/document/a400ffe62ae21aca/vote_merge_the_development_of_solr_lucene_take_2#22d7cd086d9c5cf0
> > Subject: 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.
>
+1
I think that, in the long term, this move will prove beneficial for both the
projects.
--
Regards,
Shalin Shekhar Mangar.
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Grant Ingersoll <gs...@apache.org>.
Hi Patrick,
I'm sorry you feel like it was railroaded. This has been a long and lengthy discussion and I think we made several improvements on the original proposal, but I also think the vote has passed and it is time to move on, especially in light of the Bernd's and the Board's notion that there is one project with one set of committers. This will take some time to get there.
Some more thoughts inline.
On Mar 13, 2010, at 10:36 PM, patrick o'leary wrote:
>
> If you want a concrete example take Field Collapsing
> https://issues.apache.org/jira/browse/SOLR-236
>
> That's been around 3 years now, has 61 votes and 72 watchers, yet it's been
> sat on... the community has delivered, but committers have refused to heed
> them...
> It's it complete?
As can be seen by the large number of iterations on it, it doesn't appear that those who are working on it think it is complete, either. However, they have done exactly what was asked of them, by breaking it down into smaller issues and working to get those committed (and they are in fact being committed if you look at the subissues). Very large, monolithic patches are very hard to commit. At the rate it is going, it will be in 1.5, but also keep in mind, Field Collapsing is a VERY hard problem, as every committer and who contributor who has worked on it will tell you.
> I feel it's more complete that all the function query work that was
> committed to Solr trunk for spatial solr...
Possibly, but the function query stuff (I presume you are referring to the sort by function error for a very small subset of queries) is _WAY_ smaller and only effects a few files. Field collapsing touches the very deep innards of Solr and touches a lot of Solr. There's a big difference.
But, also, if you don't like it, please offer help. I'm not perfect, never have been. Nor is any other committer. That's why it takes a whole community to get it right. I look forward to working with you more on it, as you are much more of an expert on it than I am. I'm confident that if we work together on it, we can crank out a very high quality solution that is better than either you or I could do by ourselves.
> It's clearly shown there's two sets of rules for this, as a committer you
> can do as you please, as a community member you've got to hope that there is
> a committer who needs what you've done or asked for, and agrees with the way
> you've implemented it..
For better or worse, this is how every last open source project on the entire planet works, but see below for some more thoughts on this as there is always room for improvement. At least in the ASF, there is a mechanism for the community to become a committer. In most Open Source projects, it is simply the Dictator for Life model and you have zero chance of ever significantly contributing.
However, if the community doesn't trust the committers to have the best interest of the project in mind, then the community can either:
1. Abandon the project
2. Step up and pitch in and help out. The ASF has a very clear path to becoming a committer. You have gone down that path.
I certainly hope people choose #2, but I can't make them, either.
>
> That's where I feel there is a lack of diversity in concepts, direction and
> design within solr.
So, please contribute. You know how the process works.
>
> And as such I would hate to see the same thing happen to lucene.
>
> Granted we all work for a living, we can't always work on projects or ideas
> others bring to the table. I write code maybe once a month these days, and
> often can't keep up with the requests that come into the open source stuff I
> support. But I've always allowed others to contribute and extend, if it
> compiles, works, and doesn't mess things up, I always feel that if it's
> important enough, then iteration will make it better if it needs to be
> better. And I've been lucky that several folks on the locallucene world have
> rolled up their selves and helped out.
Yes, but it also needs to be up to a certain standard as well. There was a lot of feedback, for instance, on SOLR-773 from at least 3 or 4 different committers who suggested ways to make it better fit into Solr's model before committing. I don't understand why iteration before committing is any different from iteration after committing, except that by doing it before you break a lot fewer people and end up with more people happy in the long run.
>
> I respect, and appreciate folks for taking any hemorrhage of concepts and
> making them better, and that's how see open source working.
>
Likewise, we respect people making contributions. This has always been the case and always will be, as it's the ASF way.
> Apache provides hosting, and legal protection for people who develop
> community driven projects, but not projects that are restricted to the ideas
> of those that have commit karma.
This is always a fine line to walk. As a committer, your responsibility is to make sure the code going in meets the quality demands of the project as well as
the legal requirements of the ASF. This is further complicated by a large variety of contributors from all over the world with a variety of programming and documentation skills. It is then further complicated by time pressure on all people involved. Finally, being a committer is often as much about knowing what not to touch as what to touch. For instance, on Field Collapsing, I don't feel particularly qualified to work on it. If I did work on it, I know it would take a lot of my time just to get up to speed, and I simply don't have that kind of time, either, which is why I asked the contributors to try to break it up into smaller pieces. This is why I work on the spatial stuff, because I can bite off very small chunks. I wish I could dedicate all my time to it, but I have a day job too.
I think if you take a step back from the immediate issue, it's pretty safe to say that those who have been working on Lucene and Solr for the past X years have done a pretty decent job at it. By no means are we perfect, but I think the community as a whole has done a very good job of working through issues and constantly improving the projects. Even as contentious as this issue has been, it has been a very healthy discussion. It is a tremendous tribute to the community as a whole that it has stuck on topic and been on the issues. I've been involved in plenty of other projects where a discussion of this length would have already degenerated into personal attacks.
Cheers,
Grant
Re: [VOTE] merge lucene/solr development (take 3)
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hey Patrick,
> Actually Mark the problem with Spatial is that there hasn't been enough
> folks involved in it as a project. I am a single point of failure for it. So
> I have gone about solving that, by getting assistance from several experts
> in this field to help put this proposal together
>
> http://wiki.apache.org/incubator/SpatialProposal
>
> <http://wiki.apache.org/incubator/SpatialProposal>And we should
> be committing very soon
We're happy to be working with you, and I think you've got that "expert"
title in this area well pinned down.
Cheers,
Chris
>
>
> On Sat, Mar 13, 2010 at 7:45 PM, Mark Miller <ma...@gmail.com> wrote:
>
>>
>>
>> On 03/13/2010 10:36 PM, patrick o'leary wrote:
>>
>>> As for this vote, I will allow our proximity to St. Patricks day to tone
>>> down my description of it, by describing it as shenanigans !
>>>
>>
>> As long as we are talking about what committers should be working on, I
>> wish you'd support the spatial contrib you dumped in. I've explained the
>> issues with it in the past, and while you agreed about them, where is the
>> help!
>>
>> Field Collapsing is a biggie (I think Shalin was working at it a bit, along
>> with others at different times), and not an easy one to make time for, or
>> take responsibility for the commit - especially with so many having concerns
>> with its scalability - but if you help at all with spatial, I promise to
>> push on Field Collapsing. Its why you were made a contrib committer. I'm not
>> sure why you accepted if someone else could have just committed the code
>> load.
>>
>
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: Chris.Mattmann@jpl.nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Re: [VOTE] merge lucene/solr development (take 3)
Posted by patrick o'leary <pj...@pjaol.com>.
Actually Mark the problem with Spatial is that there hasn't been enough
folks involved in it as a project. I am a single point of failure for it. So
I have gone about solving that, by getting assistance from several experts
in this field to help put this proposal together
http://wiki.apache.org/incubator/SpatialProposal
<http://wiki.apache.org/incubator/SpatialProposal>And we should
be committing very soon
On Sat, Mar 13, 2010 at 7:45 PM, Mark Miller <ma...@gmail.com> wrote:
>
>
> On 03/13/2010 10:36 PM, patrick o'leary wrote:
>
>> As for this vote, I will allow our proximity to St. Patricks day to tone
>> down my description of it, by describing it as shenanigans !
>>
>
> As long as we are talking about what committers should be working on, I
> wish you'd support the spatial contrib you dumped in. I've explained the
> issues with it in the past, and while you agreed about them, where is the
> help!
>
> Field Collapsing is a biggie (I think Shalin was working at it a bit, along
> with others at different times), and not an easy one to make time for, or
> take responsibility for the commit - especially with so many having concerns
> with its scalability - but if you help at all with spatial, I promise to
> push on Field Collapsing. Its why you were made a contrib committer. I'm not
> sure why you accepted if someone else could have just committed the code
> load.
>
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Mark Miller <ma...@gmail.com>.
On 03/13/2010 10:36 PM, patrick o'leary wrote:
> As for this vote, I will allow our proximity to St. Patricks day to tone
> down my description of it, by describing it as shenanigans !
As long as we are talking about what committers should be working on, I
wish you'd support the spatial contrib you dumped in. I've explained the
issues with it in the past, and while you agreed about them, where is
the help!
Field Collapsing is a biggie (I think Shalin was working at it a bit,
along with others at different times), and not an easy one to make time
for, or take responsibility for the commit - especially with so many
having concerns with its scalability - but if you help at all with
spatial, I promise to push on Field Collapsing. Its why you were made a
contrib committer. I'm not sure why you accepted if someone else could
have just committed the code load.
Re: [VOTE] merge lucene/solr development (take 3)
Posted by patrick o'leary <pj...@pjaol.com>.
I do appreciate you reaching out to me, but I think this needs to be an open
response.
Folks, have used the terms *bullied*, *rail-road*, and *pushed* to describe
this vote, folks that aren't even me.
I look at development that's occurring in solr and I am concerned, I don't
feel that it's serving the community.
I've seen comments on threads of (paraphrasing) person X,Y,Z voted and are
committers and they are the guys who do the work, so that's all that
matters....
Well no, the community contributes code, ideas / concepts, but
the committers seem to sit on these ideas, unless it meets a feature they
want. I can bring several examples to display this, and not just localsolr.
If you want a concrete example take Field Collapsing
https://issues.apache.org/jira/browse/SOLR-236
That's been around 3 years now, has 61 votes and 72 watchers, yet it's been
sat on... the community has delivered, but committers have refused to heed
them...
It's it complete?
I feel it's more complete that all the function query work that was
committed to Solr trunk for spatial solr...
It's clearly shown there's two sets of rules for this, as a committer you
can do as you please, as a community member you've got to hope that there is
a committer who needs what you've done or asked for, and agrees with the way
you've implemented it..
That's where I feel there is a lack of diversity in concepts, direction and
design within solr.
And as such I would hate to see the same thing happen to lucene.
Granted we all work for a living, we can't always work on projects or ideas
others bring to the table. I write code maybe once a month these days, and
often can't keep up with the requests that come into the open source stuff I
support. But I've always allowed others to contribute and extend, if it
compiles, works, and doesn't mess things up, I always feel that if it's
important enough, then iteration will make it better if it needs to be
better. And I've been lucky that several folks on the locallucene world have
rolled up their selves and helped out.
I respect, and appreciate folks for taking any hemorrhage of concepts and
making them better, and that's how see open source working.
Apache provides hosting, and legal protection for people who develop
community driven projects, but not projects that are restricted to the ideas
of those that have commit karma.
As for this vote, I will allow our proximity to St. Patricks day to tone
down my description of it, by describing it as shenanigans !
Patrick O'Leary
On Sat, Mar 13, 2010 at 6:23 AM, Yonik Seeley <ys...@gmail.com> wrote:
> Hi Patrick,
>
> I understand some of your concerns with the vote - it certainly wasn't
> perfect, and (I believe) could never be unanimous. But it's done, and
> the merge is already moving forward, so I'd like to put that behind
> us.
>
> I did want to take some time to address any concerns you had about the
> actual dev merge though (impacts on Lucene and Solr). There will be
> some negative impacts to Solr and some negative impacts to Lucene, but
> overall it seems like the good will outweigh the bad.
>
> On Mon, Mar 8, 2010 at 10:16 PM, patrick o'leary <pj...@pjaol.com> wrote:
> > Hmm, Right now I consider Solr too far from lucene to see a merge
> succeed,
> > if you asked me 2 years ago I would have said merge merge merge.
>
> If you mean just getting back onto Lucene's trunk, this shouldn't be
> too big of a job. And it certainly won't have any impact on Lucene
> before we do.
>
> > I also think Solr hasn't worked out a good roadmap or schedule for
> releases,
> > which I'm sure will impact the lucene world.
>
> I've never really seen much in the way of roadmaps from Lucene either.
> And since Solr became open source, Lucene as only had one more major
> release (not counting 3.0 which just removed deprecations). The
> bugfix releases are easy in comparison - I don't see problems with
> those.
>
> Now, it's certainly possible that Lucene could impact Solr's schedule,
> and vice-versa... little slips will happen on both sides. If
> extenuating circumstance arises where Solr is clearly not close, but
> lucene is, then we can always opt to not release the Solr artifacts
> (that's the clause that Mike spelled out in VOTE #2 to ease fears
> about that).
>
> Again, there can be any number of little potential disadvantages to
> the merge... but there are also a ton of positives, and the main
> point is that we'll be working hard to make sure the good outweighs
> the bad.
>
> -Yonik
>
Re: [VOTE] merge lucene/solr development (take 3)
Posted by patrick o'leary <pj...@pjaol.com>.
Hmm, Right now I consider Solr too far from lucene to see a merge succeed,
if you asked me 2 years ago I would have said merge merge merge.
I also think Solr hasn't worked out a good roadmap or schedule for releases,
which I'm sure will impact the lucene world.
So
-1
On Mon, Mar 8, 2010 at 6:11 PM, Yonik Seeley <ys...@gmail.com> wrote:
> Apoligies in advance for calling yet another vote, but I just wanted
> to make sure this was official.
> Mike's second VOTE thread could probably technically stand on it's own
> (since it included PMC votes), but given that I said in my previous
> VOTE thread that I was just polling Lucene/Solr committers and would
> call a second PMC vote, that may have acted to suppress PMC votes on
> Mike's thread also.
>
> Please vote for the proposal quoted below to merge lucene/solr development.
> Here's my +1
>
> -Yonik
>
> Mike's call for a VOTE (amongst lucene/solr committers +11 to -1):
>
> http://search.lucidimagination.com/search/document/a400ffe62ae21aca/vote_merge_the_development_of_solr_lucene_take_2#22d7cd086d9c5cf0
> > Subject: 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.
>
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Simon Willnauer <si...@googlemail.com>.
On Fri, Mar 12, 2010 at 2:47 PM, Yonik Seeley <ys...@gmail.com> wrote:
> On Fri, Mar 12, 2010 at 1:39 AM, Simon Willnauer
> <si...@googlemail.com> wrote:
>> I rather consider this as being far away from a
>> consensus decision.
>
> You are correct - it's a majority decision, but certainly not a consensus one.
> There are some types of issues people will clearly never get full
> consensus on - unfortunately this is one of them. More discussion and
> more votes wouldn't change the outcome. It may not seem fair that the
> majority override the minority, but it's also not fair for the
> minority to override or hold up progress of the majority.
Agreed, I just wish we had more support on this.
simon
>
> -Yonik
>
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Yonik Seeley <ys...@gmail.com>.
On Fri, Mar 12, 2010 at 1:39 AM, Simon Willnauer
<si...@googlemail.com> wrote:
> I rather consider this as being far away from a
> consensus decision.
You are correct - it's a majority decision, but certainly not a consensus one.
There are some types of issues people will clearly never get full
consensus on - unfortunately this is one of them. More discussion and
more votes wouldn't change the outcome. It may not seem fair that the
majority override the minority, but it's also not fair for the
minority to override or hold up progress of the majority.
-Yonik
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Otis Gospodnetic <ot...@yahoo.com>.
Hi,
But remember the early days of this (or these) vote threads. I recall some people saying things like "I won't vote -1 since I don't want to veto the proposal, so I'll vote +|-0". I recall Doug being one of those people. I don't think we heard back from Doug in subsequent vote threads. I think there were a few others on the fence.
I don't think I even voted because things were not clear and there was too much discussion going on. If I had to vote, I think I'd vote -1 mainly because I believe that what I think the proposal's goal is can be achieved with the current structure. I mentioned this in some emails about a week ago, but nobody from +1 side reacted from what I recall.
I agree that in general in life it's impossible to get 100% of people to agree on something and sometimes that means that a "largish minority" will have to live with a change they disagree with, but here I feel that there are other ways of achieving the desired goal, so it's not clear to me while those less drastic ways are not tried first. I'll send a separate email about those ways.
Otis
----- Original Message ----
> From: Michael McCandless <lu...@mikemccandless.com>
> To: general@lucene.apache.org
> Sent: Sun, March 14, 2010 6:28:57 AM
> Subject: Re: [VOTE] merge lucene/solr development (take 3)
>
> On Sun, Mar 14, 2010 at 12:26 AM, Michael Busch <
> ymailto="mailto:buschmic@gmail.com"
> href="mailto:buschmic@gmail.com">buschmic@gmail.com> wrote:
> This
> whole thing feels like it's been pushed through, and while I'm
> not
> against the updated proposal anymore (I voted +0), the bad
> feeling that
> consensus wasn't really reached remains.
But: this vote is not expected
> nor required to reach consensus.
We as a community are very used to only
> pursuing things when they
reach [near-]consensus, simply because nearly every
> biggish topic we
discuss must first reach consensus. That's a very high
> bar and it
blocks many good changes (look at how many times we've
> broached
relaxing back compat policy...).
This change does not require
> consensus. It requires only a majority
to pass, which it has
> achieved. Yes, it's contentious, but a change
this big will always be
> contentious, and this is why Apache requires
only majority for it to
> pass.
Mike
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Michael McCandless <lu...@mikemccandless.com>.
On Sun, Mar 14, 2010 at 12:26 AM, Michael Busch <bu...@gmail.com> wrote:
> This whole thing feels like it's been pushed through, and while I'm
> not against the updated proposal anymore (I voted +0), the bad
> feeling that consensus wasn't really reached remains.
But: this vote is not expected nor required to reach consensus.
We as a community are very used to only pursuing things when they
reach [near-]consensus, simply because nearly every biggish topic we
discuss must first reach consensus. That's a very high bar and it
blocks many good changes (look at how many times we've broached
relaxing back compat policy...).
This change does not require consensus. It requires only a majority
to pass, which it has achieved. Yes, it's contentious, but a change
this big will always be contentious, and this is why Apache requires
only majority for it to pass.
Mike
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Michael Busch <bu...@gmail.com>.
On 3/12/10 4:30 AM, Simon Willnauer wrote:
> I don't think that is the case. A large amount of different concerns
> are out there. Simply based on the amount of "huge" comments this
> seems to be not a clearly passed vote.
>
> simon
>
Just for the record: I don't think it's a good idea to consider this
vote as passed either. This whole thing feels like it's been pushed
through, and while I'm not against the updated proposal anymore (I voted
+0), the bad feeling that consensus wasn't really reached remains.
Michael
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Yonik Seeley <ys...@gmail.com>.
On Sun, Mar 14, 2010 at 11:02 AM, Otis Gospodnetic
<ot...@yahoo.com> wrote:
> Would it be correct to say that a subset of Lucene/Solr committers discussed the proposal "internally/offline" (i.e. not on MLs) before proposing it?
Nope. Where did this idea come from?
I'm quite sure my proposal (my original we-should-just-merge email)
was a surprise to everyone. I discussed it with no one previously.
All of the related discussions in previous months had been about
pulling stuff out of Solr, why that was disadvantageous to Solr, etc,
etc.
-Yonik
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Otis Gospodnetic <ot...@yahoo.com>.
Hi,
Would it be correct to say that a subset of Lucene/Solr committers discussed the proposal "internally/offline" (i.e. not on MLs) before proposing it?
Thanks,
Otis
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Otis Gospodnetic <ot...@yahoo.com>.
Would it be correct to say that in order to have a voting be perfectly clear, the VOTE thread should have just the votes and no comments/discussion?
Otis
----- Original Message ----
> From: Grant Ingersoll <gs...@apache.org>
> To: general@lucene.apache.org
> Sent: Fri, March 12, 2010 11:02:34 AM
> Subject: Re: [VOTE] merge lucene/solr development (take 3)
>
>
On Mar 12, 2010, at 10:56 AM, Mattmann, Chris A (388J) wrote:
> Hi
> Simon,
>
> On 3/12/10 4:30 AM, "Simon Willnauer" <
> ymailto="mailto:simon.willnauer@googlemail.com"
> href="mailto:simon.willnauer@googlemail.com">simon.willnauer@googlemail.com>
>
> wrote:
>
>> I don't think that is the case. A large amount of
> different concerns
>> are out there. Simply based on the amount of
> "huge" comments this
>> seems to be not a clearly passed
> vote.
>>
>> simon
>
> Agreed.
>
>
Comments are not votes. Tally up the +1, 0, and -1's.
> There is your vote. If people don't understand that the thing you are
> voting on is the first email in the [VOTE] thread, then I don't know how else to
> explain it. This thread very clearly has something to vote on it in the
> first thread.
-Grant
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Grant Ingersoll <gs...@apache.org>.
On Mar 12, 2010, at 10:56 AM, Mattmann, Chris A (388J) wrote:
> Hi Simon,
>
> On 3/12/10 4:30 AM, "Simon Willnauer" <si...@googlemail.com>
> wrote:
>
>> I don't think that is the case. A large amount of different concerns
>> are out there. Simply based on the amount of "huge" comments this
>> seems to be not a clearly passed vote.
>>
>> simon
>
> Agreed.
>
Comments are not votes. Tally up the +1, 0, and -1's. There is your vote. If people don't understand that the thing you are voting on is the first email in the [VOTE] thread, then I don't know how else to explain it. This thread very clearly has something to vote on it in the first thread.
-Grant
Re: [VOTE] merge lucene/solr development (take 3)
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hi Simon,
On 3/12/10 4:30 AM, "Simon Willnauer" <si...@googlemail.com>
wrote:
> I don't think that is the case. A large amount of different concerns
> are out there. Simply based on the amount of "huge" comments this
> seems to be not a clearly passed vote.
>
> simon
Agreed.
Cheers,
Chris
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: Chris.Mattmann@jpl.nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Simon Willnauer <si...@googlemail.com>.
On Fri, Mar 12, 2010 at 1:00 PM, Grant Ingersoll <gs...@apache.org> wrote:
>
>
>
> On Mar 12, 2010, at 1:39 AM, Simon Willnauer wrote:
>
>> On Fri, Mar 12, 2010 at 5:39 AM, patrick o'leary <pj...@pjaol.com> wrote:
>>> Hows that?
>>>
>>> Which vote has been passed? 1,2 or 3?
>>> Considering how much has been discussed / altered in email threads, what's
>>> actually been voted upon?
>>>
>>> The proposition is definitely unclear, and needs full fleshing out and
>>> discussion before another vote is called.
>>>
>>>
>>> On Thu, Mar 11, 2010 at 6:29 PM, Yonik Seeley <yo...@apache.org> wrote:
>>>
>>>> Thanks everyone, this vote has passed.
>>>> A bit more contentious of a PMC vote than usual, but the committer
>>>> vote was clear.
>> While I have voted +1 I have to admin that I don't know which vote has passed or
>> if at all. The noise on this vote / issue was extremely high from a
>> community side I rather consider this as being far away from a
>> consensus decision. I have to agree with chris that due to all the
>> community discussions and arguments on the issue some might change
>> their mind or come up with a proposal that work better for everybody.
>> Lets wait a week or two, discuss again and vote again. Unless we don't
>> get a clear vote without all this discussions I'd say there is still
>> something "wrong" with the proposal.
>>
>
> The vote is always the one proposed on the thread. It was in Yonik's original email on this thread.
I would guess that 50% of the people replying to this issue where not
aware of this!
>
>
>> Don't get me wrong, I agree the committer vote was kind of clear but
>> both projects are more than a list of committers and if the community
>> is unhappy we should take the time and revise such a major structural
>> / procedural change. Are we in a rush!? I don't think so.
>
> I'd hardly say the community is unhappy. A few people have expressed unhappiness, but overall the large majority of people that expressed interest were for it. The primary objection seems to be concern that Solr is going to take over Lucene and all of Lucene is going to be consumed by a HTTP Server code, which has been rejected a number of times by all who are for it
I don't think that is the case. A large amount of different concerns
are out there. Simply based on the amount of "huge" comments this
seems to be not a clearly passed vote.
simon
>
> -Grant
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Grant Ingersoll <gs...@apache.org>.
On Mar 12, 2010, at 1:39 AM, Simon Willnauer wrote:
> On Fri, Mar 12, 2010 at 5:39 AM, patrick o'leary <pj...@pjaol.com> wrote:
>> Hows that?
>>
>> Which vote has been passed? 1,2 or 3?
>> Considering how much has been discussed / altered in email threads, what's
>> actually been voted upon?
>>
>> The proposition is definitely unclear, and needs full fleshing out and
>> discussion before another vote is called.
>>
>>
>> On Thu, Mar 11, 2010 at 6:29 PM, Yonik Seeley <yo...@apache.org> wrote:
>>
>>> Thanks everyone, this vote has passed.
>>> A bit more contentious of a PMC vote than usual, but the committer
>>> vote was clear.
> While I have voted +1 I have to admin that I don't know which vote has passed or
> if at all. The noise on this vote / issue was extremely high from a
> community side I rather consider this as being far away from a
> consensus decision. I have to agree with chris that due to all the
> community discussions and arguments on the issue some might change
> their mind or come up with a proposal that work better for everybody.
> Lets wait a week or two, discuss again and vote again. Unless we don't
> get a clear vote without all this discussions I'd say there is still
> something "wrong" with the proposal.
>
The vote is always the one proposed on the thread. It was in Yonik's original email on this thread.
> Don't get me wrong, I agree the committer vote was kind of clear but
> both projects are more than a list of committers and if the community
> is unhappy we should take the time and revise such a major structural
> / procedural change. Are we in a rush!? I don't think so.
I'd hardly say the community is unhappy. A few people have expressed unhappiness, but overall the large majority of people that expressed interest were for it. The primary objection seems to be concern that Solr is going to take over Lucene and all of Lucene is going to be consumed by a HTTP Server code, which has been rejected a number of times by all who are for it.
-Grant
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Simon Willnauer <si...@googlemail.com>.
On Fri, Mar 12, 2010 at 5:39 AM, patrick o'leary <pj...@pjaol.com> wrote:
> Hows that?
>
> Which vote has been passed? 1,2 or 3?
> Considering how much has been discussed / altered in email threads, what's
> actually been voted upon?
>
> The proposition is definitely unclear, and needs full fleshing out and
> discussion before another vote is called.
>
>
> On Thu, Mar 11, 2010 at 6:29 PM, Yonik Seeley <yo...@apache.org> wrote:
>
>> Thanks everyone, this vote has passed.
>> A bit more contentious of a PMC vote than usual, but the committer
>> vote was clear.
While I have voted +1 I have to admin that I don't know which vote has passed or
if at all. The noise on this vote / issue was extremely high from a
community side I rather consider this as being far away from a
consensus decision. I have to agree with chris that due to all the
community discussions and arguments on the issue some might change
their mind or come up with a proposal that work better for everybody.
Lets wait a week or two, discuss again and vote again. Unless we don't
get a clear vote without all this discussions I'd say there is still
something "wrong" with the proposal.
Don't get me wrong, I agree the committer vote was kind of clear but
both projects are more than a list of committers and if the community
is unhappy we should take the time and revise such a major structural
/ procedural change. Are we in a rush!? I don't think so.
Simon
>>
>> -Yonik
>>
>>
>> On Mon, Mar 8, 2010 at 9:11 PM, Yonik Seeley <ys...@gmail.com> wrote:
>> > Apoligies in advance for calling yet another vote, but I just wanted
>> > to make sure this was official.
>> > Mike's second VOTE thread could probably technically stand on it's own
>> > (since it included PMC votes), but given that I said in my previous
>> > VOTE thread that I was just polling Lucene/Solr committers and would
>> > call a second PMC vote, that may have acted to suppress PMC votes on
>> > Mike's thread also.
>> >
>> > Please vote for the proposal quoted below to merge lucene/solr
>> development.
>> > Here's my +1
>> >
>> > -Yonik
>> >
>> > Mike's call for a VOTE (amongst lucene/solr committers +11 to -1):
>> >
>> http://search.lucidimagination.com/search/document/a400ffe62ae21aca/vote_merge_the_development_of_solr_lucene_take_2#22d7cd086d9c5cf0
>> >> Subject: 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.
>> >
>>
>
Re: [VOTE] merge lucene/solr development (take 3)
Posted by patrick o'leary <pj...@pjaol.com>.
Hows that?
Which vote has been passed? 1,2 or 3?
Considering how much has been discussed / altered in email threads, what's
actually been voted upon?
The proposition is definitely unclear, and needs full fleshing out and
discussion before another vote is called.
On Thu, Mar 11, 2010 at 6:29 PM, Yonik Seeley <yo...@apache.org> wrote:
> Thanks everyone, this vote has passed.
> A bit more contentious of a PMC vote than usual, but the committer
> vote was clear.
>
> -Yonik
>
>
> On Mon, Mar 8, 2010 at 9:11 PM, Yonik Seeley <ys...@gmail.com> wrote:
> > Apoligies in advance for calling yet another vote, but I just wanted
> > to make sure this was official.
> > Mike's second VOTE thread could probably technically stand on it's own
> > (since it included PMC votes), but given that I said in my previous
> > VOTE thread that I was just polling Lucene/Solr committers and would
> > call a second PMC vote, that may have acted to suppress PMC votes on
> > Mike's thread also.
> >
> > Please vote for the proposal quoted below to merge lucene/solr
> development.
> > Here's my +1
> >
> > -Yonik
> >
> > Mike's call for a VOTE (amongst lucene/solr committers +11 to -1):
> >
> http://search.lucidimagination.com/search/document/a400ffe62ae21aca/vote_merge_the_development_of_solr_lucene_take_2#22d7cd086d9c5cf0
> >> Subject: 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.
> >
>
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Bernd Fondermann <be...@googlemail.com>.
On Fri, Mar 12, 2010 at 15:15, Dennis Kubes <ku...@apache.org> wrote:
> Yes railroading.
>
> Many people don't want this to occur. More than just minus 2. Underlying
> concerns are not being addressed. Vetos count. Ignoring that is ignoring
> how Apache operates. Merging projects is definitely a code change.
Yet, no code changed happened, just a whole lot of (maybe not
sufficient, not my call) discussion. Or, in other words, please name
the revision number and give a technical justification for your veto.
On the other hand, I would think it would be pretty cool and only fair
if the Lucene community would embrace and address all concerns of the
minority along the change process.
Bernd
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Dennis Kubes <ku...@apache.org>.
Ok. Thank you for your reply. For me it puts everything down in one
place. I think the simple fact is we disagree on this and it looks like
this is going through over objections. I hope that it is a good thing
for both projects and the concerns we have don't become a reality.
Dennis
Grant Ingersoll wrote:
> On Mar 12, 2010, at 9:15 AM, Dennis Kubes wrote:
>
>> Yes railroading.
>>
>> Many people don't want this to occur. More than just minus 2
>
> Only 2 committers on Lucene and Solr were against it. Those are the people that do the work.
>
>
>> . Underlying concerns are not being addressed.
>
> I don't follow. We've talked up and down about it. Sometimes every last issue can't be addressed, but I think we've all worked reasonably hard to address them. We've addressed the release issue, we've addressed the duplication/poaching issue.
>
>> Vetos count.
>
> No, they don't. It's majority approval.
>
>> Ignoring that is ignoring how Apache operates.
>
> No, it's not. Nobody is ignoring anything. There are some valid concerns. I think they will be addressed by all of us being vigilant. I have plenty of Lucene only projects in my stable, as do most other Solr committers as well as all of the current Lucene committers. Nobody here wants Lucene to be consumed by Solr and HTTP server to be rammed down their throats.
>
> Please remember that this isn't just Solr committers who want this. Most of the people who do the daily lifting on Lucene who are not Solr committers (Michael, Robert, Uwe is +0) are for it as well.
>
>> Merging projects is definitely a code change. Getting around it by saying this is a goal is fundamentally wrong.
>>
>> 1) What prevents functionality be moved over into Lucene within the current project structure? Nothing, so why are we even discussing this.
>>
>> 2) Why is Solr getting special treatment? Because there is a lot of committer overlap? Should I propose to merge Nutch in too, lets just have one big project, no distinctions.
>
> I have no problem with you proposing to bring in Nutch's overlap. The fact is, the Board doesn't like subprojects anyway and we are likely headed for some consolidation/spinning out anyway (see the December Board Minutes). Mahout is going after 0.3 is out. I could totally see spinning out the crawling stuff from Nutch and taking the good bits of Lucene in there into java-dev. (We should be working together on that stuff anyway as we all end up writing the same code and the solution in the end will be better.) But that wasn't what this discussion was about. If you can convince all of the committers in Nutch to go for it and then convince all the Lucene committers as well, then go for it. I'm certainly not going to force it, as that is up to the Nutch community.
>
> At any rate, as Otis said, "it's just software". If it doesn't work, we can split back off.
>
>> 3) Why the big push here to blur project responsibilities? Idk, I keep wondering that myself.
>
> Please read the thread. The arguments have been made over and over. There is still going to be a set of Lucene JARs and there is still going to be Solr JARs. IDK why it is such a big deal right back when most everyone who actually does the coding on the two projects is for it.
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Grant Ingersoll <gs...@apache.org>.
On Mar 12, 2010, at 9:15 AM, Dennis Kubes wrote:
> Yes railroading.
>
> Many people don't want this to occur. More than just minus 2
Only 2 committers on Lucene and Solr were against it. Those are the people that do the work.
> . Underlying concerns are not being addressed.
I don't follow. We've talked up and down about it. Sometimes every last issue can't be addressed, but I think we've all worked reasonably hard to address them. We've addressed the release issue, we've addressed the duplication/poaching issue.
> Vetos count.
No, they don't. It's majority approval.
> Ignoring that is ignoring how Apache operates.
No, it's not. Nobody is ignoring anything. There are some valid concerns. I think they will be addressed by all of us being vigilant. I have plenty of Lucene only projects in my stable, as do most other Solr committers as well as all of the current Lucene committers. Nobody here wants Lucene to be consumed by Solr and HTTP server to be rammed down their throats.
Please remember that this isn't just Solr committers who want this. Most of the people who do the daily lifting on Lucene who are not Solr committers (Michael, Robert, Uwe is +0) are for it as well.
> Merging projects is definitely a code change. Getting around it by saying this is a goal is fundamentally wrong.
>
> 1) What prevents functionality be moved over into Lucene within the current project structure? Nothing, so why are we even discussing this.
>
> 2) Why is Solr getting special treatment? Because there is a lot of committer overlap? Should I propose to merge Nutch in too, lets just have one big project, no distinctions.
I have no problem with you proposing to bring in Nutch's overlap. The fact is, the Board doesn't like subprojects anyway and we are likely headed for some consolidation/spinning out anyway (see the December Board Minutes). Mahout is going after 0.3 is out. I could totally see spinning out the crawling stuff from Nutch and taking the good bits of Lucene in there into java-dev. (We should be working together on that stuff anyway as we all end up writing the same code and the solution in the end will be better.) But that wasn't what this discussion was about. If you can convince all of the committers in Nutch to go for it and then convince all the Lucene committers as well, then go for it. I'm certainly not going to force it, as that is up to the Nutch community.
At any rate, as Otis said, "it's just software". If it doesn't work, we can split back off.
>
> 3) Why the big push here to blur project responsibilities? Idk, I keep wondering that myself.
Please read the thread. The arguments have been made over and over. There is still going to be a set of Lucene JARs and there is still going to be Solr JARs. IDK why it is such a big deal right back when most everyone who actually does the coding on the two projects is for it.
Re: [VOTE] merge lucene/solr development (take 3)
Posted by patrick o'leary <pj...@pjaol.com>.
I consider this to be pretty basic
1) A vote was called, 3 times... Obviously that shows a lack of
clarification of the proposal.
2) The details of the proposal was discussed and I would say points of it's
implications augmented from vote 1 through to vote 3 in email threads.
3) Votes had already occurred when clarifications / changes were made.
I don't think anyone can honestly state this vote is acceptable.
If you are confident that the community is happy then you should have
confidence that the points of the proposal can be posted to a static page,
discussion & clarifications can be had, once everything is cleared up, the
vote can then be called with the same outcome.
Otherwise I would consider this an invalid vote
On Fri, Mar 12, 2010 at 6:51 AM, Mark Miller <ma...@gmail.com> wrote:
> Personal? Heh. I think you misread my email. Or confused it with someone
> elses.
>
>
> On 03/12/2010 09:38 AM, Dennis Kubes wrote:
>
>> Don't try and make this personal. That is just juvenile and will only take
>> this discussion (If that is what this is) in the wrong direction.
>>
>> Being overruled doesn't mean I won't make my opinion known vocally when I
>> think a very large mistake is being made. And you aren't just overruling
>> me. Many people have expressed discontent with this plan, but you guys are
>> pushing it through anyways.
>>
>> Dennis
>>
>>
>> Mark Miller wrote:
>>
>>> You have come a long way from "If that means I get overruled, so be it."
>>> Dennis.
>>>
>>> Its a PMC vote where majority rules. As Bernd noted, vetoes are for
>>> specific svn
>>> commits with valid technical reasons. If you guys want to try and drag it
>>> out forever,
>>> I don't see much to stop you from trying, but the whole situation is
>>> pretty clear.
>>>
>>> I, for one, am looking forward to what this merge will bring to Lucene
>>> and Solr.
>>>
>>>
>>> On 03/12/2010 09:15 AM, Dennis Kubes wrote:
>>>
>>>> Yes railroading.
>>>>
>>>> Many people don't want this to occur. More than just minus 2.
>>>> Underlying concerns are not being addressed. Vetos count. Ignoring
>>>> that is ignoring how Apache operates. Merging projects is definitely
>>>> a code change. Getting around it by saying this is a goal is
>>>> fundamentally wrong.
>>>>
>>>> 1) What prevents functionality be moved over into Lucene within the
>>>> current project structure? Nothing, so why are we even discussing
>>>> this.
>>>>
>>>> 2) Why is Solr getting special treatment? Because there is a lot of
>>>> committer overlap? Should I propose to merge Nutch in too, lets just
>>>> have one big project, no distinctions.
>>>>
>>>> 3) Why the big push here to blur project responsibilities? Idk, I
>>>> keep wondering that myself.
>>>>
>>>> Dennis
>>>>
>>>> Grant Ingersoll wrote:
>>>> > On Mar 12, 2010, at 7:54 AM, Dennis Kubes wrote:
>>>> >
>>>> >> This has definitely NOT passed. With as much contention,
>>>> >> discussion, and debate as there has been on this, saying that it
>>>> >> has passed is akin to saying "we are just going to do it
>>>> >> anyways". This is being railroaded IMO and needs to be taken to
>>>> >> a higher level within the Apache organization.
>>>> >
>>>> > How is two weeks of discussion and all the committers on the
>>>> > projects minus 2 being for it and three different votes on it (all
>>>> > with the same outcome), "railroading"? -Grant
>>>>
>>>
>>>
>>>
>
> --
> - Mark
>
> http://www.lucidimagination.com
>
>
>
>
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Mark Miller <ma...@gmail.com>.
Personal? Heh. I think you misread my email. Or confused it with someone
elses.
On 03/12/2010 09:38 AM, Dennis Kubes wrote:
> Don't try and make this personal. That is just juvenile and will only
> take this discussion (If that is what this is) in the wrong direction.
>
> Being overruled doesn't mean I won't make my opinion known vocally
> when I think a very large mistake is being made. And you aren't just
> overruling me. Many people have expressed discontent with this plan,
> but you guys are pushing it through anyways.
>
> Dennis
>
>
> Mark Miller wrote:
>> You have come a long way from "If that means I get overruled, so be
>> it." Dennis.
>>
>> Its a PMC vote where majority rules. As Bernd noted, vetoes are for
>> specific svn
>> commits with valid technical reasons. If you guys want to try and
>> drag it out forever,
>> I don't see much to stop you from trying, but the whole situation is
>> pretty clear.
>>
>> I, for one, am looking forward to what this merge will bring to
>> Lucene and Solr.
>>
>>
>> On 03/12/2010 09:15 AM, Dennis Kubes wrote:
>>> Yes railroading.
>>>
>>> Many people don't want this to occur. More than just minus 2.
>>> Underlying concerns are not being addressed. Vetos count. Ignoring
>>> that is ignoring how Apache operates. Merging projects is definitely
>>> a code change. Getting around it by saying this is a goal is
>>> fundamentally wrong.
>>>
>>> 1) What prevents functionality be moved over into Lucene within the
>>> current project structure? Nothing, so why are we even discussing
>>> this.
>>>
>>> 2) Why is Solr getting special treatment? Because there is a lot of
>>> committer overlap? Should I propose to merge Nutch in too, lets just
>>> have one big project, no distinctions.
>>>
>>> 3) Why the big push here to blur project responsibilities? Idk, I
>>> keep wondering that myself.
>>>
>>> Dennis
>>>
>>> Grant Ingersoll wrote:
>>> > On Mar 12, 2010, at 7:54 AM, Dennis Kubes wrote:
>>> >
>>> >> This has definitely NOT passed. With as much contention,
>>> >> discussion, and debate as there has been on this, saying that it
>>> >> has passed is akin to saying "we are just going to do it
>>> >> anyways". This is being railroaded IMO and needs to be taken to
>>> >> a higher level within the Apache organization.
>>> >
>>> > How is two weeks of discussion and all the committers on the
>>> > projects minus 2 being for it and three different votes on it (all
>>> > with the same outcome), "railroading"? -Grant
>>
>>
--
- Mark
http://www.lucidimagination.com
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Dennis Kubes <ku...@apache.org>.
Don't try and make this personal. That is just juvenile and will only
take this discussion (If that is what this is) in the wrong direction.
Being overruled doesn't mean I won't make my opinion known vocally when
I think a very large mistake is being made. And you aren't just
overruling me. Many people have expressed discontent with this plan,
but you guys are pushing it through anyways.
Dennis
Mark Miller wrote:
> You have come a long way from "If that means I get overruled, so be it."
> Dennis.
>
> Its a PMC vote where majority rules. As Bernd noted, vetoes are for
> specific svn
> commits with valid technical reasons. If you guys want to try and drag
> it out forever,
> I don't see much to stop you from trying, but the whole situation is
> pretty clear.
>
> I, for one, am looking forward to what this merge will bring to Lucene
> and Solr.
>
>
> On 03/12/2010 09:15 AM, Dennis Kubes wrote:
>> Yes railroading.
>>
>> Many people don't want this to occur. More than just minus 2.
>> Underlying concerns are not being addressed. Vetos count. Ignoring
>> that is ignoring how Apache operates. Merging projects is definitely
>> a code change. Getting around it by saying this is a goal is
>> fundamentally wrong.
>>
>> 1) What prevents functionality be moved over into Lucene within the
>> current project structure? Nothing, so why are we even discussing
>> this.
>>
>> 2) Why is Solr getting special treatment? Because there is a lot of
>> committer overlap? Should I propose to merge Nutch in too, lets just
>> have one big project, no distinctions.
>>
>> 3) Why the big push here to blur project responsibilities? Idk, I
>> keep wondering that myself.
>>
>> Dennis
>>
>> Grant Ingersoll wrote:
>> > On Mar 12, 2010, at 7:54 AM, Dennis Kubes wrote:
>> >
>> >> This has definitely NOT passed. With as much contention,
>> >> discussion, and debate as there has been on this, saying that it
>> >> has passed is akin to saying "we are just going to do it
>> >> anyways". This is being railroaded IMO and needs to be taken to
>> >> a higher level within the Apache organization.
>> >
>> > How is two weeks of discussion and all the committers on the
>> > projects minus 2 being for it and three different votes on it (all
>> > with the same outcome), "railroading"? -Grant
>
>
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Mark Miller <ma...@gmail.com>.
You have come a long way from "If that means I get overruled, so be it."
Dennis.
Its a PMC vote where majority rules. As Bernd noted, vetoes are for
specific svn
commits with valid technical reasons. If you guys want to try and drag
it out forever,
I don't see much to stop you from trying, but the whole situation is
pretty clear.
I, for one, am looking forward to what this merge will bring to Lucene
and Solr.
On 03/12/2010 09:15 AM, Dennis Kubes wrote:
> Yes railroading.
>
> Many people don't want this to occur. More than just minus 2.
> Underlying concerns are not being addressed. Vetos count. Ignoring
> that is ignoring how Apache operates. Merging projects is definitely
> a code change. Getting around it by saying this is a goal is
> fundamentally wrong.
>
> 1) What prevents functionality be moved over into Lucene within the
> current project structure? Nothing, so why are we even discussing
> this.
>
> 2) Why is Solr getting special treatment? Because there is a lot of
> committer overlap? Should I propose to merge Nutch in too, lets just
> have one big project, no distinctions.
>
> 3) Why the big push here to blur project responsibilities? Idk, I
> keep wondering that myself.
>
> Dennis
>
> Grant Ingersoll wrote:
> > On Mar 12, 2010, at 7:54 AM, Dennis Kubes wrote:
> >
> >> This has definitely NOT passed. With as much contention,
> >> discussion, and debate as there has been on this, saying that it
> >> has passed is akin to saying "we are just going to do it
> >> anyways". This is being railroaded IMO and needs to be taken to
> >> a higher level within the Apache organization.
> >
> > How is two weeks of discussion and all the committers on the
> > projects minus 2 being for it and three different votes on it (all
> > with the same outcome), "railroading"? -Grant
--
- Mark
http://www.lucidimagination.com
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Dennis Kubes <ku...@apache.org>.
Yes railroading.
Many people don't want this to occur. More than just minus 2.
Underlying concerns are not being addressed. Vetos count. Ignoring
that is ignoring how Apache operates. Merging projects is definitely a
code change. Getting around it by saying this is a goal is
fundamentally wrong.
1) What prevents functionality be moved over into Lucene within the
current project structure? Nothing, so why are we even discussing this.
2) Why is Solr getting special treatment? Because there is a lot of
committer overlap? Should I propose to merge Nutch in too, lets just
have one big project, no distinctions.
3) Why the big push here to blur project responsibilities? Idk, I keep
wondering that myself.
Dennis
Grant Ingersoll wrote:
> On Mar 12, 2010, at 7:54 AM, Dennis Kubes wrote:
>
>> This has definitely NOT passed. With as much contention, discussion, and debate as there has been on this, saying that it has passed is akin to saying "we are just going to do it anyways". This is being railroaded IMO and needs to be taken to a higher level within the Apache organization.
>
> How is two weeks of discussion and all the committers on the projects minus 2 being for it and three different votes on it (all with the same outcome), "railroading"?
>
> -Grant
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Grant Ingersoll <gs...@apache.org>.
On Mar 12, 2010, at 7:54 AM, Dennis Kubes wrote:
> This has definitely NOT passed. With as much contention, discussion, and debate as there has been on this, saying that it has passed is akin to saying "we are just going to do it anyways". This is being railroaded IMO and needs to be taken to a higher level within the Apache organization.
How is two weeks of discussion and all the committers on the projects minus 2 being for it and three different votes on it (all with the same outcome), "railroading"?
-Grant
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Otis Gospodnetic <ot...@yahoo.com>.
Hello,
----- Original Message ----
> From: Grant Ingersoll <gs...@apache.org>
> To: general@lucene.apache.org
> Sent: Fri, March 12, 2010 11:21:57 AM
> Subject: Re: [VOTE] merge lucene/solr development (take 3)
>
>
On Mar 12, 2010, at 11:07 AM, Mattmann, Chris A (388J) wrote:
>
> Here's what I didn't like. The vote was:
>
> * ambiguous
> *
> something that the Solr devs tried to push through and bullied folks on during
> discussion (those who originally had questions were persuaded that it was the
> "right thing to do" by those in the PMC leadership).
It was Mike's
> proposal to begin with and he isn't a Solr committer. As I said in the
> email the delta of Lucene committers who are not Solr committers are all either
> +1 or 0 and they are the ones doing the work. Go look at the votes.
> As for persuasion, isn't that how discussions work? Both sides make there
> case and then people vote.
I think that's part of the problem. There was no clear vote, but discussion+voting all mixed up. Which is why it's hard to get a clear, objective picture of what happened with the vote.
> * not healthy for the
> project
Clearly, you are in the minority on that view, especially given
> that the all of the most active Lucene committers are for it. There is
> still going to be Solr and still going to be Lucene.
Does "most active" vs. "less actively" matter during voting or is everyone's vote count the same? If the latter, than "most active" mention above has no merit.
> * subject to
> VETO since at the very least it proposes code modifications, but also
> because:
No, it doesn't. No one has proposed any code mods.
> There is still going to be Solr and still going to be Lucene. Separate
> JARs. Separate WARs. You will likely see some code moved (analyzers
> to start), but you can veto those specific moves when the time comes if you
> don't think it makes sense.
That's correct.
Otis
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Mark Miller <ma...@gmail.com>.
On 03/14/2010 12:12 PM, Otis Gospodnetic wrote:
> But I also recall people (Mark Miller maybe?) saying that the votes are not being counted and we are just looking to get an idea about the sentiment on this suggestion (paraphrasing him, sorry if I messed something up).
>
> Otis
>
When I tallied up the in progress votes, I said it was not an official
tally because I didn't want to claim I could make that call. I was just
trying to show where people stood with the votes - kind of clearing that
out of the discussion. And to let people clarify if they didn't actually
mean to vote that way.
Technically, committer votes are not binding. That's why we had the
third vote - the PMC vote - really they are the only binding votes on
anything - though of course they should probably take the larger
community in mind when deciding how they will vote.
So the reason we had 3 votes, from what I saw:
The first vote was just to gauge the committers - technically, according
to Apache rules, committers can't actually confirm something like this
happening (though it does say some can have earned enough merritt to
have a binding vote - not sure who would decide that though). Apache
says that "those that do decide", but it also says that PMC members have
the only binding votes. Its an "interesting" intersection I'll admit.
The second vote was to change things so that Grant, Michael Busch, and
Andi were more comfortable with the proposal - they all liked the idea
of adding that Lucene could release without Solr. Mike McCandless
decided to change the proposal, and so we went with another vote.
Apparently we were all okay with that change.
The third vote was the PMC vote - that's really a vote that had to
happen, because they have the binding votes.
--
- Mark
http://www.lucidimagination.com
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Otis Gospodnetic <ot...@yahoo.com>.
Hello,
----- Original Message ----
> From: Grant Ingersoll <gs...@apache.org>
> To: general@lucene.apache.org
> Sent: Fri, March 12, 2010 12:03:07 PM
> Subject: Re: [VOTE] merge lucene/solr development (take 3)
>
>
On Mar 12, 2010, at 11:54 AM, patrick o'leary wrote:
>>> Go
> look at the votes.
>
> Which ones? from vote 1 2 or
> 3??
3. That is this thread.
But I also recall people (Mark Miller maybe?) saying that the votes are not being counted and we are just looking to get an idea about the sentiment on this suggestion (paraphrasing him, sorry if I messed something up).
Otis
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Grant Ingersoll <gs...@apache.org>.
On Mar 12, 2010, at 11:54 AM, patrick o'leary wrote:
>>> Go look at the votes.
>
> Which ones? from vote 1 2 or 3??
3. That is this thread.
Re: [VOTE] merge lucene/solr development (take 3)
Posted by patrick o'leary <pj...@pjaol.com>.
>>Go look at the votes.
Which ones? from vote 1 2 or 3??
On Fri, Mar 12, 2010 at 8:21 AM, Grant Ingersoll <gs...@apache.org>wrote:
>
> On Mar 12, 2010, at 11:07 AM, Mattmann, Chris A (388J) wrote:
>
> > Here's what I didn't like. The vote was:
> >
> > * ambiguous
> > * something that the Solr devs tried to push through and bullied folks on
> during discussion (those who originally had questions were persuaded that it
> was the "right thing to do" by those in the PMC leadership).
>
> It was Mike's proposal to begin with and he isn't a Solr committer. As I
> said in the email the delta of Lucene committers who are not Solr committers
> are all either +1 or 0 and they are the ones doing the work. Go look at the
> votes. As for persuasion, isn't that how discussions work? Both sides make
> there case and then people vote.
>
> > * not healthy for the project
>
> Clearly, you are in the minority on that view, especially given that the
> all of the most active Lucene committers are for it. There is still going
> to be Solr and still going to be Lucene.
>
> > * subject to VETO since at the very least it proposes code modifications,
> but also because:
>
> No, it doesn't. No one has proposed any code mods. There is still going
> to be Solr and still going to be Lucene. Separate JARs. Separate WARs.
> You will likely see some code moved (analyzers to start), but you can veto
> those specific moves when the time comes if you don't think it makes sense.
>
>
>
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Grant Ingersoll <gs...@apache.org>.
On Mar 12, 2010, at 11:07 AM, Mattmann, Chris A (388J) wrote:
> Here's what I didn't like. The vote was:
>
> * ambiguous
> * something that the Solr devs tried to push through and bullied folks on during discussion (those who originally had questions were persuaded that it was the "right thing to do" by those in the PMC leadership).
It was Mike's proposal to begin with and he isn't a Solr committer. As I said in the email the delta of Lucene committers who are not Solr committers are all either +1 or 0 and they are the ones doing the work. Go look at the votes. As for persuasion, isn't that how discussions work? Both sides make there case and then people vote.
> * not healthy for the project
Clearly, you are in the minority on that view, especially given that the all of the most active Lucene committers are for it. There is still going to be Solr and still going to be Lucene.
> * subject to VETO since at the very least it proposes code modifications, but also because:
No, it doesn't. No one has proposed any code mods. There is still going to be Solr and still going to be Lucene. Separate JARs. Separate WARs. You will likely see some code moved (analyzers to start), but you can veto those specific moves when the time comes if you don't think it makes sense.
Re: [VOTE] merge lucene/solr development (take 3)
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Here's what I didn't like. The vote was:
* ambiguous
* something that the Solr devs tried to push through and bullied folks on during discussion (those who originally had questions were persuaded that it was the "right thing to do" by those in the PMC leadership).
* not healthy for the project
* subject to VETO since at the very least it proposes code modifications, but also because:
- there have been seemingly hundreds of emails over the last week just to discuss this issue, with there being enough misunderstanding to have folks recommending that we (a) break the proposal up into concrete, actionable (retractable) steps, and; (b) at the very least sitting on it for a week and then revisiting the issue.
Also rather than "speculating" on what the board will do, I'd rather just find out.
Cheers,
Chris
On 3/12/10 5:26 AM, "Bernd Fondermann" <be...@googlemail.com> wrote:
What's it that you don't like about the vote?
o that it wasn't prepended with enough community [DISCUSS]
o the phrasing of the vote itself
o the length of the voting process
o the outcome of the vote
o something else
Just curious.
BTW, I think it will be hard to appeal to the board or any other body
of the ASF (IMHO).
The Lucene PMC is tasked with directing the project and functional in
doing so (as far as I can see).
And honestly, if there would be another VOTE (or 10 such votes),
wouldn't the outcome in terms of general direction of the project be
the same, entirely?
Bernd
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: Chris.Mattmann@jpl.nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Bernd Fondermann <be...@googlemail.com>.
On Fri, Mar 12, 2010 at 13:54, Dennis Kubes <ku...@apache.org> wrote:
> This has definitely NOT passed. With as much contention, discussion, and
> debate as there has been on this, saying that it has passed is akin to
> saying "we are just going to do it anyways". This is being railroaded IMO
> and needs to be taken to a higher level within the Apache organization.
What's it that you don't like about the vote?
o that it wasn't prepended with enough community [DISCUSS]
o the phrasing of the vote itself
o the length of the voting process
o the outcome of the vote
o something else
Just curious.
BTW, I think it will be hard to appeal to the board or any other body
of the ASF (IMHO).
The Lucene PMC is tasked with directing the project and functional in
doing so (as far as I can see).
And honestly, if there would be another VOTE (or 10 such votes),
wouldn't the outcome in terms of general direction of the project be
the same, entirely?
Bernd
>
> Dennis
>
> Yonik Seeley wrote:
>>
>> Thanks everyone, this vote has passed.
>> A bit more contentious of a PMC vote than usual, but the committer
>> vote was clear.
>>
>> -Yonik
>>
>>
>> On Mon, Mar 8, 2010 at 9:11 PM, Yonik Seeley <ys...@gmail.com> wrote:
>>>
>>> Apoligies in advance for calling yet another vote, but I just wanted
>>> to make sure this was official.
>>> Mike's second VOTE thread could probably technically stand on it's own
>>> (since it included PMC votes), but given that I said in my previous
>>> VOTE thread that I was just polling Lucene/Solr committers and would
>>> call a second PMC vote, that may have acted to suppress PMC votes on
>>> Mike's thread also.
>>>
>>> Please vote for the proposal quoted below to merge lucene/solr
>>> development.
>>> Here's my +1
>>>
>>> -Yonik
>>>
>>> Mike's call for a VOTE (amongst lucene/solr committers +11 to -1):
>>>
>>> http://search.lucidimagination.com/search/document/a400ffe62ae21aca/vote_merge_the_development_of_solr_lucene_take_2#22d7cd086d9c5cf0
>>>>
>>>> Subject: 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.
>
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Dennis Kubes <ku...@apache.org>.
This has definitely NOT passed. With as much contention, discussion,
and debate as there has been on this, saying that it has passed is akin
to saying "we are just going to do it anyways". This is being
railroaded IMO and needs to be taken to a higher level within the Apache
organization.
Dennis
Yonik Seeley wrote:
> Thanks everyone, this vote has passed.
> A bit more contentious of a PMC vote than usual, but the committer
> vote was clear.
>
> -Yonik
>
>
> On Mon, Mar 8, 2010 at 9:11 PM, Yonik Seeley <ys...@gmail.com> wrote:
>> Apoligies in advance for calling yet another vote, but I just wanted
>> to make sure this was official.
>> Mike's second VOTE thread could probably technically stand on it's own
>> (since it included PMC votes), but given that I said in my previous
>> VOTE thread that I was just polling Lucene/Solr committers and would
>> call a second PMC vote, that may have acted to suppress PMC votes on
>> Mike's thread also.
>>
>> Please vote for the proposal quoted below to merge lucene/solr development.
>> Here's my +1
>>
>> -Yonik
>>
>> Mike's call for a VOTE (amongst lucene/solr committers +11 to -1):
>> http://search.lucidimagination.com/search/document/a400ffe62ae21aca/vote_merge_the_development_of_solr_lucene_take_2#22d7cd086d9c5cf0
>>> Subject: 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.
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Bernd Fondermann <be...@googlemail.com>.
On Fri, Mar 12, 2010 at 17:04, Mattmann, Chris A (388J)
<ch...@jpl.nasa.gov> wrote:
> Hi Bernd,
>
>> On Fri, Mar 12, 2010 at 04:29, Mattmann, Chris A (388J)
>> <ch...@jpl.nasa.gov> wrote:
>>> Hi Yonik,
>>>
>>> IMO, this vote has not passed. A bullet of this proposal proposes code
>>> modifications and this is subject to VETO per Apache guidelines:
>>>
>>> http://www.apache.org/foundation/voting.html#Veto
>>
>> Vetos only relate to some specific svn commit.
>> You cannot veto proposals, releases, strategic decisions and anything else.
>>
>> (This is intended to be a generic comment, I'm not commenting on the
>> vote(s) in this thread itself.)
>
> Actually code modifications are those performed or proposed.
Well, this project is about code, so nearly any discussion will result
in code changes in some way.
> At least that's
> my interpretation, but I'm not an ASF lawyer :)
A technical veto is a very powerful tool, so there's a strict set of
conditions to be met.
Clearly, for me, this is a strategic decision, but...
> Let's ask the board though
> -- they can help.
... hey, try it. It can't be bad.
> Regardless, even if that point is moot, the sheer amount of emails,
> discussion, amendments, etc., to these 3 sets of proposals and their
> evolution is enough for me to also believe that this was too nebulous of a
> vote to even know what you're voting on.
+1. This is something I agree with. In my personal opinion, a vote
should only ratify a consensus reached - or - cut a decision after a
long running discussion where all arguments have been exchanged
multiple times where no consensus could be reached. It would have been
much better to first have a [DISCUSS] thread, followed up with a
[PROPOSAL], ratified by a [VOTE] for such a fundamental change in the
project's organisation.
> So, I'd like to ask the board about
> that, and plan to.
There you go.
BTW, I think we will notice that the PMC chair will mention this
discussion in his upcoming report.
Bernd
Re: [VOTE] merge lucene/solr development (take 3)
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hi Bernd,
> On Fri, Mar 12, 2010 at 04:29, Mattmann, Chris A (388J)
> <ch...@jpl.nasa.gov> wrote:
>> Hi Yonik,
>>
>> IMO, this vote has not passed. A bullet of this proposal proposes code
>> modifications and this is subject to VETO per Apache guidelines:
>>
>> http://www.apache.org/foundation/voting.html#Veto
>
> Vetos only relate to some specific svn commit.
> You cannot veto proposals, releases, strategic decisions and anything else.
>
> (This is intended to be a generic comment, I'm not commenting on the
> vote(s) in this thread itself.)
Actually code modifications are those performed or proposed. At least that's
my interpretation, but I'm not an ASF lawyer :) Let's ask the board though
-- they can help.
Regardless, even if that point is moot, the sheer amount of emails,
discussion, amendments, etc., to these 3 sets of proposals and their
evolution is enough for me to also believe that this was too nebulous of a
vote to even know what you're voting on. So, I'd like to ask the board about
that, and plan to.
>
>>
>> Since that point is up for debate, I think we can get clarification on this
>> from the board at their next meeting, but I dispute calling the VOTE
>> "passed" until that time.
>
> At this point, I don't think the board can really help resolving this
> issue any better than this community can.
Well that's your perspective. I have a different one.
Cheers,
Chris
>
> Bernd
>
>> In the meanwhile there has been much community discussion and points made in
>> favor of each point of view over the past week. My recommendation is to sit
>> on this for at least a week, then revisit the issue with clear and concise
>> goals, and incremental pieces to vote on.
>>
>> Cheers,
>> Chris
>>
>> On 3/11/10 6:29 PM, "Yonik Seeley" <yo...@apache.org> wrote:
>>
>>> Thanks everyone, this vote has passed.
>>> A bit more contentious of a PMC vote than usual, but the committer
>>> vote was clear.
>>>
>>> -Yonik
>>>
>>>
>>> On Mon, Mar 8, 2010 at 9:11 PM, Yonik Seeley <ys...@gmail.com> wrote:
>>>> Apoligies in advance for calling yet another vote, but I just wanted
>>>> to make sure this was official.
>>>> Mike's second VOTE thread could probably technically stand on it's own
>>>> (since it included PMC votes), but given that I said in my previous
>>>> VOTE thread that I was just polling Lucene/Solr committers and would
>>>> call a second PMC vote, that may have acted to suppress PMC votes on
>>>> Mike's thread also.
>>>>
>>>> Please vote for the proposal quoted below to merge lucene/solr development.
>>>> Here's my +1
>>>>
>>>> -Yonik
>>>>
>>>> Mike's call for a VOTE (amongst lucene/solr committers +11 to -1):
>>>> http://search.lucidimagination.com/search/document/a400ffe62ae21aca/vote_me
>>>> rg
>>>> e_the_development_of_solr_lucene_take_2#22d7cd086d9c5cf0
>>>>> Subject: 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.
>>>>
>>>
>>
>>
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> Chris Mattmann, Ph.D.
>> Senior Computer Scientist
>> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
>> Office: 171-266B, Mailstop: 171-246
>> Email: Chris.Mattmann@jpl.nasa.gov
>> WWW: http://sunset.usc.edu/~mattmann/
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> Adjunct Assistant Professor, Computer Science Department
>> University of Southern California, Los Angeles, CA 90089 USA
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>
>>
>>
>
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: Chris.Mattmann@jpl.nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Bernd Fondermann <be...@googlemail.com>.
On Fri, Mar 12, 2010 at 04:29, Mattmann, Chris A (388J)
<ch...@jpl.nasa.gov> wrote:
> Hi Yonik,
>
> IMO, this vote has not passed. A bullet of this proposal proposes code
> modifications and this is subject to VETO per Apache guidelines:
>
> http://www.apache.org/foundation/voting.html#Veto
Vetos only relate to some specific svn commit.
You cannot veto proposals, releases, strategic decisions and anything else.
(This is intended to be a generic comment, I'm not commenting on the
vote(s) in this thread itself.)
>
> Since that point is up for debate, I think we can get clarification on this
> from the board at their next meeting, but I dispute calling the VOTE
> "passed" until that time.
At this point, I don't think the board can really help resolving this
issue any better than this community can.
Bernd
> In the meanwhile there has been much community discussion and points made in
> favor of each point of view over the past week. My recommendation is to sit
> on this for at least a week, then revisit the issue with clear and concise
> goals, and incremental pieces to vote on.
>
> Cheers,
> Chris
>
> On 3/11/10 6:29 PM, "Yonik Seeley" <yo...@apache.org> wrote:
>
>> Thanks everyone, this vote has passed.
>> A bit more contentious of a PMC vote than usual, but the committer
>> vote was clear.
>>
>> -Yonik
>>
>>
>> On Mon, Mar 8, 2010 at 9:11 PM, Yonik Seeley <ys...@gmail.com> wrote:
>>> Apoligies in advance for calling yet another vote, but I just wanted
>>> to make sure this was official.
>>> Mike's second VOTE thread could probably technically stand on it's own
>>> (since it included PMC votes), but given that I said in my previous
>>> VOTE thread that I was just polling Lucene/Solr committers and would
>>> call a second PMC vote, that may have acted to suppress PMC votes on
>>> Mike's thread also.
>>>
>>> Please vote for the proposal quoted below to merge lucene/solr development.
>>> Here's my +1
>>>
>>> -Yonik
>>>
>>> Mike's call for a VOTE (amongst lucene/solr committers +11 to -1):
>>> http://search.lucidimagination.com/search/document/a400ffe62ae21aca/vote_merg
>>> e_the_development_of_solr_lucene_take_2#22d7cd086d9c5cf0
>>>> Subject: 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.
>>>
>>
>
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Chris Mattmann, Ph.D.
> Senior Computer Scientist
> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> Office: 171-266B, Mailstop: 171-246
> Email: Chris.Mattmann@jpl.nasa.gov
> WWW: http://sunset.usc.edu/~mattmann/
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Adjunct Assistant Professor, Computer Science Department
> University of Southern California, Los Angeles, CA 90089 USA
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>
>
Re: [VOTE] merge lucene/solr development (take 3)
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hi Yonik,
IMO, this vote has not passed. A bullet of this proposal proposes code
modifications and this is subject to VETO per Apache guidelines:
http://www.apache.org/foundation/voting.html#Veto
Since that point is up for debate, I think we can get clarification on this
from the board at their next meeting, but I dispute calling the VOTE
"passed" until that time.
In the meanwhile there has been much community discussion and points made in
favor of each point of view over the past week. My recommendation is to sit
on this for at least a week, then revisit the issue with clear and concise
goals, and incremental pieces to vote on.
Cheers,
Chris
On 3/11/10 6:29 PM, "Yonik Seeley" <yo...@apache.org> wrote:
> Thanks everyone, this vote has passed.
> A bit more contentious of a PMC vote than usual, but the committer
> vote was clear.
>
> -Yonik
>
>
> On Mon, Mar 8, 2010 at 9:11 PM, Yonik Seeley <ys...@gmail.com> wrote:
>> Apoligies in advance for calling yet another vote, but I just wanted
>> to make sure this was official.
>> Mike's second VOTE thread could probably technically stand on it's own
>> (since it included PMC votes), but given that I said in my previous
>> VOTE thread that I was just polling Lucene/Solr committers and would
>> call a second PMC vote, that may have acted to suppress PMC votes on
>> Mike's thread also.
>>
>> Please vote for the proposal quoted below to merge lucene/solr development.
>> Here's my +1
>>
>> -Yonik
>>
>> Mike's call for a VOTE (amongst lucene/solr committers +11 to -1):
>> http://search.lucidimagination.com/search/document/a400ffe62ae21aca/vote_merg
>> e_the_development_of_solr_lucene_take_2#22d7cd086d9c5cf0
>>> Subject: 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.
>>
>
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: Chris.Mattmann@jpl.nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Yonik Seeley <yo...@apache.org>.
Thanks everyone, this vote has passed.
A bit more contentious of a PMC vote than usual, but the committer
vote was clear.
-Yonik
On Mon, Mar 8, 2010 at 9:11 PM, Yonik Seeley <ys...@gmail.com> wrote:
> Apoligies in advance for calling yet another vote, but I just wanted
> to make sure this was official.
> Mike's second VOTE thread could probably technically stand on it's own
> (since it included PMC votes), but given that I said in my previous
> VOTE thread that I was just polling Lucene/Solr committers and would
> call a second PMC vote, that may have acted to suppress PMC votes on
> Mike's thread also.
>
> Please vote for the proposal quoted below to merge lucene/solr development.
> Here's my +1
>
> -Yonik
>
> Mike's call for a VOTE (amongst lucene/solr committers +11 to -1):
> http://search.lucidimagination.com/search/document/a400ffe62ae21aca/vote_merge_the_development_of_solr_lucene_take_2#22d7cd086d9c5cf0
>> Subject: 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.
>
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Mark Miller <ma...@gmail.com>.
I alerted java-dev and solr-dev of the committer vote - we are now onto
a PMC vote.
On 03/08/2010 10:18 PM, Ian Holsman wrote:
> you should x-post this on solr-dev.
>
> (not a committer so no vote for me)
> On 3/9/10 1:11 PM, Yonik Seeley wrote:
>> Apoligies in advance for calling yet another vote, but I just wanted
>> to make sure this was official.
>> Mike's second VOTE thread could probably technically stand on it's own
>> (since it included PMC votes), but given that I said in my previous
>> VOTE thread that I was just polling Lucene/Solr committers and would
>> call a second PMC vote, that may have acted to suppress PMC votes on
>> Mike's thread also.
>>
>> Please vote for the proposal quoted below to merge lucene/solr
>> development.
>> Here's my +1
>>
>> -Yonik
>>
>> Mike's call for a VOTE (amongst lucene/solr committers +11 to -1):
>> http://search.lucidimagination.com/search/document/a400ffe62ae21aca/vote_merge_the_development_of_solr_lucene_take_2#22d7cd086d9c5cf0
>>
>>> Subject: 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.
>
--
- Mark
http://www.lucidimagination.com
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Ian Holsman <li...@holsman.net>.
you should x-post this on solr-dev.
(not a committer so no vote for me)
On 3/9/10 1:11 PM, Yonik Seeley wrote:
> Apoligies in advance for calling yet another vote, but I just wanted
> to make sure this was official.
> Mike's second VOTE thread could probably technically stand on it's own
> (since it included PMC votes), but given that I said in my previous
> VOTE thread that I was just polling Lucene/Solr committers and would
> call a second PMC vote, that may have acted to suppress PMC votes on
> Mike's thread also.
>
> Please vote for the proposal quoted below to merge lucene/solr development.
> Here's my +1
>
> -Yonik
>
> Mike's call for a VOTE (amongst lucene/solr committers +11 to -1):
> http://search.lucidimagination.com/search/document/a400ffe62ae21aca/vote_merge_the_development_of_solr_lucene_take_2#22d7cd086d9c5cf0
>
>> Subject: 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.
>>
>
Re: [VOTE] merge lucene/solr development (take 3)
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hey Mark,
I hear ya on that. No worries.
Cheers,
Chris
On 3/8/10 6:58 PM, "Mark Miller" <ma...@gmail.com> wrote:
On 03/08/2010 09:50 PM, Mattmann, Chris A (388J) wrote:
>
> won't
> happen again.
>
Thanks - I'm obviously not terribly upset about it, but I'd like to
feel that things I send to private won't go public without me making it
so, since I will write those emails thinking such.
--
- Mark
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: Chris.Mattmann@jpl.nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Mark Miller <ma...@gmail.com>.
On 03/08/2010 09:50 PM, Mattmann, Chris A (388J) wrote:
>
> won't
> happen again.
>
Thanks - I'm obviously not terribly upset about it, but I'd like to
feel that things I send to private won't go public without me making it
so, since I will write those emails thinking such.
--
- Mark
Re: [VOTE] merge lucene/solr development (take 3)
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
>> Yet the information we were voting on is public information really and this
>> doesn't really count as "sensitive" IMO.
> Any thing I send to private@, I kind of count on not being public. I'd
> rather you not decide that for me. In this case, I'm not terribly upset
> that my private vote has gotten out - but again, I'd prefer that you
> didn't make that call for me. I gave reasons for me vote, and you have
> taken the liberty of taking my vote apart from them - I don't like that
> either.
If you're unhappy I've passed along your private vote, sorry about that. I
think that the natural interpretation of the comments (and subsequent
actions) is that this is a vote best held in public, so I imagined since no
one's vote really changed from the public version we've held 2 times already
(nor did the rationale seemingly) it was a liberty to take. In any case,
sorry to take your liberty away from providing your own private vote, won't
happen again.
>
>> I'd venture to guess not all the PMC is subscribed to general@, and may miss
>> this vote, so it's important their votes be counted.
>>
> If you concerned about this, the best way to handle it is to send them a
> note. Or send a followup to private@ with a reminder
> that a vote is happening on general@.
That's one way, sure. If it's not a sensitive matter, it's typical Apache
policy for the PMC to conduct as much non-sensitive business in public as
possible. Passing along non-sensitive information for completeness on a VOTE
with impact is a just cause IMO. But, everyone is free to their own
interpretation and those other folks can feel free to re-chime in with their
votes (I've CC'ed them on this message -- please reply to general@).
Cheers,
Chris
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: Chris.Mattmann@jpl.nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Mark Miller <ma...@gmail.com>.
On 03/08/2010 09:32 PM, Mattmann, Chris A (388J) wrote:
> Yet the information we were voting on is public information really and this doesn't really count as "sensitive" IMO.
Any thing I send to private@, I kind of count on not being public. I'd
rather you not decide that for me. In this case, I'm not terribly upset
that my private vote has gotten out - but again, I'd prefer that you
didn't make that call for me. I gave reasons for me vote, and you have
taken the liberty of taking my vote apart from them - I don't like that
either.
> I'd venture to guess not all the PMC is subscribed to general@, and may miss this vote, so it's important their votes be counted.
>
If you concerned about this, the best way to handle it is to send them a
note. Or send a followup to private@ with a reminder
that a vote is happening on general@. Get permission to take their
private votes public for them. Anything would be better than making our
private communications public - whether we decided the vote should have
been done in public or not.
> Chris
>
>
>
> On 3/8/10 6:23 PM, "Yonik Seeley"<ys...@gmail.com> wrote:
>
> On Mon, Mar 8, 2010 at 9:22 PM, Mattmann, Chris A (388J)
> <ch...@jpl.nasa.gov> wrote:
>
>> For completeness from the VOTE on private@
>>
> It's called private for a reason.
>
> -Yonik
>
>
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Chris Mattmann, Ph.D.
> Senior Computer Scientist
> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> Office: 171-266B, Mailstop: 171-246
> Email: Chris.Mattmann@jpl.nasa.gov
> WWW: http://sunset.usc.edu/~mattmann/
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Adjunct Assistant Professor, Computer Science Department
> University of Southern California, Los Angeles, CA 90089 USA
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>
>
--
- Mark
http://www.lucidimagination.com
Re: [VOTE] merge lucene/solr development (take 3)
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Yet the information we were voting on is public information really and this doesn't really count as "sensitive" IMO. I'd venture to guess not all the PMC is subscribed to general@, and may miss this vote, so it's important their votes be counted.
Chris
On 3/8/10 6:23 PM, "Yonik Seeley" <ys...@gmail.com> wrote:
On Mon, Mar 8, 2010 at 9:22 PM, Mattmann, Chris A (388J)
<ch...@jpl.nasa.gov> wrote:
> For completeness from the VOTE on private@
It's called private for a reason.
-Yonik
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: Chris.Mattmann@jpl.nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Re: [VOTE] merge lucene/solr development (take 3)
Posted by Yonik Seeley <ys...@gmail.com>.
On Mon, Mar 8, 2010 at 9:22 PM, Mattmann, Chris A (388J)
<ch...@jpl.nasa.gov> wrote:
> For completeness from the VOTE on private@
It's called private for a reason.
-Yonik
Re: [VOTE] merge lucene/solr development (take 3)
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
For completeness from the VOTE on private@
PMC votes:
========================
+1
Mark Miller
Michael McCandless
Yonik Seely
Ryan McKinley
-0
Doug Cutting
-1
Dennis Kubes
Scott Ganyo
Chris Mattmann
Cheers,
Chris
On 3/8/10 6:11 PM, "Yonik Seeley" <ys...@gmail.com> wrote:
Apoligies in advance for calling yet another vote, but I just wanted
to make sure this was official.
Mike's second VOTE thread could probably technically stand on it's own
(since it included PMC votes), but given that I said in my previous
VOTE thread that I was just polling Lucene/Solr committers and would
call a second PMC vote, that may have acted to suppress PMC votes on
Mike's thread also.
Please vote for the proposal quoted below to merge lucene/solr development.
Here's my +1
-Yonik
Mike's call for a VOTE (amongst lucene/solr committers +11 to -1):
http://search.lucidimagination.com/search/document/a400ffe62ae21aca/vote_merge_the_development_of_solr_lucene_take_2#22d7cd086d9c5cf0
> Subject: 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.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: Chris.Mattmann@jpl.nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++