I do not think openser is a good idea. This will only lead to further confusion and interoperability problems vis-a-vis ser.cfg. Why can't the openser guys invest their time and efforts to work with ser people rather than forking on a new path? It seems to me voice-systems.ro is trying to endorse itself by launching openser. Dave

On Jun 14, 2005 at 20:10, Bogdan-Andrei Iancu <bogdan(a)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. Forking ser is a very bad ideea and your exposed reason are far from enough to motivate it. Anyway anybody can cvs co -rrel_0_9_0 .

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). Some of the changes listed in the diffs will break compatibility with current ser configuration scripts. I wonder also when have you tested all your changes. Andrei _______________________________________________ Serdev mailing list Serdev(a)iptel.org http://mail.iptel.org/mailman/listinfo/serdev

having multiple options instead of only one proved in many case to be a progress engine. I would rather say that both projects will benefit from this. And most important, the user (don't forget them) will: they will have a larger diversity to choose from. indeed, time (and to be more specific, allocated time for the public SER) was an important factor for deciding to start OpenSER. Also another factor was how to deal with new contributions and how to *help* them to get into the main stream. Placing them in a separate directory I think will not help too much - see the history of the snmp module. and about splitting the time between the two projects - I don't thing will be a problem for us since we are the people who complain the thing are not fast enough ;) bogdan

Bogdan-Andrei Iancu wrote: Diversity is not necessarily a good thing in every situation, for example diversity in a limited resource environment can lead to less effective use of those resources and, in the end, may lead to the opposite of what you describe (a progress engine). Also IMO diversity seems to be a argument against proprietary software models, such as "Application X has this features A,B,C and doesn't see it as necessary to implement features D and E for whatever reason (generally non-technical) so i'll use Application Y because it has features D and E (which i really need) however it does not have feature B which i can do without" An argument against proprietary models and (generally) not OSS

because (by definition) the latter is open to improvement and modification by anyone who wishes to take the time and because of this a community is created around that project. If there is a problem then, as a community, we should make every effort to deal with it as such. Now i don't particularily want to approach the problems associated with self-defensive, impressionistic territorial behaviour that is quite common in most OSS projects but it is (IMO) a serious one which is taken into consideration by (i believe) many who post requests. If you have a hard getting your point across i can see how it may seem impossible to enact any great change without a very large amount of effort in which case a simple branch is the easiest solution I think if you really are serious about branching SER you should first consult with the developers and users of SER to find out what they think and if there exists a way resolve (or objectively document, for reference in the least..) the issues you are having. I think that this would be a reasonable approach, your sudden declaration of a branch is a total surprise to (i'm sure) everyone on these lists and i think it may not be the best approach. tavis _______________________________________________ Devel mailing list Devel(a)openser.org http://openser.org/cgi-bin/mailman/listinfo/devel

Andrei Pelinescu-Onciul wrote: I agree, forking will have a negative effect on SER in the long-run by reducing the amount of available resources (programmer time, administrative time) If there is a problem it should be worked out as a community instead of forgoing the difficult task of enacting change (if you think somthing needs to change) and simply creating a parallel project. I think it is important that not every patch and module simply be added to the project but put aside so that someone can review the code and make sure it safe and integrates well. I wouldn't say there has been a lack of progress just because there hasn't been a stable release for some time, your own changlog can attest to this, there has been many improvements. I do agree, however, that there should be some facility it place to centralize the development of unstable modules that may eventually be included in the mainstream distribution or at least in a stable "addons" package, so that work may progress more efficientely in those area's. _______________________________________________ Serusers mailing list Serusers(a)iptel.org http://mail.iptel.org/mailman/listinfo/serusers

