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]
