If we were going to move them down a level then I wouldnt pick what seems like a fairly random new name for the folder, especially if the motiviation is to make things clearer. Thats definitely not where names like trident/triton take me, and I have no idea where it would take someone new coming along looking for all the existing stuff that is as far as they are concerned just now, what Qpid is.
I dont have anything to suggest myself right now, but the end state example doesnt particularly inspire me as easier to work with either, requiring lots of different chekouts to stay out to date on the different components, or alternatively a massive amount of playing with svn folder depths on checkouts (which im not sure play nice with git-svn anyway). Regarding the existing extra 'inner qpid folder', we have discussed removing it in the past and decided not to simply because it had been that way for so long, isnt really doing any harm , and doesnt seem worth the hassle for merges, breaking peoples existing checkouts etc. Its presence doesnt particularly bother me either FWIW, its easy enough to ignore (though I actually dont, I checkout 'trunk') Robbie On 21 January 2013 17:17, Justin Ross <[email protected]> wrote: > Qpid has undergone some important changes in the last year. "What > Qpid is" has shifted. In particular, the introduction of Proton is > important because it means that Qpid is not just (mainly) the stuff > under repos/asf/qpid/trunk/qpid anymore. > > One point of confusion (and certainly not the only! more emails to > follow) is the source tree. Here's what we have now: > > jross@localhost qpid$ svn ls https://svn.apache.org/repos/asf/qpid/ > branches/ > doap_qpid.rdf > proton/ > site/ > tags/ > trunk/ > > Some of those things are alike, and some are not. Since the > introduction of "proton" and "site" at this level, we've begun to mix > the long-existing qpid/$language model with the new one that has > distinct and independently releasable modules. > > The first step I propose to clean things up is pretty simple. Take > qpid/{branches,tags,trunk} and move them under a name, just as proton > is organized. > > In other words, move to this: > > qpid/ > doap_qpid.rdf > site/ > proton/ > trunk/ > branches/ > tags/ > trident/ - qpid as we have known it > trunk/ > branches/ > tags/ > > Queue naming debate, ;). I chose "trident" for my illustration > because I like how it sounds. I would also take this opportunity > eliminate the extra qpid (die repos/asf/qpid/trunk/*qpid*). > > After that step, I see it evolving over time as in the following example: > > qpid/ > doap_qpid.rdf > site/ > proton/ > triton/ > --- > jms/ - a new jms implementation powered by proton > janet/ - a new home for the java tree, migrated from triton/trunk/java > casper/ - a new home for the cpp tree, migrated from triton/trunk/cpp > > This is merely an illustration of what I would consider correct under > this new scheme. I've included the last two to show how I think we > might begin to move things out of triton (which is more or less the > old qpid model as is) and into new top-level modules. > > The names under qpid/ should not in my opinion be brands unto > themselves; "Qpid" is our brand, and Qpid has named components. They > are simply distinct modules with defined interfaces and dependencies. > They *can* be released independently, and in some cases we would have > reason to do so, but in general I think creating one release > distribution is preferable. > > Thanks! > Justin > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
