Mailing-List: contact general-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@lucene.apache.org
Received-SPF: pass (nike.apache.org: domain of thoward37@gmail.com designates
 209.85.214.48 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :content-type;
        b=LYMRAJHLPE5Z1KCeUelrGLv+KQ6hVAU8K0TInFwC01XY8vovG8OUTwyFHkdh7VBaXq
         Slenly51gA4rrtVl0AUXcmwzXr7Mn4yYe99Zjw7Sko4Jfg9cfU12OcDvVPDJRoXxptfB
         I/UJ31uLdjb1U8j1FZQr9uAC7vkrk/ipMsuNA=
MIME-Version: 1.0
In-Reply-To: <BANLkTikLnD5vf7hcK3xXc5z4jcb8ERoZCg@mail.gmail.com>
References: <BANLkTinoVYPZwno8rcQBn5z8c1rJPkLKNw@mail.gmail.com>
 <2D127F11DC79714E9B6A43AC9458147FB3CE710E@suex07-mbx-03.ad.syr.edu>
 <BANLkTikLnD5vf7hcK3xXc5z4jcb8ERoZCg@mail.gmail.com>
From: Troy Howard <thoward37@gmail.com>
Date: Tue, 26 Apr 2011 15:00:09 -0700
Message-ID: <BANLkTinY=MkXNy-e28uP1EBa7FEess6PyQ@mail.gmail.com>
Subject: Re: [VOTE] Create Solr TLP
To: general@lucene.apache.org
Content-Type: multipart/alternative; boundary=0016e6d7e8f3c57dfb04a1d973d4

--0016e6d7e8f3c57dfb04a1d973d4
Content-Type: text/plain; charset=UTF-8

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 <ted.dunning@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 <sarowe@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
> >
>

--0016e6d7e8f3c57dfb04a1d973d4--