Security Redesign and Release 10.x Branch

[Anil Patel-3]

Adrian,
I am not arguing against merging security context code into trunk. In fact we will love to get it in trunk so it can we can use it.

Having it in brach will make sense only if we can use it and it will meet of exceed the current security abilities of Ofbiz framework. If this is true then, Yes, I am in favor of getting the merge happen soon.

In case the code in security context branch is not ready for use then, I don't see the advantage of having code in release branch that cannot be used.

Thanks and Regards
Anil Patel
HotWax Media Inc
Find us on the web at www.hotwaxmedia.com or Google Keyword "ofbiz"

On Apr 6, 2010, at 8:59 PM, Scott Gray wrote:

> On 6/04/2010, at 6:36 PM, Adrian Crum wrote:
>
>> --- On Tue, 4/6/10, Scott Gray <[hidden email]> 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

[Tim Ruppert]

That's not true and you know it - my email specifically addresses how much I think it will be an improvement.

Cheers,
Ruppert

On Apr 6, 2010, at 5:18 PM, Adrian Crum wrote:

> 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.

[BJ Freeman]

I remember the discussion about the new security when andy introduced it
I remember the push back then.
I believe you were the biggest supporter of the security change.
this is evident because of the energy you have put into it.

I also agree that the release will be obsolete regardless of the
addition of the security, since many will continue to contribute feature
and not stop to validate the release candidate.

I would really like to see a trend where incomplete or less features
than it should be stopped.

I can't directly comment on the security since I have not thought about
it backwards and forwards.

I what I would like to see on these endeavors is a statement that the
branch for security is ready to be tested and once that is completed by
some of the developers so they can back you then have it merged

my 2cents



=========================
BJ Freeman
http://bjfreeman.elance.com
Strategic Power Office with Supplier Automation <http://www.businessesnetwork.com/automation/viewforum.php?f=93>
Specialtymarket.com <http://www.specialtymarket.com/>

Systems Integrator-- Glad to Assist

Chat  Y! messenger: bjfr33man
Linkedin
<http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro>


Adrian Crum sent the following on 4/6/2010 5:36 PM:

> --- On Tue, 4/6/10, Scott Gray <[hidden email]> 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."
>
> 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.
>
> -Adrian
>
>
>
>
>

[Jacopo Cappellato-4]

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
>
>
>
>

[Bob Morley]

+1 not sure on release overhead but release often is desirable from  
where I sit. Nothing wrong with triggering on a major functional  
addition.

Bob

On 2010-04-07, at 2:08 AM, Jacopo Cappellato <[hidden email]
 > 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
>>
>>
>>
>>
>

[Anil Patel-3]

This makes sense to me.
Isn't this similar to what Eclipse does, RC1 ,RC2 .... Finally RC 6 becomes final release. Then final release is maintained.

So we can do RC10.04, RC10.06, and at some point RC10.06 is stable to be released.  
 
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 2: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
>>
>>
>>
>>
>

[Jacopo Cappellato-4]

On Apr 7, 2010, at 8:14 AM, Anil Patel wrote:

> This makes sense to me.
> Isn't this similar to what Eclipse does, RC1 ,RC2 .... Finally RC 6 becomes final release. Then final release is maintained.
>
> So we can do RC10.04, RC10.06, and at some point RC10.06 is stable to be released.  

Yes, this is good, even if for ASF they will all be official releases (no RC): but 10.04, 10.6 will be "alpha" (or similar) releases and "10.06" will be a "stable" release.
Even if, and I always insist on this, only the community, with the contributions coming from users of the "stable" release, will decide if the "stable" release will be "maintained": this cannot be a responsibility of committers.

Jacopo

>
> 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 2: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
>>>
>>>
>>>
>>>
>>
>

[Anil Patel-3]

Like it.

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 2:19 AM, Jacopo Cappellato wrote:

> On Apr 7, 2010, at 8:14 AM, Anil Patel wrote:
>
>> This makes sense to me.
>> Isn't this similar to what Eclipse does, RC1 ,RC2 .... Finally RC 6 becomes final release. Then final release is maintained.
>>
>> So we can do RC10.04, RC10.06, and at some point RC10.06 is stable to be released.  
>
> Yes, this is good, even if for ASF they will all be official releases (no RC): but 10.04, 10.6 will be "alpha" (or similar) releases and "10.06" will be a "stable" release.
> Even if, and I always insist on this, only the community, with the contributions coming from users of the "stable" release, will decide if the "stable" release will be "maintained": this cannot be a responsibility of committers.
>
> Jacopo
>
>>
>> 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 2: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
>>>>
>>>>
>>>>
>>>>
>>>
>>
>

[Adrian Crum-2]

Thank Jacopo - that sounds a lot better than the all-or-nothing conversation.

-Adrian

--- On Tue, 4/6/10, Jacopo Cappellato <[hidden email]> wrote:

> From: Jacopo Cappellato <[hidden email]>
> Subject: Re: Security Redesign and Release 10.x Branch
> To: [hidden email]
> Date: Tuesday, April 6, 2010, 11:07 PM
> 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
> >
> >
> >
> >
>
>

     

[Erwan de FERRIERES]

Le 07/04/2010 08:07, Jacopo Cappellato a écrit :
> 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?)

Sounds good to me !

--
Erwan de FERRIERES
www.nereide.biz

