geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
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.

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


Mime
View raw message