Sorry, I mixed "trident" and "triton" in my examples. I mean them to stand for the same thing. I've been mulling both names as contenders.
On Mon, Jan 21, 2013 at 12:17 PM, 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]
