qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aidan Skinner" <ai...@apache.org>
Subject Re: M3 and some community clean-up
Date Wed, 18 Jun 2008 15:55:17 GMT
On Wed, Jun 18, 2008 at 4:29 PM, Rajith Attapattu <rajith77@gmail.com> wrote:

> On Tue, Jun 17, 2008 at 5:18 PM, Aidan Skinner <aidan@apache.org> wrote:
>
>> On Tue, Jun 17, 2008 at 5:38 PM, Gordon Sim <gsim@redhat.com> wrote:
>>
>> > Perhaps even that is over ambitious for M3 though, depending on the dates
>> > chosen. I guess my question is whether there is benefit in setting those
>> > dates such that we can improve this matrix for M3 or whether an earlier
>> M3
>> > is warranted.
>>
>> Personally, I'd like to get M3 out soonish, given it's our first
>> release from trunk for a while (cough) and I'm concerned about stuff
>> rotting there (cough, cough). I could be convinced updating the
>> clients would be worth it if it could be done quickly(ish), but I'd
>> tend towards getting M3 out and everybody working together on trunk
>> before hacking 0-10 into .Net. I don't know enough about the Ruby
>> client to have a feel for how quickly that could be done, IIRC it's
>> quite thin and close to the spec so might be substantially easier.
>>
>
> Aidan if we do this, then again we will end up  with the Java broker and
> .NET client lagging behind.
> This will add further to the confusion.

Adding 0-10 support to the Java broker will take Some Time, and I'd
like to get a release out this year. ;) Ideally 2.

> I think from an end user POV what is important is that when we make the 0-10
> release all clients and brokers work with each other.

1. I don't think M3 has to be 'the 0-10 release'
2. Having all the clients talk is a more realistic, seperate
proposition from "everything speaks 0-10"
3. I don't think M3 has to be that release either, although it would be nice.

> IMO even if it takes time, we should aim to do this for M3.
> Once we achive this baseline then we can do more frequent releases to cover
> bug fixes/enhancements etc.

I don't see what value holding our code on trunk has. We need to do
more frequent releases, full stop. We keep finding reasons not to
release until this, that or the other are done, which is somethign
that all software projects share in common - people have an urge to
focus on the shiney newness, rather than delivering actual product.

Release early, release often.

> The key value proposition of AMQP is interoperability and if we don't aim
> for that (at least with our own releases)  we are not making full use of
> AMQP.

It is, we should and we're not. I don't disagree with any of that, and
I think we should be doing more testing with the other AMQP
implementations and aiming for full, seemless interop there as well.

I just don't think that it's necessary to hold up our next release
until then, provided it's clearly documented.

- Aidan
-- 
aim/y!:aidans42 g:aidan.skinner@gmail.com
http://aidan.skinner.me.uk/
"We belong to nobody and nobody belongs to us. We don't even belong to
each other."

Mime
View raw message