Security Redesign and Release 10.x Branch

[Adrian Crum-2]

I would like to start bringing parts of the executioncontext20091231 branch into the trunk before we create the next release branch. The implementation of the new security design is not finished, but it will be disabled - so everything will still work the same.

My goal is to allow users of the 10.x release to plan for the forthcoming changes, and maybe have the conversion to the new design completed by the release that follows 10.x.

I will wait a few days, and if there are no objections I will begin merging the design into the trunk.

-Adrian



     

[Anil Patel-3]

I was thinking, Why not other way round.

As I understand, we will not be able to use execution content features in other parts of Ofbiz in time for 10.4 release. If this is the case then additional code in release branch may add some new issues but will not add any benefits. Right?

So IMO we should wait till 10.04 release branch is created and merge executioncontext20091231 with trunk after 10.04 release branch is created.
 
Thanks and Regards
Anil Patel
HotWax Media Inc
Find us on the web at www.hotwaxmedia.com or Google Keyword "ofbiz"

On Apr 4, 2010, at 2:21 PM, Adrian Crum wrote:

> I would like to start bringing parts of the executioncontext20091231 branch into the trunk before we create the next release branch. The implementation of the new security design is not finished, but it will be disabled - so everything will still work the same.
>
> My goal is to allow users of the 10.x release to plan for the forthcoming changes, and maybe have the conversion to the new design completed by the release that follows 10.x.
>
> I will wait a few days, and if there are no objections I will begin merging the design into the trunk.
>
> -Adrian
>
>
>
>

[Adrian Crum]

Anil Patel wrote:
> I was thinking, Why not other way round.
>
> As I understand, we will not be able to use execution content features in other parts of Ofbiz in time for 10.4 release. If this is the case then additional code in release branch may add some new issues but will not add any benefits. Right?

Have you even looked at the design document or the code?

> So IMO we should wait till 10.04 release branch is created and merge executioncontext20091231 with trunk after 10.04 release branch is created.

Okay, let's wait and then we will add the new issues to the 11.x
release. Oops, we better not do that - let's hold off until 12.x...

Do you see where this is going? We already have Webslinger in the
project - a feature that isn't finished and isn't used. Has that caused
problems in 9.04?

-Adrian

[Scott Gray-2]

On 6/04/2010, at 3:03 PM, Adrian Crum wrote:

> Anil Patel wrote:
>> I was thinking, Why not other way round. As I understand, we will not be able to use execution content features in other parts of Ofbiz in time for 10.4 release. If this is the case then additional code in release branch may add some new issues but will not add any benefits. Right?
>
> Have you even looked at the design document or the code?

I haven't, as long as there were two branches I've been staying well clear of them.

>
>> So IMO we should wait till 10.04 release branch is created and merge executioncontext20091231 with trunk after 10.04 release branch is created.
>
> Okay, let's wait and then we will add the new issues to the 11.x release. Oops, we better not do that - let's hold off until 12.x...
>
> Do you see where this is going? We already have Webslinger in the project - a feature that isn't finished and isn't used. Has that caused problems in 9.04?

I agree with Anil's sentiment, I just never got around to writing the email.

What I am for at this point:
- Anything that makes the user's life easier

What I am against:
- Any major changes to existing functionality that may just result in a whole lot of problems for early adopters and a whole lot of backporting

I'm still not entirely clear on what you're trying to achieve by pushing non-functional code into the trunk prior to branching.

p.s. I don't think webslinger should be in the project

[Anil Patel-3]

I am really not against merging executioncontext branch with trunk. I don't see reason to include it in upcoming release branch if we will not be using it.  And yes, even though Webslinger is not a good examples we can still say that, decision put it in trunk was made too early, but its just me.

Merging of executioncontext will make more sense to me if our release policy allowed back porting of some features from trunk to release brach (Internally I will be doing it anyways). If such thing was allowed then I can include framework changes now and at later date back port related enhancements to the branch.

I have not seen Execution context thing but still I can say its more native to Ofbiz framework and qualifies to be in trunk more then webslinger (I have nothing against it).  

