On 21 January 2013 20:20, Justin Ross <[email protected]> wrote: > My main goal is to populate the top level with equivalent things. If > we don't, then I think the source tree itself forces you to think > about Qpid with two conflicting frames: Qpid is qpid/{cpp,java,etc.}, > and Qpid is qpid/{proton,$futuremodule,etc.}. > > The funny name is not required. The trouble is I can't think of a > better approach. Can you think of a functional name that works in > this role? I'm open to almost anything except qpid/qpid. > >
While I think we could probably spend some time thinking about the desired end-state of our source tree (and should think about how we can move things such as the Java and C++ Brokers to become peers of Proton in said tree), I'm not sure changing these will fundamentally solve the communication issues around how the components of the project fit together. I think it more important to review our website and our release artefacts. While the source tree is undoubtedly a mess, it will mostly affect ourselves as developers on Qpid. Hopefully we should be aware of the fact that Proton is a sub-project of Qpid, and the fact that the other "sub-projects" currently have a really poor directory structure is just an accident of history. In order to communicate better how Proton and other components make up the Qpid project I think we need to take a good hard look at how we present ourselves through the website, our documentation, and in our mailing lists. If we are to be discussing source code directory structure I would like us to actually agree (and document) what our fundamental requirements are, particularly given the ongoing discussion [1] on the proton mailing list on how we cope with interdependency between different (cross language) sub-components within proton itself. Other points of view / suggestions in that discussion would be most welcome. -- Rob [1] http://mail-archives.apache.org/mod_mbox/qpid-proton/201301.mbox/browser > Justin > > On Mon, Jan 21, 2013 at 1:07 PM, Robbie Gemmell > <[email protected]> wrote: > > 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] > >> > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
