Yes, A docker image will definitely help. I wasn't trying to downplay that On Tue, Oct 6, 2020 at 6:55 PM Ishan Chattopadhyaya <ichattopadhy...@gmail.com> wrote: > > > > 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, > <ichattopadhy...@gmail.com> 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, <tomasflo...@gmail.com> >> 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 <noble.p...@gmail.com> 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 <dsmi...@apache.org> 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
-- ----------------------------------------------------- Noble Paul --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