Thanks and Regards
Anil Patel
HotWax Media Inc
Find us on the web at www.hotwaxmedia.com or Google Keyword "ofbiz"

On Apr 6, 2010, at 5:03 PM, Adrian Crum wrote:

> Anil Patel wrote:
>> I was thinking, Why not other way round. As I understand, we will not be able to use execution content features in other parts of Ofbiz in time for 10.4 release. If this is the case then additional code in release branch may add some new issues but will not add any benefits. Right?
>
> Have you even looked at the design document or the code?
>
>> So IMO we should wait till 10.04 release branch is created and merge executioncontext20091231 with trunk after 10.04 release branch is created.
>
> Okay, let's wait and then we will add the new issues to the 11.x release. Oops, we better not do that - let's hold off until 12.x...
>
> Do you see where this is going? We already have Webslinger in the project - a feature that isn't finished and isn't used. Has that caused problems in 9.04?
>
> -Adrian
>

[Tim Ruppert]

Inline

Cheers,
Ruppert

On Apr 6, 2010, at 3:47 PM, Anil Patel wrote:

> I am really not against merging executioncontext branch with trunk. I don't see reason to include it in upcoming release branch if we will not be using it.  

+1 - I was writing an email explaining the same thing.

> And yes, even though Webslinger is not a good examples we can still say that, decision put it in trunk was made too early, but its just me.

I would have to agree - I wish we had even more simple static pages showing how it works so well in the CMS, etc - otherwise, I see no reason to have it in there until it's used.  To be clear, I'd still rather have it in there with examples of how to use it :) the demos I've seen have always been impressive.

> Merging of executioncontext will make more sense to me if our release policy allowed back porting of some features from trunk to release brach (Internally I will be doing it anyways). If such thing was allowed then I can include framework changes now and at later date back port related enhancements to the branch.

I thought we were moving further away from that.  But I can say that if it is complete and ready to be used - then it's something that would make sense to have in there - even if we're not putting it in place of our existing security for stability reasons - so that when you base your next release of your software, you have it to work with as an alternative.

> I have not seen Execution context thing but still I can say its more native to Ofbiz framework and qualifies to be in trunk more then webslinger (I have nothing against it).  
>
> Thanks and Regards
> Anil Patel
> HotWax Media Inc
> Find us on the web at www.hotwaxmedia.com or Google Keyword "ofbiz"
>
> On Apr 6, 2010, at 5:03 PM, Adrian Crum wrote:
>
>> Anil Patel wrote:
>>> I was thinking, Why not other way round. As I understand, we will not be able to use execution content features in other parts of Ofbiz in time for 10.4 release. If this is the case then additional code in release branch may add some new issues but will not add any benefits. Right?
>>
>> Have you even looked at the design document or the code?
>>
>>> So IMO we should wait till 10.04 release branch is created and merge executioncontext20091231 with trunk after 10.04 release branch is created.
>>
>> Okay, let's wait and then we will add the new issues to the 11.x release. Oops, we better not do that - let's hold off until 12.x...
>>
>> Do you see where this is going? We already have Webslinger in the project - a feature that isn't finished and isn't used. Has that caused problems in 9.04?
>>
>> -Adrian
>>
>

[Adrian Crum]

Scott Gray wrote:

> On 6/04/2010, at 3:03 PM, Adrian Crum wrote:
>
>> Anil Patel wrote:
>>> I was thinking, Why not other way round. As I understand, we will not be able to use execution content features in other parts of Ofbiz in time for 10.4 release. If this is the case then additional code in release branch may add some new issues but will not add any benefits. Right?
>> Have you even looked at the design document or the code?
>
> I haven't, as long as there were two branches I've been staying well clear of them.
>
>>> So IMO we should wait till 10.04 release branch is created and merge executioncontext20091231 with trunk after 10.04 release branch is created.
>> Okay, let's wait and then we will add the new issues to the 11.x release. Oops, we better not do that - let's hold off until 12.x...
>>
>> Do you see where this is going? We already have Webslinger in the project - a feature that isn't finished and isn't used. Has that caused problems in 9.04?
>
> I agree with Anil's sentiment, I just never got around to writing the email.
>
> What I am for at this point:
> - Anything that makes the user's life easier
>
> What I am against:
> - Any major changes to existing functionality that may just result in a whole lot of problems for early adopters and a whole lot of backporting
>
> I'm still not entirely clear on what you're trying to achieve by pushing non-functional code into the trunk prior to branching.

