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