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 >>> >>
