> This might sound a bit harsh, but maybe Lucene devs helping with Solr has let > Solr off the hook a bit too much? I actually like the fact that the split > causes Solr to figure out it's own situation and focus on its problems.
Well said. > Take our ongoing test flakiness woes and SolrCloud instability issues as > examples: both are serious threats to the project, both have been around for > years, and both are here to stay for the foreseeable future. Contrary to Jason I don't think keeping Solr and Lucene code together helps anybody in tackling those issues now or in the future. The first thing Mark (Miller) did when he started cleaning up the codebase for gradle was to *disable* nearly all randomizations and fix certain parameters to bring back stability and speed up Solr tests. I bet it would be a tad easier if he only had Solr (or Lucene) side to take care of (rather than both Lucene AND Solr). What is good for Lucene may not be as good for Solr. Maybe removing randomizations that currently happen in LuceneTestCase will calm down tests? Who knows. Sincerely, I think a split project may bring a clean slate for more drastic refactorings and cleanups. A combined codebase keeps the status quo we've been in for years. Dawid --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
