[VOTE] Create Solr TLP

classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[VOTE] Create Solr TLP

Yonik Seeley-2
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
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Create Solr TLP

pjaol
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 <[hidden email]> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Create Solr TLP

Grant Ingersoll-2
In reply to this post by Yonik Seeley-2
-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


Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Create Solr TLP

Michael McCandless-2
In reply to this post by Yonik Seeley-2
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 <[hidden email]> 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
>
Reply | Threaded
Open this post in threaded view
|

RE: [VOTE] Create Solr TLP

steve_rowe
In reply to this post by Yonik Seeley-2
-1

I think real compromise is in order, rather than serial confrontation ending in divorce.

Steve

> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of Yonik
> Seeley
> Sent: Tuesday, April 26, 2011 2:50 PM
> To: [hidden email]
> 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
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Create Solr TLP

Ted Dunning
-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 <[hidden email]> wrote:

> -1
>
> I think real compromise is in order, rather than serial confrontation
> ending in divorce.
>
> Steve
>
> > -----Original Message-----
> > From: [hidden email] [mailto:[hidden email]] On Behalf Of Yonik
> > Seeley
> > Sent: Tuesday, April 26, 2011 2:50 PM
> > To: [hidden email]
> > 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
>
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Create Solr TLP

Mark Miller-3
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 <[hidden email]> wrote:
>
>> -1
>>
>> I think real compromise is in order, rather than serial confrontation
>> ending in divorce.
>>
>> Steve
>>
>>> -----Original Message-----
>>> From: [hidden email] [mailto:[hidden email]] On Behalf Of Yonik
>>> Seeley
>>> Sent: Tuesday, April 26, 2011 2:50 PM
>>> To: [hidden email]
>>> 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





Reply | Threaded
Open this post in threaded view
|

RE: [VOTE] Create Solr TLP

Uwe Schindler
In reply to this post by Yonik Seeley-2
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: [hidden email]

> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of Yonik
> Seeley
> Sent: Tuesday, April 26, 2011 8:50 PM
> To: [hidden email]
> 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

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Create Solr TLP

Ryan McKinley
In reply to this post by Yonik Seeley-2
-1

for most of the same reasons everyone else is saying...


On Tue, Apr 26, 2011 at 2:50 PM, Yonik Seeley <[hidden email]> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Create Solr TLP

Mark Miller-3
In reply to this post by Uwe Schindler
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: [hidden email]
>
>> -----Original Message-----
>> From: [hidden email] [mailto:[hidden email]] On Behalf Of Yonik
>> Seeley
>> Sent: Tuesday, April 26, 2011 8:50 PM
>> To: [hidden email]
>> 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





Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Create Solr TLP

Troy Howard
In reply to this post by Ted Dunning
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 <[hidden email]> 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 <[hidden email]> wrote:
>
> > -1
> >
> > I think real compromise is in order, rather than serial confrontation
> > ending in divorce.
> >
> > Steve
> >
> > > -----Original Message-----
> > > From: [hidden email] [mailto:[hidden email]] On Behalf Of Yonik
> > > Seeley
> > > Sent: Tuesday, April 26, 2011 2:50 PM
> > > To: [hidden email]
> > > 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
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Create Solr TLP

Michael Busch
In reply to this post by Yonik Seeley-2
-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
>

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Create Solr TLP

Mark Miller-3

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





Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Create Solr TLP

Michael Busch
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.
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Create Solr TLP

Mark Miller-3

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





Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Create Solr TLP

Robert Muir
On Tue, Apr 26, 2011 at 8:12 PM, Mark Miller <[hidden email]> 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" '
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Create Solr TLP

Mark Miller-3

On Apr 26, 2011, at 8:21 PM, Robert Muir wrote:

> On Tue, Apr 26, 2011 at 8:12 PM, Mark Miller <[hidden email]> 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





Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Create Solr TLP

Robert Muir
On Tue, Apr 26, 2011 at 8:32 PM, Mark Miller <[hidden email]> wrote:

>
> On Apr 26, 2011, at 8:21 PM, Robert Muir wrote:
>
>> On Tue, Apr 26, 2011 at 8:12 PM, Mark Miller <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Create Solr TLP

Grant Ingersoll-2

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



Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Create Solr TLP

Simon Willnauer
On Wed, Apr 27, 2011 at 3:34 AM, Grant Ingersoll <[hidden email]> 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
>
>
>
>
12