Solr Alpha (EA) release of Reference Branch

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
38 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Solr Alpha (EA) release of Reference Branch

Ishan Chattopadhyaya
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
Reply | Threaded
Open this post in threaded view
|

Re: Solr Alpha (EA) release of Reference Branch

Ilan Ginzburg
Thanks Ishan for the initiative!
I think that’s a good idea if it allows testing that branch, assuming some are ready to invest what it takes and run this in production (maybe not with user facing prod traffic?).

I do not think naming it Solr 10 is a good idea though, as it is likely very different from what will end up being in Solr 10 (and even from what will be in Solr 9.

I do hope we manage to port to master all these improvements!

Ilan

On Sat 3 Oct 2020 at 21:42, Ishan Chattopadhyaya <[hidden email]> wrote:
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
Reply | Threaded
Open this post in threaded view
|

Re: Solr Alpha (EA) release of Reference Branch

Erick Erickson
I agree with Ilan, let’s call it something else. “super special the future of Solr” maybe ;) “Marks baby”. “batshit crazy better Solr”.

What I’d like to avoid is confusion about where to fix things. Say I’m working on an issue. Should I fix it in this impl then backport to 9.0 and 8x? Do like we do now (fix on 9.0 backport to 8x as indicated) then “forward port” to the reference impl? Ignore the reference impl other than testing?

Questions:

- 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? BTW, how many warnings are there ;)

- The above notwithstanding, 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….

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

- Has Lucene changed much (or at all) in the EA? I’m guessing not. Maybe not even touched…

Thanks,
Erick

