geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shawn Jiang <genspr...@gmail.com>
Subject Re: I prefer the sandbox/branch option.
Date Mon, 25 Apr 2011 09:39:09 GMT
Ops, modifying title will bread the gmail thread.  Added the same comments
to the original thread.

Please ignore this mail.

On Mon, Apr 25, 2011 at 5:34 PM, Shawn Jiang <genspring@gmail.com> wrote:

>
>
> On Mon, Apr 25, 2011 at 11:34 AM, Kevan Miller <kevan.miller@gmail.com>wrote:
>
>> As you know, David Jencks has been working on restructuring Geronimo to
>> move away from the Geronimo's ConfigurationManager and DependencyManager and
>> use standards based OSGi mechanisms.
>>
>> I took a look at his current code --
>> http://people.apache.org/~djencks/22-4-2011.full.bundle (I used git clone
>> 'git clone ~/downloads/22-4-2011.full.bundle geronimo' and 'git checkout
>> arch3' to create a working copy). After running 'mvn -N' I was able to build
>> successfully (well build up to framework assembly at which point there's an
>> IANAL-style check for license/notice files). The resulting framework server
>> starts and, IMO, things are looking pretty good.
>>
>> I think it's time to start getting more eyes on this work. Assuming we
>> like the direction, I'd like to see this code in trunk. Allowing multiple
>> people to start working on further integration.
>>
>> An alternative would be to create a sandbox/branch for this new work.
>> However, I'm more inclined to go with trunk. Here's how things could work:
>>
>
> With the later options, we need to re-setup m2 dev/AHP/build environment
> immediately and have to maintain two set of code for tck for an unknown
> period.   I'd prefer the sandbox/branch instead of branching current trunk
> before major potential issues in the new kernel is resolved.
>
> Here are the possible working logic if choosing the sandbox option:
>
> 1, Run full tck/SVT against the sandbox branch to find the gaps.
> 2, Keep resolving the Major issues until we are comfortable to put it into
> trunk.
> 3, Branch current trunk to new M2 when the sandbox branch is ready.
> 4, Merge the sandbox branch to trunk.
>
> Thoughts ?
>
>
>>
>> Create a new branch off of current trunk and use this branch for continued
>> TCK testing. This assumes that fixes for TCK problems do not have much
>> overlap with changes for the new server structure -- I think this will
>> largely be true. This does imply that TCK fixes will need to be merged into
>> trunk. This seems better than other alternatives. Though I'd certainly
>> listen to other options/opinions.
>>
>> One option for this new branch is to call it 3.0-M2 (and abandon the
>> current M2 branch). I'd really like to see us get a web profile compliant
>> Milestone release. Would be useful for our users, anyway...
>>
>> I'm hopeful that our switch over to the new trunk codebase can go pretty
>> quickly. I think we certainly want to minimize time with two active
>> development branches/trunks.
>>
>
> I agree we want to minimize time with two active developement branches.
>
>
>>
>> Thoughts?
>>
>> --kevan
>>
>>
>
>
> --
> Shawn
>



-- 
Shawn

Mime
View raw message