The security redesign works, it's just disabled. It's disabled because
there are security holes in the existing code, and the new security
design plugs those holes - making parts of the project unreachable.

Why not do it now? What set of circumstances would make it acceptable to
merge?

The design has been discussed for nearly a year, the design document has
been up for almost as long, and the branch has been around since last
August. There has been plenty of time for code review and discussion.

-Adrian

[Scott Gray-2]

On 6/04/2010, at 4:03 PM, Adrian Crum wrote:

> Scott Gray wrote:
>> On 6/04/2010, at 3:03 PM, Adrian Crum wrote:
>>> Anil Patel wrote:
>>>> I was thinking, Why not other way round. As I understand, we will not be able to use execution content features in other parts of Ofbiz in time for 10.4 release. If this is the case then additional code in release branch may add some new issues but will not add any benefits. Right?
>>> Have you even looked at the design document or the code?
>> I haven't, as long as there were two branches I've been staying well clear of them.
>>>> So IMO we should wait till 10.04 release branch is created and merge executioncontext20091231 with trunk after 10.04 release branch is created.
>>> Okay, let's wait and then we will add the new issues to the 11.x release. Oops, we better not do that - let's hold off until 12.x...
>>>
>>> Do you see where this is going? We already have Webslinger in the project - a feature that isn't finished and isn't used. Has that caused problems in 9.04?
>> I agree with Anil's sentiment, I just never got around to writing the email.
>> What I am for at this point:
>> - Anything that makes the user's life easier
>> What I am against:
>> - Any major changes to existing functionality that may just result in a whole lot of problems for early adopters and a whole lot of backporting
>> I'm still not entirely clear on what you're trying to achieve by pushing non-functional code into the trunk prior to branching.
>
> The security redesign works, it's just disabled. It's disabled because there are security holes in the existing code, and the new security design plugs those holes - making parts of the project unreachable.
>
> Why not do it now? What set of circumstances would make it acceptable to merge?
>
> The design has been discussed for nearly a year, the design document has been up for almost as long, and the branch has been around since last August. There has been plenty of time for code review and discussion.

Here's part of your original message:
> The implementation of the new security design is not finished, but it will be disabled - so everything will still work the same.

The circumstances that would make it acceptable to me for merging would be a statement like this:
"The implementation of the new security design is finished"

How does David feel about your implementation?  Has the problem of two competing designs been resolved?

Regards
Scott

[Adrian Crum]

Scott Gray wrote:

> On 6/04/2010, at 4:03 PM, Adrian Crum wrote:
>
>> Scott Gray wrote:
>>> On 6/04/2010, at 3:03 PM, Adrian Crum wrote:
>>>> Anil Patel wrote:
>>>>> I was thinking, Why not other way round. As I understand, we will not be able to use execution content features in other parts of Ofbiz in time for 10.4 release. If this is the case then additional code in release branch may add some new issues but will not add any benefits. Right?
>>>> Have you even looked at the design document or the code?
>>> I haven't, as long as there were two branches I've been staying well clear of them.
>>>>> So IMO we should wait till 10.04 release branch is created and merge executioncontext20091231 with trunk after 10.04 release branch is created.
>>>> Okay, let's wait and then we will add the new issues to the 11.x release. Oops, we better not do that - let's hold off until 12.x...
>>>>
>>>> Do you see where this is going? We already have Webslinger in the project - a feature that isn't finished and isn't used. Has that caused problems in 9.04?
>>> I agree with Anil's sentiment, I just never got around to writing the email.
>>> What I am for at this point:
>>> - Anything that makes the user's life easier
>>> What I am against:
>>> - Any major changes to existing functionality that may just result in a whole lot of problems for early adopters and a whole lot of backporting
>>> I'm still not entirely clear on what you're trying to achieve by pushing non-functional code into the trunk prior to branching.
>> The security redesign works, it's just disabled. It's disabled because there are security holes in the existing code, and the new security design plugs those holes - making parts of the project unreachable.
>>
>> Why not do it now? What set of circumstances would make it acceptable to merge?
>>
>> The design has been discussed for nearly a year, the design document has been up for almost as long, and the branch has been around since last August. There has been plenty of time for code review and discussion.
>
> Here's part of your original message:
>> The implementation of the new security design is not finished, but it will be disabled - so everything will still work the same.
>
> The circumstances that would make it acceptable to me for merging would be a statement like this:
> "The implementation of the new security design is finished"
>
> How does David feel about your implementation?  Has the problem of two competing designs been resolved?

