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
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).
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.
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.
How do we want it to work? How should we decide?
Justin
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
