qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Ross <jr...@apache.org>
Subject Proposal to adjust our source tree layout
Date Mon, 21 Jan 2013 17:17:43 GMT
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: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org


Mime
View raw message