There never was two competing designs. We had competing branches - both
implemented the same design. On the contrary, we collaborated on the
design - go look at the design document.

-Adrian

[Scott Gray-2]

On 6/04/2010, at 4:23 PM, Adrian Crum wrote:

> Scott Gray wrote:
>> On 6/04/2010, at 4:03 PM, Adrian Crum wrote:
>>> Scott Gray wrote:
>>>> On 6/04/2010, at 3:03 PM, Adrian Crum wrote:
>>>>> Anil Patel wrote:
>>>>>> I was thinking, Why not other way round. As I understand, we will not be able to use execution content features in other parts of Ofbiz in time for 10.4 release. If this is the case then additional code in release branch may add some new issues but will not add any benefits. Right?
>>>>> Have you even looked at the design document or the code?
>>>> I haven't, as long as there were two branches I've been staying well clear of them.
>>>>>> So IMO we should wait till 10.04 release branch is created and merge executioncontext20091231 with trunk after 10.04 release branch is created.
>>>>> Okay, let's wait and then we will add the new issues to the 11.x release. Oops, we better not do that - let's hold off until 12.x...
>>>>>
>>>>> Do you see where this is going? We already have Webslinger in the project - a feature that isn't finished and isn't used. Has that caused problems in 9.04?
>>>> I agree with Anil's sentiment, I just never got around to writing the email.
>>>> What I am for at this point:
>>>> - Anything that makes the user's life easier
>>>> What I am against:
>>>> - Any major changes to existing functionality that may just result in a whole lot of problems for early adopters and a whole lot of backporting
>>>> I'm still not entirely clear on what you're trying to achieve by pushing non-functional code into the trunk prior to branching.
>>> The security redesign works, it's just disabled. It's disabled because there are security holes in the existing code, and the new security design plugs those holes - making parts of the project unreachable.
>>>
>>> Why not do it now? What set of circumstances would make it acceptable to merge?
>>>
>>> The design has been discussed for nearly a year, the design document has been up for almost as long, and the branch has been around since last August. There has been plenty of time for code review and discussion.
>> Here's part of your original message:
>>> The implementation of the new security design is not finished, but it will be disabled - so everything will still work the same.
>> The circumstances that would make it acceptable to me for merging would be a statement like this:
>> "The implementation of the new security design is finished"
>> How does David feel about your implementation?  Has the problem of two competing designs been resolved?
>
> There never was two competing designs. We had competing branches - both implemented the same design. On the contrary, we collaborated on the design - go look at the design document.

Okay fair enough, I guess David's branch should be deleted then?

I'm happy to trust your judgement but my advice is that if there is any chance that these changes could cause problems then I really think it should be merged straight after the release branch is created and not before.

Regards
Scott

[Adrian Crum]

Scott Gray wrote:

