> Would this not be eased to some extent if the initial committer base of both > the projects was the same?
"Who has commit karma to a project" is a separate question from "Who will make commits in practice". Having Lucene committers retain their status as Solr committers only helps if they're willing and interested in keeping Solr up to date. From discussion on this thread so far, I'm not sure how much of that interest exists. After all, avoiding this solr-update-burden was one of the arguments cited in favor of a split. > Contrary to Jason I don't think keeping Solr and Lucene code together helps > anybody in tackling those issues now or in the future. That's not the point I was making. I wasn't saying that the split (or lack thereof) affects our ability to address test-flakiness (etc.). I was citing test-flakiness as an example of how bad us Solr folks have been historically at prioritizing this sort of work that's crucial for project health but not tied to a specific feature. I brought this historical example up as a parallel or a prediction to how we might do with a similar task: managing to stay up to date on Lucene. My whole point was: "We historically don't do well at getting this sort of work done; therefore I expect we're going to have some level of lag behind Lucene" On Wed, May 13, 2020 at 2:11 PM Dawid Weiss <dawid.we...@gmail.com> wrote: > > > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
