> I do hope we manage to port to master all these improvements! Ilan: It is a very important consideration. We should ensure that this happens (either these changes are ported to master in chunks, or this branch becomes master after fixing the history to decompose in meaningful chunks).
> What’s your sense of how much effort changing _functionality_ on master/8x and porting it to the EA is? I’m sure “It Depends(tm)”, I’m more interested in whether you expect most stuff ports pretty easily or very little stuff to port easily? Erick: I feel both branches (master and reference) are mostly on par functionality wise (except recent changes in master, post June). AFAICT, bulk of the changes in reference branch are fixes, refactorings and SolrCloud improvements. Mark, please fill in if I've missed something. > BTW, how many warnings are there ;) Erick: Tons! Precommit fails too. That's why we need time till December :-) > does it become futile to chase down the intermittent failures we see on master/8x? One of the major thrusts of the EA is things like race conditions and the like. If many/most such errors just disappear in EA, I have little incentive to fix them in master/8x. Under any circumstances, I suspect that most fixes like this would be totally different between the two. That’s a huge positive BTW…. Erick: Depends on how optimistic we are about the success of this branch. At this moment, I am not confident enough to have these changes in reference branch merged back to master, and hence I want users to do a thorough production testing before we are confident. Just because tests run fast doesn't necessarily mean the service will run flawlessly in production, even though that is definitely the hope Mark started this effort with. In my opinion, fixes to 8x/master should definitely not stop because of this effort. > Does it make sense to cut 9.0 coincidentally with the EA being adopted as the right future direction? In that case, 9x may be short-lived, more of a placeholder that we deprecate methods, backport new changes from EA etc, but don’t necessarily expend much effort to backport changes from 10x that don’t backport easily. Erick: +1, definitely one of the many reasonable paths to take, IMO. > Has Lucene changed much (or at all) in the EA? I’m guessing not. Maybe not even touched… Erick: It is the same Lucene as what master is using. I don't see any Lucene level changes. > Let's focus on making all the tests pass and get this to the hands of our users. Noble: +1 > Let's say Solr 10 ( or whatever name gets picked ) turns out stable enough in the alpha phase - What would the next step be? Varun: I think at that point we should make sure that branch is the master: either (i) by porting over all changes from that branch, piece by piece, to master branch (I volunteer to do so), or (ii) fix the commit history of that branch itself (decompose all the changes into meaningful/logical chunks) and make sure all features in current master are on that branch (I volunteer to do so). > Would we bring back all the changes to master? Varun: As I explained above, that is one of the possiblities. > Do you have a sense into how that would end up playing out? Could it be brought in chunks or would it have to be wholesale ? Varun: It can surely be brought in wholesale. As per a conversation with Noble and David, we agreed that bringing it in chunks would be best going forward. All chunks may not independently work/pass tests, but they will be isolated enough to capture the themes. > Also do you know what features in the reference branch have been removed because they were unstable ? Varun: None that I am aware of. Mark, please help me here. There are many features whose tests are disabled, either because they were failing or they were taking very long. It is our collective goal to ensure they are unignored before this EA release. Mark is working on it, AFAIK. > Finding out the features/bug-fixes in master that haven't made it to the reference branch would be easier to find out. Varun: This is important, so that master and reference are on par with each other features wise. This is what I was working on, and intend to continue working on. (SOLR-14830) > When we say "let users try", do we mean actual public with a release published on our website? Alex: Yes, an official release via Apache process. > Because I can see the publishing of version 10, however it is tagged > (alpha, whatever), completely confusing people about the upcoming 9 > version and causing an adoption delay. Alex: We have to be very clear about messaging that this is an early access preview release, and by no means what will be there in the final 10.0 (or howsoever we tag it). > Especially combined with > cleanups that we already put in 9.0. Alex: All 9.0 cleanups (deprecations, removals, examples) etc. should ideally be mirrored in this reference branch. We should ensure that and that is part of what I'm working on: SOLR-14830 > 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). > And if the issue with naming it 'not 10.x' is one piece of code > (package manager), maybe we can one-off patch that instead. Or hack > the version to be something ridiculous like 42 (the answer to > everything...) instead of something that is psychologically feasible. Alex: I am fine with any version so long as it is numeric (with a alphanumeric suffix, e.g. 10.0.0-alpha or 10.0.0-ea, or 42.0.0-alpha). We can arrive at that number in a separate thread, if needed. On Sun, Oct 4, 2020 at 9:33 PM Alexandre Rafalovitch <arafa...@gmail.com> wrote: > (The comments below are in the context of +1 of getting this working out.) > > When we say "let users try", do we mean actual public with a release > published on our website? > > Because I can see the publishing of version 10, however it is tagged > (alpha, whatever), completely confusing people about the upcoming 9 > version and causing an adoption delay. Especially combined with > cleanups that we already put in 9.0. Maybe we could release it to > committers community first and dogfood it "internally"? > > And if the issue with naming it 'not 10.x' is one piece of code > (package manager), maybe we can one-off patch that instead. Or hack > the version to be something ridiculous like 42 (the answer to > everything...) instead of something that is psychologically feasible. > I recall this dual version confusion happening before in other > communities and it really messed things up. Python is a recent > example, but I seem to recall other similar events for > products/communities that no longer exist (hopefully for other > reasons). > > And yes, all the questions of forward-porting are there as well, > if/once this succeeds. > > Regards, > Alex. > > > Regards, > Alex. > > On Sun, 4 Oct 2020 at 11:34, Varun Thacker <va...@vthacker.in> wrote: > > > > Hi Ishan, > > > > Let's say Solr 10 ( or whatever name gets picked ) turns out stable > enough in the alpha phase - What would the next step be? > > > > Would we bring back all the changes to master? Do you have a sense into > how that would end up playing out? Could it be brought in chunks or would > it have to be wholesale ? > > > > Also do you know what features in the reference branch have been removed > because they were unstable ? Finding out the features/bug-fixes in master > that haven't made it to the reference branch would be easier to find out. > > > > On Sat, Oct 3, 2020 at 10:17 PM Ishan Chattopadhyaya < > ichattopadhy...@gmail.com> wrote: > >> > >> Erick, I'll answer your questions shortly. > >> > >> On Sun, 4 Oct, 2020, 10:33 am Ishan Chattopadhyaya, < > ichattopadhy...@gmail.com> wrote: > >>> > >>> Agree, Noble. Let's not worry about the naming too much. We can > discuss that later as well, or in a separate thread. > >>> > >>> On Sun, 4 Oct, 2020, 10:06 am Noble Paul, <noble.p...@gmail.com> > wrote: > >>>> > >>>> +1 Ishan > >>>> > >>>> It's important that the branch gets some real world testing and > >>>> feedback. At this point we cannot be 100% sure about the stability of > >>>> that branch to port all the changes to master. > >>>> > >>>> Users don't care what is Solr 9/Solr 10 or even Mark's Solr or even a > >>>> "Crazy Solr". As long as all the tests pass and they can do an upgrade > >>>> of their existing cluster to that release,that IS Solr. I think we do > >>>> not need to worry too much about it now. If/when we reach a point > >>>> where we have a new stable release of Solr that is 100% compatible > >>>> with our other branch, we can resume this discussion. > >>>> > >>>> As Ilan said, we may get real feedback from our users deploying it on > >>>> production scale but non critical deployments. Our JUnit tests are not > >>>> good enough to uncover stability issues. > >>>> > >>>> Let's focus on making all the tests pass and get this to the hands of > our users. > >>>> > >>>> On Sun, Oct 4, 2020 at 8:01 AM Uwe Schindler <u...@thetaphi.de> wrote: > >>>> > > >>>> > Is the branch ready for Jenkins testing? > >>>> > > >>>> > If yes and "gradlew check" works, I really would like to set it up. > >>>> > > >>>> > Uwe > >>>> > > >>>> > Am October 3, 2020 7:42:22 PM UTC schrieb Ishan Chattopadhyaya < > ichattopadhy...@gmail.com>: > >>>> >> > >>>> >> Hi Devs, > >>>> >> > >>>> >> As you might be aware, the reference_impl branch has a lot of > improvements that we want to see in Solr master. However, it is currently a > large deviation from master and hence the stability and reliability (though > improved in certain aspects) remains to be tested in real production > environments before we gain confidence in bringing those changes to master. > >>>> >> > >>>> >> I propose that we do a one off preview release from that branch, > say Solr 10 alpha (early access) or any other name that someone suggests, > so that users could try it out and report regressions or improvements etc. > >>>> >> > >>>> >> I volunteer to be the RM and planning to start the process around > 1 December-15 December timeframe. Until then, we can tighten the loose ends > on the branch and plan for such a release. > >>>> >> > >>>> >> Is there any thoughts, concerns, questions? > >>>> >> > >>>> >> Regards, > >>>> >> Ishan > >>>> > > >>>> > > >>>> > -- > >>>> > Uwe Schindler > >>>> > Achterdiek 19, 28357 Bremen > >>>> > https://www.thetaphi.de > >>>> > >>>> > >>>> > >>>> -- > >>>> ----------------------------------------------------- > >>>> Noble Paul > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
