> This sounds like a decision has already been made. No. I plan to send a VOTE thread nonetheless. A vote thread is just that -- a vote. If majority decides both projects should stay together it's still a decision. A discussion without any resolution is going to dissolve over time into no resolution at all.
> Additionally, all of the counterarguments presented come with rebuttals > attached, so I'm not sure if this is supposed to be a persuasive case or an > expositional one. This thread is for discussion, please expand the counterarguments with any point of view you like. I did include counterarguments I collected from private mailing list. > I think I have an initial reaction that I'm opposed to a split, but I'm not > yet concretely sure why. Like I said multiple times I see this as a reasonable technical decision and I don't think the community (communities?) will suffer much because of this. This is not a hostile code fork or an attempt to hijack developers. Whoever has interest in Solr and Lucene will still be a Solr and Lucene developer. I really don't think that much will change. My point of view crystallised because of the build system work - I admit this freely. The ant one is hair-bending. The gradle one is inconvenient like hell when you have effectively two "top-level" projects to handle within the same configuration. When I started looking at other aspects I became convinced this is the right way to go. Separately from that I think Solr has become older, larger and is an industry standard search component. It is time for it to mature and just be a top-level Apache project even from public-relations point of view. > This seems like an argument for fixing the tests and making them faster, I'm > not sure how we get to splitting the projects from here. If you're doing Solr > only changes, it's pretty easy to run "./gradlew -p solr test" and skip the > lucene tests, similar for lucene only development. Nah, this isn't true. All CI jobs, github, etc. - everything is checked and verified and extends things twice more than it should. > > Mailing lists, build servers > This is probably a good idea and I think this is easy enough to do without > splitting the project as well. They are already separated to a large degree. The only thing in common is dev list an even there threads are really split between discussions concerning Solr and Lucene functionality. > > Solr tests are the first “battlefield” test zone for Lucene changes > I think https://issues.apache.org/jira/browse/SOLR-14428 is a great example > of the kind of collaboration that we can see, and a good hint of what to > expect if the projects are split. To summarize, there was a Lucene change > which caused some issues in Solr. The fix is likely going to end up being > another Lucene change, but just as easily could have been a kind of ugly > workaround on the Solr side. Maybe. There are a lot of maybes. I still think a split would make things easier. For example the ugly workaround could go into an immediate bugfix release for Solr, followed by a patch to Lucene and a proper fix later on. Now you can't do an immediate bugfix/ workaround Solr release without a corresponding Lucene release (which doesn't make sense to me at all). Oh, and don't get me wrong - I understand you can have doubts. I am prepared to defend my position because it's been growing in me for a few months now; I have been digesting this for a longer time and it probably makes a difference. Dawid --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
