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.dunn...@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 <sar...@syr.edu> wrote: > > > -1 > > > > I think real compromise is in order, rather than serial confrontation > > ending in divorce. > > > > Steve > > > > > -----Original Message----- > > > From: ysee...@gmail.com [mailto:ysee...@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 > > >