[reSIProcate] 1.0 release candidate

[Byron Campen]

	RFC4475TortureTests is nowhere near complete. The skeleton is there,  
but there is very little meat. I fully expect this thing to be > 10K  
lines of code before it is done. (Just look at the first three test  
cases and extrapolate) This will take some time to complete (I am not  
even comfortable with slating it for the 1.1 release, seeing as how  
we have bigger fish to fry; ie outbound and gruu.)

	I would love to see issue 13 addressed too, but I don't know if we  
have the time to choose a fix, and test that fix completely. What has  
been thrown around so far sounds risky; instead of a little bit of  
processor spin, the connections could starve. If someone can step up  
and say "I know how to fix this, I know it will work, and I can write  
test-cases to prove it.", that may change my mind on the matter. But  
otherwise, we probably need to take a more conservative approach.

Best regards,
Byron Campen

> Great stuff.
>
> I'd love to see at least 13 addressed in this release.  : )
>
> FYI - testTimer and testAppTimer periodically fail in windows for some
> reason (some strange timing issue) - but I don't think this is  
> anything
> new.
>
> RFC4475TortureTests run without any asserts - does this means it  
> passes?
> Are there any define's required in order to get all  
> RFC4475TortureTests
> to pass?
>
> All other tests in rutil/test and stack/test pass.
>
> Scott
>
>> -----Original Message-----
>> From: resiprocate-devel-bounces at list.sipfoundry.org
>> [mailto:resiprocate-devel-bounces at list.sipfoundry.org] On Behalf Of
>> Byron Campen
>> Sent: Friday, August 18, 2006 1:12 PM
>> To: resiprocate-devel
>> Subject: [reSIProcate] 1.0 release candidate
>>
>>
>> Most of the open issues that we have been discussing have been
>> addressed at this point, but we have still not fixed/come to a
> decision
>> on the following:
>>
>>
>> 4.       UDP Transport enhancement patch to peek message size and
>> allocate buffer appropriately.
>> 4.       Not fixed (the MSG_PEEK | MSG_TRUNC trick is not portable at
>> all). Although, it would be easy to set up a 64K staging buffer where
>> the datagram is initially copied, and then allocate a smaller buffer
>> and copy again)
>>
>> 6.       Not using PrivateKey pass phrases at all.  All private keys
>> must be unencrypted on the disk.
>> 6.       Probably not fixed (Cullen)
>>
>> 7.       Change to DateCategory to make is more compatible with other
>> implementations.
>> 7.       Not addressed (we probably should if it is easy)
>>
>> 13.   TLS Client Connect Inefficiency.
>> 13.   Not addressed. Discussing on list.
>>
>>
>> Do these things need to be fixed for the 1.0 release? Can they wait
> for
>> 1.1? Opinions? (Unless these are show-stoppers, we should probably
>> press on)
>>
>>
>> As far as general testing goes:
>>
>> make install seems to be working fine on FC4 and OS 10.4.
>>
>> I have verified that "make check" works on both FC4 and OS 10.4.
>>
>> tfm also works on both FC4 and OS 10.4.  (except for the
> testEarlyMedia
>> case, but this appears to be a timing issue in the
>> test-case)
>>
>> Scott has tested the build (at least) on Windows. I'd feel better  
>> if I
>> knew we were passing some test-cases.
>>
>> We are passing the protos test suite on FC4 with the PEDANTIC_STACK
>> build flag set (ie, we fully parse every message, giving more
>> opportunities for the parser to explode).
>>
>> It looks to me like we would pass RFC 4475 Torture-Tests (at least as
>> far as stack requirements go, I don't know about DUM), but until the
>> test-case is completely written (a LOT of work), we cannot claim  
>> to be
>> Torture-Tests compliant. This will have to wait.
>>
>>
>>
>> I think we will not have any problems dropping a release candidate
>> today. As per Jason's suggestion, we will just be giving a tag and a
>> revision number for the release candidate. Unless something pops  
>> up, I
>> will be doing this at the end of the day (5ish Central Time).
>>
>> Best regards,
>> Byron Campen
>>
>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2369 bytes
Desc: not available
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20060818/9c916eca/attachment.bin>