geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <>
Subject Re: Time for trunk res
Date Tue, 26 Apr 2011 12:59:44 GMT

On Apr 25, 2011, at 9:45 PM, David Jencks wrote:

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

Catching up on this thread and was going to suggest exactly that.  Buys us a little time to
do some manual TCK runs off the branch.  Once things look good, we could flip branch/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.
> thanks
> 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