lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Willnauer <simon.willna...@googlemail.com>
Subject Lucene & Solr a one way street?
Date Sun, 13 Mar 2011 15:23:40 GMT
Hey folks,

I have recently tried to push some refactorings towards moving stuff
from Solr to modules land to enable users of Lucene to benefit from
the developments that have been made in Solr land during the past with
very little success. Actually, it was a really disappointing
experience whenever  I tried to kick off issues towards this
direction. On LUCENE-2308 David asked a good question why FieldType is
not ported to Lucene rather than a new development.
I replied with:

{quote}
Moving stuff from Solr to Lucene involves lots of politics. It is way
easier to let Solr adopt eventually than fight your way through the
politics (this is my opinion though.)
{quote}

Yet, while the answer to his question doesn't matter in this context
but it raised some other question from Roberts side:

{quote}
Then why do we still have merged codebases?
If this is the way things are, then we should un-merge the two projects.

because as a lucene developer, i spend a lot of time trying to do my
part to fix various things in Solr... if its a one-way-street then we
need to un-merge.
{quote}

The discussions on LUCENE-2883 changed my personal reception on how
things work here quite dramatically. I lost almost all enthusiasm to
even try to push developments towards moving things out of Solr and
into modules since literally every movement in this direction starts a
lot of politics (at least this is my understanding drawn from the
rather non-technical disagreements I have seen folks mentioning on
this issue). I don't care where those politics come from but in my
opinion we need to find an agreement how we deal with "stealing"
functionality form Solr and make them available to lucene users. My
personal opinion is that any refactoring, consolidation of APIs etc.
should NOT be influenced by the fact that they have been Solr private
and "might" influence further development on solr with regards to
backwards compatibility etc.

Moving features to modules should be first priority and please correct
me if I am wrong this was one of the major reason why we merged the
code base. All users should benefit from the nice features which are
currently hidden in the solr code base. FunctionQuery is a tiny one
IMO and the frustration it caused on my side was immense. I don't even
wanna try to suggest to make replication, faceting or even the cloud
feature decoupled from Solr (I don't want to argue about the
feasibility or the amount of work this would be here! Just lemme say
one thing we can always branch and there is a large workforce out
there that is willing to work on stuff like that).

I can only agree with robert that if this is a one way street that the
merge makes no sense anymore. Refactoring will bring a lot of benefits
to both lucene AND solr. I also wanna quote Earwin here (I don't find
the issue right now - this quote is from my memory): "we should try to
decouple things rather than couple them even more tight". I moved out
of all Solr issues since then and I am not willing to do any work on
it until we find an agreement on this.

I should have raised this issue earlier I guess but I rather do it now
than never.

thanks for reading,

simon

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message