> On 6/04/2010, at 4:23 PM, Adrian Crum wrote:
>
>> Scott Gray wrote:
>>> On 6/04/2010, at 4:03 PM, Adrian Crum wrote:
>>>> Scott Gray wrote:
>>>>> On 6/04/2010, at 3:03 PM, Adrian Crum wrote:
>>>>>> Anil Patel wrote:
>>>>>>> I was thinking, Why not other way round. As I understand, we will not be able to use execution content features in other parts of Ofbiz in time for 10.4 release. If this is the case then additional code in release branch may add some new issues but will not add any benefits. Right?
>>>>>> Have you even looked at the design document or the code?
>>>>> I haven't, as long as there were two branches I've been staying well clear of them.
>>>>>>> So IMO we should wait till 10.04 release branch is created and merge executioncontext20091231 with trunk after 10.04 release branch is created.
>>>>>> Okay, let's wait and then we will add the new issues to the 11.x release. Oops, we better not do that - let's hold off until 12.x...
>>>>>>
>>>>>> Do you see where this is going? We already have Webslinger in the project - a feature that isn't finished and isn't used. Has that caused problems in 9.04?
>>>>> I agree with Anil's sentiment, I just never got around to writing the email.
>>>>> What I am for at this point:
>>>>> - Anything that makes the user's life easier
>>>>> What I am against:
>>>>> - Any major changes to existing functionality that may just result in a whole lot of problems for early adopters and a whole lot of backporting
>>>>> I'm still not entirely clear on what you're trying to achieve by pushing non-functional code into the trunk prior to branching.
>>>> The security redesign works, it's just disabled. It's disabled because there are security holes in the existing code, and the new security design plugs those holes - making parts of the project unreachable.
>>>>
>>>> Why not do it now? What set of circumstances would make it acceptable to merge?
>>>>
>>>> The design has been discussed for nearly a year, the design document has been up for almost as long, and the branch has been around since last August. There has been plenty of time for code review and discussion.
>>> Here's part of your original message:
>>>> The implementation of the new security design is not finished, but it will be disabled - so everything will still work the same.
>>> The circumstances that would make it acceptable to me for merging would be a statement like this:
>>> "The implementation of the new security design is finished"
>>> How does David feel about your implementation?  Has the problem of two competing designs been resolved?
>> There never was two competing designs. We had competing branches - both implemented the same design. On the contrary, we collaborated on the design - go look at the design document.
>
> Okay fair enough, I guess David's branch should be deleted then?

Don't ask ME to do that! ;-) Actually, that branch still contains
valuable information on his plans to eliminate the circular-dependency
issue. I plan on tackling that issue next, so it would help if I could
refer to it.

> I'm happy to trust your judgement but my advice is that if there is any chance that these changes could cause problems then I really think it should be merged straight after the release branch is created and not before.

You don't have to trust my judgment - go see for yourself. I just synced
the branch with the trunk - try to make it do something wrong.

-Adrian

[Scott Gray-2]

On 6/04/2010, at 4:48 PM, Adrian Crum wrote:

