On 24/01/07, Carl Trieloff <[EMAIL PROTECTED]> wrote:
Steve Vinoski wrote:
>
> So again, development items that cause significant disruption and
> churn, such as the maven switchover, persistence work, and protocol
> changes like 0-9, belong on a branch until stable, at which point they
> should be merged.
>
I think that we might be talking past each other --- the goal is to get
the branch clean before merging. Thus no curn on the trunk. Whether to
merge or not is another matter - as the work has been voted in - and the
changes that Cisco requested is basically just another field to WIP that
seems like forward progress to me. Also note that we have other changes
on the trunk that are not in the spec yet / or even proposed which I
believe some other parties are going to propose. So if we have work that
has not been voted on yet, we can surely have work that has been voted
on and is marked for final inclusion in 0-10.
I thought the WIP had just be 'checkpointed' i.e. agreement in the
direction that the WIP is going but that doesn't guarantee inclusion
for 0-10. It is true that there are non spec compliant changes on
trunk to enable JMS over AMQP but these changes should only cause
problems when trying to interact with a Qpid JMS client. If the Qpid
Java implementation had a separation between AMQP and JMS then an AMQP
compliant Qpid Java client should be possible. Whither it is useful to
have is a different question. As I believe anyone using the Qpid Java
client will want to use the JMS API. That said, the Qpid clients
should all be able to interact and exactly how JMS and AMQP should
interoperate still needs to be worked out by the AMQP people.
I also strongly believe that we should create a JIRA category for spec
issues in qpid, so that we can keep track if issues that we need to work
around so that they can all be brought back to the AMQP Working Group
and then once resolved we can update qpid to match and the resolution
and close the JIRA issue
Carl.
--
Martin Ritchie
