Sorry if I am hijacking this thread, but the more I think of it the more I believe we should officially create an "alpha" release 10.04, instead of simply creating a release candidate for 10.04. In this way we will have two official current releases: 09.04 Stable Release 10.04 Alpha Release
Intended audiences: 09.04: final users with no interest (or resources) in helping the community to build and maintain stable releases 10.04: users (they could be service providers, end user companies with internal resources or longer term goals etc...) that are willing to help the community to build and maintain a stable release If there will be interest around the 10.04 alpha release, we will get bug fixes that will be part of a future 10.04.1 "stable" (bug fix) release (or a "beta" release), or even 10.04.2,3,4,5 etc... (each of them more stable than the predecessor). Jacopo On Apr 8, 2010, at 8:11 PM, Scott Gray wrote: > 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 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>> >> >
