[VOTE] Create Solr TLP

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

Re: [VOTE] Create Solr TLP

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

Re: [VOTE] Create Solr TLP

Simon Willnauer
On Wed, Apr 27, 2011 at 10:08 AM, Doron Cohen <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Create Solr TLP

Andrzej Białecki-2
In reply to this post by Yonik Seeley-2
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

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Create Solr TLP

Michael McCandless-2
In reply to this post by Mark Miller-3
On Tue, Apr 26, 2011 at 8:12 PM, Mark Miller <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Create Solr TLP

Mark Miller-3

On Apr 27, 2011, at 5:49 AM, Michael McCandless wrote:

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





Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Create Solr TLP

Chris Hostetter-3
In reply to this post by Yonik Seeley-2

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
12