Tentative +1 to Hoss' questions. I agree with his summary of the potential risks here, and I share his ignorance of the perceived benefits.
(I thought for a time that this was driven by interest in having release cadences independent from Solr-core releases. I'm all for that goal, but if that's the motivation I'm not sure what the obstacle is to doing that with a single repo - all build systems these days support versioning and releasing modules independent of one another. But maybe that was never a driving factor here.) I know there have been a lot of discussions about this, and I know the repo has already been created. So maybe it's too late to object even if I wanted to, which I'm not sure I do. But can someone that understands the motivation please summarize what multiple-repos gets us over a single repo that outweighs the "cons" that Hoss mentioned? Jason On Thu, Jan 14, 2021 at 12:34 PM Chris Hostetter <hossman_luc...@fucit.org> wrote: > > > : As we discussed over the last few months, there seems a need to move > : non-core pieces away from the Solr core module. The contribs are presently > : a good place, but it makes sense to have a separate git repository hosting > : such modules. Some candidates that come to mind are the present day contrib > > can you explain why it makes sense to have a separate git repo for these > things? > > I can think of lots of reasons why it makes sense to have a single > repo for all things solr (unified CI that quickly identifies if core > changes break "first order" plugins, shared feature branches & monotomic > commits of code that affects APIs and impls of those APIs, etc...) but > I've yet to see any concrete specifics of why multiple git repos are > "better" then just having distinct sub-projects (with distinct artifacts) > in the same repo other then "it makes sense" > > why does it make sense? > > why can't the ideas of "solr-sandbox" and "solr-extras" just be > directories in the "solr repo" ? ... what value is gained by making them > new repos? > > > -Hoss > http://www.lucidworks.com/ > > --------------------------------------------------------------------- > 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