Absolutely, Ilan! Good idea. I initially hesitated in doing so because
Andrzej had a workaround in mind for them, so I thought it would be better
if he did this. But, it makes sense to inform them of the issue right away
anyway.
On Wed, 22 Jul, 2020, 11:42 pm Ilan Ginzburg, wrote:
> Shouldn't
Shouldn't we add a note right away to 8.6 notifying of the issue?
Le mer. 22 juil. 2020 à 20:08, Atri Sharma a écrit :
> +1, thanks Houston.
>
> On Wed, Jul 22, 2020 at 10:51 PM Houston Putman
> wrote:
> >
> > If we agree that this warrants a patch release, I volunteer to do the
> release.
> >
+1, thanks Houston.
On Wed, Jul 22, 2020 at 10:51 PM Houston Putman wrote:
>
> If we agree that this warrants a patch release, I volunteer to do the release.
>
> I do think a patch release is reasonable even if users have to take an action
> when upgrading from 8.6.0. I imagine most users
+1 for the release. Having a hotfix release that fixes regression is a
great option for users who plan to be on 8.6.x.
Thanks Houston and Ishan!
On Wed, Jul 22, 2020 at 10:15 AM Houston Putman
wrote:
> If we agree that this warrants a patch release, I volunteer to do the
> release.
>
> I do
Thanks Houston!
On Wed, 22 Jul, 2020, 10:51 pm Houston Putman,
wrote:
> If we agree that this warrants a patch release, I volunteer to do the
> release.
>
> I do think a patch release is reasonable even if users have to take an
> action when upgrading from 8.6.0. I imagine most users haven't
If we agree that this warrants a patch release, I volunteer to do the
release.
I do think a patch release is reasonable even if users have to take an
action when upgrading from 8.6.0. I imagine most users haven't upgraded to
8.6.0 yet, so if we make the patch now we will make life easier for
Ignore this, I misread your email.
On Wed, Jul 22, 2020 at 9:11 PM Atri Sharma wrote:
>
> Should we not revert the change so that users upgrading from 8.6 to
> 8.6.1 get the earlier default policy?
>
> On Wed, Jul 22, 2020 at 9:09 PM Houston Putman
> wrote:
> >
> > +1
> >
> > Question about
Communicating a workaround may or may not reach everybody affected — unless
we plan to publish it on every channel.
Whereas a release is much more visible and an obvious way to mitigate the
issue.
On Wed, 22 Jul 2020 at 21:40, Ilan Ginzburg wrote:
> I didn't look at the issue, but if it is due
I didn't look at the issue, but if it is due to a default inefficient
policy, instead of a new release (that as Houston points out will not even
solve the issue), can't we communicate a workaround, namely a way to reset
the default policy to some other value after 8.6 deploy that would make the
Should we not revert the change so that users upgrading from 8.6 to
8.6.1 get the earlier default policy?
On Wed, Jul 22, 2020 at 9:09 PM Houston Putman wrote:
>
> +1
>
> Question about the change. Since this patch added a default autoscaling
> policy, if users upgrade to 8.6 and then 8.6.1,
+1
On Wed, Jul 22, 2020 at 11:23 AM Ishan Chattopadhyaya
wrote:
>
> Hi,
> There was a performance regression identified in 8.6.0 release due to
> SOLR-12845. I think it is serious enough to warrant an immediate bug fix
> release.
>
> I propose a 8.6.1 release. Unfortunately, I'll be unable to
+1
Question about the change. Since this patch added a default autoscaling
policy, if users upgrade to 8.6 and then 8.6.1, does the default
autoscaling policy stay once they have upgraded? If so we probably want to
include instructions in the release notes on how to fix this issue once
upgrading.
I think the first step would be comprehensive unit tests for joins in
Parallel SQL, coupled with performance tests so we understand how
distributed performs at scale through the calcites framework. Then we know
if we can actually say joins are really supported. Then we can add the
documentation.
13 matches
Mail list logo
