[Devel] Re: [Serusers] OpenSER release

[Daniel-Constantin Mierla]

On 06/14/05 22:06, Andrei Pelinescu-Onciul wrote:

>On Jun 14, 2005 at 21:20, Daniel-Constantin Mierla <daniel at voice-system.ro> wrote:
>  
>
>>On 06/14/05 20:39, Andrei Pelinescu-Onciul wrote:
>>
>>    
>>
>>>On Jun 14, 2005 at 20:10, Bogdan-Andrei Iancu <bogdan at voice-system.ro> 
>>>wrote:
>>>
>>>The release is delayed due to lack of time.
>>>Current show stoppers were me reviewing the whole tcp code (after finding
>>>a minor bug) and some radius makefile problem.
>>>      
>>>
>>Well, that was the the main reason, the start for new release was 
>>announced on the 16th December, last year, a half an year ago. Some of 
>>us declared maintained code ready for release in about one month. Others 
>>had no time till now and they didn't announce any schedule, some of us 
>>volunteered to test and fix other's code, they did it and afterwards the 
>>code was reverted. The SER community was always confused in this period 
>>about the new release, what is the status, when is going to be ....
>>    
>>
>ser as many other open source projects does not have a fixed release. It
>is released when it's ready.
>  
>
Of course, and we want it ready sooner to be able to move forward, since 
for SER takes (more?!?) half a year. Our part of code is ready for 
release since winter, SER release will be done when the other is ready, 
we will help with packaging at that moment, we always did it.

>Apart from the code revert, what other problem did you have?
>  
>
A lot of time wasted for nothing ...

>If you really thought everything was ready, you should have sent a mail
>and an offer to help with the last minute tests & packaging.
>There was no discussion about it, no attempt to reconcile what you see
>as problems, you've just come with this fork out-of-the-blue.
>  
>
Remember January, February, March, April ... talks face to face?!?! 
Anyhow, we didn't consider some other parts of ser ready (and you know 
that), it is why we changed them, otherwise we would have done packaging.

>To me it looks as you were searching for some reason to fork.
>  
>
Why? Everything is public, is just an alternative to what we, as well as 
many SER users, didn't like. Don't try to suggest you were not aware of 
our complains, there was a long chain of discussions from December to 
April regarding 0.9.x release we had together.

>  
>
>>>Forking ser is a very bad ideea and your exposed reason are far from
>>>enough to motivate it.
>>>
>>>
>>>      
>>>
>>The fork will be only for the code which is not maintained by the 
>>developers from Voice System, when it is the case (a lot of modules are 
>>the same, but we cannot accept some other parts of code). Voice System 
>>developers will maintain own code from SER as they did it so far -- it 
>>is stated clear at http://www.openser.org . OpenSER will be an extra 
>>work to maintain for us. Maintainers of code modified by us can import 
>>it in their part, if they consider it good, there is no problem.
>>    
>>
>
>This is not about who will mantain openser, this is about fragmenting
>the developer comunity, which is realy very bad anyway you put it.
>  
>
It is your opinion, but I repeat myself, that the SER code maintained by 
us will go further -- I don't think that someone can claim that we 
didn't do the job for our code (the only discrepancy is some last-minute 
adds in xlog (to print avps) - will be committed on unstable very soon 
with the new color patch). The cvs was created just to ease the 
maintainance. The patches would be a nightmare.

>If you would have just created ser packages, it would have been ok.
>
>
>  
>
>>>Anyway anybody can cvs co -rrel_0_9_0 .
>>>      
>>>
>>>>Unfortunately this is not a good environment if we what to have some 
>>>>future progress for SER. And this is the main reason for starting a new 
>>>>project called OpenSER - http://www.openser.org .
>>>>
>>>>It's called open because its most important attribute is its opening to 
>>>>new ideas and contributions, fast developing and more involvement of the 
>>>>comunity. Along with quality, the progress is the main concern.
>>>>We will continue to support and develop the SER project as much as so 
>>>>far and as much as possible, but OpenSER will give the liberty for more.
>>>>        
>>>>
>>>ser just got an experimental module repository for new stuff that is not
>>>tested and/or not reviewed by a core developed (so that it can be added
>>>to the ser main repository).
>>>
>>>
>>>      
>>>
>>This is not a good solution always. Some parts which are mandatory in 
>>SIP RFC (TLS) should be accepted as soon as possible to get stable very 
>>soon. But it was suggested somehow on the mailing list that some of them 
>>will not be accepted easily, even if many community members requested.
>>    
>>
>
>Did you review the TLS code? Have you tested it?
>While it might be very good I didn't have the chance to look at it in
>detail.
>Do you have TLS in openser 0.9.0?
>  
>
No, it will be in next release. openser 0.9.4 is to end for us the long 
period of a new SER release so we can focus to new features.

>You have found one thing, that I admit it has taken way too  much time
>to integrate and now you use it as main fork argument.
>
This is just one, but there are others, like acc (patch sent long time 
before tls -- e.g., a lot of members requested to log source IP and 
other fields).

> 
>And again a solution has been found for all this: the experimental
>repository.
>
>  
>
>>>>OpenSER serves the interest of all SER users and will not change its 
>>>>purpose - as a fact I have the pleasure to announce its first release - 
>>>>OpenSER 0.9.4. The web site offers a comprehensive listing of new 
>>>>features and fixes - http://www.openser.org/index.php#features. For 
>>>>people already familiar to SER 0.9.3, going to 
>>>>http://www.openser.org/diffs-0.9.0.php will be more helpful.
>>>>  
>>>>
>>>>        
>>>>
>>>Some of the changes listed in the diffs will break compatibility with
>>>current ser configuration scripts.
>>>
>>>      
>>>
>>The script compatibility is kept. There were only fixes -- the main is 
>>the one that fix return 0 from script methods, which was a known bug, 
>>but somehow kept silent. Many methods rely on that behavior (e.g., 
>>t_newtran() for retransmissions) and the bug caused very hard to trace 
>>problems.
>>    
>>
>
>This was a feature, not a bug :-)
>  
>
So processing further the retransmissions was a feature ... ok :-)

>  
>
>>>I wonder also when have you tested
>>>all your changes.
>>>
>>>
>>>      
>>>
>>There is more than one month for most of the changes and we tested as 
>>much as possible, but no release will be bug free (even you discovered a 
>>bug of 0.8.14 a day ago). There is enough space for patch releases...
>>    
>>
>
>One of the things that  pisses me off is that for example you claim to
>use radiusclient-ng.  Although the discussion about using it 0.9.0 was
>only a week ago, you haven't sent any patch.
>  
>
Somehow it was clear from the mail thread that the maintainer's decision 
was to have radiusclient-ng 0.4.x for 0.9.0 and 0.5.0 for cvs head. We 
did it to ensure interoperability with new releases of radiusclient-ng 
(mainly are file name changes).

Daniel

>
>Andrei
>
>  
>