I personally feel that all the current issues can be solved by actually working on those problems instead of splitting and calling it a day. I don't really think that splitting provides any benefit to the Solr side of things at all, however I also completely agree that it would make things easier in the Lucene world.
- Test times: We can always run the tests separately and I think that's what everyone does most of the time. Splitting the project wouldn't really get us much here. - Builds: I agree that the build system is interlinked and non-trivial to manage, especially when you have a task like switching over to a new system (thanks for all the effort around that) but most of it is behind us at this point. Both, Lucene and Solr do have different ways of handling things, but the difference in workflow for people wouldn't really work here specially as we would retain the committer bits across the newly split projects, if that happens. If we think there is a unified or common way to work with both projects, let's instead move in that direction and make it easier for folks. - Packaging: Another thing that is almost completely disconnected at the moment. Solr and Lucene releases don't have much in common other than the release numbers and so the back-compat requirements. - About the dependency bit - I wouldn't really compare Solr with Elasticsearch only because they are fundamentally different in terms of one being an Apache project, and the other not being one. Moreover, right now, Solr and Lucene are the same project. Personally I feel the burden of proof should not be why they should be > split up, but the other way - "what arguments can be made for keeping them > together?" I disagree with that statement. The reasons that were highlighted, while certainly are points of concerns, I don't think that splitting the project is a way to solve the problem. Suggesting that the responsibility of justifying undertaking such a task should lie on folks who support the current state doesn't seem reasonable to me. The reason for keeping the project unified overlap with a lot of what has been already mentioned w.r.t. the reasons to combine them. To reiterate, I completely agree with the concerns and that we should do something about them to make it easier and attractive for contributors, but splitting the project isn't really a solution. Will splitting do good for Solr? I don't think so. Not objectively at least. This will harm Solr in my opinion and not solve any of the above problems for the new Solr TLP. Will splitting be good for Lucene? Absolutely. It will make things easier for Lucene as the complexity around a distributed system will reduce, in addition to a lot of other things, technically and community wise. Like Simon, I am completely pro doing the right thing, irrespective of the difficulty involved, but we need to all be aware of the pros and the cons of this step, and make an informed decision. -Anshum On Wed, May 6, 2020 at 11:21 AM Gus Heck <gus.h...@gmail.com> wrote: > IMO, if we need to say “we can’t release X because it breaks Y”, or “we >> need to release X to be able to release Y”, the projects are not really >> independent, and “the PMCs will overlap” won’t take us very far. >> > > This. I don't think the two really can be separated. Any separation will > merely be artificial, and/or an excuse for throwing stuff over the wall. > The sooner incompatibilities or difficulties are identified the better. > Definitely not in favor of splitting. > > Really, we are effectively "search.apache.org" (or I suppose " > java-search.apache.org") and the lucene name as the TLP is just a > legacy thing. We can have components (as does hc.apache.org) but Solr > can't live without Lucene, so fostering a sense of separation is going to > be bad for Solr. > > If someday we reach a point where some other library could swap into Solr > to replace Lucene, then maybe. > > My opinion, YMMV :) > > > On Wed, May 6, 2020 at 5:40 AM Simon Willnauer <simon.willna...@gmail.com> > wrote: > >> I can speak from experience that working with a snapshot is much >> cleaner than working with submodules. We do this in elasticsearch for >> a very long time now and our process here works just fine. It has a >> bunch of advantages over a direct / source dependency like solr has >> right now. I recall that someone else already mentioned some of them >> like working on somewhat more stable codebase etc. do refactorings and >> integration when there are people dedicated to it and have enough time >> to do it properly. >> >> Regarding the effort of a split, I think that not doing something >> because it's a lot of work will just cause a ton of issues down the >> road. Doing the right thing is a lot of work that's for sure but we >> can start working on this in baby steps an we can all help. Like we >> can gradually do this, start with website, lists then build system >> etc. or start with build first and do website last. It's ok to apply >> progress over perfection here. We all want this to be done properly >> and we are all here to help, at least I am. >> >> simon >> >> On Wed, May 6, 2020 at 10:51 AM Ishan Chattopadhyaya >> <ichattopadhy...@gmail.com> wrote: >> > >> > Except the logistics of enacting the split, I see no valid reason of >> keeping the projects together. Git submodule is the magic that we have to >> ease any potential discomfort. However, the effort needed to split feels >> absolutely massive, so I'm not sure if it is worth the hassle. >> > >> > On Wed, 6 May, 2020, 1:31 pm Dawid Weiss, <dawid.we...@gmail.com> >> wrote: >> >> >> >> > If you go to lucene.apache.org, you'll see three things: Lucene >> Core (Lucene with all it's modules), Solr and PyLucene. That's what I mean. >> >> >> >> Hmm... Maybe I'm dim but that's essentially what I want to do. Look: >> >> >> >> 1. Lucene Core (Lucene with all it's modules) >> >> 2. Solr >> >> 3. PyLucene >> >> >> >> The thing is: (1) is already a TLP - that's just Lucene. My call is to >> >> make (2) a TLP. (3) I can't tell much about because I don't know >> >> PyLucene as well as I do Solr and Lucene... But it seems to me that >> >> PyLucene fits much better under "Lucene" umbrella, even the name >> >> suggests that. >> >> >> >> >> >> >> >> 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 >> >> > > -- > http://www.needhamsoftware.com (work) > http://www.the111shift.com (play) > -- Anshum Gupta
