lucene-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hostetter <hossman_luc...@fucit.org>
Subject RE: [VOTE] merge lucene/solr development
Date Thu, 04 Mar 2010 17:41:18 GMT

: 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


Mime
View raw message