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. 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.
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] > > > > >
