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 <yo...@apache.org> on 2011/04/26 20:50:02 UTC
[VOTE] Create Solr TLP
A single merged project works only when people are relatively on the same page,
and when people feel it's mutually beneficial. Recent events make it
clear that that
is no longer the case.
Improvements to Solr have been recently blocked and reverted on the
grounds that the new functionality was not immediately available to
non-Solr users.
This was obviously never part of the original idea (well actually - it was
considered but rejected as too onerous). But the past doesn't matter as
much as the present - about how people chose to act and interpret
things today.
https://issues.apache.org/jira/browse/SOLR-2272
http://markmail.org/message/unrvjfudcbgqatsy
Some people warned us against merging at the start, and I guess it
turns out they were right.
I no longer feel it's in Solr's best interests to remain under the same
PMC as Lucene-Java, and I know some other committers who have said
they feel like Lucene got the short end of the stick. But rather than
arguing about who's right (maybe both?) since enough of us feel it's no longer
mutually beneficial, we should stop fighting and just go our separate
ways.
Please VOTE to create a new Apache Solr TLP.
Here's my +1
-Yonik
Re: [VOTE] Create Solr TLP
Posted by Mark Miller <ma...@gmail.com>.
My biggest de-merge argument is the loss of Uwe!! Who will handle Solr's sophisticated tokesteam jsps and xml obscurities.
On Apr 26, 2011, at 5:28 PM, Uwe Schindler wrote:
> Hi,
>
> Strong -1 to unmerge.
>
> Many of you know that I was originally against the merge, but once I saw the
> possibilities (especially refactoring the analysis stuff), I started to also
> actively support it. I helped together with lots of other
> previous-only-Lucene committers to move the svn together and rewrite parts
> of the build system. After that we started to move analyzers to one place,
> added Solr by factories for *all* Lucene analyzers available and vice versa
> opened Solr analyzers to Lucene users. We removed lots of deprecated code
> usage (which made Solr move from Lucene 2.9 to 3.0). This was especially the
> work of Lucene committers who originally developed the new analysis API.
> Solr had at this time not many active developers, so help from Lucene users
> was welcome. So at this time, the merge helped both projects.
>
> Problems started at that time, when some of us suggested to "remove"
> features from Solr and move it to Lucene Core, means faceting (I mentioned
> that first on a conference to the public, which disagreed some people),
> function queries, schema support, clustering, dismax. From my point of view
> as originally only a "Lucene Committer" is, that Solr was and is still
> somehow dominated by one person who is afraid of losing functionality in
> Solr that was originally developed by him and this could reduce the power of
> Solr on the market (yes, there is also a company behind, that mainly wants
> to sell consulting to Solr users [as this is of course easier to do], but
> that's just a side note).
>
> I think instead of splitting again, Lucene TLP should consider thinking
> about better communication between the committers, allow different opinions
> for Solr's later development and maybe vote a new PMC (as the current PMC
> was simply merged from Solr and Lucene, where conflicts are programmed).
>
> If the merged Lucene+Solr is not what the dominating person wants to have,
> it is free to fork Solr from Apache (yes it's open source and you can
> sell/provide a forked version to customers with only huper-duper features
> that separates from Lucene, but I think this is already done -
> LW-Enterprise). But if most committers here want to help to bring both
> Lucene+Solr to the top of search engines, they are free to do it at the ASF
> with discussion and also lots of code refactoring - we are using SVN, so we
> always have the track what was done. Reverting or not reverting is only
> political, nothing technical. And disagreement is also valid in an open
> source project, but disagreeing people should sometimes revise their opinion
> - this applies to a few more people here, I am also not always the best
> discussion partner (police is the executive... *g*).
>
> Uwe
>
> -----
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: uwe@thetaphi.de
>
>> -----Original Message-----
>> From: yseeley@gmail.com [mailto:yseeley@gmail.com] On Behalf Of Yonik
>> Seeley
>> Sent: Tuesday, April 26, 2011 8:50 PM
>> To: general@lucene.apache.org
>> Subject: [VOTE] Create Solr TLP
>>
>> A single merged project works only when people are relatively on the same
>> page, and when people feel it's mutually beneficial. Recent events make
> it
>> clear that that is no longer the case.
>>
>> Improvements to Solr have been recently blocked and reverted on the
>> grounds that the new functionality was not immediately available to
> non-Solr
>> users.
>> This was obviously never part of the original idea (well actually - it was
>> considered but rejected as too onerous). But the past doesn't matter as
>> much as the present - about how people chose to act and interpret things
>> today.
>>
>> https://issues.apache.org/jira/browse/SOLR-2272
>> http://markmail.org/message/unrvjfudcbgqatsy
>>
>> Some people warned us against merging at the start, and I guess it turns
> out
>> they were right.
>>
>> I no longer feel it's in Solr's best interests to remain under the same
> PMC as
>> Lucene-Java, and I know some other committers who have said they feel like
>> Lucene got the short end of the stick. But rather than arguing about
> who's
>> right (maybe both?) since enough of us feel it's no longer mutually
> beneficial,
>> we should stop fighting and just go our separate ways.
>>
>> Please VOTE to create a new Apache Solr TLP.
>>
>> Here's my +1
>>
>> -Yonik
>
- Mark Miller
lucidimagination.com
Lucene/Solr User Conference
May 25-26, San Francisco
www.lucenerevolution.org
RE: [VOTE] Create Solr TLP
Posted by Uwe Schindler <uw...@thetaphi.de>.
Hi,
Strong -1 to unmerge.
Many of you know that I was originally against the merge, but once I saw the
possibilities (especially refactoring the analysis stuff), I started to also
actively support it. I helped together with lots of other
previous-only-Lucene committers to move the svn together and rewrite parts
of the build system. After that we started to move analyzers to one place,
added Solr by factories for *all* Lucene analyzers available and vice versa
opened Solr analyzers to Lucene users. We removed lots of deprecated code
usage (which made Solr move from Lucene 2.9 to 3.0). This was especially the
work of Lucene committers who originally developed the new analysis API.
Solr had at this time not many active developers, so help from Lucene users
was welcome. So at this time, the merge helped both projects.
Problems started at that time, when some of us suggested to "remove"
features from Solr and move it to Lucene Core, means faceting (I mentioned
that first on a conference to the public, which disagreed some people),
function queries, schema support, clustering, dismax. From my point of view
as originally only a "Lucene Committer" is, that Solr was and is still
somehow dominated by one person who is afraid of losing functionality in
Solr that was originally developed by him and this could reduce the power of
Solr on the market (yes, there is also a company behind, that mainly wants
to sell consulting to Solr users [as this is of course easier to do], but
that's just a side note).
I think instead of splitting again, Lucene TLP should consider thinking
about better communication between the committers, allow different opinions
for Solr's later development and maybe vote a new PMC (as the current PMC
was simply merged from Solr and Lucene, where conflicts are programmed).
If the merged Lucene+Solr is not what the dominating person wants to have,
it is free to fork Solr from Apache (yes it's open source and you can
sell/provide a forked version to customers with only huper-duper features
that separates from Lucene, but I think this is already done -
LW-Enterprise). But if most committers here want to help to bring both
Lucene+Solr to the top of search engines, they are free to do it at the ASF
with discussion and also lots of code refactoring - we are using SVN, so we
always have the track what was done. Reverting or not reverting is only
political, nothing technical. And disagreement is also valid in an open
source project, but disagreeing people should sometimes revise their opinion
- this applies to a few more people here, I am also not always the best
discussion partner (police is the executive... *g*).
Uwe
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: uwe@thetaphi.de
> -----Original Message-----
> From: yseeley@gmail.com [mailto:yseeley@gmail.com] On Behalf Of Yonik
> Seeley
> Sent: Tuesday, April 26, 2011 8:50 PM
> To: general@lucene.apache.org
> Subject: [VOTE] Create Solr TLP
>
> A single merged project works only when people are relatively on the same
> page, and when people feel it's mutually beneficial. Recent events make
it
> clear that that is no longer the case.
>
> Improvements to Solr have been recently blocked and reverted on the
> grounds that the new functionality was not immediately available to
non-Solr
> users.
> This was obviously never part of the original idea (well actually - it was
> considered but rejected as too onerous). But the past doesn't matter as
> much as the present - about how people chose to act and interpret things
> today.
>
> https://issues.apache.org/jira/browse/SOLR-2272
> http://markmail.org/message/unrvjfudcbgqatsy
>
> Some people warned us against merging at the start, and I guess it turns
out
> they were right.
>
> I no longer feel it's in Solr's best interests to remain under the same
PMC as
> Lucene-Java, and I know some other committers who have said they feel like
> Lucene got the short end of the stick. But rather than arguing about
who's
> right (maybe both?) since enough of us feel it's no longer mutually
beneficial,
> we should stop fighting and just go our separate ways.
>
> Please VOTE to create a new Apache Solr TLP.
>
> Here's my +1
>
> -Yonik
Re: [VOTE] Create Solr TLP
Posted by Ryan McKinley <ry...@gmail.com>.
-1
for most of the same reasons everyone else is saying...
On Tue, Apr 26, 2011 at 2:50 PM, Yonik Seeley <yo...@apache.org> wrote:
> A single merged project works only when people are relatively on the same page,
> and when people feel it's mutually beneficial. Recent events make it
> clear that that
> is no longer the case.
>
> Improvements to Solr have been recently blocked and reverted on the
> grounds that the new functionality was not immediately available to
> non-Solr users.
> This was obviously never part of the original idea (well actually - it was
> considered but rejected as too onerous). But the past doesn't matter as
> much as the present - about how people chose to act and interpret
> things today.
>
> https://issues.apache.org/jira/browse/SOLR-2272
> http://markmail.org/message/unrvjfudcbgqatsy
>
> Some people warned us against merging at the start, and I guess it
> turns out they were right.
>
> I no longer feel it's in Solr's best interests to remain under the same
> PMC as Lucene-Java, and I know some other committers who have said
> they feel like Lucene got the short end of the stick. But rather than
> arguing about who's right (maybe both?) since enough of us feel it's no longer
> mutually beneficial, we should stop fighting and just go our separate
> ways.
>
> Please VOTE to create a new Apache Solr TLP.
>
> Here's my +1
>
> -Yonik
>
Re: [VOTE] Create Solr TLP
Posted by patrick o'leary <pj...@pjaol.com>.
Since when did not listening to the community and doing your own thing until
it all goes south... Qualify a project to become a TLP?
If anything Solr needs to be moved back to incubating.
On top of that the constant fighting with the community, which has
accomplished nothing but making contributors leave or move their development
out of Apache, shows that there is a need to mentor or review who is on the
PMC of SOLR / Lucene, and it's road map.
A big -1 because this project is in serious need of re-evaluation of it's
leadership and community cooperation.
I believe there is a need for a Lucene Revolution,a revolution to move SOLR
from a pseudo proprietary free code base back to an open source project, if
it wishes to remain within the ASF.
On Tue, Apr 26, 2011 at 11:50 AM, Yonik Seeley <yo...@apache.org> wrote:
> A single merged project works only when people are relatively on the same
> page,
> and when people feel it's mutually beneficial. Recent events make it
> clear that that
> is no longer the case.
>
> Improvements to Solr have been recently blocked and reverted on the
> grounds that the new functionality was not immediately available to
> non-Solr users.
> This was obviously never part of the original idea (well actually - it was
> considered but rejected as too onerous). But the past doesn't matter as
> much as the present - about how people chose to act and interpret
> things today.
>
> https://issues.apache.org/jira/browse/SOLR-2272
> http://markmail.org/message/unrvjfudcbgqatsy
>
> Some people warned us against merging at the start, and I guess it
> turns out they were right.
>
> I no longer feel it's in Solr's best interests to remain under the same
> PMC as Lucene-Java, and I know some other committers who have said
> they feel like Lucene got the short end of the stick. But rather than
> arguing about who's right (maybe both?) since enough of us feel it's no
> longer
> mutually beneficial, we should stop fighting and just go our separate
> ways.
>
> Please VOTE to create a new Apache Solr TLP.
>
> Here's my +1
>
> -Yonik
>
Re: [VOTE] Create Solr TLP
Posted by Andrzej Bialecki <ab...@getopt.org>.
On 4/26/11 8:50 PM, Yonik Seeley wrote:
> A single merged project works only when people are relatively on the same page,
> and when people feel it's mutually beneficial. Recent events make it
> clear that that
> is no longer the case.
>
> Improvements to Solr have been recently blocked and reverted on the
> grounds that the new functionality was not immediately available to
> non-Solr users.
> This was obviously never part of the original idea (well actually - it was
> considered but rejected as too onerous). But the past doesn't matter as
> much as the present - about how people chose to act and interpret
> things today.
>
> https://issues.apache.org/jira/browse/SOLR-2272
> http://markmail.org/message/unrvjfudcbgqatsy
>
> Some people warned us against merging at the start, and I guess it
> turns out they were right.
>
> I no longer feel it's in Solr's best interests to remain under the same
> PMC as Lucene-Java, and I know some other committers who have said
> they feel like Lucene got the short end of the stick. But rather than
> arguing about who's right (maybe both?) since enough of us feel it's no longer
> mutually beneficial, we should stop fighting and just go our separate
> ways.
>
> Please VOTE to create a new Apache Solr TLP.
>
> Here's my +1
-1 to unmerge - as others have said there are more good reasons to keep
these projects merged as they are now, and to keep resolving differences
in a respectful way.
-1 to blind dogmatism, to commit wars, and to unilateral decisions that
claim to represent "this or that (large) community group". And
emphatically -1 to name-calling.
+1 to iterative development, i.e. adding important new features when
they are proven to work, and refactoring/improving on them later.
--
Best regards,
Andrzej Bialecki <><
___. ___ ___ ___ _ _ __________________________________
[__ || __|__/|__||\/| Information Retrieval, Semantic Web
___|||__|| \| || | Embedded Unix, System Integration
http://www.sigram.com Contact: info at sigram dot com
Re: [VOTE] Create Solr TLP
Posted by Simon Willnauer <si...@googlemail.com>.
On Wed, Apr 27, 2011 at 3:34 AM, Grant Ingersoll <gs...@apache.org> wrote:
>
> On Apr 26, 2011, at 8:43 PM, Robert Muir wrote:
>>
>> But, this is important context to the discussion. Unfortunately, to
>> the uninformed community, asf board, members etc, my behavior likely
>> appears very irrational: but this is because they are unaware of these
>> private emails (which many of us STRONGLY encouraged to go to a
>> mailing list) expressing there should be no refactoring.
>>
>> Its unfortunate the PMC didn't address this immediately, instead we
>> all ignored the elephant in the room and ... hoped it would go away?
>>
>
> Yeah, we really should have a public discussion on modularization. I think there are pros and cons on both sides of it and we should debate it for a bit. I'm not sure what the result will be or if it will fix anything, but it would be good to outline all the pros and cons on both sides and see if we can't find a common ground strategy going forward.
I really think it is pointless to call out another discussion on the
PMC or in public or in writing directly to committers. There is
nothing left we can vote on, we voted on merging and we discussed
enough what it means. One thing that remains is the attitude of
individuals to ignore what we voted on and that will not change no
matter how many votes we call. I am so over these discussions but on
the other hand I won't let people get away with ignoring our votes and
taking it to the next level in terms of moving TLP or incubating just
to get rid of people that are, lets say inconvenient. I already hear
somebody saying "what are you talking about..." well I think I have
spelled out my opinion on the list regarding all these problems and
writing them down is a waste of time.
ps: @yonik I am really disappointed that you not even bothered to
reply on the private mail you send to a majority of committers but
pull me into yet another private IRC discussion that nobody can
follow. If you can't tell your concernes and problems on the list but
only in private and the last resort is moving TLP and still not saying
out loud why you going this path makes me wonder if you should think
about the situation you are facing again and consider the attitude
being the problem not the code.
here is my -1 to unmerge
>
> -Grant
>
>
>
>
Re: [VOTE] Create Solr TLP
Posted by Grant Ingersoll <gs...@apache.org>.
On Apr 26, 2011, at 8:43 PM, Robert Muir wrote:
>
> But, this is important context to the discussion. Unfortunately, to
> the uninformed community, asf board, members etc, my behavior likely
> appears very irrational: but this is because they are unaware of these
> private emails (which many of us STRONGLY encouraged to go to a
> mailing list) expressing there should be no refactoring.
>
> Its unfortunate the PMC didn't address this immediately, instead we
> all ignored the elephant in the room and ... hoped it would go away?
>
Yeah, we really should have a public discussion on modularization. I think there are pros and cons on both sides of it and we should debate it for a bit. I'm not sure what the result will be or if it will fix anything, but it would be good to outline all the pros and cons on both sides and see if we can't find a common ground strategy going forward.
-Grant
Re: [VOTE] Create Solr TLP
Posted by Robert Muir <rc...@gmail.com>.
On Tue, Apr 26, 2011 at 8:32 PM, Mark Miller <ma...@gmail.com> wrote:
>
> On Apr 26, 2011, at 8:21 PM, Robert Muir wrote:
>
>> On Tue, Apr 26, 2011 at 8:12 PM, Mark Miller <ma...@gmail.com> wrote:
>>>
>>> On Apr 26, 2011, at 7:43 PM, Michael Busch wrote:
>>>
>>>> I totally agree with Robert and Simon that it is currently very frustrating that moving code to Lucene is being veto'ed on.
>>>
>>> What has been vetoed on? The response veto today? That hardly counts right? Just part of today's BS fun. If you guys are letting yonik stop you before you even begin - I suppose with a glance - than really, thats your issue IMO.
>>
>> did you or did you not receive an email on march 31st (not to any
>> mailing list, directed only at individuals) containing the terms 'I
>> don't think there should be more "pull stuff out of solr" '
>
> I do think I should be rich. If it only it was so easy ;) I can find where Simon says everything will be pulled from Solr and I can find where yonik says nothing will be pulled form Solr. This is not a veto - nor are either comments anything I realistically concern myself with in this regard. These are not vetoes. They are the same froth from the same bubbly foam we are witnessing today. I suppose I recommend you don't develop based on these types of broad statements that bubble up after two sides fight.
>
But, this is important context to the discussion. Unfortunately, to
the uninformed community, asf board, members etc, my behavior likely
appears very irrational: but this is because they are unaware of these
private emails (which many of us STRONGLY encouraged to go to a
mailing list) expressing there should be no refactoring.
Its unfortunate the PMC didn't address this immediately, instead we
all ignored the elephant in the room and ... hoped it would go away?
As far as "letting someone stop me first", I think you are
underestimating the amount of time it takes to refactor this stuff,
even the tiny refactorings like this spellchecking one. LUCENE-2995
took me an entire sunday. When you already know someone is against the
patch before you even start writing the code, its very discouraging.
Re: [VOTE] Create Solr TLP
Posted by Mark Miller <ma...@gmail.com>.
On Apr 26, 2011, at 8:21 PM, Robert Muir wrote:
> On Tue, Apr 26, 2011 at 8:12 PM, Mark Miller <ma...@gmail.com> wrote:
>>
>> On Apr 26, 2011, at 7:43 PM, Michael Busch wrote:
>>
>>> I totally agree with Robert and Simon that it is currently very frustrating that moving code to Lucene is being veto'ed on.
>>
>> What has been vetoed on? The response veto today? That hardly counts right? Just part of today's BS fun. If you guys are letting yonik stop you before you even begin - I suppose with a glance - than really, thats your issue IMO.
>
> did you or did you not receive an email on march 31st (not to any
> mailing list, directed only at individuals) containing the terms 'I
> don't think there should be more "pull stuff out of solr" '
I do think I should be rich. If it only it was so easy ;) I can find where Simon says everything will be pulled from Solr and I can find where yonik says nothing will be pulled form Solr. This is not a veto - nor are either comments anything I realistically concern myself with in this regard. These are not vetoes. They are the same froth from the same bubbly foam we are witnessing today. I suppose I recommend you don't develop based on these types of broad statements that bubble up after two sides fight.
The whole meme of "solr is nothing, its just waiting to be lucene+modules" and "nothing else from solr should be moved to lucene based on the previous" does not affect what I would choose to work on. It's not how this stuff is decided. Good code generally just goes in - whether its a module or a solr join patch - until today. You can physically stop that yes. For a while.
- Mark Miller
lucidimagination.com
Lucene/Solr User Conference
May 25-26, San Francisco
www.lucenerevolution.org
Re: [VOTE] Create Solr TLP
Posted by Robert Muir <rc...@gmail.com>.
On Tue, Apr 26, 2011 at 8:12 PM, Mark Miller <ma...@gmail.com> wrote:
>
> On Apr 26, 2011, at 7:43 PM, Michael Busch wrote:
>
>> I totally agree with Robert and Simon that it is currently very frustrating that moving code to Lucene is being veto'ed on.
>
> What has been vetoed on? The response veto today? That hardly counts right? Just part of today's BS fun. If you guys are letting yonik stop you before you even begin - I suppose with a glance - than really, thats your issue IMO.
did you or did you not receive an email on march 31st (not to any
mailing list, directed only at individuals) containing the terms 'I
don't think there should be more "pull stuff out of solr" '
Re: [VOTE] Create Solr TLP
Posted by Mark Miller <ma...@gmail.com>.
On Apr 27, 2011, at 5:49 AM, Michael McCandless wrote:
> On Tue, Apr 26, 2011 at 8:12 PM, Mark Miller <ma...@gmail.com> wrote:
>
>> Consider this: if you did the work necessary to make join a module and polished it all off and submitted it to Lucene - you think yonik standing alone would block that?
>
> In fact I do think he may object to it, given his past actions, his
> statements on private emails/IRCs, etc., and that really is the core
> problem here.
>
> For example, he vetoed the suggest module (now rescinded after Greg's
> intervention).
Clearly in response to Robert reverting his commit.
>
> The private email Yonik sent a few weeks back (to only certain
> hand-picked committers) clearly applies here.
>
> Yonik, since this is all out here in the open now, can you re-send
> that email to all of us (general@)? There's no reason for it to have
> been / now remain private?
Yonik might object!? Of course he might. We all object different things all the time. This is not a block IMO. If the join module comes tomorrow, Yonik objects, the rest +1 - that is the likely scenario.
>
>> I find this a very weak argument. Perceived road blocks are certainly no roadblock.
>
> They are a roadblock because they are a powerful deterrent.
It's up to each person to determine this on the inside I guess. Some of the more aggressive new guys are a powerful deterrent to working in Lucene land sometimes too - the spirits can run high - that doesn't mean they control things.
>
> Refactoring is a lot of work, and it's non-glorious work. When
> someone has the itch, it's usually not a super strong itch, and so
> fear-of-Yonik-disasgreeing can easily defeat that itch.
Yeah? Welcome to open source. Not everything is easy - you might have to face disagreement. With consensus on your side, I'm going to argue again - if someone made a join module for Lucene, Yonik would not stop it. I don't know when he became so powerful, but it's not the Apache way, and I don't buy it and I don't operate that way.
>
> It's not unlike how a bully is able to "control" so many kids in the
> school yard. One bully's actions has wide ranging [negative] impact.
I think we fundamentally disagree on the bullying that sometimes goes on.
>
>> Revert wars are a road block
>
> Remember that Yonik has also unilaterally up and reverted a commit
> without discussion ("auto phrasing" enabled in Solr's defaults). And
> his revert still stands to this day. Really the PMC should have
> intervened then.
Meh - consensus was to keep the default - yonik changed it back to consensus. Its a difficult issue to pile onto this one - but if Robert wants to readdress that issue, certainly he could bring it up, certainly he could change it again. He doesnt seem to afraid of Yonik the bully to me.
>
> While I agree, out of context, Robert's use of a veto/revert wars is
> inappropriate, and is not how things should be done in a healthy
> Apache project.... Lucene/Solr are not healthy right now, and
> desperate times call for desperate measures.
Woah. I hope thats not using your PMC hat. I think even in context roberts behavior was inappropriate, and I think desperate measures are so wrong here. I'm surprised you defend these actions. It really worries me coming from you.
>
> Set in the wider context, Robert's veto has finally succeeded in
> getting us talking about the elephant in the room when other's (eg
> Simon's) efforts haven't.
Finally succeeded? This is far from the first time we have dug in. And it doesnt take a physical code fight to do it - trust me.
> Robert has forced the issue out into the
> open, not unlike when someone in the school yard has had enough and
> finally stands up to the bully.
The school yard kid scares a lot of people himself. This whole characterization of yours doesn't jive to me at all.
>
> Mike
>
> http://blog.mikemccandless.com
- Mark Miller
lucidimagination.com
Lucene/Solr User Conference
May 25-26, San Francisco
www.lucenerevolution.org
Re: [VOTE] Create Solr TLP
Posted by Michael McCandless <lu...@mikemccandless.com>.
On Tue, Apr 26, 2011 at 8:12 PM, Mark Miller <ma...@gmail.com> wrote:
> Consider this: if you did the work necessary to make join a module and polished it all off and submitted it to Lucene - you think yonik standing alone would block that?
In fact I do think he may object to it, given his past actions, his
statements on private emails/IRCs, etc., and that really is the core
problem here.
For example, he vetoed the suggest module (now rescinded after Greg's
intervention).
The private email Yonik sent a few weeks back (to only certain
hand-picked committers) clearly applies here.
Yonik, since this is all out here in the open now, can you re-send
that email to all of us (general@)? There's no reason for it to have
been / now remain private?
> I find this a very weak argument. Perceived road blocks are certainly no roadblock.
They are a roadblock because they are a powerful deterrent.
Refactoring is a lot of work, and it's non-glorious work. When
someone has the itch, it's usually not a super strong itch, and so
fear-of-Yonik-disasgreeing can easily defeat that itch.
It's not unlike how a bully is able to "control" so many kids in the
school yard. One bully's actions has wide ranging [negative] impact.
> Revert wars are a road block
Remember that Yonik has also unilaterally up and reverted a commit
without discussion ("auto phrasing" enabled in Solr's defaults). And
his revert still stands to this day. Really the PMC should have
intervened then.
While I agree, out of context, Robert's use of a veto/revert wars is
inappropriate, and is not how things should be done in a healthy
Apache project.... Lucene/Solr are not healthy right now, and
desperate times call for desperate measures.
Set in the wider context, Robert's veto has finally succeeded in
getting us talking about the elephant in the room when other's (eg
Simon's) efforts haven't. Robert has forced the issue out into the
open, not unlike when someone in the school yard has had enough and
finally stands up to the bully.
Mike
http://blog.mikemccandless.com
Re: [VOTE] Create Solr TLP
Posted by Mark Miller <ma...@gmail.com>.
On Apr 26, 2011, at 7:43 PM, Michael Busch wrote:
> I totally agree with Robert and Simon that it is currently very frustrating that moving code to Lucene is being veto'ed on.
What has been vetoed on? The response veto today? That hardly counts right? Just part of today's BS fun. If you guys are letting yonik stop you before you even begin - I suppose with a glance - than really, thats your issue IMO.
Consider this: if you did the work necessary to make join a module and polished it all off and submitted it to Lucene - you think yonik standing alone would block that? I find this a very weak argument. Perceived road blocks are certainly no roadblock. Revert wars are a road block.
Making challenges or pointing things out are not road blocks and should not be frowned upon. The good stuff makes it past that IMO. You could make the same argument against all us comitters - we are all road blocks, because we all question patches from new contributors (and old). I had to adjust my highlighter patch for a fricken year before it was committed. Did I claim road block? No - I worked on the damn highlighter until it went in.
This leads us back to more rehashing though...not the elusive solution...
> It doesn't necessarily even have to take longer to develop a new feature as a shared module vs. one that only lives in Solr. What usually takes much longer is to develop it first in Solr, then after the release was made refactor it and move it to a module, with the burden of having to maintain backwards-compatibility with the original implementation.
IMO, this is up to the contributor. If a contributor wants to implement join for solr and not as a module, great. In many respects that can be easier. There are tradeoffs. Mandating one thing or another is a mistake. If someone wants to do it the other way, great too. Users benefit in both cases and I am happy.
- Mark Miller
lucidimagination.com
Lucene/Solr User Conference
May 25-26, San Francisco
www.lucenerevolution.org
Re: [VOTE] Create Solr TLP
Posted by Michael Busch <bu...@gmail.com>.
On 4/26/11 3:46 PM, Mark Miller wrote:
> It really seems to come down to robert/simon and yonik being really opposed here. This bubbles up every few weeks. I just don't know how to fix that - does anybody? I want to fix things as much as anyone - but what now? We have hashed everything over and over.
>
I totally agree with Robert and Simon that it is currently very
frustrating that moving code to Lucene is being veto'ed on.
They're investing time in realizing the modularization goals we had for
the Lucene/Solr merge, but there are always roadblocks. We should really
thank them for this effort, because it's very honorable work: making an
existing feature available for more users.
I think, Yonik, that you ignored the concerns of other committers in
SOLR-2272. It shouldn't be a surprise that this leads to frustration. If
it's a goal of the Lucene/Solr project to have shareable modules for
common code then in order to get a new feature committed discussions
about where the code should live have to happen very early in the phase
of a new feature. And then you need to scope the necessary development
time accordingly.
It doesn't necessarily even have to take longer to develop a new feature
as a shared module vs. one that only lives in Solr. What usually takes
much longer is to develop it first in Solr, then after the release was
made refactor it and move it to a module, with the burden of having to
maintain backwards-compatibility with the original implementation.
It's a responsibility of every committer to eg. make sure that Solr
tests pass when a new Lucene feature is developed. It should also be the
responsibility to figure out early on where code should live. I can not
emphasize this enough.
Re: [VOTE] Create Solr TLP
Posted by Mark Miller <ma...@gmail.com>.
On Apr 26, 2011, at 6:32 PM, Michael Busch wrote:
> Let's stop this passive-aggressive silliness and find a good solution.
We have got to do some of that or most of us would wonder what happened to everyone ;) I agree though. I think a *lot* of us are on this page. Probably though, others, like me, are at somewhat of a loss.
I feel a lot like you do it seems - I come down in the middle. I like modules. I'm pro modules. But I think that Yonik brings up valid points that should be considered. I think features that are ready for Solr should go into Solr - if someone makes join a module for Lucene tomorrow - fantastic. I simply don't think we should require that to get it in now for Solr. I also think if anyone makes a module, its not going to just be blocked as I suppose some assume. I'd +1 any reasonable module like we know almost everyone here would.
We all know this though. And the majority of us loosely agree from what I can tell. But what is the good solution? I don't really know. I don't think it's a de-merge. I don't think its a Solr is just sugar on Lucene and everything should by default be a module. I also think if someone actually makes something from Solr available in Lucene, I'd be for that. Patches welcomed and appreciated.
What's the path forward? We have all made various suggestions in the past. What do they mean? How do we settle on something?
Can we at least settle on the fact that we'd like to try and all work something out? Most of us would I think.
It really seems to come down to robert/simon and yonik being really opposed here. This bubbles up every few weeks. I just don't know how to fix that - does anybody? I want to fix things as much as anyone - but what now? We have hashed everything over and over.
- Mark Miller
lucidimagination.com
Lucene/Solr User Conference
May 25-26, San Francisco
www.lucenerevolution.org
Re: [VOTE] Create Solr TLP
Posted by Michael Busch <bu...@gmail.com>.
-1 of course
We can not just randomly merge/unmerge Lucene/Solr whenever a problem
comes up. It will still be the same community and therefore we need to
fix the way we interact with each other.
Could we all please try to be less stubborn and accusing and figure this
out? Obviously things like vetoing refactorings to move code into Lucene
is very counterproductive. But also Solr progress shouldn't suffer.
Hanging out with you guys at Apachecons always felt to me like we were
all good friends. Reading these discussions makes me think we can't
stand each other. Let's stop this passive-aggressive silliness and find
a good solution.
On 4/26/11 11:50 AM, Yonik Seeley wrote:
> A single merged project works only when people are relatively on the same page,
> and when people feel it's mutually beneficial. Recent events make it
> clear that that
> is no longer the case.
>
> Improvements to Solr have been recently blocked and reverted on the
> grounds that the new functionality was not immediately available to
> non-Solr users.
> This was obviously never part of the original idea (well actually - it was
> considered but rejected as too onerous). But the past doesn't matter as
> much as the present - about how people chose to act and interpret
> things today.
>
> https://issues.apache.org/jira/browse/SOLR-2272
> http://markmail.org/message/unrvjfudcbgqatsy
>
> Some people warned us against merging at the start, and I guess it
> turns out they were right.
>
> I no longer feel it's in Solr's best interests to remain under the same
> PMC as Lucene-Java, and I know some other committers who have said
> they feel like Lucene got the short end of the stick. But rather than
> arguing about who's right (maybe both?) since enough of us feel it's no longer
> mutually beneficial, we should stop fighting and just go our separate
> ways.
>
> Please VOTE to create a new Apache Solr TLP.
>
> Here's my +1
>
> -Yonik
>
Re: [VOTE] Create Solr TLP
Posted by Grant Ingersoll <gs...@apache.org>.
-1. I don't think it solves anything and just makes it more likely that we have duplicate functionality.
On Apr 26, 2011, at 2:50 PM, Yonik Seeley wrote:
> A single merged project works only when people are relatively on the same page,
> and when people feel it's mutually beneficial. Recent events make it
> clear that that
> is no longer the case.
>
> Improvements to Solr have been recently blocked and reverted on the
> grounds that the new functionality was not immediately available to
> non-Solr users.
> This was obviously never part of the original idea (well actually - it was
> considered but rejected as too onerous). But the past doesn't matter as
> much as the present - about how people chose to act and interpret
> things today.
>
> https://issues.apache.org/jira/browse/SOLR-2272
> http://markmail.org/message/unrvjfudcbgqatsy
>
> Some people warned us against merging at the start, and I guess it
> turns out they were right.
>
> I no longer feel it's in Solr's best interests to remain under the same
> PMC as Lucene-Java, and I know some other committers who have said
> they feel like Lucene got the short end of the stick. But rather than
> arguing about who's right (maybe both?) since enough of us feel it's no longer
> mutually beneficial, we should stop fighting and just go our separate
> ways.
>
> Please VOTE to create a new Apache Solr TLP.
>
> Here's my +1
>
> -Yonik
Re: [VOTE] Create Solr TLP
Posted by Michael McCandless <lu...@mikemccandless.com>.
Big -1.
I voted for the merge originally so that we'd be free to refactor code
across the two projects, and I don't think we're nearly done with
that.
Robert worked hard and factored out the analyzers module, the original
"trigger" for merging, and this is AWESOME progress.
But eg factoring out function queries
(https://issues.apache.org/jira/browse/LUCENE-2883), suggest module
(https://issues.apache.org/jira/browse/LUCENE-2995), this new join
ability (https://issues.apache.org/jira/browse/SOLR-2272), facets,
grouping, analyzer factories, data import, clustering, tika
integration, spatial, *dismax query parsers, are not done yet.
Other open source search engines (eg Xapian, Sphinx, etc.) already do
much of this ootb, so we clearly have some catching up to do, and
remaining merged is our best hope of getting there.
The problem is, even merged, we're still struggling because you
(Yonik) often veto / strongly resist others' refactoring efforts (eg
see the first 2 issues above). Simon sums it the problem/frustration
at http://markmail.org/thread/po7rr3egrsozgk3y
Good refactoring is strongly beneficial to both Solr and Lucene, as
the common code will get more attention, improvements, iterations,
etc. It seems like big win/win to me...
Mike
http://blog.mikemccandless.com
On Tue, Apr 26, 2011 at 2:50 PM, Yonik Seeley <yo...@apache.org> wrote:
> A single merged project works only when people are relatively on the same page,
> and when people feel it's mutually beneficial. Recent events make it
> clear that that
> is no longer the case.
>
> Improvements to Solr have been recently blocked and reverted on the
> grounds that the new functionality was not immediately available to
> non-Solr users.
> This was obviously never part of the original idea (well actually - it was
> considered but rejected as too onerous). But the past doesn't matter as
> much as the present - about how people chose to act and interpret
> things today.
>
> https://issues.apache.org/jira/browse/SOLR-2272
> http://markmail.org/message/unrvjfudcbgqatsy
>
> Some people warned us against merging at the start, and I guess it
> turns out they were right.
>
> I no longer feel it's in Solr's best interests to remain under the same
> PMC as Lucene-Java, and I know some other committers who have said
> they feel like Lucene got the short end of the stick. But rather than
> arguing about who's right (maybe both?) since enough of us feel it's no longer
> mutually beneficial, we should stop fighting and just go our separate
> ways.
>
> Please VOTE to create a new Apache Solr TLP.
>
> Here's my +1
>
> -Yonik
>
Re: [VOTE] Create Solr TLP
Posted by Simon Willnauer <si...@googlemail.com>.
On Wed, Apr 27, 2011 at 10:08 AM, Doron Cohen <cd...@gmail.com> wrote:
> -1 for unmerge.
>
> Another thing to keep in mind is that Solr can be considered not just "an
>> application that uses Lucene", but rather the *ideal* application layer for
>> Lucene. Solr is basically an awesome example of what Lucene can be used for
>> in an application. Every feature that Lucene supports, should be available
>> through Solr. The opposite (that every Solr feature should be available via
>> Lucene) depends on the feature and can't be stated as a general rule.
>>
> ...
>
>> So, what makes sense to me is to allow Solr developers to create features
>> for the application in whatever manner is most sensible for the application
>> need. Those features should be added to the Solr project. Then, for each of
>> those new features, have a discussion (and subsequently a proper Apache
>> vote) to determine whether or not this feature should be a library layer
>> feature or not. Once it's decided that it should be, an appropriate
>> generalized design should be proposed, agreed upon, then implemented in
>> Lucene. Once that is finished, the Solr feature can be updated to use the
>> new functionality from Lucene.
>>
> ...
>
>> If at any point this is not working out for Solr, the application layer can
>> change the implementation to be what it needs to be, and then start a
>> discussion about how the library layer implementation can be updated to
>> support that.
>>
>> Following that process, I really don't see a conflict at all.
>>
>
> The above quite summarizes my opinion on this.
>
> It really is a win-win:
> - Generalization (modules) should not block Solr
> - Solr helps improving Lucene
> - Solr has the privilege of guiding Lucene about which features to develop
> and how
>
> while(true) {
> f = app.develop-new-great-feature();
> if (is-a-general-interest-feature(f)) {
> g = generalize-feature(f);
> m = port-to-modules(g);
> f2 = app.rewrite-based-on-modules(f,m);
> app.replace-impl(f,f2);
> }
> }
>
> Compiled with an optimistic compiler... :)
>
> Doron
>
here is a patch to make it more realistic
while(true) {
f = app.develop-new-great-feature();
if (is-a-general-interest-feature(f)) {
- g = generalize-feature(f);
+ try {
+ g = generalize-feature(f);
+ } catch (YonikDoesntLikeItException ex) {
+ continue;
+ }
m = port-to-modules(g);
f2 = app.rewrite-based-on-modules(f,m);
app.replace-impl(f,f2);
}
}
sorry for the sarcasm,
simon
Re: [VOTE] Create Solr TLP
Posted by Doron Cohen <cd...@gmail.com>.
-1 for unmerge.
Another thing to keep in mind is that Solr can be considered not just "an
> application that uses Lucene", but rather the *ideal* application layer for
> Lucene. Solr is basically an awesome example of what Lucene can be used for
> in an application. Every feature that Lucene supports, should be available
> through Solr. The opposite (that every Solr feature should be available via
> Lucene) depends on the feature and can't be stated as a general rule.
>
...
> So, what makes sense to me is to allow Solr developers to create features
> for the application in whatever manner is most sensible for the application
> need. Those features should be added to the Solr project. Then, for each of
> those new features, have a discussion (and subsequently a proper Apache
> vote) to determine whether or not this feature should be a library layer
> feature or not. Once it's decided that it should be, an appropriate
> generalized design should be proposed, agreed upon, then implemented in
> Lucene. Once that is finished, the Solr feature can be updated to use the
> new functionality from Lucene.
>
...
> If at any point this is not working out for Solr, the application layer can
> change the implementation to be what it needs to be, and then start a
> discussion about how the library layer implementation can be updated to
> support that.
>
> Following that process, I really don't see a conflict at all.
>
The above quite summarizes my opinion on this.
It really is a win-win:
- Generalization (modules) should not block Solr
- Solr helps improving Lucene
- Solr has the privilege of guiding Lucene about which features to develop
and how
while(true) {
f = app.develop-new-great-feature();
if (is-a-general-interest-feature(f)) {
g = generalize-feature(f);
m = port-to-modules(g);
f2 = app.rewrite-based-on-modules(f,m);
app.replace-impl(f,f2);
}
}
Compiled with an optimistic compiler... :)
Doron
Re: [VOTE] Create Solr TLP
Posted by Troy Howard <th...@gmail.com>.
While I agree that in general "refactoring to promote reuse" is an ideal, I
think more consideration should be taken for Yoriks concerns.
The core issue seems to stem from a fundamental difference between an
application and a library.
Applications need to support one specific set of features and have those
features behave exactly as intended. Those features often are added,
removed, and changed rapidly to meet specific needs. Libraries have to
support many different use cases, and thus many different feature sets.
Those features need to operate in a way that is compatible with all posed
use cases, and so the design is more generalized. Beyond that, libraries,
which surface a public API, are responsible for backward compatibility.
The constraints on design for a library are quite different than those of an
application.
An existential question comes into play when thinking about these
distinctions. For any given feature, is it an "application layer" feature or
a "library layer" feature? It's clear that Solr was and is, at times,
developing library layer features to support application layer features.
Those library layer features should be refactored back into the Lucene
library rather than remaining in the application layer.
That said, when doing that refactoring, one must look past the initial
implementation that was created in the application layer, and find a way to
generalize the feature to be part of the library layer. This can take
a considerable amount of time, thought, discussion and engineering to come
up with an appropriate design. We must take care not to integrate
application layer features into the library layer.
Another thing to keep in mind is that Solr can be considered not just "an
application that uses Lucene", but rather the *ideal* application layer for
Lucene. Solr is basically an awesome example of what Lucene can be used for
in an application. Every feature that Lucene supports, should be available
through Solr. The opposite (that every Solr feature should be available via
Lucene) depends on the feature and can't be stated as a general rule.
So, what makes sense to me is to allow Solr developers to create features
for the application in whatever manner is most sensible for the application
need. Those features should be added to the Solr project. Then, for each of
those new features, have a discussion (and subsequently a proper Apache
vote) to determine whether or not this feature should be a library layer
feature or not. Once it's decided that it should be, an appropriate
generalized design should be proposed, agreed upon, then implemented in
Lucene. Once that is finished, the Solr feature can be updated to use the
new functionality from Lucene.
If at any point this is not working out for Solr, the application layer can
change the implementation to be what it needs to be, and then start a
discussion about how the library layer implementation can be updated to
support that.
Following that process, I really don't see a conflict at all.
I have no comment on the interpersonal dynamics other than to say that
without a clear process defined and agreed on by the group to cover these
situations, we are left with a battle of wills which is counterproductive
for all.
Thanks,
Troy
On Tue, Apr 26, 2011 at 2:15 PM, Ted Dunning <te...@gmail.com> wrote:
> -1 (non-binding since I am only a contributor, not a committer)
>
> I have looked at a bunch of the discussions on JIRA and they frankly look
> pretty silly. How can anyone seriously say that refactoring to promote
> re-use is bad? How can somebody veto a code contribution that adds
> important and useful capabilities?
>
> Seriously, this looks like kindergarten all over again (these are *my*
> marbles, I am going home). It doesn't look like open source at all.
>
> Loosen up.
>
> On Tue, Apr 26, 2011 at 1:05 PM, Steven A Rowe <sa...@syr.edu> wrote:
>
> > -1
> >
> > I think real compromise is in order, rather than serial confrontation
> > ending in divorce.
> >
> > Steve
> >
> > > -----Original Message-----
> > > From: yseeley@gmail.com [mailto:yseeley@gmail.com] On Behalf Of Yonik
> > > Seeley
> > > Sent: Tuesday, April 26, 2011 2:50 PM
> > > To: general@lucene.apache.org
> > > Subject: [VOTE] Create Solr TLP
> > >
> > > A single merged project works only when people are relatively on the
> same
> > > page,
> > > and when people feel it's mutually beneficial. Recent events make it
> > > clear that that
> > > is no longer the case.
> > >
> > > Improvements to Solr have been recently blocked and reverted on the
> > > grounds that the new functionality was not immediately available to
> > > non-Solr users.
> > > This was obviously never part of the original idea (well actually - it
> > > was
> > > considered but rejected as too onerous). But the past doesn't matter
> as
> > > much as the present - about how people chose to act and interpret
> > > things today.
> > >
> > > https://issues.apache.org/jira/browse/SOLR-2272
> > > http://markmail.org/message/unrvjfudcbgqatsy
> > >
> > > Some people warned us against merging at the start, and I guess it
> > > turns out they were right.
> > >
> > > I no longer feel it's in Solr's best interests to remain under the same
> > > PMC as Lucene-Java, and I know some other committers who have said
> > > they feel like Lucene got the short end of the stick. But rather than
> > > arguing about who's right (maybe both?) since enough of us feel it's no
> > > longer
> > > mutually beneficial, we should stop fighting and just go our separate
> > > ways.
> > >
> > > Please VOTE to create a new Apache Solr TLP.
> > >
> > > Here's my +1
> > >
> > > -Yonik
> >
>
Re: [VOTE] Create Solr TLP
Posted by Mark Miller <ma...@gmail.com>.
Oh this is open source all right - at least based on the history of many of the projects I know. Its just not one of the prettier moments.
On Apr 26, 2011, at 5:15 PM, Ted Dunning wrote:
> -1 (non-binding since I am only a contributor, not a committer)
>
> I have looked at a bunch of the discussions on JIRA and they frankly look
> pretty silly. How can anyone seriously say that refactoring to promote
> re-use is bad? How can somebody veto a code contribution that adds
> important and useful capabilities?
>
> Seriously, this looks like kindergarten all over again (these are *my*
> marbles, I am going home). It doesn't look like open source at all.
>
> Loosen up.
>
> On Tue, Apr 26, 2011 at 1:05 PM, Steven A Rowe <sa...@syr.edu> wrote:
>
>> -1
>>
>> I think real compromise is in order, rather than serial confrontation
>> ending in divorce.
>>
>> Steve
>>
>>> -----Original Message-----
>>> From: yseeley@gmail.com [mailto:yseeley@gmail.com] On Behalf Of Yonik
>>> Seeley
>>> Sent: Tuesday, April 26, 2011 2:50 PM
>>> To: general@lucene.apache.org
>>> Subject: [VOTE] Create Solr TLP
>>>
>>> A single merged project works only when people are relatively on the same
>>> page,
>>> and when people feel it's mutually beneficial. Recent events make it
>>> clear that that
>>> is no longer the case.
>>>
>>> Improvements to Solr have been recently blocked and reverted on the
>>> grounds that the new functionality was not immediately available to
>>> non-Solr users.
>>> This was obviously never part of the original idea (well actually - it
>>> was
>>> considered but rejected as too onerous). But the past doesn't matter as
>>> much as the present - about how people chose to act and interpret
>>> things today.
>>>
>>> https://issues.apache.org/jira/browse/SOLR-2272
>>> http://markmail.org/message/unrvjfudcbgqatsy
>>>
>>> Some people warned us against merging at the start, and I guess it
>>> turns out they were right.
>>>
>>> I no longer feel it's in Solr's best interests to remain under the same
>>> PMC as Lucene-Java, and I know some other committers who have said
>>> they feel like Lucene got the short end of the stick. But rather than
>>> arguing about who's right (maybe both?) since enough of us feel it's no
>>> longer
>>> mutually beneficial, we should stop fighting and just go our separate
>>> ways.
>>>
>>> Please VOTE to create a new Apache Solr TLP.
>>>
>>> Here's my +1
>>>
>>> -Yonik
>>
- Mark Miller
lucidimagination.com
Lucene/Solr User Conference
May 25-26, San Francisco
www.lucenerevolution.org
Re: [VOTE] Create Solr TLP
Posted by Ted Dunning <te...@gmail.com>.
-1 (non-binding since I am only a contributor, not a committer)
I have looked at a bunch of the discussions on JIRA and they frankly look
pretty silly. How can anyone seriously say that refactoring to promote
re-use is bad? How can somebody veto a code contribution that adds
important and useful capabilities?
Seriously, this looks like kindergarten all over again (these are *my*
marbles, I am going home). It doesn't look like open source at all.
Loosen up.
On Tue, Apr 26, 2011 at 1:05 PM, Steven A Rowe <sa...@syr.edu> wrote:
> -1
>
> I think real compromise is in order, rather than serial confrontation
> ending in divorce.
>
> Steve
>
> > -----Original Message-----
> > From: yseeley@gmail.com [mailto:yseeley@gmail.com] On Behalf Of Yonik
> > Seeley
> > Sent: Tuesday, April 26, 2011 2:50 PM
> > To: general@lucene.apache.org
> > Subject: [VOTE] Create Solr TLP
> >
> > A single merged project works only when people are relatively on the same
> > page,
> > and when people feel it's mutually beneficial. Recent events make it
> > clear that that
> > is no longer the case.
> >
> > Improvements to Solr have been recently blocked and reverted on the
> > grounds that the new functionality was not immediately available to
> > non-Solr users.
> > This was obviously never part of the original idea (well actually - it
> > was
> > considered but rejected as too onerous). But the past doesn't matter as
> > much as the present - about how people chose to act and interpret
> > things today.
> >
> > https://issues.apache.org/jira/browse/SOLR-2272
> > http://markmail.org/message/unrvjfudcbgqatsy
> >
> > Some people warned us against merging at the start, and I guess it
> > turns out they were right.
> >
> > I no longer feel it's in Solr's best interests to remain under the same
> > PMC as Lucene-Java, and I know some other committers who have said
> > they feel like Lucene got the short end of the stick. But rather than
> > arguing about who's right (maybe both?) since enough of us feel it's no
> > longer
> > mutually beneficial, we should stop fighting and just go our separate
> > ways.
> >
> > Please VOTE to create a new Apache Solr TLP.
> >
> > Here's my +1
> >
> > -Yonik
>
RE: [VOTE] Create Solr TLP
Posted by Steven A Rowe <sa...@syr.edu>.
-1
I think real compromise is in order, rather than serial confrontation ending in divorce.
Steve
> -----Original Message-----
> From: yseeley@gmail.com [mailto:yseeley@gmail.com] On Behalf Of Yonik
> Seeley
> Sent: Tuesday, April 26, 2011 2:50 PM
> To: general@lucene.apache.org
> Subject: [VOTE] Create Solr TLP
>
> A single merged project works only when people are relatively on the same
> page,
> and when people feel it's mutually beneficial. Recent events make it
> clear that that
> is no longer the case.
>
> Improvements to Solr have been recently blocked and reverted on the
> grounds that the new functionality was not immediately available to
> non-Solr users.
> This was obviously never part of the original idea (well actually - it
> was
> considered but rejected as too onerous). But the past doesn't matter as
> much as the present - about how people chose to act and interpret
> things today.
>
> https://issues.apache.org/jira/browse/SOLR-2272
> http://markmail.org/message/unrvjfudcbgqatsy
>
> Some people warned us against merging at the start, and I guess it
> turns out they were right.
>
> I no longer feel it's in Solr's best interests to remain under the same
> PMC as Lucene-Java, and I know some other committers who have said
> they feel like Lucene got the short end of the stick. But rather than
> arguing about who's right (maybe both?) since enough of us feel it's no
> longer
> mutually beneficial, we should stop fighting and just go our separate
> ways.
>
> Please VOTE to create a new Apache Solr TLP.
>
> Here's my +1
>
> -Yonik
Re: [VOTE] Create Solr TLP
Posted by Chris Hostetter <ho...@fucit.org>.
I've been sick the last 48 hours, and didn't really have the energy to
read all my email, even as i saw what look like some seriously omonious
fucking threads grow and grow.
Trying to catch up now, I'm somewhat at a loss ... my capacity (and
willingness) to wade in and aggresively diffuse petty disagreements seems
to be failing me in my advanced age.
Fortunately this thread seems to have died out, and a new more positive
thread is taking shape on the dev list, and that seems to be the one
salvation of what strikes me as being the ugglesist 48 hours i have ever
seen in this community.
For the record...
: Subject: [VOTE] Create Solr TLP
-1.
I initially voted against merged lucene/solr development last year,
because even though i liked the *idea* i thought the entire "vote" was
vague, non-specific, and targeted a "goal" of more integrated development
w/o really adressing what kind of process we (as a community) would use to
get there.
Guess what ladies and gentlemen: This is that process.
It's messy, and it's ugly, and it involves a lot of opinions and
disagreements, and egos, and a lot of hashing shit out.
I don't regret that we merged dev, and I don't think we should
"un-merge" -- you can't put the genie back in the bottle, and i wouldn't
want to if we could -- because i think merging helped us make a lot of
great progress, and we need to keep moving foward.
Lastly, because i don't think they can be stated enough, i would like to
repeat the most insightful comments i saw in this thread. (the wisdom
in these particular comments is really what kept me going enough to read
all the way through w/o giving up and going to bed)...
: pretty silly. How can anyone seriously say that refactoring to promote
: re-use is bad? How can somebody veto a code contribution that adds
: important and useful capabilities?
...
: Another thing to keep in mind is that Solr can be considered not just "an
: application that uses Lucene", but rather the *ideal* application layer for
: Lucene. Solr is basically an awesome example of what Lucene can be used for
: in an application. Every feature that Lucene supports, should be available
: through Solr. The opposite (that every Solr feature should be available via
: Lucene) depends on the feature and can't be stated as a general rule.
...
: Could we all please try to be less stubborn and accusing and figure this out?
: Obviously things like vetoing refactorings to move code into Lucene is very
: counterproductive. But also Solr progress shouldn't suffer.
:
: Hanging out with you guys at Apachecons always felt to me like we were all
: good friends. Reading these discussions makes me think we can't stand each
: other. Let's stop this passive-aggressive silliness and find a good solution.
-Hoss