On 22 January 2013 17:12, Rafael Schloming <[email protected]> wrote:
> I have directly experienced some of the opportunity cost that Justin speaks > of. I once observed someone (a director level decision maker) being very > surprised to be informed that qpid is actually *two* brokers. He had ruled > it out as an option entirely until he found out that we actualy have a Java > broker that speaks multiple versions of the protocol. Yes - this is the sort of thing that I think we need to make clear from the starting point of the website. What components we have, what the can be used for, and what components we are looking to build. I think the general idea of having other libraries and services at the same level as proton makes a lot of sense... however given the way that the Java tree is constructed (I can't speak for the C++), it'd be a little hard to arrange right now and having a top level entry corresponding to "java" probably wouldn't help with the silo-ing which you describe below (moreover it really doesn't make much sense from a user perspective either). So a directory structure which had top level entries something more like ** proton ** Java broker ** C++ broker ** JMS client ** Messaging API client(s) ** AMQP proxy ** AMQP router ** Management Console Would definitely make sense (note some entries above may not currently exist, may not end up as distinct components, etc). In order to get the Java side to that sort of state we'd probably first need to sort out the "common" code which is shared between the Java (0.x) client and the broker. Ideally we'd probably want to turn the 0-8/0-9/0-9-1 and 0-10 protocol layers into components (though they'll not be getting much love going forward). that would still leave a fair amount of cruft which is shared but not really AMQP protocol related. Altogether, it would be a fair amount of work, and not something I'd necessarily want to prioritize. > Now while I agree > that the source tree layout is likely not a serious impediment for > developers, I do think it may have an impact in promoting the silo effect > which can obviously propagate beyond developers to our detriment. > > Agreed. One thing I am very keen to avoid is the categorization by language that our current build tree suggests. Top level components should be defined in terms of function rather than language (IMHO), though for some (e.g. a JMS client) language may be implied. (And where a component has multiple languages used, developers in that component should endeavour to be familiar with the build and test process for each such language). -- Rob > That said, I agree the first step is to get the web site sorted and ensure > we have a shared model of what the structure should be. I think with this > in place and well understood, the case to change the layout to something > more sensible will be compelling. FWIW, I think the proposed layout is > probably very close to where we should end up, the total number of top > level components notwithstanding. > > --Rafael > > On Tue, Jan 22, 2013 at 9:49 AM, Robbie Gemmell <[email protected] > >wrote: > > > On 22 January 2013 13: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. > > > > > > > > If you are looking into a new website design, now would probably be a > good > > time to look at the branding requirements: > > > > http://www.apache.org/foundation/marks/pmcs > > > > 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. > > > > > > > > As with Rob, for me it is a balance between the time taken to get > existing > > stuff to any new structure and what improvement that would bring versus > > spending all that time on different things that could have a bigger > payoff. > > > > Whilst I might not pick what we have now as a new starting point, the > > layout of our source doesnt seem all that confusing to me. Qpid was the > > first 'real project' I ever worked on, and it wasn't a problem figuring > out > > where stuff was. I dont recall seeing many questions on the subject > either, > > whereas the website and documentation (or lack therof) gather/cause many > > and so would be more deliver more rewarding for any effort in my mind. > > > > > > > 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. > > > > > > 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] > > > > > > > > >
