On 13/04/2010, at 9:41 PM, Jacopo Cappellato wrote: > > On Apr 13, 2010, at 11:36 AM, Jacopo Cappellato wrote: > >> On Apr 13, 2010, at 11:33 AM, Scott Gray wrote: >> >>> Hi Jacopo, >>> >>> What exactly does it mean to create an "alpha" release, compared to what we >>> have now where we create a release branch? >> >> It fundamentally means that we can distribute it outside of the inner group >> of contributors because the we can guarantee that it is full compliant with >> ASF license requirements. >> > > But apart from this (important, in my opinion) difference the "alpha" release > will be used exactly as we have used the release candidate: to build (with > the help of the community) a "stable" release. > Having the ability of distribute it will increase our chances to get more > help (tests and bug fixes but also documentation) from the community and the > "stable" release will be an effort of the community (instead of the result of > backported patches done by committers only). > > Jacopo
I'm very much in favor of moving away from svn as our core distribution method. I believe that doing so would encourage service providers (or even the community) to build and offer migration tools and services. Regards Scott >> Kind regards, >> >> Jacopo >> >>> >>> Thanks >>> Scott >>> >>> On 13/04/2010, at 8:19 PM, Jacopo Cappellato wrote: >>> >>>> 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 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
smime.p7s
Description: S/MIME cryptographic signature
