On 22 January 2013 14:11, Justin Ross <[email protected]> wrote: > This isn't even a first draft, but to show good faith, I am working on > this: > > http://people.apache.org/~jross/transom/output/ > > I'll have a better draft and a more proper introduction later, with an > outline of what Qpid's components are and how they fit together. > > Thanks Justin - much appreciated! I think we should probably try to come up with some blurb on AMQP as well as simply pointing to the AMQP site.
To me Apache Qpid should be all about AMQP (in particular about AMQP 1.0). > In my opinion, we are underestimating the significance of things such > as source tree layout, mailing list names, and such. They are not > merely internal details. When I go to understand a project, those are > precisely the things I look at. I think leaving Qpid in a confused > state, such as the state it is in right now, is not really worth > tolerating. > > I agree they are important, just that the cost vs. benefit of trying to change the directory structure of the existing components right now does not add up for me. For all new components then I think we should have a template of how those are added and agreement on what a sensible source code directory structure looks like / what our requirements of such are. I'm also open to the idea of trying to migrate our existing components into such a structure, however my knowledge of the Java build is such that I wouldn't expect any such work to be quick or easy... Simply moving the entire java build tree up to be a peer of the proton component doesn't seem like it would help our users any more than our current structure. Personally as a user, if there are clearly available source / binary tarballs for downloading with good documentation as to what they contain, then I would choose those over checking out the repo. There's probably a stronger case for changing the mailing lists in that the cost of change is probably low. I just feel its potentially getting a bit bike-sheddy when our main problem is that the content is not there (i.e. the problem is not that the question about "what is proton vs. qpid" was asked on different lists, it's that the answer isn't clear from the website). In other words, that confusion has a significant opportunity cost. > Facing confusion, many people will turn away. Sometimes opportunity > costs are hard to measure. My sense (and I admit this is intuition) > is that in this case, the cost is more than you might think. > > Agreed - personally my feeling is that if we have cycles which we can use to improve the "stickiness" of Qpid, then those cycles should be spent on generating content for the website and keeping the website up to date. Further it would be nice if we actually had things like a roadmap that were clearly visible to people interested in the project. Again such things need to be kept up to date by the project team. In an ideal world I think the directory structure in your head and in my head are probably pretty much the same - but (at least on the Java side) it would take a lot of pain to get there, and I think our limited energies would be better spent on producing AMQP 1.0 libraries and services and updating our website so that people know about our good work and can then download it :) -- Rob > Justin > > On Tue, Jan 22, 2013 at 5:57 AM, Robbie Gemmell > <[email protected]> wrote: > > 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] > >> > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
