On 6/04/2010, at 6:36 PM, Adrian Crum wrote: > --- On Tue, 4/6/10, Scott Gray <scott.g...@hotwaxmedia.com> wrote: >> On 6/04/2010, at 5:18 PM, Adrian Crum >> wrote: >> >>> Adam Heath wrote: >>>> 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? >>>> Hmm, why do you have to be so difficult? >> Couldn't you have just >>>> answered the question? Or included a >> reference to the design >>>> document? You know more about this branch >> than others, so why not >>>> share that knowledge? >>> >>> I wasn't being difficult. Anil is saying the security >> redesign won't add any benefits. That tells me he hasn't >> read the design document. >> >> I think you're misinterpreting what he was saying, the no >> benefits is in reference to it being disabled because it >> isn't complete >> >>> I'm a little stunned by all the push back. A year ago >> there was a lot of enthusiasm for this. Now it seems I'm the >> only person interested in seeing it included in the >> project. >> >> Included in the project and included in a release branch to >> be created this month are two very different things. > > Then something has changed. In the past, a release branch was created > regardless of the state of the trunk. In other words, it was released "warts > and all."
Nothing has changed, there is a difference between putting something in the trunk because it's ready to go in there and putting something in the trunk because a release branch is about to be created. So I would argue that the change is a behavioral one on your part because of the looming release branch. > I not trying to be argumentative, but I would like to make one more point. If > we wait until after the release branch, then the branch will be immediately > obsolete. As an example: right after the R4 branch was created we refactored > the UI. For the next two years we had users wishing we would port the trunk's > UI over to R4. > > The new security design is far better than the current one. I have a feeling > history will repeat itself. If that is a real problem then we should be delaying creating the branch and not rushing to cram things in there. The security framework is either finished and works and is ready to be committed or it isn't, which is it? I'm quite sure I will be working with this branch on a regular basis and I'm gonna be annoyed if it's plagued with problems because of this merge, I'm not saying it will be but I'd like to assured that it isn't likely. Regards Scott
smime.p7s
Description: S/MIME cryptographic signature
