I think that a fork is bad for everybody. Whatever way you put it, it will still involve extra overhead at least for each code merge.
So this mail is an attempt to come to a compromise that would be acceptable for everybody.
My first proposal would be to have another branch on ser cvs (berlios). Something like openser_0.x.y (where the version number should reflect somehow that it's newer than 0.9 but not unstable). Bogdan and Daniel would mantain this branch and they would be able to release from it as often as they want. It would be some kind of stable on steroids :-)
This would have the main advantage that code merges/diffs/fixes propagation would be much easier and much faster. Administrating all the stuff will be also easier (like common bug tracking system a.s.o). It would be also easier for users, it will be much more easier to keep track of the changes and to choose an appropiate version.
There must be however some rules. Something like: backporting/forwadporting from unstable/stable should be ok, the same for minor patches (e.g. xlog colors), but not major code changes, not present in unstable and without the code maintainer approval (to maintain future compatibility). Adding new stuff (new modules) should also be ok, but it would be preferable that these module come from either unstable or experimental.
The mailing list for development should remain serdev. For users it could be a different one (if the changes or the mail traffic gets too big).
As far as integrating new contributions faster in unstable, I agree that this is a problem, but I think we can sort it out. The experimental repository is a beginning and if there are better ideeas on how to speed things up while maintaing sanity, please speak. Maybe some kind of reviewed patches (e.g: someone sends a patch that adds a new feature in core, Bogdan reviews it decides it's ok and blesses it => I will integrate much faster something blessed by other ser developer).
If you don't agree with my proposal, please say what you don't like and what you would like changed so that it would be acceptable for you. I'm sure that we can reach a compromise and hopefully improve ser development pace in the process.
Andrei
Hi,
Finally we move from philosophy to specifics.
I think there are 3 parties involved in here: iptel, voice-systems and users. Iptel and voice-systems have their own agenda's, and fights between them end up harming users.
The project model started by iptel took us very far and made ser a great application, but it's own success should make them realize that changes are needed. Greger's and Iqbal's email are I think mostly right and layout a good view of what is going on here. And Andrei's email is a good way to start "peace talks".
Clearly, SER has grown far so that different interests apply and this has caused friction. Friction means there is a problem. I do think that forking is not the best solution, but things MUST change. Contributions must have an easy way into SER: starting maybe as experimental, then moving into unstable, then as testing and finally into stable (kind of debian approach). And this process must be well-defined and NOT CONTROLLED exclusively by a company (be iptel or voice-systems, same-o, same-o). If the contribution is voted as desirable by a community of users, it is well tested and so on, it should be accepted. TLS is only the first, but what will happen when someone develops a free-LDAP module (actually, i think there is one ... just never became mainstream) or any other module which now is kept private by iptel/voice-systems?? If SER is opensource, let it be the whole way.
Summarizing ... I think the shake up by the voice-system's guys is good and desirable, but now it is time to stick together and work out a compromise which works for everybody (and specially for the user). I think Andrei's email is a good start. Let's work on it.
Cesc
On 6/15/05, Andrei Pelinescu-Onciul andrei@iptel.org wrote:
I think that a fork is bad for everybody. Whatever way you put it, it will still involve extra overhead at least for each code merge.
So this mail is an attempt to come to a compromise that would be acceptable for everybody.
My first proposal would be to have another branch on ser cvs (berlios). Something like openser_0.x.y (where the version number should reflect somehow that it's newer than 0.9 but not unstable). Bogdan and Daniel would mantain this branch and they would be able to release from it as often as they want. It would be some kind of stable on steroids :-)
This would have the main advantage that code merges/diffs/fixes propagation would be much easier and much faster. Administrating all the stuff will be also easier (like common bug tracking system a.s.o). It would be also easier for users, it will be much more easier to keep track of the changes and to choose an appropiate version.
There must be however some rules. Something like: backporting/forwadporting from unstable/stable should be ok, the same for minor patches (e.g. xlog colors), but not major code changes, not present in unstable and without the code maintainer approval (to maintain future compatibility). Adding new stuff (new modules) should also be ok, but it would be preferable that these module come from either unstable or experimental.
The mailing list for development should remain serdev. For users it could be a different one (if the changes or the mail traffic gets too big).
As far as integrating new contributions faster in unstable, I agree that this is a problem, but I think we can sort it out. The experimental repository is a beginning and if there are better ideeas on how to speed things up while maintaing sanity, please speak. Maybe some kind of reviewed patches (e.g: someone sends a patch that adds a new feature in core, Bogdan reviews it decides it's ok and blesses it => I will integrate much faster something blessed by other ser developer).
If you don't agree with my proposal, please say what you don't like and what you would like changed so that it would be acceptable for you. I'm sure that we can reach a compromise and hopefully improve ser development pace in the process.
Andrei
Serdev mailing list serdev@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serdev
Hello,
On 06/15/05 16:59, Cesc wrote:
Hi,
Finally we move from philosophy to specifics.
I think there are 3 parties involved in here: iptel, voice-systems and users. Iptel and voice-systems have their own agenda's, and fights between them end up harming users.
The project model started by iptel
see my previous mail to know exactly how it was.
took us very far and made ser a great application, but it's own success should make them realize that changes are needed. Greger's and Iqbal's email are I think mostly right and layout a good view of what is going on here. And Andrei's email is a good way to start "peace talks".
Clearly, SER has grown far so that different interests apply and this has caused friction. Friction means there is a problem. I do think that forking is not the best solution, but things MUST change. Contributions must have an easy way into SER: starting maybe as experimental, then moving into unstable, then as testing and finally into stable (kind of debian approach). And this process must be well-defined and NOT CONTROLLED exclusively by a company (be iptel or voice-systems, same-o, same-o). If the contribution is voted as desirable by a community of users, it is well tested and so on, it should be accepted.
It is exactly what openser aims. I may leave for 6 month for an island to drink and smoke, the community should not wait for me ... Hopefully this situation could have been avoided if some would accept to delegate a replacement maintainers if they have no time. Half an year is way too much, as it was pointed out, many users requested new features from unstable to be released as stable (e.g., lcr), should they wait another half an year?!? They tested, they are using it for long time, so I think they are right.
TLS is only the first, but what will happen when someone develops a free-LDAP module (actually, i think there is one ... just never became mainstream) or any other module which now is kept private by iptel/voice-systems?? If SER is opensource, let it be the whole way.
Summarizing ... I think the shake up by the voice-system's guys is good and desirable, but now it is time to stick together and work out a compromise which works for everybody (and specially for the user). I think Andrei's email is a good start. Let's work on it.
I already sent my contribution there. Waiting now ...
Daniel
Cesc
On 6/15/05, Andrei Pelinescu-Onciul andrei@iptel.org wrote:
I think that a fork is bad for everybody. Whatever way you put it, it will still involve extra overhead at least for each code merge.
So this mail is an attempt to come to a compromise that would be acceptable for everybody.
My first proposal would be to have another branch on ser cvs (berlios). Something like openser_0.x.y (where the version number should reflect somehow that it's newer than 0.9 but not unstable). Bogdan and Daniel would mantain this branch and they would be able to release from it as often as they want. It would be some kind of stable on steroids :-)
This would have the main advantage that code merges/diffs/fixes propagation would be much easier and much faster. Administrating all the stuff will be also easier (like common bug tracking system a.s.o). It would be also easier for users, it will be much more easier to keep track of the changes and to choose an appropiate version.
There must be however some rules. Something like: backporting/forwadporting from unstable/stable should be ok, the same for minor patches (e.g. xlog colors), but not major code changes, not present in unstable and without the code maintainer approval (to maintain future compatibility). Adding new stuff (new modules) should also be ok, but it would be preferable that these module come from either unstable or experimental.
The mailing list for development should remain serdev. For users it could be a different one (if the changes or the mail traffic gets too big).
As far as integrating new contributions faster in unstable, I agree that this is a problem, but I think we can sort it out. The experimental repository is a beginning and if there are better ideeas on how to speed things up while maintaing sanity, please speak. Maybe some kind of reviewed patches (e.g: someone sends a patch that adds a new feature in core, Bogdan reviews it decides it's ok and blesses it => I will integrate much faster something blessed by other ser developer).
If you don't agree with my proposal, please say what you don't like and what you would like changed so that it would be acceptable for you. I'm sure that we can reach a compromise and hopefully improve ser development pace in the process.
Andrei
Serdev mailing list serdev@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serdev
who going away forr 6 mnths, when and what are they smoking....more importantly why are we NOT invited :-)
Iqbal
Daniel-Constantin Mierla wrote:
Hello,
On 06/15/05 16:59, Cesc wrote:
Hi,
Finally we move from philosophy to specifics. I think there are 3 parties involved in here: iptel, voice-systems and users. Iptel and voice-systems have their own agenda's, and fights between them end up harming users.
The project model started by iptel
see my previous mail to know exactly how it was.
took us very far and made ser a great application, but it's own success should make them realize that changes are needed. Greger's and Iqbal's email are I think mostly right and layout a good view of what is going on here. And Andrei's email is a good way to start "peace talks".
Clearly, SER has grown far so that different interests apply and this has caused friction. Friction means there is a problem. I do think that forking is not the best solution, but things MUST change. Contributions must have an easy way into SER: starting maybe as experimental, then moving into unstable, then as testing and finally into stable (kind of debian approach). And this process must be well-defined and NOT CONTROLLED exclusively by a company (be iptel or voice-systems, same-o, same-o). If the contribution is voted as desirable by a community of users, it is well tested and so on, it should be accepted.
It is exactly what openser aims. I may leave for 6 month for an island to drink and smoke, the community should not wait for me ... Hopefully this situation could have been avoided if some would accept to delegate a replacement maintainers if they have no time. Half an year is way too much, as it was pointed out, many users requested new features from unstable to be released as stable (e.g., lcr), should they wait another half an year?!? They tested, they are using it for long time, so I think they are right.
TLS is only the first, but what will happen when someone develops a free-LDAP module (actually, i think there is one ... just never became mainstream) or any other module which now is kept private by iptel/voice-systems?? If SER is opensource, let it be the whole way.
Summarizing ... I think the shake up by the voice-system's guys is good and desirable, but now it is time to stick together and work out a compromise which works for everybody (and specially for the user). I think Andrei's email is a good start. Let's work on it.
I already sent my contribution there. Waiting now ...
Daniel
Cesc
On 6/15/05, Andrei Pelinescu-Onciul andrei@iptel.org wrote:
I think that a fork is bad for everybody. Whatever way you put it, it will still involve extra overhead at least for each code merge.
So this mail is an attempt to come to a compromise that would be acceptable for everybody.
My first proposal would be to have another branch on ser cvs (berlios). Something like openser_0.x.y (where the version number should reflect somehow that it's newer than 0.9 but not unstable). Bogdan and Daniel would mantain this branch and they would be able to release from it as often as they want. It would be some kind of stable on steroids :-)
This would have the main advantage that code merges/diffs/fixes propagation would be much easier and much faster. Administrating all the stuff will be also easier (like common bug tracking system a.s.o). It would be also easier for users, it will be much more easier to keep track of the changes and to choose an appropiate version.
There must be however some rules. Something like: backporting/forwadporting from unstable/stable should be ok, the same for minor patches (e.g. xlog colors), but not major code changes, not present in unstable and without the code maintainer approval (to maintain future compatibility). Adding new stuff (new modules) should also be ok, but it would be preferable that these module come from either unstable or experimental.
The mailing list for development should remain serdev. For users it could be a different one (if the changes or the mail traffic gets too big).
As far as integrating new contributions faster in unstable, I agree that this is a problem, but I think we can sort it out. The experimental repository is a beginning and if there are better ideeas on how to speed things up while maintaing sanity, please speak. Maybe some kind of reviewed patches (e.g: someone sends a patch that adds a new feature in core, Bogdan reviews it decides it's ok and blesses it => I will integrate much faster something blessed by other ser developer).
If you don't agree with my proposal, please say what you don't like and what you would like changed so that it would be acceptable for you. I'm sure that we can reach a compromise and hopefully improve ser development pace in the process.
Andrei
Serdev mailing list serdev@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serdev
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
.
Let's put it straight! First to clarify some things many users seem to be confused about.
SER was started and developed inside FOKUS Fraunhofer Institute, Berlin. All core developers of SER were employed until a stage by that institute. Many contributors were inteship students at FOKUS, many are still active contributors from their current location and others retired from SER development. The development of SER was somehow known (or promoted) as the "iptel" project (it is what the public mainly saw).
Now, none of the core developers are employed anymore by FOKUS. Some of them created a venture named "iptelorg.com" where some other core developers are employed now, and the others started "voice-system.ro". Because the iptelorg has the control of the SER project site (iptel.org) and a similar name, the general impression is that the SER was developed by iptelorg which is far from true. For example, Juha contributed most of the RADIUS code, enum and a lot of other modules...
Now, we are not saying that fork is good in general, otherwise it will be a fork each day :-), but when there is no willing to cooperate, hold-back policies and abuses for self-promoting I see no other way.
We will gladly participate in a *really* open source project. A very good example is the Linux kernel -- it is clear that many of the main developers and contributors are employed by major Linux vendors, which have enterprise/closed releases, but you don't see on the main page of kernel.org advertising for none of them. In the sources is no explicit advertising message, and so on ...
So the proposal is:
- move the project's main site on an independent host (I bet there are people willing to sponsor the hosting)
- remove all references that are intended for private publicity
- introduce a better management of the project, allowing people to be able to take over when someone is very busy or unwilling to cooperate
- make the project really open for contributions and contributors. Outstanding developers can be good reviewers for new contributors when the others are busy
- don't hide the new features from the community, we are on open source, what is the reason to have that ... so each new featured should be described shortly to the community, otherwise keep it in a private repository
- the next steps in develpment should be discussed between the developers to avoid overlapping and waste of time and to select the best way to do it
- members should have a fair attitude to the others and try to discuss each issue is a nice manner (without trying to impose from beginning own opinion and ideas)
This is shortly how we see it. If you agree (improvements are welcome), then we can move forward together, otherwise we will maintain further our code from SER as well as openser.
Daniel
On 06/15/05 16:06, Andrei Pelinescu-Onciul wrote:
I think that a fork is bad for everybody. Whatever way you put it, it will still involve extra overhead at least for each code merge.
So this mail is an attempt to come to a compromise that would be acceptable for everybody.
My first proposal would be to have another branch on ser cvs (berlios). Something like openser_0.x.y (where the version number should reflect somehow that it's newer than 0.9 but not unstable). Bogdan and Daniel would mantain this branch and they would be able to release from it as often as they want. It would be some kind of stable on steroids :-)
This would have the main advantage that code merges/diffs/fixes propagation would be much easier and much faster. Administrating all the stuff will be also easier (like common bug tracking system a.s.o). It would be also easier for users, it will be much more easier to keep track of the changes and to choose an appropiate version.
There must be however some rules. Something like: backporting/forwadporting from unstable/stable should be ok, the same for minor patches (e.g. xlog colors), but not major code changes, not present in unstable and without the code maintainer approval (to maintain future compatibility). Adding new stuff (new modules) should also be ok, but it would be preferable that these module come from either unstable or experimental.
The mailing list for development should remain serdev. For users it could be a different one (if the changes or the mail traffic gets too big).
As far as integrating new contributions faster in unstable, I agree that this is a problem, but I think we can sort it out. The experimental repository is a beginning and if there are better ideeas on how to speed things up while maintaing sanity, please speak. Maybe some kind of reviewed patches (e.g: someone sends a patch that adds a new feature in core, Bogdan reviews it decides it's ok and blesses it => I will integrate much faster something blessed by other ser developer).
If you don't agree with my proposal, please say what you don't like and what you would like changed so that it would be acceptable for you. I'm sure that we can reach a compromise and hopefully improve ser development pace in the process.
Andrei
On Jun 15, 2005 at 22:42, Daniel-Constantin Mierla daniel@voice-system.ro wrote:
[...]
Now, we are not saying that fork is good in general, otherwise it will be a fork each day :-), but when there is no willing to cooperate, hold-back policies and abuses for self-promoting I see no other way.
Let's try not to degenerate in another flame war and please try not to exagerate it: no willing to cooperate, hold-back policies and all the other stuff...
We will gladly participate in a *really* open source project. A very good example is the Linux kernel -- it is clear that many of the main developers and contributors are employed by major Linux vendors, which have enterprise/closed releases, but you don't see on the main page of kernel.org advertising for none of them. In the sources is no explicit advertising message, and so on ...
So the proposal is:
- move the project's main site on an independent host (I bet there are
people willing to sponsor the hosting)
- remove all references that are intended for private publicity
This will take a while as some of the other core devepers are either traveling or will be away for the next days (e.g.: me).
- introduce a better management of the project, allowing people to be
able to take over when someone is very busy or unwilling to cooperate
That sounds very scary... The general ser approach so far was every one is maintaining its own code and other people should not go over it without his approval (except for fixing bugs). The ideea here is that the code maintainer might have his own plans for its own module and he wouldn't want it changed "under him". If I'm away for two months I wouldn't like to not recognize what I've been working on when I'm back (this of course doesn't include bugfixes). There is some other point: a code maintainer might not accept a change. While the change submitor, might think it's the best thing in the world, not everyone might share his opinion.
- make the project really open for contributions and contributors.
Outstanding developers can be good reviewers for new contributors when the others are busy
Yes, I agree, but this doesn't mean that each and every contributions will be applied. In fact I do think this problem is exagerated a lot, given ser's history (you can look even at your linux kernel example, lots of patches are unanswered, and very few make it to the kernel).
- don't hide the new features from the community, we are on open source,
what is the reason to have that ... so each new featured should be described shortly to the community, otherwise keep it in a private repository
I don't agree with this (and with calling it "hiding"). This is a documentation problem. I don't think "document everything or don't add new features" is a good ideea. We do accept documentation patches, is just not realistical to ask all developers to document each new minor feature.
- the next steps in develpment should be discussed between the
developers to avoid overlapping and waste of time and to select the best way to do it
This depends on what you understand by next steps. I do see the potential for interminable discussion.
- members should have a fair attitude to the others and try to discuss
each issue is a nice manner (without trying to impose from beginning own opinion and ideas)
This is shortly how we see it. If you agree (improvements are welcome), then we can move forward together, otherwise we will maintain further our code from SER as well as openser.
Andrei
On 06/16/05 18:51, Andrei Pelinescu-Onciul wrote:
On Jun 15, 2005 at 22:42, Daniel-Constantin Mierla daniel@voice-system.ro wrote:
[...]
Now, we are not saying that fork is good in general, otherwise it will be a fork each day :-), but when there is no willing to cooperate, hold-back policies and abuses for self-promoting I see no other way.
Let's try not to degenerate in another flame war and please try not to exagerate it:
I don't think I do at all, but this is my opinion, so I might be wrong, you can have yours ... but how should I call ...
no willing to cooperate,
no response for more than 8 months
hold-back policies
TLS until a few days ago when that experimental repository was born (after more than 3 months, for something mandatory in RFC)
and all the other stuff...
I stop here, too.
We will gladly participate in a *really* open source project. A very good example is the Linux kernel -- it is clear that many of the main developers and contributors are employed by major Linux vendors, which have enterprise/closed releases, but you don't see on the main page of kernel.org advertising for none of them. In the sources is no explicit advertising message, and so on ...
So the proposal is:
- move the project's main site on an independent host (I bet there are
people willing to sponsor the hosting)
- remove all references that are intended for private publicity
This will take a while as some of the other core devepers are either traveling or will be away for the next days (e.g.: me).
- introduce a better management of the project, allowing people to be
able to take over when someone is very busy or unwilling to cooperate
That sounds very scary... The general ser approach so far was every one is maintaining its own code and other people should not go over it without his approval (except for fixing bugs). The ideea here is that the code maintainer might have his own plans for its own module and he wouldn't want it changed "under him". If I'm away for two months I wouldn't like to not recognize what I've been working on when I'm back (this of course doesn't include bugfixes). There is some other point: a code maintainer might not accept a change. While the change submitor, might think it's the best thing in the world, not everyone might share his opinion.
So if a maintainer leaves for 10years, everything should freeze because he wants to start again along with his grandkids the development. My grandkid will love to start using again the project ... Of course, this is an exaggeration, but even half an year is much too long.
What we want is __a way to move forward in critical situations__. What can guarantee that the maintainer does not act against the project? Do not understand wrong, there will not be accepted all patches, but what the community requires and needs. When someone spent time to do it, and does not harm what exists, but brings more features or quality, give me a reason not to accept it. Do not think that the developer and maintainer is going to be thrown away day by day. It must be a strong reason behind.
So that a community of people is more impartial that a single person, and this should somehow guarantee for fairness.
- make the project really open for contributions and contributors.
Outstanding developers can be good reviewers for new contributors when the others are busy
Yes, I agree, but this doesn't mean that each and every contributions will be applied. In fact I do think this problem is exagerated a lot, given ser's history (you can look even at your linux kernel example, lots of patches are unanswered, and very few make it to the kernel).
I said above, not every nit is going to be applied, but if it is something good and needed by many users, and someone contributed for free, why not? And we can say that ser's history has two parts, the old age, when everything went smooth and the last period. As you can see, from other reactions, too, there is a strong reason behind this move.
- don't hide the new features from the community, we are on open source,
what is the reason to have that ... so each new featured should be described shortly to the community, otherwise keep it in a private repository
I don't agree with this (and with calling it "hiding"). This is a documentation problem. I don't think "document everything or don't add new features" is a good ideea. We do accept documentation patches, is just not realistical to ask all developers to document each new minor feature.
I am going to believe that you see only the extremes. We talk about important features, which were committed, and nothing about them. Don't ask for examples, there were "waves" about some...
How to expect users to contribute to documentation if no announcement of new features are made. Also, this features are not added day by day, so 3 minutes to write a mail should be acceptable.
- the next steps in develpment should be discussed between the
developers to avoid overlapping and waste of time and to select the best way to do it
This depends on what you understand by next steps. I do see the potential for interminable discussion.
So you will end up discussing all your live :-) If primary needs cannot be identified, then it is waste of time.
Daniel
- members should have a fair attitude to the others and try to discuss
each issue is a nice manner (without trying to impose from beginning own opinion and ideas)
This is shortly how we see it. If you agree (improvements are welcome), then we can move forward together, otherwise we will maintain further our code from SER as well as openser.
Andrei
Hello,
I am trying to reconcile patches and improvement suggestions that have been left unanswered on the mailing lists. I went through serusers and serdev mailing list archives from the beginning of 2004 till now.
I was mainly focusing on submitted patches and non-trivial feature requests. Below is a list of issues that I was able to find in the mailing list archives. Given the number of messages that were sent to the lists in the last year I am pretty sure that the list below will miss many suggestions.
If you submitted a patch or improvement and it was neither accepted nor rejected, and it is still relevant, please resubmit your proposal to serdev@lists.iptel.org mailing list or (preferably) create an issue in the bug tracking system at:
Please re-submit also improvements sent in individual messages to developers.
Summary -------
When it comes to accepting improvements, there surely is space for improvements but the situation, in my opinion, is not as bad as it may seem from the recent discussions. Properly reported bugs get usualy fixed quickly. The more detailed description the faster the fix, so I think there are no big problems with that.
The list at the end of this message contains patches and feature requests that I was able to find in the archives. From the list the following issues have not yet been closed:
1, 4, 7, 18, 19, 21, 22, 23, 24, 25, 30, 31
And from those only 1, 4, 18, 21, 22, 25, 31 contained patches that have been left unanswered. That 7 patches which still need to be processed.
The following patches have in my opinion low importance:
1 - date header in REGISTER replies 18 - radius fix for acc 21 - check_to for digest credentials without database
The following patches can be classified as important:
4 - AVP support in acc 22 - transactional auth replies 25 - Free TLS 31 - Xten improvements of pa
In addition to that there are the following improvement suggestions which did not contain any patches: 7, 19, 23, 24
So I was able to find 4 important and 3 less important patches that were not integrated in the last 1.5 year from the 31 items below. Also I created issues in the bug tracking system for all items below that are not yet closed.
The winner among them in terms of e-mail volume is free TLS, of course.
Jan.
PS: Code back-porting is another issue and is not covered here.
------------------------------------------------------------------------------
SERUSERS - 2004 ---------------
1) Date Header in REGISTER responses Feature request by TeleSIP, I have a patch for that already from Robert Sanders which will be integrated Status: OPEN Bug: SER-30
2) PA interoperability with RTC, patch submitted by Klaus Darilion, integrated by Jamey HICKS Status: CLOSED
3) branch=0 problem reported on 16 Jul 2004, closed by Jiri as "not a bug" Status: CLOSED
4) AVP patch for acc module, submitted by Ramona on 31 Oct 2004 Status: OPEN Bug: SER-31
SERDEV - 2004 -------------
5) Video - related patch for nathelper, integrated by Maxim Status: CLOSED
6) fix_nated_contact for nathelper (replied by Maxim) Status: CLOSED
7) 16 Apr 2004 Juha proposed adding npdi and pstn URI parameters (no patches) Status: OPEN Bug: SER-32
8) Maxim submitted patch adding PIDs of all processes into the pid file, resolved by another means Status: CLOSED
9) 20 Apr. 2004 Alexander Mayhofer submitted patch for rtpproxy, commited by Maxim Status: CLOSED
10) Test for realm in auth_radius too tight, reported by Cesar Hernandez, fixed by Jan Status: CLOSED
11) 23 Apr 2004 Multicast support patch, commited by Andrei Status: CLOSED
12) 24 Apr 2004 Postgres patch by Alexander Mayhofer, in CVS Status: CLOSED
13) max_expires patch submitted by Jamey Hicks, in CVS Status: CLOSED
14) start/stop commands fro SEMS into serctl by Klaus Darilion, rejected. Status: CLOSED
15) 30 Jun 2004 User agent support in xlog module by Alexander Mayhofer, in cvs Status: CLOSED
16) 7 Jul 2004 Patch for configurable user agent string by Maxim, resolved by other means Status: CLOSED
17) 21 Jul 2004 Patch for storing user agent string in location table, commited by Maxim Status: CLOSED
18) 21 Jul 2004 Radius-related patch for acc module Status: OPEN Bug: SER-33
19) 2 Oct 2004 Escaped uri characters are not interpreted properly, no patch Status: DEFERED Bug: SER-34
20) 27 Oct 2004 Mysql_ping patch by Dan Pascu, in cvs Status: CLOSED
21) 10 Nov 2004 uri_db patch to make it possible to use check_to and check_from without database (submitted by Marian Dumitru). Status: OPEN Bug: SER-35
22) 25 Dec 2004 Maxim's patch to make it possible send transactional replies from authentication modules Status: OPEN Bug: SER-36
23) Additional header fields requested by Juha (server, refer-to) Status: OPEN Bug: SER-37
SERUSERS - 2005 ---------------
24) feature request route("string") Status: DEFERED Bug: SER-38
25) Free TLS Status: OPEN Bug: SER-39
26) 19 Apr 2005 branch=0 in ACK problem, rejected by Jiri Status: CLOSED
27) 20 Apr 2005 mysql_ping patch for 0.8.14, not important enough to be commited to 0.8.14 Status: CLOSED
28) Backport of radius auth changes from unstable to stable, rejected Status: CLOSED
SERDEV - 2005 -------------
29) Transaction replies in auth modules (by Maxim) Status: OPEN Bug: SER-36
30) NAT support in usrloc and registrar, partially done Status: OPEN Bug: SER-40
31) RFC3265,RFC3903 support in pa, I could not find the patch Status: OPEN Bug: SER-41
Hi,
This is a good move, but this is just a cosmetic change. Suddenly adding patches and new features forgotten may ease some tensions, but background problems persist as to the whole philosophy of SER.
Let's not fork (also) from the main discussion topic ;)
Cesc
On 6/16/05, Jan Janak jan@iptel.org wrote:
Hello,
I am trying to reconcile patches and improvement suggestions that have been left unanswered on the mailing lists. I went through serusers and serdev mailing list archives from the beginning of 2004 till now.
I was mainly focusing on submitted patches and non-trivial feature requests. Below is a list of issues that I was able to find in the mailing list archives. Given the number of messages that were sent to the lists in the last year I am pretty sure that the list below will miss many suggestions.
If you submitted a patch or improvement and it was neither accepted nor rejected, and it is still relevant, please resubmit your proposal to serdev@iptel.org mailing list or (preferably) create an issue in the bug tracking system at:
Jan Janak writes:
16 Apr 2004 Juha proposed adding npdi and pstn URI parameters (no patches) Status: OPEN Bug: SER-32
this is now related to overall fix of ser uri handling that will include proper support for tel uris. the work was started by andrei (with some bits from me) in february, but is not yet complete.
Additional header fields requested by Juha (server, refer-to) Status: OPEN Bug: SER-37
i think my refer-to parsing patch is already included in ser CVS head.
19 Apr 2005 branch=0 in ACK problem, rejected by Jiri Status: CLOSED
this IS a bug, but perhaps not important enough to spend time on fixing.
-- juha
On 20-06-2005 09:32, Juha Heinanen wrote:
Jan Janak writes:
16 Apr 2004 Juha proposed adding npdi and pstn URI parameters (no patches) Status: OPEN Bug: SER-32
this is now related to overall fix of ser uri handling that will include proper support for tel uris. the work was started by andrei (with some bits from me) in february, but is not yet complete.
OK.
Additional header fields requested by Juha (server, refer-to) Status: OPEN Bug: SER-37
i think my refer-to parsing patch is already included in ser CVS head.
You are right, i closed the bug.
19 Apr 2005 branch=0 in ACK problem, rejected by Jiri Status: CLOSED
this IS a bug, but perhaps not important enough to spend time on fixing.
Ok, so far there was only one implementation that had troubles with this, but maybe we should look at it in the future. Handling of end-to-end ACKs in tm module should be fixed anyway. tm module tries to correlate ACKs to corresponding INVITE transactions (I do not remember what was the reason for this but I think it was related to accounting) and I am not sure if this is still needed.
Jan.
-
Andrei Pelinescu-Onciul -
Cesc -
Daniel-Constantin Mierla -
Iqbal -
Jan Janak -
Juha Heinanen