Offtopic: Gus, I'm looking at Vespa core for Solr someday. I used to work at Yahoo! and I was a strong advocate of replacing Vespa with Solr for our team. A quick benchmark back then proved to me that Vespa was faster than Solr for our usecase and I rested my case. Both Lucene and Vespa have improved, so I'd love to do that experiment again.
On Wed, 6 May, 2020, 11:51 pm 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) >
