On 22 January 2013 09:55, Rob Godfrey <[email protected]> wrote:
> 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. > Regarding that thread, I've just created a wiki page listing some of the build system / directory layout requirements that have been mooted: https://cwiki.apache.org/confluence/display/qpid/Proton+build+system+requirements These potential requirements may apply to the broader Qpid project, so any opinions would be very welcome. Phil > -- 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] > > > > >
