I dont really see the proposed end state outlined as being full of equivalent things. Site gets a top level dir because its effectively a sub project, and burying it within any other sub folder would seem a little strange. Proton gets a top level dir because it is a sub-project with its own release cycle. The same isnt true of the other pre-existing bits, and until we decide that thigns like jms clients and caspers have their own indepenant release cycles I dont think I would structure the repository in such a way that so strictly segregated their development in the way that having independant trunks for each component does.
Having a look around, there are other projects with structures somewhat similar to our own, where the main project has the trunk etc at the top level along with any sub-projects and their site. Of the others, one example would be the Maven project whereby they have maven1, maven2, and maven3 dirs (with trunk, branches, etc) directly under the maven parent dir plus site and other dirs as their peers. If we wanted a sub-dir, then in similar fashion qpid/qpid would actually the most obvious choice for me. Personally, I'd leave it the way it is now and concentrate on larger issues such as things causing user confusion, e.g improving the website and communicating about things like what Proton is and where its going. Robbie On 21 January 2013 19: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. > > 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] > >
