I like the idea about being a bit more organized (goes for docs too but that is another thread). I have questions about the proposal > > - Create the following SVN sub-projects > --- SCA 1.x > --- SCA 2.x > --- DAS > --- SDO > --- CPP
This seems a bit unbalanced. On one hand you have the projects split by programming model (SCA, SDO etc.). On the other you have them grouped by implementation technology (CPP). Is your proposal that SCA 1.x, SCA 2.x, DAS, SDO are Java projects? > > - Each sub-project will have the following basic SVN structure > -- Project > ---- trunk > ---- branches > ---- tags > ---- contrib What is the intention of contrib here? We discussed a while back the idea of having a contrib directory where people could check in and work on anything that is not yet ready for release so that we don't have to ask the "what should be in the release" question each time we do a release. Is this it? If so it should probably be inside trunk. > > - Contents from the current SVN structure (e.g tags, branches, contrib > folders, etc) will then be merged into the proposed SVN structure for > each sub-project > > - The following folders will not change > --- Maven > --- Site > --- Sanbox > > - The following folders does not seem to be in use currently > --- collaboration README says that this is a collaboration area for all ASF committers. > --- interop This was for interop testing between CPP and Java SDO.I imagine it's out of date but could be added to the CPP SDO project if you want to tidy it out of the way. > > - TBD > --- Maven plugins (continue as a sub-project ???) We'll it's Java but the plugins here are only relevant to the 2.x codebase > --- SDO CTS (part of SDO sub-project ???) It depends on what the top level split is intended to be. I'd be happy for this to remain as a separate Java project. Simon
