Just to be clear though, I am NOT in favor of back-porting large chunks of functionality to the release branch under the guise of bug fixes.
Regards Scott On 8/04/2010, at 12:06 PM, Anil Patel wrote: > Looks like, none who participated in this thread have objections for merging > of securitycontext20091231 branch with trunk. > > Thanks and Regards > Anil Patel > HotWax Media Inc > Find us on the web at www.hotwaxmedia.com or Google Keyword "ofbiz" > > On Apr 7, 2010, at 7:46 PM, Scott Gray wrote: > >> Well I don't see any problem with dropping it in right now then. The real >> question will be what do people want to be able to backport once the release >> branch is created. >> >> Regards >> Scott >> >> On 7/04/2010, at 5:35 PM, Adrian Crum wrote: >> >>> The security redesign implementation itself is mostly finished. There are a >>> few TODOs and they can be found in the BranchReadMe.txt file. >>> >>> I recently synchronized the branch with the trunk and there is a remote >>> chance something in the design might have broken in the process. I need to >>> run some tests and review the code to see if that happened. >>> >>> The Example component has been switched over to the new design. >>> >>> There is a user login called "artifact-user" that demonstrates the new >>> design. That user login is restricted to using the Example component. >>> >>> If the branch was merged back to the trunk and the new security design was >>> enabled, the Example component would use the new design and the remaining >>> components would still use the current security design. The two can >>> co-exist. >>> >>> I imagine the process after that would be similar to when we introduced the >>> permission checking services - contributors can contribute code that >>> converts parts of the project over to the new security design. Conversion >>> involves removing hard-coded permission checks and creating seed data to >>> grant permission to component artifacts. >>> >>> As I mentioned before, switching a component over to the new design can >>> create some unexpected problems. That's because our existing code has >>> security holes in it, and the new design plugs those holes - making parts >>> of the component unreachable. In other words, parts of code that happily >>> allow you to do things you don't have permission to do will start to throw >>> exceptions in the new design. >>> >>> -Adrian >>> >>> >>> Scott Gray wrote: >>>> Question: >>>> What exactly is the current status of the execution branch? What is it >>>> that needs to be done for it to be enabled in the trunk? >>>> I'm sorry if you feel you've already answered that question but I'm afraid >>>> it still isn't entirely clear to me. >>>> Regards >>>> Scott >>>> On 7/04/2010, at 5:14 PM, Adrian Crum wrote: >>>>> If we wait, then we're waiting for evaluation and testing of the branch. >>>>> I've done all I can do - the code is written, I suggested we do the merge >>>>> before the release branch, and I gave my reasons for suggesting it. >>>>> >>>>> At this point in time I have stepped out of the discussion (in a positive >>>>> way) to give others a chance to look at the design and the code and >>>>> decide for themselves if it should be included. In other words, I don't >>>>> want to be in a position where I have to convince the community what it >>>>> should do. If the design and the implementation are good, then there will >>>>> be no need to convince anyone, right? >>>>> >>>>> I'll answer questions about the executioncontext branch, and I'll >>>>> continue to work on it here and there when I have the time. If the >>>>> release branch is created without it, then that will be fine with me. >>>>> >>>>> :-) >>>>> >>>>> -Adrian >>>>> >>>>> >>>>> Scott Gray wrote: >>>>>> Considering we have yet to do an official release after 3.5 years and >>>>>> the lack of user interest in our release branches (partly because we >>>>>> recommend the trunk to everybody), I think it would be a waste of time >>>>>> and effort to create more than one release branch per year. If we want >>>>>> the security branch in there then lets wait, there is no good reason for >>>>>> us to release this month, it's just an arbitrary date. >>>>>> HotWax Media >>>>>> http://www.hotwaxmedia.com >>>>>> On 7/04/2010, at 12:07 AM, Jacopo Cappellato wrote: >>>>>>> I would suggest to: >>>>>>> 1) release 10.04 before the merge is done >>>>>>> 2) merge the code to the trunk, switch to it, fix any possible issue >>>>>>> 3) do another release (10.06?) >>>>>>> >>>>>>> I know this is not inline with what we currently think a release should >>>>>>> be, but this is very inline with what the ASF practices and so I will >>>>>>> continue to insist with the release-often practice. :-) >>>>>>> >>>>>>> Jacopo >>>>>>> >>>>>>> On Apr 4, 2010, at 8: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 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >> >
smime.p7s
Description: S/MIME cryptographic signature
