Hoss, One important reason why separate repo for solr-extras is a good idea, as opposed to conrib modules, is that separate repo can be used to test against many Solr versions. Imagine a component that works across Solr versions 6x through 9x from day one. I can't imagine such a component being part of the lucene-solr repo itself.
Also, today, contrib modules are shipped with Solr, which we don't want for new things we might want to build. On Mon, Jan 25, 2021 at 4:25 PM Ishan Chattopadhyaya < ichattopadhy...@gmail.com> wrote: > I haven't been able to follow up on creation of the extras repo, but more > importantly I wanted to respond to Hoss. I'm out on an emergency for a week > or so, shall resume then. If there's a decision on this until then, I shall > accept it. > > On Mon, 25 Jan, 2021, 9:04 am Jason Gerlowski, <gerlowsk...@gmail.com> > wrote: > >> 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 >> >>