Hi guys. I'm just any other SER user in the world that I have taken advantage of this project to deploy SIP service. I haven't contribute with the project as far as I have tried to replay some posts at the mailing list. There are many people that is dedicated and compromised with this project. I have seen people like SER Team (Jiri, Jan and Andrei), Juha, Marie, Bodgan, Daniel, Iqbal, Greger, Paul, and many others that have been giving their time and effort to SER project without asking for a compensation. The open source development philosophy goes in this way: Everybody contributes with it and there isn't any payment (money) back. Then we have a project like SER when there should be a leader for the benefit and success of the project. There are rules and policies about how to use the software, how to make the documentation, how to integrate the improvements, new code, etc. and everybody should follow this rules and policies. And what about the people that is dedicated 100% to the project, how they are handling their incomes? Some body need to pay the bills. I don't know about SER guys like Jan, Jiri and Andrei what other thinks are they doing besides SER Project but I can imagine they have a lot work to do at the project. I don't know this is true but I though the main concern about Bodgan and Daniel is that SER development group aren't dedicating the 100% to the project because they have as main target the iptelorg commercial project. There are some post at the mailing list that have shown the feelings from some people about it. I have seen many people that have posted improvements, corrections, add-on, etc. They are asking to integrate their contributions to the project but they haven't received a positive answer and that is not motivate it for anybody. And maybe they start to feel like "Something is wrong, why this guys are not taking my code? Is there other kind of interest here?" Why you don't make an agreement about this? Why don't to make a re-engineering at the SER team and define team groups by features or by modules which the team leader and members could be as from iptel-group as from any other organization? In this way you could have a decision maker by module or feature that could decide what o when to integrate new code or features. Maybe you could adopt the way like the IETF organization works. Maybe this could help to have a better communication and to improve the time to release the new stable versions of SER. These are my personals thougths I would like everything goes well and everybody be happy.It's a little difficult to approach this kind of goal but with a little effort, tolerance and good will everything is possible. Regards Alberto Cruz reticent wrote: >Andrei Pelinescu-Onciul wrote: > > > >>On Jun 14, 2005 at 20:10, Bogdan-Andrei Iancu <bogdan(a)voice-system.ro> wrote: >> >> >> >> >>>Hi SER community, >>> >>>there are almost two years from the last official SER release and things >>>do not promise too much right now. Not only that the progress stuck >>>somewhere on the way (rel 0.9.0 was started more than half a year ago), >>>but even any attempt to push thing forward seems to be denied - I tried >>>along with Daniel to push the release, but seems that not everybody >>>shares our and comunity's interest regarding the public part of SER - >>>upgrades were rolled back, new software contributions haven't found >>>their way in (like TLS and other new modules), modules maintained by >>>other developers are inaccessible. >>> >>> >>> >>> >>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. >>Forking ser is a very bad ideea and your exposed reason are far from >>enough to motivate it. >>Anyway anybody can cvs co -rrel_0_9_0 . >> >> >> >> >> >> >I agree, forking will have a negative effect on SER in the long-run by >reducing the amount of available resources (programmer time, >administrative time) >If there is a problem it should be worked out as a community instead of >forgoing the difficult task of enacting change (if you think somthing >needs to change) and simply creating a parallel project. >I think it is important that not every patch and module simply be added >to the project but put aside so that someone can review the code and >make sure it safe and integrates well. > >I wouldn't say there has been a lack of progress just because there >hasn't been a stable release for some time, your own changlog can attest >to this, there has been many improvements. > >I do agree, however, that there should be some facility it place to >centralize the development of unstable modules that may eventually be >included in the mainstream distribution or at least in a stable "addons" >package, so that work may progress more efficientely in those area's. > > > > > >>>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). >> >> >> >> >> >>>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. I wonder also when have you tested >>all your changes. >> >> >> >>Andrei >> >>_______________________________________________ >> >>

On Jun 14, 2005 at 20:10, Bogdan-Andrei Iancu <bogdan(a)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.

Forking ser is a very bad ideea and your exposed reason are far from enough to motivate it.

Anyway anybody can cvs co -rrel_0_9_0 . 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).

Some of the changes listed in the diffs will break compatibility with current ser configuration scripts.

I wonder also when have you tested all your changes.

Andrei _______________________________________________ Serusers mailing list Serusers(a)iptel.org http://mail.iptel.org/mailman/listinfo/serusers

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.

Andrei Pelinescu-Onciul writes: i remember that jan once sent an email to ser list telling that he will make radiusclient-ng change just before 0.9.0 is released. because of the crashes due to radiusclient, i couldn't wait and patched myself rel_0_9_0 to use radiusclient-ng. i'm happy to commit them if iptel folks think it is a good idea.

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.

On 06/14/05 22:06, Andrei Pelinescu-Onciul wrote: 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. A lot of time wasted for nothing ... 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. 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. 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. 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. 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). So processing further the retransmissions was a feature ... ok :-) 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 _______________________________________________ Serusers mailing list serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

There are people testing it and already fixing bugs. I remember a person asking for help to create a cvs where he can extend the TLS patch - and there was no response from the iptel guys. I also took quite long to come up with the "contribs/experimental" directory - which IMO is not very comfortable.

Klaus Darilion writes: i don't know what happened at iptel regarding tls. more than a month ago i got private email from iptel saying that tls will be included officially is ser CVS. this contribs/experimental thing cannot be it or if it is, i'm disappointed. -- juha

_______________________________________________ Serusers mailing list serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

Hi all! It's good to see that there are people encouraged to improve ser and integrating new features. It was also obvious, that iptel was not happy about the open TLS code. Nevertheless, a split is not only the best way. I'm a user - not a developer. For users this is getting a nightmare. I have to subscribe to the openser mailinglists and read both of them. There are still emails from people asking if they should use rtpproxy or mediaproxy. There are also several avp modules and yet I refused using them as I do not know which I should use. Now imagine, how many emails we have to answer from people asking which version of ser they should use - and the worst thing, there is no easy answer.

Some features will be only in the main ser, others will be only in openser. Although you state that you will incorporate patches to the main ser, I'm sure your business will grow and you don't have the time to maintain two versions of ser - and synchronize patches.

Please, dont forget the users.

regards, klaus Bogdan-Andrei Iancu wrote: _______________________________________________ Devel mailing list Devel(a)openser.org http://openser.org/cgi-bin/mailman/listinfo/devel