Agreed. +1 Sent from my iPhone > On Jan 7, 2026, at 4:30 AM, Jan Høydahl <[email protected]> wrote: > > +1 > > As a module in monorepo it will get more testing and love. And can easily be > moved elsewhere if we change our preferences down the road vs multi repo and > packages. > > Jan > >> 7. jan. 2026 kl. 07:11 skrev David Smiley <[email protected]>: >> >> +1 to add it to the primary Solr repo. >> >> On Fri, Sep 26, 2025 at 9:17 AM Jason Gerlowski <[email protected]> >> wrote: >> >>>> I don't think sandbox was intended originally to host ready modules with >>> a release process. >>> >>> Yeah, it's a bit handwave-y, but my understanding of "sandbox" was >>> that it was for more experimental code, which doesn't seem like it's >>> the case for the encryption stuff at this point? >>> >>> Even outside of the messaging or implications about experimental vs >>> production-readiness, the code would be easier to consume if it was >>> elsewhere. Sandbox is "just" a code repo, so consumers need to do >>> their own releases, compatibility testing (for their particular Solr >>> version), packaging or installing into Solr, etc. Moving it into the >>> main repo as a module would provide a lot of benefit to any potential >>> consumers. >>> >>> Anyway I'm +1 on the overall idea, as I understand it at least. But I >>> do have some feedback on the writeup/proposal: >>> >>> - if the "ask" at the heart of the SIP is to change where the code >>> lives, the writeup should spend a bit more time outlining why that's a >>> better path forward. What are the problems with keeping the code in >>> "sandbox"? What's the benefit to a potential user of having the code >>> in the main repo? (We've discussed some of those details already in >>> this thread, but it's still worth summarizing in the "Motivation" >>> section of the SIP) >>> >>> - I love the architecture docs in the current "Proposed Changes" >>> section! But the section spends so much time detailing the current >>> state of the code that it doesn't really talk much about what would >>> actually change. I get that this is mostly "just" a move, but there >>> will be changes I imagine: does the sandbox code require any changes >>> or updates to fit into the Solr "module" paradigm? is it already >>> building with Java 21? since it currently builds against Solr 9.9 in >>> sandbox does it need any particular changes to get it working against >>> the "main" branch? what sort of ref-guide documentation should be >>> added? etc. >>> >>> Best, >>> >>> Jason >>> >>> On Tue, Aug 12, 2025 at 5:56 AM Bruno Roustant <[email protected]> >>> wrote: >>>> >>>> Thanks David. >>>> >>>> Yes, I'm proposing to discuss whether it should move to the main Solr >>> repo. >>>> In the current state, solr-sandbox seems dedicated to incubating modules. >>>> Actually, my main point is to say the encryption module should exit the >>>> incubation state, whether it stays in the sandbox or not. But if it stays >>>> there, there should be a clear way to differentiate "incubating" or >>> "ready" >>>> modules for external users. >>>> - If users want to have encryption for Solr (provided they have the right >>>> use-case, as described in the doc), they should have confidence they can >>>> use it. >>>> - To my knowledge, there is no section in the Solr doc that describes the >>>> modules in solr-sandbox. >>>> - Maybe a new module available should be announced in dev and user list. >>>> But it should wait for some feedback first I think. >>>> >>>> Technically, the sandbox is separate from the main repo, so many updates >>>> need to wait for the next Solr release: development is longer. >>>> And you are right, there is no test infra nor release process. I don't >>>> think sandbox was intended originally to host ready modules with a >>> release >>>> process. >>> >>> --------------------------------------------------------------------- >>> 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] >
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
