You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Martin Ritchie <ri...@apache.org> on 2007/04/20 09:39:00 UTC
SVN reorganisation.
Qpid-ians,
We've been talking for a while now about interop testing and how the
project members can become quite 'silo-ed' in their language of choice
(I know I've made more than one change to the spec file that broke the
C++, sorry).
I'd like to know what everyone's opinion was on a reshuffle of the svn
code. I think that we might be able to get away from our 'silos' be
breaking the project by function not implementation. It should allow
us to break the ties between client and broker implementations such
has developed (out of necessity) for the java code base.
I like to think that in developing 0-10 (and beyond) with the possible
introduction of a common API across all languages (as is being
discussed on another thread) it may make it easier for one developer
to apply the same bugfix/improvement across multiple language
implementations, or at least add in a comment place holder pointing to
the JIRA.
I know it may be a real pain but as we have a brief break between
deciding what the next AMQP version to push forward with is we have a
rare opportunity to do this setting us up for the future.
It might even allow us to do some interesting things such as create
shared libraries between languages, like a high speed c++ framing lib
that can be used in the java via JNI.
The thinking was something along the lines of:
broker
qpidc
qpidj
...
client
qpid.net
qpidc
qpidj
qpidpy
qpidr
common
qpidc
qpidj
management
qpidc
qpidj
qpidjmx
...
spec
gentools
--
Martin Ritchie
Re: SVN reorganisation.
Posted by Marnie McCormack <ma...@googlemail.com>.
Hi All,
Martin - thanks for taking the time to think about how we could be less
bunkered :-)
'Fraid I agree with the others that the svn revamp is probably not a good
way to go, sorry.
However, it has prompted a really useful discussion about how we might
achieve better clarity around requirements/testing/traceability/project
goals.
This has always been a tricky process, at least in goal setting terms, as
we're not driven by a common commecial goal as we would be a for-profit
project environment. Makes it quite hard sometimes to agree the scope of
things and so we've tended to be more organic I guess.
However, I do still think there's value to be had in defining a set of
requirements, even if we just scrub up our JIRAs and scope them for M3. I've
always been heavily in favour of describing the matching tests in any
resolution details too (not necessarily test driven, but at least test
proven ... not that I'm claiming the moral high ground in any way).
I also think we ought to consider a change to our lifecycle for JIRAs with
the developer completing the work handing over to another developer to test
and 'close' the JIRA. This should improve project quality imho !
I guess our first focus should be building M2 and then we should, as Martin
suggests, take the chance to look at where we are vs where we want to be,
both in project features/code maturity/test coverage/interop terms but also
from an incubator graduation perspective (project surround etc).
Bfn,
Marnie
On 4/23/07, Martin Ritchie <ri...@apache.org> wrote:
>
> On 23/04/07, Alan Conway <ac...@redhat.com> wrote:
> > On Fri, 2007-04-20 at 21:11 +0100, Robert Godfrey wrote:
> > > Hmmm... How do you test your tests are testing the right thing?
> > >
> > > 1. write requirement in English
> > > (1a. agree on requirement)
> > > 2. write test
> > > 3. write code that is going to be tested :-)
> > >
> > Absolutely, you can't map requirements to tests until you know what the
> > requirements are.
> >
> > > I've seen so many tests that tests that the code does what it does...
> > > Verifying requirements, particularly with people who don't read/write
> code
> > > is a valuable exercise in itself. The AMQP spec is obviously our
> major set
> > > of requirements, however we also have Qpid specific requirements.
> >
> > Again absolutely. In an ideal world developers would write unit tests
> > for their code, *users* would write acceptance tests for requirements.
> > I've never seen that happen in real life, but we have quite a few Qpid
> > team members from user organizations which is good, so hopefully we can
> > at least pick up some good quality user requirements in English and get
> > some developer input on test writing from people close to the action.
> >
> > Cheers,
> > Alan.
>
> I agree that we really need to focus on testing (unit, functional and
> interop). It is interesting to see every one's opinion on a
> reorganisation. I remember the pain we had with our maven
> reorganisation but that was more to do with getting the tool to work.
> I'm not driven to have a particular layout especially when development
> tools these days present everything as one view anyway.
>
> We do currently have an mix between functional and language structure.
> The gentools are for all languages rather than there being a
> c++/gentools or a java/gentools. Thinking about the interop testing
> system that we are in the process of building. I would have thought it
> would have been good to have it together rather than spread across
> language specific folders.
>
>
> Thanks for the thoughts, guess as a group we don't really want to move
> things around just now. As long as we do not force our developers to
> build entire products they do not wish/need with our current setup
> then I have no real problem. Just thought I'd mention it while we had
> a brief pause between AMQP versions.
>
>
> Cheers
> --
> Martin Ritchie
>
Re: SVN reorganisation.
Posted by Martin Ritchie <ri...@apache.org>.
On 23/04/07, Alan Conway <ac...@redhat.com> wrote:
> On Fri, 2007-04-20 at 21:11 +0100, Robert Godfrey wrote:
> > Hmmm... How do you test your tests are testing the right thing?
> >
> > 1. write requirement in English
> > (1a. agree on requirement)
> > 2. write test
> > 3. write code that is going to be tested :-)
> >
> Absolutely, you can't map requirements to tests until you know what the
> requirements are.
>
> > I've seen so many tests that tests that the code does what it does...
> > Verifying requirements, particularly with people who don't read/write code
> > is a valuable exercise in itself. The AMQP spec is obviously our major set
> > of requirements, however we also have Qpid specific requirements.
>
> Again absolutely. In an ideal world developers would write unit tests
> for their code, *users* would write acceptance tests for requirements.
> I've never seen that happen in real life, but we have quite a few Qpid
> team members from user organizations which is good, so hopefully we can
> at least pick up some good quality user requirements in English and get
> some developer input on test writing from people close to the action.
>
> Cheers,
> Alan.
I agree that we really need to focus on testing (unit, functional and
interop). It is interesting to see every one's opinion on a
reorganisation. I remember the pain we had with our maven
reorganisation but that was more to do with getting the tool to work.
I'm not driven to have a particular layout especially when development
tools these days present everything as one view anyway.
We do currently have an mix between functional and language structure.
The gentools are for all languages rather than there being a
c++/gentools or a java/gentools. Thinking about the interop testing
system that we are in the process of building. I would have thought it
would have been good to have it together rather than spread across
language specific folders.
Thanks for the thoughts, guess as a group we don't really want to move
things around just now. As long as we do not force our developers to
build entire products they do not wish/need with our current setup
then I have no real problem. Just thought I'd mention it while we had
a brief pause between AMQP versions.
Cheers
--
Martin Ritchie
Re: SVN reorganisation.
Posted by Alan Conway <ac...@redhat.com>.
On Fri, 2007-04-20 at 21:11 +0100, Robert Godfrey wrote:
> Hmmm... How do you test your tests are testing the right thing?
>
> 1. write requirement in English
> (1a. agree on requirement)
> 2. write test
> 3. write code that is going to be tested :-)
>
Absolutely, you can't map requirements to tests until you know what the
requirements are.
> I've seen so many tests that tests that the code does what it does...
> Verifying requirements, particularly with people who don't read/write code
> is a valuable exercise in itself. The AMQP spec is obviously our major set
> of requirements, however we also have Qpid specific requirements.
Again absolutely. In an ideal world developers would write unit tests
for their code, *users* would write acceptance tests for requirements.
I've never seen that happen in real life, but we have quite a few Qpid
team members from user organizations which is good, so hopefully we can
at least pick up some good quality user requirements in English and get
some developer input on test writing from people close to the action.
Cheers,
Alan.
Re: SVN reorganisation.
Posted by Robert Godfrey <ro...@gmail.com>.
On 20/04/07, Alan Conway <ac...@redhat.com> wrote:
>
> On Fri, 2007-04-20 at 18:24 +0100, Robert Godfrey wrote:
> > I would add that at a higher level the best way to get feature choerence
> is
> > to use a common set of requirements :-)
>
> Hear hear! And the best kind of requirements are executable
> requirements, aka: tests. If you want common behavior you have to test
> for it.
Hmmm... How do you test your tests are testing the right thing?
1. write requirement in English
(1a. agree on requirement)
2. write test
3. write code that is going to be tested :-)
I've seen so many tests that tests that the code does what it does...
Verifying requirements, particularly with people who don't read/write code
is a valuable exercise in itself. The AMQP spec is obviously our major set
of requirements, however we also have Qpid specific requirements.
With a good interop test suite its very easy to tell where you are on
> each component: which tests does pass? Its easy to tell how close you
> are to release - how many tests still fail? Its easy to prepare the list
> of supported features - which features do we test?
>
> Implementing a good interop test framework, mapping our requirements to
> test cases and implementing those tests across all languages is the most
> important next step towards a coherent project.
Yes agreed.
Cheers,
Rob
Cheers,
> Alan.
>
>
Re: SVN reorganisation.
Posted by Alan Conway <ac...@redhat.com>.
On Fri, 2007-04-20 at 18:24 +0100, Robert Godfrey wrote:
> I would add that at a higher level the best way to get feature choerence is
> to use a common set of requirements :-)
Hear hear! And the best kind of requirements are executable
requirements, aka: tests. If you want common behavior you have to test
for it.
With a good interop test suite its very easy to tell where you are on
each component: which tests does pass? Its easy to tell how close you
are to release - how many tests still fail? Its easy to prepare the list
of supported features - which features do we test?
Implementing a good interop test framework, mapping our requirements to
test cases and implementing those tests across all languages is the most
important next step towards a coherent project.
Cheers,
Alan.
Re: SVN reorganisation.
Posted by Robert Godfrey <ro...@gmail.com>.
> So lets think about what we really want in terms of coherence:
> - interop
> - feature coherence
> - consistent "user experience"
> - coherent packaging
>
> All these can be tackled by "meta projects" that combine contributions
> from each language into the desired result. We need the discipline as
> developers to insure that we take account of these meta projects when we
> make changes to any given codebase. It certainly would be a good thing
> if people work on more than one codebase but I don't think it's
> productive to force that on people who can't/don't want to.
>
> Interop: the *only* way to get interop is to run a daily interop test
> suite and treat interop failures as trunk failures for *every* language
> involved. Every language will be required to pass the interop test suite
> to be considered functional. This is already starting to get underway.
>
> Feature coherence: the best way to get feature coherence is to have a
> comprehensive cross-language feature test suite and require projects to
> pass it for every feature they claim to support. We already have a
> pretty decent cross-language broker test suite in the python tests. I
> anticipate this will develop and there be some synergy with the interop
> test suite work.
I would add that at a higher level the best way to get feature choerence is
to use a common set of requirements :-)
I think we need more project co-ordination about i) what we are trying to
achieve in each release and ii) how we go about achieving it. Certainly
there is little visibility on this list as to that. Pulling together the M2
release makes it clearer how disparate the different elements have become.
For M3 I would hope that we set out at the start to define a scope, and try
to pull together those things which we think should be designed jointly by
the C++ and Java communities, and those things which should be completely
language specific.
Personally I think the C++ and Java broker developers can work/design almost
completely independently if they so desire. I think there should be a high
degree of interaction between the client library developers. Contrary to
your experience Alan, I am finding a large number of people who wish to use
more than one client library technology.
It would be good for all of us I think if we all had visibilty on where we
are with each client library, and where we are going. The vote on M2
revealed a great deal uncertainty from the committers as to where the
different client libraries were at.
Packaging: decide what packages we want and write the infrastructure to
> assemble them, with each project making its contribution. I suspect
> packaging along language lines will be what most users want, but there's
> nothing to preclude packaging along functional lines if people want that
> too. There's no point trying to organise the code in terms of how we
> plan to package it because we will certainly want to package it in more
> than one way. There's also no point in trying to create RPMs with Maven
> or POMs with Makefiles. Do each task with the most appropriate tools and
> assemble the result.
Agreed... but we should also be careful to properly separate those things
which are separate. The Java Broker and Java Client should be built
separately IMHO. They are each, independently, dependent upon the Java
common library. Always building client and broker together gives one the
impression that they are tied. They should not be. [However it is much
more convenient for me as primarily a Java developer, to always build all
the Java.]
This is a mindset thing. There is (or should not be) a "Java implementation
of Qpid" or a "C++ implementation of Qpid". There is a Java broker, a C++
broker, a Java client, a C++ client, a .NET client, a Python client...
etc...
Consistent "user experience": Usability is more important than
> consistency. Where consistency and usability conflict, usability should
> win every time. It's more important to provide the best solution to each
> environment than a consistent set of solutions that are a bit crappy for
> one or more environments.
>
> For brokers, the users experience is mainly covered by interop &
> features. Configuration and deployment are certainly areas where we can
> look at greater alignment, but Unix sysadmins don't like XML, with good
> reason. Java deployers don't like binaries and shell scripts, with good
> reason. We should give each what they want.
Hmmm... this Java developer is actually quite keen on shell scripts and not
at all fond of XML... :-) Actually I think configuration is less important
than things like consistent log messages...
For clients, it is better to provide an excellent API in each langauge
> than a consistent API that is a bit crap in some or all langauges.
> Relatively few users work in multiple languages. AMQP has a strong
> enough conceptual framework to ensure that all clients will be built on
> the same concepts. Beyond that they should be designed to best suit the
> programmer of the given language.
>
> A large part of CORBA's downfall was the literal translation of
> interfaces born of C++ into other languages. Java developers _hated_
> CORBA APIs, and with good reason. The Java Remote APIS were much better
> *for Java*. Even as a professed die-hard C++/CORBA bigot, I prefer
> Java's Remote interfaces when writing Java code because they're so much
> simpler to use.
>
> Splitting every language into micro projects along functional lines does
> absolutely nothing to address any of the consistency issues, it just
> makes life a bit harder and slower for all the developers. So lets focus
> on the real issues: filling out python functional tests, building the
> interop framework, building a langauge-neutral framework to test
> clients, better defining what we want to package and writing
> infrastructure to it and so on.
And defining what is the scope for a release up front :-)
The code structure we already will serve us well.
We shall see... Ultimately wether the directory structure is
<function>/<language> or <language>/<function> matters little as long as I
can build a C++ client without building the C++ broker....
-- Rob
Cheers
> Alan.
>
>
Re: SVN reorganisation.
Posted by Alan Conway <ac...@redhat.com>.
On Fri, 2007-04-20 at 15:49 +0100, Robert Godfrey wrote:
> On 20/04/07, Andrew Stitcher <as...@redhat.com> wrote:
> >
> > Speaking from the perspective of the C++ implementation, I'm not sure
> > this would be helpful:
>
>
> Not necessarily helpful to us developers... true... however in terms of
> thinking what the actual packages and deliverables from this project are.
> If we look at this from a "Qpid" perspective, we might want to think about
> setting requirements for the "client" project and requirements for the
> "broker" project.
Absolutely agree with the sentiment, but not at all agreed that the
breakdown Martin suggests is the way to a achive it. In past lives I
have been on two major projects offering equivalent functionaliy in C++
and Java. One had clearly separated C++/Java codebases. The other had a
hybrid C++/Java build system split on functional lines (it even built
hybrid JNI/C++ code.) The first was *much* more successful at delivering
consistency across languages. There are many reasons for that but I can
assure you from bitter, bitter personal experience that mixing up
languages did _absolutely nothing_ to help make the second project more
consistent.
So lets think about what we really want in terms of coherence:
- interop
- feature coherence
- consistent "user experience"
- coherent packaging
All these can be tackled by "meta projects" that combine contributions
from each language into the desired result. We need the discipline as
developers to insure that we take account of these meta projects when we
make changes to any given codebase. It certainly would be a good thing
if people work on more than one codebase but I don't think it's
productive to force that on people who can't/don't want to.
Interop: the *only* way to get interop is to run a daily interop test
suite and treat interop failures as trunk failures for *every* language
involved. Every language will be required to pass the interop test suite
to be considered functional. This is already starting to get underway.
Feature coherence: the best way to get feature coherence is to have a
comprehensive cross-language feature test suite and require projects to
pass it for every feature they claim to support. We already have a
pretty decent cross-language broker test suite in the python tests. I
anticipate this will develop and there be some synergy with the interop
test suite work.
Packaging: decide what packages we want and write the infrastructure to
assemble them, with each project making its contribution. I suspect
packaging along language lines will be what most users want, but there's
nothing to preclude packaging along functional lines if people want that
too. There's no point trying to organise the code in terms of how we
plan to package it because we will certainly want to package it in more
than one way. There's also no point in trying to create RPMs with Maven
or POMs with Makefiles. Do each task with the most appropriate tools and
assemble the result.
Consistent "user experience": Usability is more important than
consistency. Where consistency and usability conflict, usability should
win every time. It's more important to provide the best solution to each
environment than a consistent set of solutions that are a bit crappy for
one or more environments.
For brokers, the users experience is mainly covered by interop &
features. Configuration and deployment are certainly areas where we can
look at greater alignment, but Unix sysadmins don't like XML, with good
reason. Java deployers don't like binaries and shell scripts, with good
reason. We should give each what they want.
For clients, it is better to provide an excellent API in each langauge
than a consistent API that is a bit crap in some or all langauges.
Relatively few users work in multiple languages. AMQP has a strong
enough conceptual framework to ensure that all clients will be built on
the same concepts. Beyond that they should be designed to best suit the
programmer of the given language.
A large part of CORBA's downfall was the literal translation of
interfaces born of C++ into other languages. Java developers _hated_
CORBA APIs, and with good reason. The Java Remote APIS were much better
*for Java*. Even as a professed die-hard C++/CORBA bigot, I prefer
Java's Remote interfaces when writing Java code because they're so much
simpler to use.
Splitting every language into micro projects along functional lines does
absolutely nothing to address any of the consistency issues, it just
makes life a bit harder and slower for all the developers. So lets focus
on the real issues: filling out python functional tests, building the
interop framework, building a langauge-neutral framework to test
clients, better defining what we want to package and writing
infrastructure to it and so on. The code structure we already will serve
us well.
Cheers
Alan.
Re: SVN reorganisation.
Posted by Gordon Sim <gs...@redhat.com>.
Robert Godfrey wrote:
> the Java client should no more be tied to the Java broker than it
> should be to the C++ broker.
[...]
> The real discussion is not on the filesystem layout but on project
> organisation :-)
Yes, I agree with both these points.
Re: SVN reorganisation.
Posted by Robert Godfrey <ro...@gmail.com>.
On 20/04/07, Gordon Sim <gs...@redhat.com> wrote:
>
> Robert Godfrey wrote:
> > At the moment the Java and C++ projects are fairly distinct to the
> > point of being barely interoperable.
>
> I agree that needs some work.
>
> > I think we might be in a better position if we organise ourselves on
> > functional rather than technical lines.
>
> I'm not convinced re-organising the directory would improve things.
>
> > At the moment I do wonder what coherence there is to Qpid as a
> > whole...
>
> Again, I agree, but this is to me more about coordination, communication
> and actually spending time aligning the codebases where that is feasible
> and sensible. I don't think the particular nesting of directories makes
> much of a difference. In fact it would seem to use time better spent on
> e.g. interop tests or defining common client api principles.
>
> [...]
> > But it is also our way of thinking ... we identify ourselves as
> > working on the "C++" or "Java" (or Python, .NET or whatever) rather
> > than thinking about working on the client or the broker or the
> > management console. Since we are never going to have everyone able
> > to work on all codebases, I think at some level it makes sense to
> > organise our project along a functional split.
>
> I see there being several different components. A client component for
> c++, java, c#, python & ruby and broker components for java and c++.
>
> The client and broker components within a particular language tend to
> reuse some code (and e.g. build system scripts etc) between them, making
> it not uncommon for people to work on both. Moving from client to broker
> is simpler in general than moving between languages and I don't see that
> changing with a different layout.
Agreed... it is not about making it easier to move between... if anything
it is about making it harder for people to think in the "Java" or "C++"
silos.
The Java and C++ brokers are substancial projects in themselves. The Qpid
client libraries are separate, and could usefully exist without either
broker. However the Java client should no more be tied to the Java broker
than it should be to the C++ broker. The fact that there is common code
between the java client and java server could be seen as just a sensible
refactoring, but it is not intrinsic either to the client or the broker.
The real discussion is not on the filesystem layout but on project
organisation :-)
-- Rob
Re: SVN reorganisation.
Posted by Gordon Sim <gs...@redhat.com>.
Robert Godfrey wrote:
> At the moment the Java and C++ projects are fairly distinct to the
> point of being barely interoperable.
I agree that needs some work.
> I think we might be in a better position if we organise ourselves on
> functional rather than technical lines.
I'm not convinced re-organising the directory would improve things.
> At the moment I do wonder what coherence there is to Qpid as a
> whole...
Again, I agree, but this is to me more about coordination, communication
and actually spending time aligning the codebases where that is feasible
and sensible. I don't think the particular nesting of directories makes
much of a difference. In fact it would seem to use time better spent on
e.g. interop tests or defining common client api principles.
[...]
> But it is also our way of thinking ... we identify ourselves as
> working on the "C++" or "Java" (or Python, .NET or whatever) rather
> than thinking about working on the client or the broker or the
> management console. Since we are never going to have everyone able
> to work on all codebases, I think at some level it makes sense to
> organise our project along a functional split.
I see there being several different components. A client component for
c++, java, c#, python & ruby and broker components for java and c++.
The client and broker components within a particular language tend to
reuse some code (and e.g. build system scripts etc) between them, making
it not uncommon for people to work on both. Moving from client to broker
is simpler in general than moving between languages and I don't see that
changing with a different layout.
Re: SVN reorganisation.
Posted by Robert Godfrey <ro...@gmail.com>.
On 20/04/07, Andrew Stitcher <as...@redhat.com> wrote:
>
> Speaking from the perspective of the C++ implementation, I'm not sure
> this would be helpful:
Not necessarily helpful to us developers... true... however in terms of
thinking what the actual packages and deliverables from this project are.
If we look at this from a "Qpid" perspective, we might want to think about
setting requirements for the "client" project and requirements for the
"broker" project.
At the moment the Java and C++ projects are fairly distinct to the point of
being barely interoperable. I think we might be in a better position if we
organise ourselves on functional rather than technical lines.
At the moment I do wonder what coherence there is to Qpid as a whole...
-- Rob
We've just reorganised the C++ source so that it the file layout matches
> the namespace layout. As some interfaces are shared between client and
> broker separating them would cause us a fair bit of pain at build and
> install time.
>
> I do agree that breaking down the silos is a good idea, but I don't
> think this is the way to do it.
>
> Having said that I find that I frequently look at and change the python
> code, so I think the real cause of the separation is that people don't
> know/care about that they don't use.
But it is also our way of thinking ... we identify ourselves as working on
the "C++" or "Java" (or Python, .NET or whatever) rather than thinking about
working on the client or the broker or the management console. Since we are
never going to have everyone able to work on all codebases, I think at some
level it makes sense to organise our project along a functional split.
-- Rob
Andrew
>
> On Fri, 2007-04-20 at 08:39 +0100, Martin Ritchie wrote:
> > Qpid-ians,
> >
> > We've been talking for a while now about interop testing and how the
> > project members can become quite 'silo-ed' in their language of choice
> > (I know I've made more than one change to the spec file that broke the
> > C++, sorry).
> >
> > I'd like to know what everyone's opinion was on a reshuffle of the svn
> > code. I think that we might be able to get away from our 'silos' be
> > breaking the project by function not implementation. It should allow
> > us to break the ties between client and broker implementations such
> > has developed (out of necessity) for the java code base.
> >
> > I like to think that in developing 0-10 (and beyond) with the possible
> > introduction of a common API across all languages (as is being
> > discussed on another thread) it may make it easier for one developer
> > to apply the same bugfix/improvement across multiple language
> > implementations, or at least add in a comment place holder pointing to
> > the JIRA.
> >
> > I know it may be a real pain but as we have a brief break between
> > deciding what the next AMQP version to push forward with is we have a
> > rare opportunity to do this setting us up for the future.
> >
> > It might even allow us to do some interesting things such as create
> > shared libraries between languages, like a high speed c++ framing lib
> > that can be used in the java via JNI.
> >
> > The thinking was something along the lines of:
> >
> > broker
> > qpidc
> > qpidj
> > ...
> > client
> > qpid.net
> > qpidc
> > qpidj
> > qpidpy
> > qpidr
> > common
> > qpidc
> > qpidj
> > management
> > qpidc
> > qpidj
> > qpidjmx
> > ...
> > spec
> > gentools
> >
> >
> >
>
>
Re: SVN reorganisation.
Posted by Andrew Stitcher <as...@redhat.com>.
Speaking from the perspective of the C++ implementation, I'm not sure
this would be helpful:
We've just reorganised the C++ source so that it the file layout matches
the namespace layout. As some interfaces are shared between client and
broker separating them would cause us a fair bit of pain at build and
install time.
I do agree that breaking down the silos is a good idea, but I don't
think this is the way to do it.
Having said that I find that I frequently look at and change the python
code, so I think the real cause of the separation is that people don't
know/care about that they don't use.
Andrew
On Fri, 2007-04-20 at 08:39 +0100, Martin Ritchie wrote:
> Qpid-ians,
>
> We've been talking for a while now about interop testing and how the
> project members can become quite 'silo-ed' in their language of choice
> (I know I've made more than one change to the spec file that broke the
> C++, sorry).
>
> I'd like to know what everyone's opinion was on a reshuffle of the svn
> code. I think that we might be able to get away from our 'silos' be
> breaking the project by function not implementation. It should allow
> us to break the ties between client and broker implementations such
> has developed (out of necessity) for the java code base.
>
> I like to think that in developing 0-10 (and beyond) with the possible
> introduction of a common API across all languages (as is being
> discussed on another thread) it may make it easier for one developer
> to apply the same bugfix/improvement across multiple language
> implementations, or at least add in a comment place holder pointing to
> the JIRA.
>
> I know it may be a real pain but as we have a brief break between
> deciding what the next AMQP version to push forward with is we have a
> rare opportunity to do this setting us up for the future.
>
> It might even allow us to do some interesting things such as create
> shared libraries between languages, like a high speed c++ framing lib
> that can be used in the java via JNI.
>
> The thinking was something along the lines of:
>
> broker
> qpidc
> qpidj
> ...
> client
> qpid.net
> qpidc
> qpidj
> qpidpy
> qpidr
> common
> qpidc
> qpidj
> management
> qpidc
> qpidj
> qpidjmx
> ...
> spec
> gentools
>
>
>
Re: SVN reorganisation.
Posted by Robert Greig <ro...@gmail.com>.
On 20/04/07, Martin Ritchie <ri...@apache.org> wrote:
> I'd like to know what everyone's opinion was on a reshuffle of the svn
> code. I think that we might be able to get away from our 'silos' be
> breaking the project by function not implementation. It should allow
> us to break the ties between client and broker implementations such
> has developed (out of necessity) for the java code base.
> The thinking was something along the lines of:
>
> broker
> qpidc
> qpidj
> ...
> client
> qpid.net
> qpidc
> qpidj
> qpidpy
> qpidr
> common
> qpidc
> qpidj
> management
> qpidc
> qpidj
> qpidjmx
> ...
> spec
> gentools
>From a practical SVN perspective I'm not sure how this will work.
For example, you frequently want to treat a broker, client and common
for a given language as a single package and then be able to tag and
branch them .With the above would we not have to either grab the whole
thing or create separate branches for each of client/broker/common.
>From a practical perspective due to differing resourcing levels on
each language we are going to want to release different languages at
different times. I agree it's not ideal but if we only have a couple
of developers working on .NET then we can't expect it to progress as
rapidly as Java.
Having said that, like everyone else I agree we need to focus more on
interoperability - but this has been tricky to date in no small part
due to the protocol not evolving rapidly enough to support the
features our users demand (e.g.full JMS compatibility). I would hope
and expect that as the protocol matures and stabilises we will be able
to make progress on interop.
RG
Re: SVN reorganisation.
Posted by Robert Greig <ro...@gmail.com>.
On 20/04/07, Martin Ritchie <ri...@apache.org> wrote:
> I'd like to know what everyone's opinion was on a reshuffle of the svn
> code. I think that we might be able to get away from our 'silos' be
> breaking the project by function not implementation. It should allow
> us to break the ties between client and broker implementations such
> has developed (out of necessity) for the java code base.
> The thinking was something along the lines of:
>
> broker
> qpidc
> qpidj
> ...
> client
> qpid.net
> qpidc
> qpidj
> qpidpy
> qpidr
> common
> qpidc
> qpidj
> management
> qpidc
> qpidj
> qpidjmx
> ...
> spec
> gentools
>From a practical SVN perspective I'm not sure how this will work.
For example, you frequently want to treat a broker, client and common
for a given language as a single package and then be able to tag and
branch them .With the above would we not have to either grab the whole
thing or create separate branches for each of client/broker/common.
>From a practical perspective due to differing resourcing levels on
each language we are going to want to release different languages at
different times. I agree it's not ideal but if we only have a couple
of developers working on .NET then we can't expect it to progress as
rapidly as Java.
Having said that, like everyone else I agree we need to focus more on
interoperability - but this has been tricky to date in no small part
due to the protocol not evolving rapidly enough to support the
features our users demand (e.g.full JMS compatibility). I would hope
and expect that as the protocol matures and stabilises we will be able
to make progress on interop.
RG