Re: Intent to backport OAK-6656 to 1.6 and 1.4 branch

2017-09-13 Thread Vikas Saurabh 
Ack. Would continue with the backport then :).

On Wed, Sep 13, 2017 at 2:22 PM, Chetan Mehrotra
 wrote:
> Its was +0 ;)
> Chetan Mehrotra
>
>
> On Wed, Sep 13, 2017 at 2:15 PM, Vikas Saurabh  
> wrote:
>> Hi Chetan,
>>
>> Was your concern a -1 or a +/- 0?
>>
>> Thanks,
>> Vikas

Re: Intent to backport OAK-6656 to 1.6 and 1.4 branch

2017-09-13 Thread Chetan Mehrotra 
Its was +0 ;)
Chetan Mehrotra


On Wed, Sep 13, 2017 at 2:15 PM, Vikas Saurabh  wrote:
> Hi Chetan,
>
> Was your concern a -1 or a +/- 0?
>
> Thanks,
> Vikas

Re: Intent to backport OAK-6656 to 1.6 and 1.4 branch

2017-09-13 Thread Vikas Saurabh 
Hi Chetan,

Was your concern a -1 or a +/- 0?

Thanks,
Vikas

Re: Intent to backport OAK-6656 to 1.6 and 1.4 branch

2017-09-13 Thread Davide Giannella 
On 13/09/2017 09:22, Vikas Saurabh wrote:
> Hi,
>
> On Wed, Sep 13, 2017 at 9:32 AM, Chetan Mehrotra
>  wrote:
>
>> Would the backport be of use now? As any upgrade I think would happen
>> first to initial release from that branch where this fix would not be
>> present
> Well, from arguments pov, I think one can always package upgraded
> setup with latest oak (yes, I understand that's not the case for AEM).
> But, my hidden agenda is that "this is a bad bug + the fix is simple
> => we should fix it".
> But, sure, if it doesn't feel right, then I agree it's a not a major
> bug from backport pov.

+1 for backporting. It's trivial, well test covered and it's definitely
better to have this as we don't know exactly what an Oak deployment
could be.

D.

Re: Intent to backport OAK-6656 to 1.6 and 1.4 branch

2017-09-13 Thread Vikas Saurabh 
Hi,

On Wed, Sep 13, 2017 at 9:32 AM, Chetan Mehrotra
 wrote:

> Would the backport be of use now? As any upgrade I think would happen
> first to initial release from that branch where this fix would not be
> present

Well, from arguments pov, I think one can always package upgraded
setup with latest oak (yes, I understand that's not the case for AEM).
But, my hidden agenda is that "this is a bad bug + the fix is simple
=> we should fix it".
But, sure, if it doesn't feel right, then I agree it's a not a major
bug from backport pov.

Thanks,
Vikas

Re: Intent to backport OAK-6656 to 1.6 and 1.4 branch

2017-09-12 Thread Chetan Mehrotra 
> The fix is fairly simple and I'd like to backport it to 1.4 and 1.6
> branch (where OAK-3768 went).

Would the backport be of use now? As any upgrade I think would happen
first to initial release from that branch where this fix would not be
present
Chetan Mehrotra


On Wed, Sep 13, 2017 at 12:33 AM, Vikas Saurabh  wrote:
> Hi,
>
> Recently we discovered OAK-6656 which shows that if there's an
> "ordered" property index on a setup then post 1.4 and with
> failOnMissingProvider the commits would fail.
>
> While this shows up easily for non-async ordered index. The effect
> with async ordered property index is that async indexing would keep on
> failing in the background.
>
> The fix is fairly simple and I'd like to backport it to 1.4 and 1.6
> branch (where OAK-3768 went).
>
> Thanks,
> Vikas

Intent to backport OAK-6656 to 1.6 and 1.4 branch

2017-09-12 Thread Vikas Saurabh 
Hi,

Recently we discovered OAK-6656 which shows that if there's an
"ordered" property index on a setup then post 1.4 and with
failOnMissingProvider the commits would fail.

While this shows up easily for non-async ordered index. The effect
with async ordered property index is that async indexing would keep on
failing in the background.

The fix is fairly simple and I'd like to backport it to 1.4 and 1.6
branch (where OAK-3768 went).

Thanks,
Vikas