qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rafael Schloming <rafa...@redhat.com>
Subject Re: [VOTE] Qpid M2 Release
Date Wed, 07 Mar 2007 19:01:43 GMT
Kevin Smith wrote:
> Rafael Schloming wrote:
>> Martin Ritchie wrote:
>>> Can the Authors of the Ruby/Python speak for its current state? If we
>>> are to release python and ruby clients then all the clients should
>>> interop.
>>
>> Python should be good to go once the interop issues mentioned in 
>> another thread are addressed. To my knowledge it's been a few months 
>> since anyone has done anything with Ruby, so I'm rechecking whether it 
>> still works now. I'll send an email when I have more info.
>>
>> --Rafael
>>
>>>
>>> On 06/03/07, Das, Kapali Tejeswar <tejeswar.das@iona.com> wrote:
>>>> +1 from me.
>>>>
>>>> Regards
>>>> Tejeswar
>>>>
>>>> -----Original Message-----
>>>> From: Marnie McCormack [mailto:marnie.mccormack@googlemail.com]
>>>> Sent: Tuesday, March 06, 2007 6:41 AM
>>>> To: qpid-dev@incubator.apache.org
>>>> Subject: [VOTE] Qpid M2 Release
>>>>
>>>> Hi All,
>>>>
>>>> I there are now some compelling motivations for releasing an M2.
>>>>
>>>> I'd like to propose an M2, to include:
>>>>
>>>> - Java Broker
>>>> - Java Client
>>>> - C++ Broker
>>>> - C++ Client
>>>> - .NET Client
>>>>
>>>> I can speak with more authority on some areas than others, but 
>>>> here's my
>>>> quick summary of major changes since M1:
>>>>
>>>> - the Java Client/Broker pass the SUN TCK making our offering in this
>>>> area
>>>> much more attractive
>>>> - the persistence rework on the Java broker is complete and
>>>> significantly
>>>> advances the functionality
>>>> - the C++ broker is ready for some real use and should get out there 
>>>> for
>>>> early adopters
>>>> - the C++ client interop has been worked upon/used quite a bit in dev
>>>> - the .NET client has been substantially extended and interop improved
>>>> - and a lot of JIRAs resolved on all front, bugs and improvements
>>>>
>>>> We also need to introduce a new AMQP protocol version across the board,
>>>> and
>>>> it makes good sense to get M2 out there before we do this.
>>>>
>>>> I think we also considered releasing the python and ruby for M1, but
>>>> there
>>>> were gaps in the docs etc. I'm happy that we should include these in 
>>>> M2,
>>>> assuming someone is willing to contribute the required docs etc (and
>>>> they
>>>> interop).
>>>>
>>>> I'd like to structure our initial vote as follows:
>>>>
>>>> - M2 Release including Java, C++ and .NET
>>>> - Additionally python and ruby
>>>>
>>>> Let's vote first to get an idea of the consensus and then we can create
>>>> threads on release manager, dates, code freezes etc.
>>>>
>>>> We have quite a bit of work to consider/do prior to release including
>>>> interop testing, docs etc. Happy to raise JIRAs (or assist the release
>>>> manager) for an M2 set of tasks if we proceed.
>>>>
>>>> *Votes please :*
>>>>
>>>> *[ ] M2 Release inc Java, C++, .NET
>>>> [ ] Python and Ruby clients
>>>>
>>>> *And here is my +1 for all both.
>>>>
>>>> Regards,
>>>> Marnie
>>>>
>>>
>>>
>>
> If there's any tasks you need help with the Ruby broker, let me know. 
> I've been meaning to get into that code but haven't had the time. Now 
> that my day job is lightening up, I'd be willing to help out.

Thanks for the offer. Here's a few things off the top of my head.

First of all the ruby implementation isn't a broker, just a client, so 
obviously if you have any need for or interest in a full fledged ruby 
broker there is a lot left to do. ;)

The 0-9 python code actually has a skeletal server framework that allows 
you to easily script various pieces of broker side functionality without 
actually writing a full fledged broker. This is something that I'd like 
to see ported to ruby as well at some point.

There will also be updates necessary for 0-9/0-10, but those are still 
up in the air at the moment.

Another thing that would benefit the code a lot would be to actually use 
it to implement something vaguely resembling a real app to make sure 
that we actually have reasonable API coverage for AMQP functionality.

And finally if none of those things excite you there is always room for 
more test coverage. ;)

--Rafael

Mime
View raw message