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