> Scott Gray wrote:
>> On 6/04/2010, at 4:23 PM, Adrian Crum wrote:
>>> Scott Gray wrote:
>>>> On 6/04/2010, at 4:03 PM, Adrian Crum wrote:
>>>>> Scott Gray wrote:
>>>>>> On 6/04/2010, at 3:03 PM, Adrian Crum wrote:
>>>>>>> Anil Patel wrote:
>>>>>>>> I was thinking, Why not other way round. As I understand, we will not be able to use execution content features in other parts of Ofbiz in time for 10.4 release. If this is the case then additional code in release branch may add some new issues but will not add any benefits. Right?
>>>>>>> Have you even looked at the design document or the code?
>>>>>> I haven't, as long as there were two branches I've been staying well clear of them.
>>>>>>>> So IMO we should wait till 10.04 release branch is created and merge executioncontext20091231 with trunk after 10.04 release branch is created.
>>>>>>> Okay, let's wait and then we will add the new issues to the 11.x release. Oops, we better not do that - let's hold off until 12.x...
>>>>>>>
>>>>>>> Do you see where this is going? We already have Webslinger in the project - a feature that isn't finished and isn't used. Has that caused problems in 9.04?
>>>>>> I agree with Anil's sentiment, I just never got around to writing the email.
>>>>>> What I am for at this point:
>>>>>> - Anything that makes the user's life easier
>>>>>> What I am against:
>>>>>> - Any major changes to existing functionality that may just result in a whole lot of problems for early adopters and a whole lot of backporting
>>>>>> I'm still not entirely clear on what you're trying to achieve by pushing non-functional code into the trunk prior to branching.
>>>>> The security redesign works, it's just disabled. It's disabled because there are security holes in the existing code, and the new security design plugs those holes - making parts of the project unreachable.
>>>>>
>>>>> Why not do it now? What set of circumstances would make it acceptable to merge?
>>>>>
>>>>> The design has been discussed for nearly a year, the design document has been up for almost as long, and the branch has been around since last August. There has been plenty of time for code review and discussion.
>>>> Here's part of your original message:
>>>>> The implementation of the new security design is not finished, but it will be disabled - so everything will still work the same.
>>>> The circumstances that would make it acceptable to me for merging would be a statement like this:
>>>> "The implementation of the new security design is finished"
>>>> How does David feel about your implementation?  Has the problem of two competing designs been resolved?
>>> There never was two competing designs. We had competing branches - both implemented the same design. On the contrary, we collaborated on the design - go look at the design document.
>> Okay fair enough, I guess David's branch should be deleted then?
>
> Don't ask ME to do that! ;-) Actually, that branch still contains valuable information on his plans to eliminate the circular-dependency issue. I plan on tackling that issue next, so it would help if I could refer to it.

I was just trying to bring the situation to a head :-)  I don't care if it stays or goes.

>> I'm happy to trust your judgement but my advice is that if there is any chance that these changes could cause problems then I really think it should be merged straight after the release branch is created and not before.
>
> You don't have to trust my judgment - go see for yourself. I just synced the branch with the trunk - try to make it do something wrong.

Well I could do that, but then I'd have to stop what I'm doing.  I fly back to NZ on Saturday so my time is short at the moment.

I would certainly like to look at it at some point but I still don't understand the need to get an unfinished implementation into the release branch.

Regards
Scott

[Adam Heath-2]

Adrian Crum wrote:
> Anil Patel wrote:
>> I was thinking, Why not other way round.
>> As I understand, we will not be able to use execution content features
>> in other parts of Ofbiz in time for 10.4 release. If this is the case
>> then additional code in release branch may add some new issues but
>> will not add any benefits. Right?
>
> Have you even looked at the design document or the code?

Hmm, why do you have to be so difficult?  Couldn't you have just
answered the question?  Or included a reference to the design
document?  You know more about this branch than others, so why not
share that knowledge?

>> So IMO we should wait till 10.04 release branch is created and merge
>> executioncontext20091231 with trunk after 10.04 release branch is
>> created.
>
> Okay, let's wait and then we will add the new issues to the 11.x
> release. Oops, we better not do that - let's hold off until 12.x...
>
> Do you see where this is going? We already have Webslinger in the
> project - a feature that isn't finished and isn't used. Has that caused
> problems in 9.04?

webslinger isn't deeply integrated at all.

[Adrian Crum]

Adam Heath wrote:

> Adrian Crum wrote:
>> Anil Patel wrote:
>>> I was thinking, Why not other way round.
>>> As I understand, we will not be able to use execution content features
>>> in other parts of Ofbiz in time for 10.4 release. If this is the case
>>> then additional code in release branch may add some new issues but
>>> will not add any benefits. Right?
>> Have you even looked at the design document or the code?
>
> Hmm, why do you have to be so difficult?  Couldn't you have just
> answered the question?  Or included a reference to the design
> document?  You know more about this branch than others, so why not
> share that knowledge?

I wasn't being difficult. Anil is saying the security redesign won't add
any benefits. That tells me he hasn't read the design document.

I'm a little stunned by all the push back. A year ago there was a lot of
enthusiasm for this. Now it seems I'm the only person interested in
seeing it included in the project.

