You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-dev@jackrabbit.apache.org by Davide Giannella <da...@apache.org> on 2016/12/01 11:15:43 UTC
Oak 1.5.15 release plan
Hello team,
I'm planning to cut Oak 1.5.15 on Monday 5th December.
If there are any objections please let me know. Otherwise I will
re-schedule any non-resolved issue for the next iteration.
Angela, Manfred, is https://issues.apache.org/jira/browse/OAK-5200
really a blocker for 1.5.15? Or is it rather for 1.6? If it's for 1.5.15
how long for the fix to get done?
Thanks
Davide
Re: Oak 1.5.15 release plan
Posted by Chetan Mehrotra <ch...@gmail.com>.
Hi Davide,
All blocking issue from my side are resolved now
Chetan Mehrotra
On Mon, Dec 5, 2016 at 12:39 PM, Chetan Mehrotra
<ch...@gmail.com> wrote:
> Hi Davide,
>
> I have marked OAK-5219 as blocker as I want it to be included in
> 1.5.15. It might take max 1 day to resolve this issue. Would let you
> know once I have any further update
> Chetan Mehrotra
>
>
> On Thu, Dec 1, 2016 at 4:45 PM, Davide Giannella <da...@apache.org> wrote:
>> Hello team,
>>
>> I'm planning to cut Oak 1.5.15 on Monday 5th December.
>>
>> If there are any objections please let me know. Otherwise I will
>> re-schedule any non-resolved issue for the next iteration.
>>
>> Angela, Manfred, is https://issues.apache.org/jira/browse/OAK-5200
>> really a blocker for 1.5.15? Or is it rather for 1.6? If it's for 1.5.15
>> how long for the fix to get done?
>>
>> Thanks
>> Davide
>>
>>
Re: Oak 1.5.15 release plan
Posted by Chetan Mehrotra <ch...@gmail.com>.
Hi Davide,
I have marked OAK-5219 as blocker as I want it to be included in
1.5.15. It might take max 1 day to resolve this issue. Would let you
know once I have any further update
Chetan Mehrotra
On Thu, Dec 1, 2016 at 4:45 PM, Davide Giannella <da...@apache.org> wrote:
> Hello team,
>
> I'm planning to cut Oak 1.5.15 on Monday 5th December.
>
> If there are any objections please let me know. Otherwise I will
> re-schedule any non-resolved issue for the next iteration.
>
> Angela, Manfred, is https://issues.apache.org/jira/browse/OAK-5200
> really a blocker for 1.5.15? Or is it rather for 1.6? If it's for 1.5.15
> how long for the fix to get done?
>
> Thanks
> Davide
>
>
Re: Oak 1.5.15 release plan
Posted by Julian Reschke <ju...@gmx.de>.
On 2016-12-01 12:15, Davide Giannella wrote:
> Hello team,
>
> I'm planning to cut Oak 1.5.15 on Monday 5th December.
>
> If there are any objections please let me know. Otherwise I will
> re-schedule any non-resolved issue for the next iteration.
>
> Angela, Manfred, is https://issues.apache.org/jira/browse/OAK-5200
> really a blocker for 1.5.15? Or is it rather for 1.6? If it's for 1.5.15
> how long for the fix to get done?
We'd like to get the switch to Jackrabbit 2.13.5 into this release - it
is scheduled for end of today (see
https://issues.apache.org/jira/browse/JCR-4070 and
https://issues.apache.org/jira/browse/OAK-5202).
Best regards, Julian
Re: Oak 1.5.15 release plan
Posted by Angela Schreiber <an...@adobe.com>.
Hi Manfred
I don't see how you can 'keep it' for the LDAP case. Please create
new Improvement ticket, such that we can look for a proper solution.
What you actually wanted to do but which IMO got never explicitly
mentioned due to mixing implementation details with the generic
sync-stuff:
"Ability to resolve principal name from ExternalIdentityRef without IDP
roundtrip"
IMO such an improvement would make sense for all cases not just for the
LDAP
integration. But I want to have that done properly and without hacks
and relying on implementation details of one particular impl for the
generic
code base.
Based on the experience we made here, I think it would make sense, to
get more reviews and feedback on changes for the mentioned modules.
Specially when API extensions are involved that are really cumbersome
to fix later on. In general I think this is a very good practise and
it may help spotting issues early in the cycle.
Kind regards
Angela
On 01/12/16 13:46, "Manfred Baedke" <ma...@gmail.com> wrote:
>Hi Davide, Angela,
>
>Note that this is not an issue with oak-auth-ldap, but rather with
>oak-auth-external.
>
>The ExternalIdentity implementation used by oak-auth-ldap uses the DN as
>both the id and the principal name, so it's working fine. Other
>implementations of the external auth mechanism may run into problems
>(btw: are other implementations known?).
>
>I'm going to revert the change now, but since the performance
>improvement was striking on customer site, I'd like to keep it for the
>LDAP case. Anyone feel free to give suggestions on the most elegant way
>to do this.
>
>Best regards,
>Manfred
>
>On 12/1/2016 12:52 PM, Angela Schreiber wrote:
>> Hi Davide
>>
>> IMO the fix for OAK-5200 is straight forward:
>>
>> 1. revert changes made to DynamicSyncContext: it's here where the bug
>>was
>> introduced.
>> that should be doable today.
>>
>> 2. have a quick discussion on oak-dev on how to deal with the new,
>> exported class ExternalGroupRef
>> which was introduced (and was already backported): this one would
>>not
>> be used any
>> more after 1) but removing it again would (afaik) lead to a major
>> version bump.
>> i want to get more opinions on that, because i am not aware that we
>>had
>> the problem
>> before (or missed/don't remember how we dealt with it).
>> if we see that it's not doable or too cumbersome reverting this
>>class,
>> we may decide
>> to leave it... we might find it useful later on or end up
>>deprecating
>> it for 1.8.
>> but i want to have a conscious decision here and some broader
>>agreement
>> from the team.
>>
>> - if we leave it -> changes in auth-ldap code base don't need to be
>> reverted
>> - if we revert it -> changes in auth-ldap also would need to be
>>reverted
>>
>> Hope that helps
>> Angela
>>
>> PS: as far as the original improvement is concerned that was the
>>intention
>> of OAK-4930
>> (but which is not obvious from the subject, which is not correct), we
>>need
>> to have a new
>> Improvement ticket, where we can discuss the options... I want that kind
>> of improvements
>> to be properly tracked in jira (and ultimately in the documentation and
>> benchmarked) such
>> that everyone can understand why a given change was made... i had a hard
>> time yesterday to
>> understand what was the actual aim of OAK-4930 and it was just by
>> coincidence that I hours
>> later spotted the issue... just because I could not understand how I
>>could
>> have mixed up
>> ID and principal name in the original code (and which turned out wasn't
>> the case).
>>
>>
>> On 01/12/16 12:15, "Davide Giannella" <da...@apache.org> wrote:
>>
>>> Hello team,
>>>
>>> I'm planning to cut Oak 1.5.15 on Monday 5th December.
>>>
>>> If there are any objections please let me know. Otherwise I will
>>> re-schedule any non-resolved issue for the next iteration.
>>>
>>> Angela, Manfred, is https://issues.apache.org/jira/browse/OAK-5200
>>> really a blocker for 1.5.15? Or is it rather for 1.6? If it's for
>>>1.5.15
>>> how long for the fix to get done?
>>>
>>> Thanks
>>> Davide
>>>
>>>
>
Re: Oak 1.5.15 release plan
Posted by Manfred Baedke <ma...@gmail.com>.
Hi Davide, Angela,
Note that this is not an issue with oak-auth-ldap, but rather with
oak-auth-external.
The ExternalIdentity implementation used by oak-auth-ldap uses the DN as
both the id and the principal name, so it's working fine. Other
implementations of the external auth mechanism may run into problems
(btw: are other implementations known?).
I'm going to revert the change now, but since the performance
improvement was striking on customer site, I'd like to keep it for the
LDAP case. Anyone feel free to give suggestions on the most elegant way
to do this.
Best regards,
Manfred
On 12/1/2016 12:52 PM, Angela Schreiber wrote:
> Hi Davide
>
> IMO the fix for OAK-5200 is straight forward:
>
> 1. revert changes made to DynamicSyncContext: it's here where the bug was
> introduced.
> that should be doable today.
>
> 2. have a quick discussion on oak-dev on how to deal with the new,
> exported class ExternalGroupRef
> which was introduced (and was already backported): this one would not
> be used any
> more after 1) but removing it again would (afaik) lead to a major
> version bump.
> i want to get more opinions on that, because i am not aware that we had
> the problem
> before (or missed/don't remember how we dealt with it).
> if we see that it's not doable or too cumbersome reverting this class,
> we may decide
> to leave it... we might find it useful later on or end up deprecating
> it for 1.8.
> but i want to have a conscious decision here and some broader agreement
> from the team.
>
> - if we leave it -> changes in auth-ldap code base don't need to be
> reverted
> - if we revert it -> changes in auth-ldap also would need to be reverted
>
> Hope that helps
> Angela
>
> PS: as far as the original improvement is concerned that was the intention
> of OAK-4930
> (but which is not obvious from the subject, which is not correct), we need
> to have a new
> Improvement ticket, where we can discuss the options... I want that kind
> of improvements
> to be properly tracked in jira (and ultimately in the documentation and
> benchmarked) such
> that everyone can understand why a given change was made... i had a hard
> time yesterday to
> understand what was the actual aim of OAK-4930 and it was just by
> coincidence that I hours
> later spotted the issue... just because I could not understand how I could
> have mixed up
> ID and principal name in the original code (and which turned out wasn't
> the case).
>
>
> On 01/12/16 12:15, "Davide Giannella" <da...@apache.org> wrote:
>
>> Hello team,
>>
>> I'm planning to cut Oak 1.5.15 on Monday 5th December.
>>
>> If there are any objections please let me know. Otherwise I will
>> re-schedule any non-resolved issue for the next iteration.
>>
>> Angela, Manfred, is https://issues.apache.org/jira/browse/OAK-5200
>> really a blocker for 1.5.15? Or is it rather for 1.6? If it's for 1.5.15
>> how long for the fix to get done?
>>
>> Thanks
>> Davide
>>
>>
Re: Oak 1.5.15 release plan
Posted by Angela Schreiber <an...@adobe.com>.
Hi Davide
IMO the fix for OAK-5200 is straight forward:
1. revert changes made to DynamicSyncContext: it's here where the bug was
introduced.
that should be doable today.
2. have a quick discussion on oak-dev on how to deal with the new,
exported class ExternalGroupRef
which was introduced (and was already backported): this one would not
be used any
more after 1) but removing it again would (afaik) lead to a major
version bump.
i want to get more opinions on that, because i am not aware that we had
the problem
before (or missed/don't remember how we dealt with it).
if we see that it's not doable or too cumbersome reverting this class,
we may decide
to leave it... we might find it useful later on or end up deprecating
it for 1.8.
but i want to have a conscious decision here and some broader agreement
from the team.
- if we leave it -> changes in auth-ldap code base don't need to be
reverted
- if we revert it -> changes in auth-ldap also would need to be reverted
Hope that helps
Angela
PS: as far as the original improvement is concerned that was the intention
of OAK-4930
(but which is not obvious from the subject, which is not correct), we need
to have a new
Improvement ticket, where we can discuss the options... I want that kind
of improvements
to be properly tracked in jira (and ultimately in the documentation and
benchmarked) such
that everyone can understand why a given change was made... i had a hard
time yesterday to
understand what was the actual aim of OAK-4930 and it was just by
coincidence that I hours
later spotted the issue... just because I could not understand how I could
have mixed up
ID and principal name in the original code (and which turned out wasn't
the case).
On 01/12/16 12:15, "Davide Giannella" <da...@apache.org> wrote:
>Hello team,
>
>I'm planning to cut Oak 1.5.15 on Monday 5th December.
>
>If there are any objections please let me know. Otherwise I will
>re-schedule any non-resolved issue for the next iteration.
>
>Angela, Manfred, is https://issues.apache.org/jira/browse/OAK-5200
>really a blocker for 1.5.15? Or is it rather for 1.6? If it's for 1.5.15
>how long for the fix to get done?
>
>Thanks
>Davide
>
>