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
smime.p7s
Description: S/MIME cryptographic signature