-Adrian

[Adrian Crum]

Anil Patel wrote:
> I am really not against merging executioncontext branch with trunk. I don't see reason to include it in upcoming release branch if we will not be using it.  And yes, even though Webslinger is not a good examples we can still say that, decision put it in trunk was made too early, but its just me.

Users can enable the new security design and convert their applications
over to it if they wish. They will also have time to evaluate it and
prepare for the eventual switch-over.

> Merging of executioncontext will make more sense to me if our release policy allowed back porting of some features from trunk to release brach (Internally I will be doing it anyways). If such thing was allowed then I can include framework changes now and at later date back port related enhancements to the branch.

Why do we need to backport features? The only backporting needed will be
bug fixes.


-Adrian

[Adam Heath-2]

Adrian Crum wrote:

> Adam Heath wrote:
>> Adrian Crum wrote:
>>> Anil Patel wrote:
>>>> I was thinking, Why not other way round.
>>>> As I understand, we will not be able to use execution content features
>>>> in other parts of Ofbiz in time for 10.4 release. If this is the case
>>>> then additional code in release branch may add some new issues but
>>>> will not add any benefits. Right?
>>> Have you even looked at the design document or the code?
>>
>> Hmm, why do you have to be so difficult?  Couldn't you have just
>> answered the question?  Or included a reference to the design
>> document?  You know more about this branch than others, so why not
>> share that knowledge?
>
> I wasn't being difficult. Anil is saying the security redesign won't add
> any benefits. That tells me he hasn't read the design document.

You still haven't included a reference to said design document.

[Scott Gray-2]

On 6/04/2010, at 5:18 PM, Adrian Crum wrote:

> Adam Heath wrote:
>> Adrian Crum wrote:
>>> Anil Patel wrote:
>>>> I was thinking, Why not other way round.
>>>> As I understand, we will not be able to use execution content features
>>>> in other parts of Ofbiz in time for 10.4 release. If this is the case
>>>> then additional code in release branch may add some new issues but
>>>> will not add any benefits. Right?
>>> Have you even looked at the design document or the code?
>> Hmm, why do you have to be so difficult?  Couldn't you have just
>> answered the question?  Or included a reference to the design
>> document?  You know more about this branch than others, so why not
>> share that knowledge?
>
> I wasn't being difficult. Anil is saying the security redesign won't add any benefits. That tells me he hasn't read the design document.

I think you're misinterpreting what he was saying, the no benefits is in reference to it being disabled because it isn't complete

> I'm a little stunned by all the push back. A year ago there was a lot of enthusiasm for this. Now it seems I'm the only person interested in seeing it included in the project.

Included in the project and included in a release branch to be created this month are two very different things.

Regards
Scott

[Adrian Crum]

Adam Heath wrote:

> Adrian Crum wrote:
>> Adam Heath wrote:
>>> Adrian Crum wrote:
>>>> Anil Patel wrote:
>>>>> I was thinking, Why not other way round.
>>>>> As I understand, we will not be able to use execution content features
>>>>> in other parts of Ofbiz in time for 10.4 release. If this is the case
>>>>> then additional code in release branch may add some new issues but
>>>>> will not add any benefits. Right?
>>>> Have you even looked at the design document or the code?
>>> Hmm, why do you have to be so difficult?  Couldn't you have just
>>> answered the question?  Or included a reference to the design
>>> document?  You know more about this branch than others, so why not
>>> share that knowledge?
>> I wasn't being difficult. Anil is saying the security redesign won't add
>> any benefits. That tells me he hasn't read the design document.
>
> You still haven't included a reference to said design document.

Oops.

http://cwiki.apache.org/confluence/display/OFBTECH/OFBiz+Security+Redesign

[Adrian Crum-2]

--- On Tue, 4/6/10, Scott Gray <[hidden email]> wrote:

