qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rafael Schloming <rafa...@redhat.com>
Subject Re: M4-RC1
Date Wed, 10 Dec 2008 17:56:39 GMT


Jonathan Robie wrote:
> Aidan Skinner wrote:
>> On Wed, Dec 10, 2008 at 7:40 AM, Rafael Schloming <rafaels@redhat.com> 
>> wrote:
>>
>>  
>>> Please have at it:
>>>
>>>  http://people.apache.org/~rhs/qpid-M4-RC1/
>>>     
>>
>> Couple of things:
>>
>> C++ src is still muckle. It probably makes sense for doc/ to be split
>> out to a seperate artifact. The docs are really nice though. ;)
>> C++ src unpacks to qpidc-0.3, 0.4 might be better.
>>
>> qpid-dotnet-M4 should probably be qpid-dotnet-0-8-M4 to be consistent
>> with qpid-dotnet-0-10. It unpacks into cwd rather than creating a
>> subdirectory which is ugly.
>>
>> Java looks good to me except for still having the duplicate libs in
>> management/ but that's not a huge deal, just annoying.
>>
>> You need to put your public key in KEYS.
>>   
> 
> A few more things:
> 
> 1. Need a README.TXT, I'll write one.

Thanks

> 2. The root directory is inconsistent for the archives. When I did an 
> untar ($ tar -xvf filename, for each archive), I got three different 
> root directories:
> 
> qpidc-0.3
> qpid-M4
> qpid-M4-RC1
> 
> It's not at all clear to me what goes in each directory and why. Should 
> there be one common root? This organization would make more sense to me:
> 
> 
> qpid-M4
> - bin - cpp
> - java        - dotnet    - python
> - ruby
> - specs
> - buildtools - gentools
> - etc    - lib  - management   - review

This is definitely an issue, but its no worse than prior releases, and 
too big an item to address for M4.

I think for M5 we should definitely improve the release structure and 
make it consistent across the different sub-projects so that our overall 
release looks a bit less like a random snapshot of distinct projects and 
a bit more like a single cohesive release.

One of the issues here is that each sub-project uses a different version 
number convention, and that is reflected in the release tarballs. The 
cpp broker is version 0.x, the java code is version "Mx", and the python 
and ruby release versions come from the overall release nomenclature (in 
this case M4-RC1). This might make sense if we did independent releases, 
but we don't, so it ends up being confusing.

> 3. The makefiles don't work in cpp/directories. I did a ./bootstrap, 
> then ./configure, and got a bunch of compile errors, I think because the 
> directories have moved around.

I don't think you're supposed to do ./bootstrap for the dist tarball. 
I'm not sure if doing it is expected to work or not though. If not, then 
possibly this is something that should be clarified in the README. Maybe 
one of the cpp experts could comment?

--Rafael


Mime
View raw message