Also.... There's a certain amount of flailing around in my (local) git commits. I don't want to spend a lot of time trying to massage these into clean atomic well-thought-out steps but I could try to do a little bit of rebasing to combine the most obviously related commits into more sensible units.
What would people like in svn? -- to see all the incremental steps -- to see a slightly better organized version with a few sets of commits merged together -- to see one commit with all changes merged (I don't think this is a good idea, but it certainly is easy) thanks david jencks On Apr 25, 2011, at 9:38 AM, David Jencks wrote: > The tck won't run against the new code yet, only the framework server builds. > > Over the weekend I resolved the git problems I was having and made a linear > history version which is up to date with svn and can be pushed back into svn. > > It would be easier for me to push my changes into trunk. If we make a > sandbox/other copy I will have to figure out how to deal with svn branches > from git, which may not be straightforward. If we make a sandbox/branch and > want to turn it into trunk an svn mv rather than merge will work better. > > The next steps I have in mind for the new code are to > > -- make the entire server build and start > > -- get the auxiliary servers (app client, various deployers) to work > > Much as I'd like to get the new code into an easier-to-see location as soon > as plausible, there isn't a whole lot of point to doing that unless more > people are going to actively work on it. > > thanks > david jencks > > > On Apr 25, 2011, at 4:18 AM, Ivan wrote: > >> I am thinking that we might give an opportunity for the new trunk codes for >> one round TCK, if the result seems OK, we might directly work on it :-) >> >> 2011/4/25 Shawn Jiang <[email protected]> >> >> >> On Mon, Apr 25, 2011 at 11:34 AM, Kevan Miller <[email protected]> >> wrote: >> As you know, David Jencks has been working on restructuring Geronimo to move >> away from the Geronimo's ConfigurationManager and DependencyManager and use >> standards based OSGi mechanisms. >> >> I took a look at his current code -- >> http://people.apache.org/~djencks/22-4-2011.full.bundle (I used git clone >> 'git clone ~/downloads/22-4-2011.full.bundle geronimo' and 'git checkout >> arch3' to create a working copy). After running 'mvn -N' I was able to build >> successfully (well build up to framework assembly at which point there's an >> IANAL-style check for license/notice files). The resulting framework server >> starts and, IMO, things are looking pretty good. >> >> I think it's time to start getting more eyes on this work. Assuming we like >> the direction, I'd like to see this code in trunk. Allowing multiple people >> to start working on further integration. >> >> An alternative would be to create a sandbox/branch for this new work. >> However, I'm more inclined to go with trunk. Here's how things could work: >> >> 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. >> >> 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. >> >> Thoughts ? >> >> >> >> Create a new branch off of current trunk and use this branch for continued >> TCK testing. This assumes that fixes for TCK problems do not have much >> overlap with changes for the new server structure -- I think this will >> largely be true. This does imply that TCK fixes will need to be merged into >> trunk. This seems better than other alternatives. Though I'd certainly >> listen to other options/opinions. >> >> One option for this new branch is to call it 3.0-M2 (and abandon the current >> M2 branch). I'd really like to see us get a web profile compliant Milestone >> release. Would be useful for our users, anyway... >> >> I'm hopeful that our switch over to the new trunk codebase can go pretty >> quickly. I think we certainly want to minimize time with two active >> development branches/trunks. >> I agree we want to minimize time with two active developement branches. >> >> >> Thoughts? >> >> --kevan >> >> >> >> >> -- >> Shawn >> >> >> >> -- >> Ivan >
