> Docker is not a big requirement for large scale installations. Most of them already have their own install scripts. Availability of docker is not important for them. If a user is only encouraged to install Solr because of a docker image , most likely they are not running a large enough cluster
I disagree, Noble. Having a docker image us going to be useful to some clients, with complex usecases. Great point, David! On Tue, 6 Oct, 2020, 1:09 pm Ishan Chattopadhyaya, < [email protected]> wrote: > As I said, I'm *personally* not confident in putting such a big changeset > into master that wasn't vetted in a real user environment widely. I have, > in the past, done enough bad things to Solr (directly or indirectly), and I > don't want to repeat the same. Also, I'll be very uncomfortable if someone > else did so. > > Having said this, if someone else wants to port the changes over to master > *without first getting enough real world testing*, feel free to do so, and > I can focus my efforts elsewhere. > > On Tue, 6 Oct, 2020, 9:22 am Tomás Fernández Löbbe, <[email protected]> > wrote: > >> I was thinking (and I haven’t flushed it out completely but will throw >> the idea) that an alternative approach with this timeline could be to cut >> 9x branch around November/December? And then you could merge into master, >> it would have the latest changes from master plus the ref branch changes. >> From there any nightly build could be use to help test/debug. >> >> That said I don’t know for sure what are the changes in the branch that >> do not belong in 9. The problem with them being 10x only is that backports >> would potentially be more difficult for all the life of 9. >> >> On Mon, Oct 5, 2020 at 4:54 PM Noble Paul <[email protected]> wrote: >> >>> >I don't think it can be said what committers do and don't do with >>> regards to running Solr. All of us would answer this differently and at >>> different points in time. >>> >>> " I have run it in one large cluster, so it is certified to be bug >>> free/stable" I don't think it's a reasonable approach. We need as much >>> feedback from our users because each of them stress Solr in a >>> different way. This is not to suggest that committers are not doing testing >>> or their tests are not valid. When I talk to the committers out here they >>> say they do not see any performance stability issues at all. But, my client >>> reports issues on a day to day basis. >>> >>> >>> >>> > Definitely publish a Docker image BTW -- it's the best way to try out >>> any software. >>> >>> Docker is not a big requirement for large scale installations. Most of >>> them already have their own install scripts. Availability of docker is not >>> important for them. If a user is only encouraged to install Solr because of >>> a docker image , most likely they are not running a large enough cluster >>> >>> >>> >>> On Tue, Oct 6, 2020, 6:30 AM David Smiley <[email protected]> wrote: >>> >>>> Thanks so much for your responses Ishan... I'm getting much more >>>> information in this thread than my attempts to get questions answered on >>>> the JIRA issue months ago. And especially, thank you for volunteering for >>>> the difficult porting efforts! >>>> >>>> Tomas said: >>>> >>>>> I do agree with the previous comments that calling it "Solr 10" (even >>>>> with the "-alpha") would confuse users, maybe use "reference"? or maybe >>>>> something in reference to SOLR-14788? >>>>> >>>> >>>> I have the opposite opinion. This word "reference" is baffling to me >>>> despite whatever Mark's explanation is. I like the justification Ishan >>>> gave for 10-alpha and I don't think I could re-phrase his justification any >>>> better. *If* the release was _not_ official (thus wouldn't show up in the >>>> usual places anyone would look for a release), I think it would alleviate >>>> that confusion concern even more, although I think "alpha" ought to be >>>> enough of a signal not to use it without digging deeper on what's going on. >>>> >>>> Alex then Ishan said: >>>> >>>>> > Maybe we could release it to >>>>> > committers community first and dogfood it "internally"? >>>>> >>>>> Alex: It is meaningless. Committers don't run large scale >>>>> installations. We barely even have time to take care of running unit tests >>>>> before destabilizing our builds. We are not the right audience. However, >>>>> we >>>>> all can anyway check out the branch and start playing with it, even >>>>> without >>>>> a release. There are orgs that don't want to install any code that wasn't >>>>> officially released; this release is geared towards them (to help us test >>>>> this at their scale). >>>>> >>>> >>>> I don't think it can be said what committers do and don't do with >>>> regards to running Solr. All of us would answer this differently and at >>>> different points in time. From time to time, though not at present, I've >>>> been well positioned to try out a new version of Solr in a stage/test >>>> environment to see how it goes. (Putting on my Salesforce metaphorical >>>> hat...) Even though I'm not able to deploy it in a realistic way today, I'm >>>> able to run a battery of tests to see if one of the features we depend on >>>> have changed or is broken. That's useful feedback to an alpha release! >>>> And even though I'm saying I'm not well positioned to try out some new Solr >>>> release in a production-ish setting now, it's something I could make a good >>>> case for internally since upgrades take a lot of effort where I work. It's >>>> in our interest for SolrCloud to be very stable (of course). >>>> >>>> Regardless, I think what you're driving at Ishan is that you want an >>>> "official" release -- one that goes through the whole ceremony. You >>>> believe that people would be more likely to use it. I think all we need to >>>> do is announce (similar to a real release) that there is some unofficial >>>> alpha distribution and that we want to solicit your feedback -- basically, >>>> help us find bugs. Definitely publish a Docker image BTW -- it's the best >>>> way to try out any software. I'm -0 on doing an official release for alpha >>>> software because it's unnecessary to achieve the goals and somewhat >>>> confusing. I think the Solr 4 alpha/beta situation was different -- it was >>>> not some fork a committer was maintaining; it was the master branch of its >>>> time, and it was destined to be the very next release, not some possible >>>> future release. >>>> >>>> ~ David Smiley >>>> Apache Lucene/Solr Search Developer >>>> http://www.linkedin.com/in/davidwsmiley >>>> >>>
