Agere with Houston 100%. I think it's a good idea to have an official repo for things that are related to Solr and, at the same time, don't belong within the Solr codebase such as the prometheus exporter or, eventually, the cross-dc work that Anshum is working on (once it "graduates" from sandbox I guess). For the "first party" plugins (things like analysis-extra, langid, ltr), it's better to keep them together with the codebase, so that we can easily guarantee compatibility and releases together with Solr.
On Wed, Jan 13, 2021 at 8:26 AM Atri Sharma <a...@apache.org> wrote: > +1 > > This is also an opportunity to create the distinction between first party > supported packages and the other plug-ins. > > > > On Wed, 13 Jan 2021, 21:00 Ishan Chattopadhyaya, < > ichattopadhy...@gmail.com> wrote: > >> Hi Devs, >> >> 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 >> modules, upcoming HDFS support module (separated away from solr-core), >> other first party packages. Along with that, there is also a need for a >> repository for hosting WIP modules/sub-projects. >> >> I propose that we apply for the creation of two new git repositories: >> 1. solr-extras (or lucene-solr-extras) >> 2. solr-sandbox (or lucene-solr-sandbox) >> >> Well tested, well supported modules/sub-projects can be released straight >> away from *solr-extras*. The first party packages can be built from this >> location and shipped with Solr (or be available for install using the >> package manager CLI). >> >> New, unproved, beta, unstable modules can be hosted on *solr-sandbox* >> (and graduate to solr-extras once stable). >> >> Please let me know if there are any questions/concerns with this approach. >> >> Thanks and regards, >> Ishan >> >