> On 6/04/2010, at 5:18 PM, Adrian Crum
> wrote:
>
> > Adam Heath wrote:
> >> Adrian Crum wrote:
> >>> Anil Patel wrote:
> >>>> I was thinking, Why not other way round.
> >>>> As I understand, we will not be able to
> use execution content features
> >>>> in other parts of Ofbiz in time for 10.4
> release. If this is the case
> >>>> then additional code in release branch may
> add some new issues but
> >>>> will not add any benefits. Right?
> >>> Have you even looked at the design document or
> the code?
> >> Hmm, why do you have to be so difficult? 
> Couldn't you have just
> >> answered the question?  Or included a
> reference to the design
> >> document?  You know more about this branch
> than others, so why not
> >> share that knowledge?
> >
> > I wasn't being difficult. Anil is saying the security
> redesign won't add any benefits. That tells me he hasn't
> read the design document.
>
> I think you're misinterpreting what he was saying, the no
> benefits is in reference to it being disabled because it
> isn't complete
>
> > I'm a little stunned by all the push back. A year ago
> there was a lot of enthusiasm for this. Now it seems I'm the
> only person interested in seeing it included in the
> project.
>
> Included in the project and included in a release branch to
> be created this month are two very different things.

Then something has changed. In the past, a release branch was created regardless of the state of the trunk. In other words, it was released "warts and all."

I not trying to be argumentative, but I would like to make one more point. If we wait until after the release branch, then the branch will be immediately obsolete. As an example: right after the R4 branch was created we refactored the UI. For the next two years we had users wishing we would port the trunk's UI over to R4.

The new security design is far better than the current one. I have a feeling history will repeat itself.

-Adrian

[Scott Gray-2]

On 6/04/2010, at 6:36 PM, Adrian Crum wrote:

> --- On Tue, 4/6/10, Scott Gray <[hidden email]> wrote:
>> On 6/04/2010, at 5:18 PM, Adrian Crum
>> wrote:
>>
>>> Adam Heath wrote:
>>>> Adrian Crum wrote:
>>>>> Anil Patel wrote:
>>>>>> I was thinking, Why not other way round.
>>>>>> As I understand, we will not be able to
>> use execution content features
>>>>>> in other parts of Ofbiz in time for 10.4
>> release. If this is the case
>>>>>> then additional code in release branch may
>> add some new issues but
>>>>>> will not add any benefits. Right?
>>>>> Have you even looked at the design document or
>> the code?
>>>> Hmm, why do you have to be so difficult?
>> Couldn't you have just
>>>> answered the question?  Or included a
>> reference to the design
>>>> document?  You know more about this branch
>> than others, so why not
>>>> share that knowledge?
>>>
>>> I wasn't being difficult. Anil is saying the security
>> redesign won't add any benefits. That tells me he hasn't
>> read the design document.
>>
>> I think you're misinterpreting what he was saying, the no
>> benefits is in reference to it being disabled because it
>> isn't complete
>>
>>> I'm a little stunned by all the push back. A year ago
>> there was a lot of enthusiasm for this. Now it seems I'm the
>> only person interested in seeing it included in the
>> project.
>>
>> Included in the project and included in a release branch to
>> be created this month are two very different things.
>
> Then something has changed. In the past, a release branch was created regardless of the state of the trunk. In other words, it was released "warts and all."

Nothing has changed, there is a difference between putting something in the trunk because it's ready to go in there and putting something in the trunk because a release branch is about to be created.  So I would argue that the change is a behavioral one on your part because of the looming release branch.

> I not trying to be argumentative, but I would like to make one more point. If we wait until after the release branch, then the branch will be immediately obsolete. As an example: right after the R4 branch was created we refactored the UI. For the next two years we had users wishing we would port the trunk's UI over to R4.
>
> The new security design is far better than the current one. I have a feeling history will repeat itself.

If that is a real problem then we should be delaying creating the branch and not rushing to cram things in there.  The security framework is either finished and works and is ready to be committed or it isn't, which is it?  I'm quite sure I will be working with this branch on a regular basis and I'm gonna be annoyed if it's plagued with problems because of this merge, I'm not saying it will be but I'd like to assured that it isn't likely.

Regards
Scott