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.
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.
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.
Also the documentation (http://www.openser.org/index.php#docs) will help for a better understanding of this release. For any additional question please use the project mailing lists:
users@openser.org - dedicated for general purpose discussions about OpenSER stable releases. devel@openser.org - dedicated for discussions related to development version and next steps of OpenSER.
bogdan
Brilliant : )
Bogdan-Andrei Iancu 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.
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.
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.
Also the documentation (http://www.openser.org/index.php#docs) will help for a better understanding of this release. For any additional question please use the project mailing lists:
users@openser.org - dedicated for general purpose discussions about OpenSER stable releases. devel@openser.org - dedicated for discussions related to development version and next steps of OpenSER.
bogdan
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
On Jun 14, 2005 at 20:10, Bogdan-Andrei Iancu bogdan@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 .
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
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
--- Andrei Pelinescu-Onciul andrei@iptel.org wrote:
On Jun 14, 2005 at 20:10, Bogdan-Andrei Iancu bogdan@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 .
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
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
__________________________________ Discover Yahoo! Find restaurants, movies, travel and more fun for the weekend. Check it out! http://discover.yahoo.com/weekend.html
Dave,
openser is an alternative for people who needs fast progress. There are more and more people asking when some feature will be available in a stable release or if a contribution will be ever accepted. For example our guys came up with a ACC patch to implement custom accounting - feature witch was ask by some users. But for almost half a year the patch was ignore by module maintainers....the same with TLS or other features. OpenSER wants to overcome this problem. And btw, the scripting is the same, compatibility will be maintained...but with more features and more module. We shouldn't confuse interoperability with enhancement.
We are SER people, even core developers of SER, but we cannot impose our point of view over the whole project - there are other people responsible for other parts of code and I cannot neither go over their code, neither to force them to progress. It's just a matter of effort versus waisted effort........
bogdan
Dave wrote:
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
Why not just make private branch in the main repository in which you can make that "fast progress"? That way you can ensure that the code can be merged back and forth without any difficulties.
-Maxim
On Tue, Jun 14, 2005 at 09:31:20PM +0300, Bogdan-Andrei Iancu wrote:
Dave,
openser is an alternative for people who needs fast progress. There are more and more people asking when some feature will be available in a stable release or if a contribution will be ever accepted. For example our guys came up with a ACC patch to implement custom accounting - feature witch was ask by some users. But for almost half a year the patch was ignore by module maintainers....the same with TLS or other features. OpenSER wants to overcome this problem. And btw, the scripting is the same, compatibility will be maintained...but with more features and more module. We shouldn't confuse interoperability with enhancement.
We are SER people, even core developers of SER, but we cannot impose our point of view over the whole project - there are other people responsible for other parts of code and I cannot neither go over their code, neither to force them to progress. It's just a matter of effort versus waisted effort........
bogdan
Dave wrote:
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
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Andrei Pelinescu-Onciul wrote:
On Jun 14, 2005 at 20:10, Bogdan-Andrei Iancu bogdan@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
Serdev mailing list Serdev@iptel.org http://mail.iptel.org/mailman/listinfo/serdev
reticent wrote:
Andrei Pelinescu-Onciul wrote:
On Jun 14, 2005 at 20:10, Bogdan-Andrei Iancu bogdan@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.
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
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.
Bogdan-Andrei Iancu wrote:
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
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
reticent wrote:
Bogdan-Andrei Iancu wrote:
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
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).
tavis, I rather see what happened as a redistribution of same resources in a more efficient way - is about team work, about each member commitment and interest in finalizing or developing something. Diversity is something we can talk a lot about - is about multiple versus single, absolutism versus democracy, bigamy versus monogamy - for sure this a vast subject to talk about, with arguments pro and against, depending of the environment. But it is a too philosophical discussion I will prefer not to get into it - at least not on this mailing list.
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
what I really appreciate here is the fact that there are people who (at least) identify the reason for this OpenSER fork (even if maybe its justification is still not fully understood).
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.
OSS gives both users and developers more liberty to choose what to use and what to work on. From developer perspective, believe me, there were several talks / discussions about the driven of SER project - even if thy were only between the SER core team, sometime you could notice some break-outs /peeks on the developing mailing list. As for user - its the reason for which we come public with the project - we want the users to benefit from what we believe/try to do more.
bogdan
On 06/14/05 23:30, reticent wrote:
Bogdan-Andrei Iancu wrote:
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
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
OSS proved that some time diversity is a very good solution. Look at the number of the linux distributions. All contribute to kernel development and other software. They have same roots and backbone, but there are differences that make people to choose only one. I chose Debian because it is very open for contributions and develops faster. This happened after RedHat chose to close its public releases. I could have gone to fedora, but I found debian more appropriate for what I need.
Daniel
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@openser.org http://openser.org/cgi-bin/mailman/listinfo/devel
On 14-06-2005 22:47, Bogdan-Andrei Iancu wrote:
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.
The history of SNMP module is simple -- it was a summer project of a FOKUS intern. The summer ended, the guy left FOKUS and noone was willing to maintain the module anymore. This has nothing to do with scarce resources -- there simply was no interest in that module.
If placing new contributions into a separate directory will not help then placing them in another CVS repository where you have to apply for another username and password and the version of ser that you will be working with will be heavily modified will not help for sure. It would be more hard to integrated such contributions to the official SER.
Jan.
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@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
Serdev mailing list Serdev@iptel.org http://mail.iptel.org/mailman/listinfo/serdev
Serusers mailing list Serusers@iptel.org http://mail.iptel.org/mailman/listinfo/serusers
On Jun 14, 2005 at 15:01, Alberto Cruz acruz@tekbrain.com wrote:
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?
They already are. The ser core team is me, Bogdan, Daniel, Jan, Jiri (alphabetical order).
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.
This is also implemented: every piece of code is maintained by somebody. If for example Jan wants to change my code (and it's not some obvious bug fix), he asks me if I agree. The general ideea here is not to modify other people code without their approval (maybe they have something else in mind). The same goes for all ser contributors with cvs access. The ser core team is a little bit more powerfull in the sense that if we agree we can make major changes.
Maybe this could help to have a better communication and to improve the time to release the new stable versions of SER.
This is why I'm so surprised (and pissed off) about this fork. There was no communication.
Andrei
[...]
Alberto,
thanks for the feedback - sometime is very useful to know what the SER users thing about the projects and their environments.
The original SER team - as part of Fokus Fraunhofer - split to different companies for a more commercial approach of SER project. The important facto here is how much time you dedicate for the public project and how much feedback you push back to the project.
And to be honest, even as core developers, I had same impression "Something is wrong, why this guys are not taking my code? Is there other kind of interest here?"; and this felling is the reason for which OpenSER was found - to reborn the interest.
bogdan
Alberto Cruz wrote:
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@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 14-06-2005 23:41, Bogdan-Andrei Iancu wrote:
Alberto,
thanks for the feedback - sometime is very useful to know what the SER users thing about the projects and their environments.
The original SER team - as part of Fokus Fraunhofer - split to different companies for a more commercial approach of SER project. The important facto here is how much time you dedicate for the public project and how much feedback you push back to the project.
And to be honest, even as core developers, I had same impression "Something is wrong, why this guys are not taking my code?
What code ?
- I integrated your changes to usrloc. You did not take into account additional branches -- I added that. I already explained the reason why I decided for a bit different way on serdev and it is my right because I am maintaining those modules.
- Your patch to rr -- I asked you to implement it using AVPs since then I haven't heard from you. I do not want to have another function in rr when we are using AVPs for everything else and thus it is a logical choice.
- Backport of radius related changes -- this was actually my code that you backported from the trunk. I politely asked you to remove it and you refused to do that. The reason why I do not want to backport that code was discussed on serusers and serdev thoroughly.
- patch to acc submitted by Ramona (I don't know if it can be considered as your code) -- that's the only think that I can remember that was not integrated.
When I look at your list:
- alias_db module -- Never contributed - additional credential parser -- Never contributed - new internal API of auth modules -- Never contributed - load_credential_list -- Never contributed - PIKE -- why didn't you commit the bugfixes into SER ? - t_flush_flags, t_local_replied -- Never contributed
The list of stuff that you never contributed seems bigger than the tree items you proposed recently -- so I do not really understand what are you complaining about.
In addition to that many items from your list listed as NEW are actually backported from the trunk, you just modified them slightly to your taste (authentication, received sockets in usrloc and registrar).
I don't think that something like this justifies a new fork of the whole project.
Jan.
On 06/14/05 20:39, Andrei Pelinescu-Onciul wrote:
On Jun 14, 2005 at 20:10, Bogdan-Andrei Iancu bogdan@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.
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 ....
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.
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.
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.
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...
Daniel
Andrei
Serusers mailing list Serusers@iptel.org http://mail.iptel.org/mailman/listinfo/serusers
On Jun 14, 2005 at 21:20, Daniel-Constantin Mierla daniel@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@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. Apart from the code revert, what other problem did you have?
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. To me it looks as you were searching for some reason to fork.
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. 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? 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. 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 :-)
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.
Andrei
Andrei Pelinescu-Onciul writes:
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.
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.
-- juha
On Jun 14, 2005 at 22:14, Juha Heinanen jh@tutpro.com wrote:
Andrei Pelinescu-Onciul writes:
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.
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.
The final plan was to add a make variable and in function of its value to use radiusclient-ng 5.x or 4.x (and it would default to 5.x).
If your patch doesn't include this extra feature, could you send it to me, so I can hack some 4.x support? If you already have this, then please commit.
Andrei
On 14-06-2005 22:14, Juha Heinanen wrote:
Andrei Pelinescu-Onciul writes:
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.
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.
I have done that already, thanks, we have been just trying to find a a convenient way how to make it possible to use both versions, because 4.x is still being used by majority of people (5.x will be default).
Jan.
On 06/14/05 22:06, Andrei Pelinescu-Onciul wrote:
On Jun 14, 2005 at 21:20, Daniel-Constantin Mierla daniel@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@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
On Jun 14, 2005 at 22:48, Daniel-Constantin Mierla daniel@voice-system.ro wrote:
[...]
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.
Maybe I've misunderstood you: is this only a parallel "stabilized" version + some features or is it a full fork (do you intend to fork unstable also)? I have no problem with another stable version, what worries me is fragmenting the development for unstable (which is the place where major changes are made).
Andrei
On 06/14/05 23:21, Andrei Pelinescu-Onciul wrote:
On Jun 14, 2005 at 22:48, Daniel-Constantin Mierla daniel@voice-system.ro wrote:
[...]
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.
Maybe I've misunderstood you: is this only a parallel "stabilized" version + some features or is it a full fork (do you intend to fork unstable also)?
It is fork for the code that we changed (acc module, usrloc module ...), in the future may be other that they do not find the path in SER. We will maintain and upgrade our part of code from SER continuously.
I have no problem with another stable version, what worries me is fragmenting the development for unstable (which is the place where major changes are made).
I see no fragmenting there -- the situation is the same for SER as it was before. For example, there is no fragment for acc module, it will be maintained by who did it till now, adding what he considers necessary there. But we came to meet a lot of requests of why the acc patch is not included in the CVS (it was fully backward compatible and had new features requested by many SER users) and we want to promote _more open_ approach to contributions to all parts of code. The acc patch was sent on November 1, 2004. No real response (neither negative, nor positive) from maintainer to the submission since then ... are you aware of a good reason?!?! ... should we wait just about (or more) half an year for each contribution?!? I will not do that anymore!!!
Daniel
Andrei
Hi All People,
what is happening with ser?
It is like astersik business?
Miklos
----- Original Message ----- From: "Daniel-Constantin Mierla" daniel@voice-system.ro To: "Andrei Pelinescu-Onciul" andrei@iptel.org Cc: "SER developer mailing list" serdev@lists.iptel.org; "serusers" serusers@lists.iptel.org; users@openser.org; devel@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@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@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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Andrei Pelinescu-Onciul wrote: ...
Did you review the TLS code? Have you tested it?
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.
regards, klaus
Klaus Darilion writes:
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.
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
Juha, I can confirm that the experimental/tls has nothing to do with iptel and that Cesc's TLS work is based on the TLS code submitted some months ago to serdev by P. Griffith. I don't know any specifics about Iptel's plans for inclusion of TLS in the trunk. Also, I feel that is the way it should be: The experimental CVS module will now live a life outside iptel's dispositions and is open to anyone who have something to contribute and who are willing to commit to doing maintanance.
How to resolve conflicts between experimental modules and iptel modules? There must obviously be some process for moving code from experimental to the main tree. Jan has just commited a new CVS policy document, I quote from the section on Unrestricted CVS Access: "When considering giving anyone full write access, we will look at your code to see whether it is of general use, it should compile with the latest SER versions and you must be willing to maintain the code in the main tree (alternatively you could convince another developer to maintain the module for you)." I assume he means the core group when writing "we" here. Experience will show whether some kind of voting in the community or other type of feedback process should influence the decision on whether an experimental module (or competing modules) should be promoted to the main CVS modules tree. The TLS module will obviously be the first test case for this new approach to contributions.
g-)
Juha Heinanen wrote:
Klaus Darilion writes:
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.
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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Juha Heinanen wrote:
Klaus Darilion writes:
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.
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
Let me start by describing our environment. We are an Enterprise environment that operates internally much like a Service Provide. We have a large (30,000+) node IP network with 25,000+ voice lines. We also have a research & development environment that is driven by our participation in Internet2 projects and also through University funded research projects.
I may not be able to speak to the contribution and patch release issues because we've only used functionality inherent in the available releases. I can say we would like a stable product which is open to development from the community and allows such development to be included in periodically released future updates.
I'm not concerned about whether these updates appear first in the unstable branch however whatever appears in this branch should only be included in a stable release if it has indeed been shown to be stable and of consistent performance. We will run whatever release we select in our test environment before deploying it internally.
What does concern me is that we have access to stable releases with clearly documented feautres and a changelog showing what enhancements have been done since the last release. It is also helpful to see a list of features and functionality that has been submitted from the community and is to be included in future releases.
I've seen quotes that say SER is the Apache of VoIP. I personally think this high praise and shows a level of confidence in SER that is worth recognizing. SER did not get this level of recognition by being a half-bake application. Let's try to focus on maintaining this confidence by acknowledging the value of contributions from the community and the architectural vision of the core developers.
$0.02 from an end user.
- Steve
Serusers mailing list serusers@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:
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.
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.
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.
Also the documentation (http://www.openser.org/index.php#docs) will help for a better understanding of this release. For any additional question please use the project mailing lists:
users@openser.org - dedicated for general purpose discussions about OpenSER stable releases. devel@openser.org - dedicated for discussions related to development version and next steps of OpenSER.
bogdan
Serdev mailing list Serdev@iptel.org http://mail.iptel.org/mailman/listinfo/serdev
Hello,
On 06/15/05 11:56, Klaus Darilion wrote:
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.
the life is not easy -- from here starts all. Each one tries to make it easier for him, I agree with that. We have to choose very day -- when we buy a car, a house, decide about a job ... nobody knows what was better at the end, maybe the time will prove something.
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.
Here is the point! What would you feel if the whole SER team would leave the project for a closed-source development or some other business. It may be possible or not. There are few other people that can take over. I don't want to have my work closed when I will retire or I will be too busy -- most of it was done in my free time. That is the problem right now. Some were too busy (I suppose and I hope :-) that was the reason) but they didn't want to allow further evolution. Everyone tries to prove that its ideas are the best and there is no space for improvement.
Business is the motivation for all SER users, I do not think that is someone that do stuff with SER just because he has no other thing to do -- many work for companies that use SER, others do studies and use ser for projects... So the business behind is the engine for development.
I consider that people that were proved to understand and support SER to be allowed to drive the development of the project when the other are busy or retired.
Please, dont forget the users.
It is why we try to make the users more important. The success of SER is due to its users. No one could have promote an open source project to be at this stage than the users community. The merits are for developers, but without users, there is no glory or business behind. They have invested a lot time and money in SER (eg., only by advertising it), so they should feel safe using SER further.
Daniel
regards, klaus
Bogdan-Andrei Iancu 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.
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.
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.
Also the documentation (http://www.openser.org/index.php#docs) will help for a better understanding of this release. For any additional question please use the project mailing lists:
users@openser.org - dedicated for general purpose discussions about OpenSER stable releases. devel@openser.org - dedicated for discussions related to development version and next steps of OpenSER.
bogdan
Serdev mailing list Serdev@iptel.org http://mail.iptel.org/mailman/listinfo/serdev
Devel mailing list Devel@openser.org http://openser.org/cgi-bin/mailman/listinfo/devel
-
Alberto Cruz -
Andrei Pelinescu-Onciul -
Bogdan-Andrei Iancu -
Daniel-Constantin Mierla -
Dave -
Greger V. Teigre -
Jan Janak -
Juha Heinanen -
Klaus Darilion -
listas iPfone -
Maxim Sobolev -
Mik Cheez -
reticent -
Steve Blair