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 23:30:26 GMT
I've committed my work.  Trunk should still be trunk and the new work should be on branches/3.0-osgi.

david jencks

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