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 <[email protected]> wrote: > 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 > problem disappear? > > But maybe the issue is more than config? > > Ilan > > On Wed, Jul 22, 2020 at 5:46 PM Houston Putman <[email protected]> > 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, 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. >> >> - Houston >> >> On Wed, Jul 22, 2020 at 1:53 AM Ishan Chattopadhyaya < >> [email protected]> 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 volunteer >>> for this release owning to some other commitments, however Andrzej >>> mentioned in Slack that he might be able to volunteer for this post 27th. >>> >>> Are there any thoughts/concerns regarding this? >>> Regards, >>> Ishan >>> >> -- Regards, Atri Apache Concerted
