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 <[email protected]> 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, <[email protected]> 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: [email protected] >> For additional commands, e-mail: [email protected] >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