> On Oct 3, 2020, at 4:27 PM, Ilan Ginzburg <[hidden email]> wrote:
>
> Thanks Ishan for the initiative!
> I think that’s a good idea if it allows testing that branch, assuming some are ready to invest what it takes and run this in production (maybe not with user facing prod traffic?).
>
> I do not think naming it Solr 10 is a good idea though, as it is likely very different from what will end up being in Solr 10 (and even from what will be in Solr 9.
>
> I do hope we manage to port to master all these improvements!
>
> Ilan
>
> On Sat 3 Oct 2020 at 21:42, Ishan Chattopadhyaya <[hidden email]> wrote:
> 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


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Solr Alpha (EA) release of Reference Branch

Uwe Schindler
In reply to this post by Ishan Chattopadhyaya
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 <[hidden email]>:
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
Reply | Threaded
Open this post in threaded view
|

Re: Solr Alpha (EA) release of Reference Branch

Ishan Chattopadhyaya
Yes Uwe, it is ready for Jenkins testing. The Solr tests should run very fast now.

As for naming, our package manager in Solr will break if we don't specify a major and a minor version. There's a concept of version constraints for packages that need to compare against Solr version. I think release process will also be much simpler if we have a major and minor version. We have done a similar release in the past, 4.0.0-beta iirc.

Why I favour 10.0-alpha or something like that is because users would clearly know it is something that isn't coming right now (and hence very early access), and it is logically a major version change (that comes after 8x). With calling it 10x instead of 9x, we have the scope of abandoning the effort as a whole if the early access releases have some serious problem or we decide to take some other release strategy later.

If the 10.0-alpha succeeds, we can always fold the changes back into a 9.1 or go from 9.0 straight to 10.0, depending on what we decide later. Alternatively, if the release looks good and 9.0 hasn't released yet, we can fold those changes back to master, and either (a) release everything normally as 9.0, or (b) call master as 10x and release from there (going from 8.8 to 10.0 directly, skipping 9x altogether).

Tldr, we shall have complete flexibility to go in any direction we want to.

WDYT?

On Sun, 4 Oct, 2020, 2:31 am Uwe Schindler, <[hidden email]> 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 <[hidden email]>:
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
Reply | Threaded
Open this post in threaded view
|

Re: Solr Alpha (EA) release of Reference Branch

Noble Paul നോബിള്‍  नोब्ळ्
In reply to this post by Uwe Schindler
+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 <[hidden email]> 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 <[hidden email]>:
>>
>> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Solr Alpha (EA) release of Reference Branch

Ishan Chattopadhyaya
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, <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:
>>
>> 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
Reply | Threaded
Open this post in threaded view
|

Re: Solr Alpha (EA) release of Reference Branch

Ishan Chattopadhyaya
Erick, I'll answer your questions shortly.

On Sun, 4 Oct, 2020, 10:33 am Ishan Chattopadhyaya, <[hidden email]> 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, <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:
>>
>> 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
Reply | Threaded
Open this post in threaded view
|

Re: Solr Alpha (EA) release of Reference Branch

Varun Thacker-4
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 <[hidden email]> wrote:
Erick, I'll answer your questions shortly.

On Sun, 4 Oct, 2020, 10:33 am Ishan Chattopadhyaya, <[hidden email]> 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, <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:
>>
>> 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
Reply | Threaded
Open this post in threaded view
|

Re: Solr Alpha (EA) release of Reference Branch

Alexandre Rafalovitch
(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 <[hidden email]> 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 <[hidden email]> wrote:
>>
>> Erick, I'll answer your questions shortly.
>>
>> On Sun, 4 Oct, 2020, 10:33 am Ishan Chattopadhyaya, <[hidden email]> 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, <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:
>>>> >>
>>>> >> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Solr Alpha (EA) release of Reference Branch

Ishan Chattopadhyaya
> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
>>
>> Erick, I'll answer your questions shortly.
>>
>> On Sun, 4 Oct, 2020, 10:33 am Ishan Chattopadhyaya, <[hidden email]> 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, <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:
>>>> >>
>>>> >> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Solr Alpha (EA) release of Reference Branch

Tomás Fernández Löbbe
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
>>
>> Erick, I'll answer your questions shortly.
>>
>> On Sun, 4 Oct, 2020, 10:33 am Ishan Chattopadhyaya, <[hidden email]> 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, <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:
>>>> >>
>>>> >> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: Solr Alpha (EA) release of Reference Branch

Uwe Schindler
In reply to this post by Ishan Chattopadhyaya

Hi,

I enabled the „gradlew check” runs on ASF Jenkins and Policeman Jenkins (Linux, Windows, MacOS).

 

I used branch (“reference_impl”). Is this correct, because it’s about a month old?

There’s also a much newer “reference_impl_dev” branch. Which one is correct?

 

I will go sleeping now, sorry for failure mails during the night. Builds seem to fail, but it’s too late to do anything against it.

 

Uwe

 

-----

Uwe Schindler

Achterdiek 19, D-28357 Bremen

https://www.thetaphi.de

eMail: [hidden email]

 

From: Ishan Chattopadhyaya <[hidden email]>
Sent: Sunday, October 4, 2020 6:32 AM
To: Uwe Schindler <[hidden email]>
Cc: Lucene Dev <[hidden email]>
Subject: Re: Solr Alpha (EA) release of Reference Branch

 

Yes Uwe, it is ready for Jenkins testing. The Solr tests should run very fast now.

 

As for naming, our package manager in Solr will break if we don't specify a major and a minor version. There's a concept of version constraints for packages that need to compare against Solr version. I think release process will also be much simpler if we have a major and minor version. We have done a similar release in the past, 4.0.0-beta iirc.

 

Why I favour 10.0-alpha or something like that is because users would clearly know it is something that isn't coming right now (and hence very early access), and it is logically a major version change (that comes after 8x). With calling it 10x instead of 9x, we have the scope of abandoning the effort as a whole if the early access releases have some serious problem or we decide to take some other release strategy later.

 

If the 10.0-alpha succeeds, we can always fold the changes back into a 9.1 or go from 9.0 straight to 10.0, depending on what we decide later. Alternatively, if the release looks good and 9.0 hasn't released yet, we can fold those changes back to master, and either (a) release everything normally as 9.0, or (b) call master as 10x and release from there (going from 8.8 to 10.0 directly, skipping 9x altogether).

 

Tldr, we shall have complete flexibility to go in any direction we want to.

 

WDYT?

 

On Sun, 4 Oct, 2020, 2:31 am Uwe Schindler, <[hidden email]> 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 <[hidden email]>:

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

Reply | Threaded
Open this post in threaded view
|

RE: Solr Alpha (EA) release of Reference Branch

Uwe Schindler

Hi,

 

In addition the gradle build scripts in the reference_impl branch seems very outdated and does not support Policeman-Jenkins Multi-JVM testing. Although it will print that it ran with later Java version, in fact it runs with JDK 11 only, as RUNTIME_JAVA_HOME is ignored.

 

Uwe

 

-----

Uwe Schindler

Achterdiek 19, D-28357 Bremen

https://www.thetaphi.de

eMail: [hidden email]

 

From: Uwe Schindler <[hidden email]>
Sent: Monday, October 5, 2020 12:01 AM
To: 'Ishan Chattopadhyaya' <[hidden email]>
Cc: 'Lucene Dev' <[hidden email]>
Subject: RE: Solr Alpha (EA) release of Reference Branch

 

Hi,

I enabled the „gradlew check” runs on ASF Jenkins and Policeman Jenkins (Linux, Windows, MacOS).

 

I used branch (“reference_impl”). Is this correct, because it’s about a month old?

There’s also a much newer “reference_impl_dev” branch. Which one is correct?

 

I will go sleeping now, sorry for failure mails during the night. Builds seem to fail, but it’s too late to do anything against it.

 

Uwe

 

-----

Uwe Schindler

Achterdiek 19, D-28357 Bremen

https://www.thetaphi.de

eMail: [hidden email]

 

From: Ishan Chattopadhyaya <[hidden email]>
Sent: Sunday, October 4, 2020 6:32 AM
To: Uwe Schindler <[hidden email]>
Cc: Lucene Dev <[hidden email]>
Subject: Re: Solr Alpha (EA) release of Reference Branch

 

Yes Uwe, it is ready for Jenkins testing. The Solr tests should run very fast now.

 

As for naming, our package manager in Solr will break if we don't specify a major and a minor version. There's a concept of version constraints for packages that need to compare against Solr version. I think release process will also be much simpler if we have a major and minor version. We have done a similar release in the past, 4.0.0-beta iirc.

 

Why I favour 10.0-alpha or something like that is because users would clearly know it is something that isn't coming right now (and hence very early access), and it is logically a major version change (that comes after 8x). With calling it 10x instead of 9x, we have the scope of abandoning the effort as a whole if the early access releases have some serious problem or we decide to take some other release strategy later.

 

If the 10.0-alpha succeeds, we can always fold the changes back into a 9.1 or go from 9.0 straight to 10.0, depending on what we decide later. Alternatively, if the release looks good and 9.0 hasn't released yet, we can fold those changes back to master, and either (a) release everything normally as 9.0, or (b) call master as 10x and release from there (going from 8.8 to 10.0 directly, skipping 9x altogether).

 

Tldr, we shall have complete flexibility to go in any direction we want to.

 

WDYT?

 

On Sun, 4 Oct, 2020, 2:31 am Uwe Schindler, <[hidden email]> 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 <[hidden email]>:

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

Reply | Threaded
Open this post in threaded view
|

Re: Solr Alpha (EA) release of Reference Branch

Noble Paul നോബിള്‍  नोब्ळ्
@Tomas Fernandez Lobbe


The naming is up for debate and it doesn't matter at this point in
time. I believe it has to be an official release to have enough
credibility. People trust the Apache brand and the community. This
will ensure that we get enough people to test this out. The very
objective of this release is to get help from our users to uncover any
bugs. Most big shops will not deploy unofficial releases in their
prod/staging environments. We wish to tick all the boxes for our users

On Mon, Oct 5, 2020 at 9:14 AM Uwe Schindler <[hidden email]> wrote:

>
> Hi,
>
>
>
> In addition the gradle build scripts in the reference_impl branch seems very outdated and does not support Policeman-Jenkins Multi-JVM testing. Although it will print that it ran with later Java version, in fact it runs with JDK 11 only, as RUNTIME_JAVA_HOME is ignored.
>
>
>
> Uwe
>
>
>
> -----
>
> Uwe Schindler
>
> Achterdiek 19, D-28357 Bremen
>
> https://www.thetaphi.de
>
> eMail: [hidden email]
>
>
>
> From: Uwe Schindler <[hidden email]>
> Sent: Monday, October 5, 2020 12:01 AM
> To: 'Ishan Chattopadhyaya' <[hidden email]>
> Cc: 'Lucene Dev' <[hidden email]>
> Subject: RE: Solr Alpha (EA) release of Reference Branch
>
>
>
> Hi,
>
> I enabled the „gradlew check” runs on ASF Jenkins and Policeman Jenkins (Linux, Windows, MacOS).
>
>
>
> I used branch (“reference_impl”). Is this correct, because it’s about a month old?
>
> There’s also a much newer “reference_impl_dev” branch. Which one is correct?
>
>
>
> I will go sleeping now, sorry for failure mails during the night. Builds seem to fail, but it’s too late to do anything against it.
>
>
>
> Uwe
>
>
>
> -----
>
> Uwe Schindler
>
> Achterdiek 19, D-28357 Bremen
>
> https://www.thetaphi.de
>
> eMail: [hidden email]
>
>
>
> From: Ishan Chattopadhyaya <[hidden email]>
> Sent: Sunday, October 4, 2020 6:32 AM
> To: Uwe Schindler <[hidden email]>
> Cc: Lucene Dev <[hidden email]>
> Subject: Re: Solr Alpha (EA) release of Reference Branch
>
>
>
> Yes Uwe, it is ready for Jenkins testing. The Solr tests should run very fast now.
>
>
>
> As for naming, our package manager in Solr will break if we don't specify a major and a minor version. There's a concept of version constraints for packages that need to compare against Solr version. I think release process will also be much simpler if we have a major and minor version. We have done a similar release in the past, 4.0.0-beta iirc.
>
>
>
> Why I favour 10.0-alpha or something like that is because users would clearly know it is something that isn't coming right now (and hence very early access), and it is logically a major version change (that comes after 8x). With calling it 10x instead of 9x, we have the scope of abandoning the effort as a whole if the early access releases have some serious problem or we decide to take some other release strategy later.
>
>
>
> If the 10.0-alpha succeeds, we can always fold the changes back into a 9.1 or go from 9.0 straight to 10.0, depending on what we decide later. Alternatively, if the release looks good and 9.0 hasn't released yet, we can fold those changes back to master, and either (a) release everything normally as 9.0, or (b) call master as 10x and release from there (going from 8.8 to 10.0 directly, skipping 9x altogether).
>
>
>
> Tldr, we shall have complete flexibility to go in any direction we want to.
>
>
>
> WDYT?
>
>
>
> On Sun, 4 Oct, 2020, 2:31 am Uwe Schindler, <[hidden email]> 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 <[hidden email]>:
>
> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Solr Alpha (EA) release of Reference Branch

Shawn Heisey-2
In reply to this post by Ishan Chattopadhyaya
On 10/3/2020 1:42 PM, Ishan Chattopadhyaya wrote:

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

How to handle this seems to come down to the answers to a couple of
questions:

* Is this new code stable enough to work in the wild?
* Do we want to release 9.0 before we merge to master, or after?

Can someone who was involved when 4.0-ALPHA and 4.0-BETA were released
tell me whether those releases actually did what was intended and made
4.0.0 better than it would have been without the special releases?  If
they did, then a special release for this new implementation before
merging to master would probably also be helpful.  If there was no real
benefit gained, then maybe we're better off just going ahead with the merge.

If the general feeling is that this new release is looking very solid,
then I think we should merge to master soon, probably just before
branch_9x is created.  If we think it needs more work, then maybe we
should hold on merging until *after* branch_9x is created, so the new
implementation will release with 10.0 and there will be more time to
make it bulletproof.

My current impression, which I will admit is made with almost zero
actual information about the code or its stability, is that we should
plan on stabilizing the new implementation for the 9.0 release.  There's
going to be some pain no matter how we handle this, so diving in now
seems like a good idea.

A tangent:  How robust is our testing?  I know they take a long time to
run, which Mark's new implementation aims to improve, but do we think
there's enough being tested?  There has been some discussion in the past
about benchmarks for Solr.  Benchmarks would be very useful, but I'm
more interested in making sure that our tests will catch problems before
they get out into the wild.  The two goals don't have to be mutually
exclusive, though.

Thanks,
Shawn

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Solr Alpha (EA) release of Reference Branch

Erick Erickson
In reply to this post by Uwe Schindler
Uwe:

I think it’s reference_impl_dev...

> On Oct 4, 2020, at 6:00 PM, Uwe Schindler <[hidden email]> wrote:
>
> Hi,
> I enabled the „gradlew check” runs on ASF Jenkins and Policeman Jenkins (Linux, Windows, MacOS).
>  
> I used branch (“reference_impl”). Is this correct, because it’s about a month old?
> There’s also a much newer “reference_impl_dev” branch. Which one is correct?
>  
> I will go sleeping now, sorry for failure mails during the night. Builds seem to fail, but it’s too late to do anything against it.
>  
> Uwe
>  
> -----
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> https://www.thetaphi.de
> eMail: [hidden email]
>  
> From: Ishan Chattopadhyaya <[hidden email]>
> Sent: Sunday, October 4, 2020 6:32 AM
> To: Uwe Schindler <[hidden email]>
> Cc: Lucene Dev <[hidden email]>
> Subject: Re: Solr Alpha (EA) release of Reference Branch
>  
> Yes Uwe, it is ready for Jenkins testing. The Solr tests should run very fast now.
>  
> As for naming, our package manager in Solr will break if we don't specify a major and a minor version. There's a concept of version constraints for packages that need to compare against Solr version. I think release process will also be much simpler if we have a major and minor version. We have done a similar release in the past, 4.0.0-beta iirc.
>  
> Why I favour 10.0-alpha or something like that is because users would clearly know it is something that isn't coming right now (and hence very early access), and it is logically a major version change (that comes after 8x). With calling it 10x instead of 9x, we have the scope of abandoning the effort as a whole if the early access releases have some serious problem or we decide to take some other release strategy later.
>  
> If the 10.0-alpha succeeds, we can always fold the changes back into a 9.1 or go from 9.0 straight to 10.0, depending on what we decide later. Alternatively, if the release looks good and 9.0 hasn't released yet, we can fold those changes back to master, and either (a) release everything normally as 9.0, or (b) call master as 10x and release from there (going from 8.8 to 10.0 directly, skipping 9x altogether).
>  
> Tldr, we shall have complete flexibility to go in any direction we want to.
>  
> WDYT?
>  
> On Sun, 4 Oct, 2020, 2:31 am Uwe Schindler, <[hidden email]> 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 <[hidden email]>:
>>> 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


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Solr Alpha (EA) release of Reference Branch

Ishan Chattopadhyaya
IIUC, reference_impl is the branch where the changes are stable. *_dev is the branch where active development is going on. Once changes are baked in there, they are promoted to reference_impl. We want to release from reference_impl.

On Mon, 5 Oct, 2020, 6:16 pm Erick Erickson, <[hidden email]> wrote:
Uwe:

I think it’s reference_impl_dev...

> On Oct 4, 2020, at 6:00 PM, Uwe Schindler <[hidden email]> wrote:
>
> Hi,
> I enabled the „gradlew check” runs on ASF Jenkins and Policeman Jenkins (Linux, Windows, MacOS).

> I used branch (“reference_impl”). Is this correct, because it’s about a month old?
> There’s also a much newer “reference_impl_dev” branch. Which one is correct?

> I will go sleeping now, sorry for failure mails during the night. Builds seem to fail, but it’s too late to do anything against it.

> Uwe

> -----
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> https://www.thetaphi.de
> eMail: [hidden email]

> From: Ishan Chattopadhyaya <[hidden email]>
> Sent: Sunday, October 4, 2020 6:32 AM
> To: Uwe Schindler <[hidden email]>
> Cc: Lucene Dev <[hidden email]>
> Subject: Re: Solr Alpha (EA) release of Reference Branch

> Yes Uwe, it is ready for Jenkins testing. The Solr tests should run very fast now.

> As for naming, our package manager in Solr will break if we don't specify a major and a minor version. There's a concept of version constraints for packages that need to compare against Solr version. I think release process will also be much simpler if we have a major and minor version. We have done a similar release in the past, 4.0.0-beta iirc.

> Why I favour 10.0-alpha or something like that is because users would clearly know it is something that isn't coming right now (and hence very early access), and it is logically a major version change (that comes after 8x). With calling it 10x instead of 9x, we have the scope of abandoning the effort as a whole if the early access releases have some serious problem or we decide to take some other release strategy later.

> If the 10.0-alpha succeeds, we can always fold the changes back into a 9.1 or go from 9.0 straight to 10.0, depending on what we decide later. Alternatively, if the release looks good and 9.0 hasn't released yet, we can fold those changes back to master, and either (a) release everything normally as 9.0, or (b) call master as 10x and release from there (going from 8.8 to 10.0 directly, skipping 9x altogether).

> Tldr, we shall have complete flexibility to go in any direction we want to.

> WDYT?

> On Sun, 4 Oct, 2020, 2:31 am Uwe Schindler, <[hidden email]> 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 <[hidden email]>:
>>> 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


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Solr Alpha (EA) release of Reference Branch

Ishan Chattopadhyaya
To conclude this thread, seems that there's general consensus for a release around early December timeframe. If there are any outstanding concerns against the release itself, please chime in.

The naming is something we can discuss separately, as we go along. State of the branch can be re-evaluated at the time of the release to see if we need to delay it, it still makes sense to go with the release, or any major shifts in direction is needed.

Thanks everyone for your suggestions, thoughts and concerns.

On Mon, 5 Oct, 2020, 6:43 pm Ishan Chattopadhyaya, <[hidden email]> wrote:
IIUC, reference_impl is the branch where the changes are stable. *_dev is the branch where active development is going on. Once changes are baked in there, they are promoted to reference_impl. We want to release from reference_impl.

On Mon, 5 Oct, 2020, 6:16 pm Erick Erickson, <[hidden email]> wrote:
Uwe:

I think it’s reference_impl_dev...

> On Oct 4, 2020, at 6:00 PM, Uwe Schindler <[hidden email]> wrote:
>
> Hi,
> I enabled the „gradlew check” runs on ASF Jenkins and Policeman Jenkins (Linux, Windows, MacOS).

> I used branch (“reference_impl”). Is this correct, because it’s about a month old?
> There’s also a much newer “reference_impl_dev” branch. Which one is correct?

> I will go sleeping now, sorry for failure mails during the night. Builds seem to fail, but it’s too late to do anything against it.

> Uwe

> -----
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> https://www.thetaphi.de
> eMail: [hidden email]

> From: Ishan Chattopadhyaya <[hidden email]>
> Sent: Sunday, October 4, 2020 6:32 AM
> To: Uwe Schindler <[hidden email]>
> Cc: Lucene Dev <[hidden email]>
> Subject: Re: Solr Alpha (EA) release of Reference Branch

> Yes Uwe, it is ready for Jenkins testing. The Solr tests should run very fast now.

> As for naming, our package manager in Solr will break if we don't specify a major and a minor version. There's a concept of version constraints for packages that need to compare against Solr version. I think release process will also be much simpler if we have a major and minor version. We have done a similar release in the past, 4.0.0-beta iirc.

> Why I favour 10.0-alpha or something like that is because users would clearly know it is something that isn't coming right now (and hence very early access), and it is logically a major version change (that comes after 8x). With calling it 10x instead of 9x, we have the scope of abandoning the effort as a whole if the early access releases have some serious problem or we decide to take some other release strategy later.

> If the 10.0-alpha succeeds, we can always fold the changes back into a 9.1 or go from 9.0 straight to 10.0, depending on what we decide later. Alternatively, if the release looks good and 9.0 hasn't released yet, we can fold those changes back to master, and either (a) release everything normally as 9.0, or (b) call master as 10x and release from there (going from 8.8 to 10.0 directly, skipping 9x altogether).

> Tldr, we shall have complete flexibility to go in any direction we want to.

> WDYT?

> On Sun, 4 Oct, 2020, 2:31 am Uwe Schindler, <[hidden email]> 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 <[hidden email]>:
>>> 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


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Solr Alpha (EA) release of Reference Branch

David Smiley
In reply to this post by Ishan Chattopadhyaya
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
12