On 25 March 2011 15:04, <[email protected]> wrote: > On Fri, 25 Mar 2011, Robert Godfrey wrote: > > We could insert a sub-project at the top level while still maintaining the >>> existing structure? For example: >>> >>> .../asf/qpid/trunk/qpid/spec >>> .../asf/qpid/trunk/qpid/cpp >>> .../asf/qpid/trunk/qpid/java >>> .../asf/qpid/trunk/qpid/... >>> >>> .../asf/qpid/qpid-amqp/trunk/common >>> .../asf/qpid/qpid-amqp/trunk/cpp >>> .../asf/qpid/qpid-amqp/trunk/java >>> .../asf/qpid/qpid-amqp/trunk/... >>> >>> This is a fairly common idiom. ActiveMQ do this, for instance : >>> >>> http://svn.apache.org/viewvc/activemq/trunk/ >>> http://svn.apache.org/viewvc/activemq/activemq-protobuf/trunk/ >>> >>> >> Andrew. >> >> >> Yeah - I think this is my preferred solution. >> >> To my mind there's probably scope for things that are currently under >> "trunk" to migrate to fully blown sub-projects over time, but I think the >> immediate next step would be to introduce the >> >> /asf/qpid/transport/[trunk|branches|...] >> > > I don't object to subprojects (indeed, it's attractive in many ways), but I > want us to have the bigger conversation about direction, first. > > The directories under qpid/trunk/qpid are already independent subprojects: > > - They don't share code > > - They don't share a build system or a test entry point > > - They interface among themselves only optionally, just like independent > projects do > > - They are largely worked on by independent groups of people > > Actually, they are not really independent (which makes the situation untenable)... the directories have weird dependencies (possibly even circular - though I haven't checked recently)... and they don't make terribly much sense as independently releasable units. They are generally just broken down by language (which could be seen as a proxy for the group of developers who work on them).
> What they share is apache infrastructure (jira category, mailing lists) and > a release schedule. > > I don't like the pretending. I want qpid to start to move in the direction > of real integration (this has some very tangible benefits), or explicitly > decide that these are independent (in code, apache infrastructure, and > release cycle). > > I agree we need to be clear in stating our goals. In terms of integration my focus would be on the user experience... that, to me, is what makes a coherent project... Our internal development structure can follow our external goals... To me a coherent project would mean that 1) The clients have a common API 2) The brokers have similar functionality, configuration, etc ... and we only need one set of docs to describe them We're getting there (slowly) on 1) but 2) isn't all that great right now. Moreover we're also including a whole lot of other stuff in our builds that essentially should be seen (IMHO) as independent. > Naturally, independent projects can have required dependencies, and under > that plan we can increase our code sharing (relative to what we have now) as > the transport intends to do. > > The downside of independent projects is, in a word, integration cost. > Without a common release, source tree, build system, and test harness, the > difficulty of maintaining a stable, coherent distribution is greater. > > I actually disagree here as I think that the discipline of properly defining the component entities that go into making a release will be a better way of ensuring code sharing and test sharing. At the moment we are siloed by language... but there should be no reason why broker system tests (for instance) are dependent on language. > Indeed, that's the problem we face right now. For instance, it's not easy > *at all* for a qpid developer to test a change to one qpid component across > the others. > > So, to turn the question around... why should (s)he have to? if you are changing the transport you pass your own unit/system tests for that component. If one of the "users" of the transport then finds a bug, it should be reported through JIRA - just as if an external project finds a bug. The problems come about when we have unnecessary coupling between entities that should be distinct. The Java codebase is terrible at this in as much as we run tests that simultaneously test both the client and the broker rather than having separate tests for each. How do we want it to work? How should we decide? > > In my mind there are two aspects Firstly we should all have a common idea about what the goal of the project is, and should all be aiming towards that. Secondly we need define the best structure that allows for each developer to work on the components they wish to work on *without it unduly affecting work elsewhere*. Releasing all of Qpid in a single build/release should be easy if each component is a self-contained and well tested unit. On the other hand (other than at major releases where there have been changes to the interfaces/APIs) there's really no reason to have to release everything at the same time. -- Rob > Justin > > > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:[email protected] > >
