@Tomas Fernandez Lobbe This is a very risky proposition. Let's say we cut 9x and now there is a new master taken from the reference branch. That master is now going to be 10.0.
* We never get it to the hands of the users anytime soon. We will never be able to reconcile these 2 branches * The master & 9x branches will diverge so much that we cannot make any meaningful commits to any of these branches Reference branch will have all the features of Solr 9.0 because it is forked from master (some latest changes are yet to be merged). So, reference branch is 100% compatible with master. A user should be able to do a drop in replacement between 9.0 & reference branch. It is also possible to have a cluster with nodes running 9x and reference together( A rolling restart should be possible). Let's take stock of what we have today. Choice 1: * Mark has made some significant changes to improve performance stability * Mark has promised to make all tests pass over the next 2-3 weeks * Ishan has promised to do the work to make a release possible * Ishan has promised to port changes to master as soon as we get enough user feedback. He has also expressed his reservations on doing this before it is tested in the wild * I promise to do code review & cleanup as much as possible. But I'm hesitant to give a stamp of approval to make it THE official release Choice: 2 * Tomas promise to port changes from the branch to master * Tomas make a release Choice 3: * Status quo * We throw away all the good work that is done & demotivate the developers * Deprive users of all the promised goodness I'm not sure what else is a choice and who is volunteering to work on that. We need people who are willing to offer to get their hands dirty. Personally, I'm totally against choice #3 and I'm willing to collaborate with anyone who is has a plan to make all the goodness in the branch available to our users On Tue, Oct 6, 2020 at 6:39 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
