[Serusers] WIH?

[listas iPfone]

Hi All People,

what is happening with ser?

It is like astersik business?

Miklos


----- Original Message ----- 
From: "Daniel-Constantin Mierla" <daniel at voice-system.ro>
To: "Andrei Pelinescu-Onciul" <andrei at iptel.org>
Cc: "SER developer mailing list" <serdev at lists.iptel.org>; "serusers" 
<serusers at lists.iptel.org>; <users at openser.org>; <devel at openser.org>
Sent: Tuesday, June 14, 2005 4:48 PM
Subject: Re: [Serusers] OpenSER release


> 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
>>
>>
>
> _______________________________________________
> Serusers mailing list
> serusers at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
>