[Jacques Le Roux]

Then, why not simply report the 10.04 to 10.06 (or 10.05), like Ubuntu did for 6.06 (which should have been 6.04 and have been
rather reported for 2 months)
I see 3 reasons:
* Confusion, I'm quite sure we will have to answer much users who will ask about the differences. This is not a big issue, but I
think it will increase users confusion which is never good. People and even more markets like stability and "certainty" (I'd say
mental certainty, as it's not real certainty, but what is reality, science?)
* Thanks to Ean's recent trends post http://www.google.com/trends?q=ofbiz&ctab=0&geo=all&date=all&sort=0 I wonder if the most
important marketing thing for us (not for the ASF) is not releasing. So if we make 2 relases in 2 months, the effect is watered down
and as I said confusion increase.
* We would like to include the layered lookups. Apart 2 minor issues they work well but when a calendar is called (it's hidden
behind). The calendar issue is maybe not that big because Sascha already solved a such issue for lookups called from a lookup. But
there is also another issue I found this weekend. We would want to make things as simple as possible for users. In order to do so,
we decided that the layer would be the default. There is currently an issue with this also. I tracked it yesterday evening but did
not have enough time to finish it yet.

The 3rd reasons is maybe not a delay problem, and I also like the release often strategy. It's only that I get some Schizophrenia:
as a developper I prefer the Apache way (release often strategy), but as a consultant I prefer the Ubuntu way. It's all about
marketing, I let you think about that :o)

Jacques

From: "Jacopo Cappellato" <[hidden email]>

>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
>>
>>
>>
>>
>
>

[BJ Freeman]

yes if every new major feature did this it would be great.
+1

=========================
BJ Freeman
http://bjfreeman.elance.com
Strategic Power Office with Supplier Automation <http://www.businessesnetwork.com/automation/viewforum.php?f=93>
Specialtymarket.com <http://www.specialtymarket.com/>

Systems Integrator-- Glad to Assist

Chat  Y! messenger: bjfr33man
Linkedin
<http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro>


Jacopo Cappellato sent the following on 4/6/2010 11:07 PM:

> 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
>>
>>
>>
>>
>
>

[Adrian Crum]

Sorry - I must have skipped over your reply. I know you've been a
supporter of the new design ever since it was first proposed.

-Adrian

Tim Ruppert wrote:

> That's not true and you know it - my email specifically addresses how much I think it will be an improvement.
>
> Cheers,
> Ruppert
>
> On Apr 6, 2010, at 5:18 PM, Adrian Crum wrote:
>
>> 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.
>
>

[Anil Patel-3]

I browsed through Ubuntu site a bit, Here are few interesting page

https://wiki.ubuntu.com/UbuntuDevelopment/ReleaseProcess
https://wiki.ubuntu.com/KarmicReleaseSchedule

They work on a release branch for about 6 months. During this time they test and enhance code base and finally release it.

Applying this to Ofbiz:
1) Create a release branch
2) Agree on list of features that will be allowed to be back ported from ofbiz trunk to ofbiz release branch.
3) When release branch is stable, release it.

This process can last for 6 months. We will have road map for what's going to happen in those 6 months. People will know what all features will be part of upcoming release and so whoever is interested on those features will help complete them.

Once released, it will only get bug fixes and no enhancements.

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 3:54 AM, Jacques Le Roux wrote:

> Then, why not simply report the 10.04 to 10.06 (or 10.05), like Ubuntu did for 6.06 (which should have been 6.04 and have been
> rather reported for 2 months)
> I see 3 reasons:
> * Confusion, I'm quite sure we will have to answer much users who will ask about the differences. This is not a big issue, but I
> think it will increase users confusion which is never good. People and even more markets like stability and "certainty" (I'd say
> mental certainty, as it's not real certainty, but what is reality, science?)
> * Thanks to Ean's recent trends post http://www.google.com/trends?q=ofbiz&ctab=0&geo=all&date=all&sort=0 I wonder if the most
> important marketing thing for us (not for the ASF) is not releasing. So if we make 2 relases in 2 months, the effect is watered down
> and as I said confusion increase.
> * We would like to include the layered lookups. Apart 2 minor issues they work well but when a calendar is called (it's hidden
> behind). The calendar issue is maybe not that big because Sascha already solved a such issue for lookups called from a lookup. But
> there is also another issue I found this weekend. We would want to make things as simple as possible for users. In order to do so,
> we decided that the layer would be the default. There is currently an issue with this also. I tracked it yesterday evening but did
> not have enough time to finish it yet.
>
> The 3rd reasons is maybe not a delay problem, and I also like the release often strategy. It's only that I get some Schizophrenia:
> as a developper I prefer the Apache way (release often strategy), but as a consultant I prefer the Ubuntu way. It's all about
> marketing, I let you think about that :o)
>
> Jacques
>
> From: "Jacopo Cappellato" <[hidden email]>
>> 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
>>>
>>>
>>>
>>>
>>
>>
>
>

[Scott Gray-2]

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
>>
>>
>>
>>
>

[Scott Gray-2]

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
>
>
>
>

[Scott Gray-2]

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
>
>
>
>

[Scott Gray-2]

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
>
>
>
>

[Scott Gray-2]

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
>
>
>
>

[Scott Gray-2]

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
>
>
>
>