: Subject: RE: [VOTE] merge lucene/solr development

-1

If this is the direction the dev community wants to go in then so be it -- FWIW: My current opinion is that this direction does make sense in teh long run -- but the vote as it stands feels way to broad. It seems like people are trying vote on a "goal" instead of on specific actions, and treating that goal as a driver to make several changes all at the same time.

i would much rather attempt specific changes first (individually when possible), and see how we progress.

As Uwe says alludes: merging releases, and trying to enforce that changes can't be made to core that might break Solr are things that could prove very challenging, particularly in the "next" release, and I don't see why we should try to make all of this happen at once.

Why don't we just start by attempting to have a common dev list and merging committers, in the hopes that it will promote better communication about features up and down the stack, and better bug fixing/refactoring/modularization -- then see if that leads us to a point where it makes sense to more tightly couple the build systems and releases?

: -1 on the current VOTE, as I am thinking the same like Michael Busch and Bill
Au: : : - I am fine with merging development mailing lists (not user mailing lists). : - But I do not want to enforce releases to appear at the same time, so there
must be some coordination with the fact that "Solr depends on Lucene but NOT
Lucene depends on Solr". : - A modularization is needed: Lucene-Core (with no analyzers at all, only
abstract classes), Lucene-Analysis, Lucene-Facetting, Lucene-FunctionQueries,
Lucene-Foobar, Solr-Core, Solr-Foobar,... : - No requirement for Lucene Committers to work on Solr Tests or that Solr
tests must pass when Lucene Changes. I would like to have it more in a way that
the issue tracker would do that like it is now: Lucene is enhanced, BW layer
still alive (so solr tests should work), so open issue against solr referring to
lucene issue to fix solr and remove usage of deprecated methods or fix other
problems. : - And last but not least the whole merge should be done *after* the current
code bases are again closer to each other, especially Flex is in and Solr is at
least on Lucene 3.0.1.

-Hoss