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 >
