geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Time for trunk res
Date Tue, 26 Apr 2011 04:45:12 GMT
It seems like it will cause less disruption if I put the new stuff on a branch.  Unless someone
asks I'm going to keep the same version, 3.0-SNAPSHOT.  So, don't push snapshots off the branch

Unless I can figure out some git magic I'm going to do this by applying the work to trunk,
moving trunk to the new branch, and restoring trunk.

I'm going to try to condense the git commits a bit so each one is fairly substantial but don't
plan to spend a lot of time on this.

I expect to do this tomorrow.

david jencks

On Apr 25, 2011, at 7:36 PM, Kevan Miller wrote:

> On Apr 25, 2011, at 5:37 AM, Shawn Jiang wrote:
>> 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.
> I"m ok with that. As long as trunk changes are being merged into the new branch. 
>> 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.
> The key will be when 2 occurs. Hopefully, it will be soon...
> --kevan

View raw message