I'm glad to see efforts to merge the reference branch changes into master. 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? Don't know what's the issue with the package manager but It likely can be modified to handle something like this. Also, why does this need to be an official Apache release? Lets just make unofficial releases (maybe tags in GH and the binaries in your apache home directory or something) and ask the community to test those. You can iterate much faster that way (you may want to have multiple of these releases , maybe weekly at some point and going through the official process will be tedious) and it would be much more clear for the users.
On Sun, Oct 4, 2020 at 10:16 AM Ishan Chattopadhyaya < [email protected]> wrote: > > 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 <[email protected]> > 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 <[email protected]> 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 < >> [email protected]> wrote: >> >> >> >> Erick, I'll answer your questions shortly. >> >> >> >> On Sun, 4 Oct, 2020, 10:33 am Ishan Chattopadhyaya, < >> [email protected]> 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, <[email protected]> >> 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 <[email protected]> >> 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 < >> [email protected]>: >> >>>> >> >> >>>> >> 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: [email protected] >> For additional commands, e-mail: [email protected] >> >>
