I am not an advocate for either ser or openser, but I would like to comment.
Is openser going to be equipped with a forum/ticket system where people can document bugs, feature requests, etc (non-configuration issues)?
This is just my observation and you may not agree, but I believe this project could be much better maintained if it used a more structured ticketing style system to manage development issues instead of the current mailing lists. In my experience, mailing lists like this foster a terrible user experience where many development issues can go on without response.
Ideally, if there was a mailing list to address user issues and ticketing system like the one Digium uses to manage Asterisk, I think everyone would benefit by being better informed and ser would ultimately be a better product for it. How many people out there feel that their issues have fallen through the cracks in the past couple years?
-----Original Message----- From: Daniel-Constantin Mierla [mailto:daniel@voice-system.ro] Sent: Wednesday, June 15, 2005 4:28 AM To: Andrei Pelinescu-Onciul Cc: SER developer mailing list; serusers; users@openser.org; devel@openser.org Subject: Re: [Serusers] OpenSER release
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
_______________________________________________ Serusers mailing list Serusers@iptel.org http://mail.iptel.org/mailman/listinfo/serusers
I completely agree with you. I have been told that there was an attempt at introducing a bug-tracking system earlier, but that it has been difficult. Anyhow, in setting up policies and procedures around the experimental directory, we have decided that usage of http://bugs.sip-router.org will be mandatory. Hopefully recent, better integration between the bug tracking system and the CVS will make it more convenient to use also for other CVS modules (however, I don't have a say there). g-)
Giudice, Salvatore wrote:
I am not an advocate for either ser or openser, but I would like to comment.
Is openser going to be equipped with a forum/ticket system where people can document bugs, feature requests, etc (non-configuration issues)?
This is just my observation and you may not agree, but I believe this project could be much better maintained if it used a more structured ticketing style system to manage development issues instead of the current mailing lists. In my experience, mailing lists like this foster a terrible user experience where many development issues can go on without response.
Ideally, if there was a mailing list to address user issues and ticketing system like the one Digium uses to manage Asterisk, I think everyone would benefit by being better informed and ser would ultimately be a better product for it. How many people out there feel that their issues have fallen through the cracks in the past couple years?
-----Original Message----- From: Daniel-Constantin Mierla [mailto:daniel@voice-system.ro] Sent: Wednesday, June 15, 2005 4:28 AM To: Andrei Pelinescu-Onciul Cc: SER developer mailing list; serusers; users@openser.org; devel@openser.org Subject: Re: [Serusers] OpenSER release
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
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
And what about documentation? When was the last time that Administration Guide was updated? And what about the Modules documentation?
Regards
Alberto Cruz
Greger V. Teigre wrote:
I completely agree with you. I have been told that there was an attempt at introducing a bug-tracking system earlier, but that it has been difficult. Anyhow, in setting up policies and procedures around the experimental directory, we have decided that usage of http://bugs.sip-router.org will be mandatory. Hopefully recent, better integration between the bug tracking system and the CVS will make it more convenient to use also for other CVS modules (however, I don't have a say there). g-)
Giudice, Salvatore wrote:
I am not an advocate for either ser or openser, but I would like to comment.
Is openser going to be equipped with a forum/ticket system where people can document bugs, feature requests, etc (non-configuration issues)?
This is just my observation and you may not agree, but I believe this project could be much better maintained if it used a more structured ticketing style system to manage development issues instead of the current mailing lists. In my experience, mailing lists like this foster a terrible user experience where many development issues can go on without response.
Ideally, if there was a mailing list to address user issues and ticketing system like the one Digium uses to manage Asterisk, I think everyone would benefit by being better informed and ser would ultimately be a better product for it. How many people out there feel that their issues have fallen through the cracks in the past couple years?
-----Original Message----- From: Daniel-Constantin Mierla [mailto:daniel@voice-system.ro] Sent: Wednesday, June 15, 2005 4:28 AM To: Andrei Pelinescu-Onciul Cc: SER developer mailing list; serusers; users@openser.org; devel@openser.org Subject: Re: [Serusers] OpenSER release
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
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Hi!
I would provide additional documentation (to the modules I'm familiar with) - but the problem is the way how documentation must be added.
I'm not familiar with sgml. I do not know the syntax, I do not know how to create the README file out of the sgml file. I'm not a cvs expert.
Adding documentation is to complex. I already added asterisk documentation to voip-info because it is very easy to do.
Maybe we could find an easier way for providing documentation.
regards, klaus
Maxim Sobolev wrote:
On Wed, Jun 15, 2005 at 10:57:06PM -0500, Alberto Cruz wrote:
And what about documentation? When was the last time that Administration Guide was updated? And what about the Modules documentation?
Are you volunteering?
-Maxim
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
I dont think you should consider a Wiki (ie. voip-info) as equal to "official" documentation for a project.
That said, I agree that a Wiki run by some kind of authority in the SER community would be a good idea.
Cheers, Soren
Klaus Darilion wrote:
Hi!
I would provide additional documentation (to the modules I'm familiar with) - but the problem is the way how documentation must be added.
I'm not familiar with sgml. I do not know the syntax, I do not know how to create the README file out of the sgml file. I'm not a cvs expert.
Adding documentation is to complex. I already added asterisk documentation to voip-info because it is very easy to do.
Maybe we could find an easier way for providing documentation.
regards, klaus
Maxim Sobolev wrote:
On Wed, Jun 15, 2005 at 10:57:06PM -0500, Alberto Cruz wrote:
And what about documentation? When was the last time that Administration Guide was updated? And what about the Modules documentation?
Are you volunteering?
-Maxim
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serdev mailing list serdev@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serdev
On 16-06-2005 11:35, Klaus Darilion wrote:
Hi!
I would provide additional documentation (to the modules I'm familiar with) - but the problem is the way how documentation must be added.
I'm not familiar with sgml. I do not know the syntax, I do not know how to create the README file out of the sgml file. I'm not a cvs expert.
The format is docbook: http://www.docbook.org It is not complex, in my opinion, and you only need a couple of basic tags (you can use existing docs as reference).
We usually generate READMEs before every release.
Adding documentation is to complex. I already added asterisk documentation to voip-info because it is very easy to do.
Maybe we could find an easier way for providing documentation.
Suggestions welcome.
Jan.
Jan Janak wrote:
On 16-06-2005 11:35, Klaus Darilion wrote:
Hi!
I would provide additional documentation (to the modules I'm familiar with) - but the problem is the way how documentation must be added.
I'm not familiar with sgml. I do not know the syntax, I do not know how to create the README file out of the sgml file. I'm not a cvs expert.
The format is docbook: http://www.docbook.org It is not complex, in my opinion, and you only need a couple of basic tags (you can use existing docs as reference).
We usually generate READMEs before every release.
Thus, CVS-users must read sgml files drectly from the CVS to get documentation :-(
Generation of the README should be done automatically - e.g. every night using a cron job.
Adding documentation is to complex. I already added asterisk documentation to voip-info because it is very easy to do.
Maybe we could find an easier way for providing documentation.
Suggestions welcome.
I would prefer a webbased solution. Everytime I resolve an issue about ser and I want to add a note to the documentation, I want to do it in a fast way. I would go the the webpage (need not be a wiki), enhance the existing document - done. Commiting the new documentation to CVS and generating the README should be done automatically.
I do not know if such tools exist.
btw: why do developers enhance ser without updating the documentation? I guess because it is too time-consuming.
regards, klaus
Klaus Darilion wrote:
Jan Janak wrote:
On 16-06-2005 11:35, Klaus Darilion wrote:
Hi!
I would provide additional documentation (to the modules I'm familiar with) - but the problem is the way how documentation must be added.
I'm not familiar with sgml. I do not know the syntax, I do not know how to create the README file out of the sgml file. I'm not a cvs expert.
The format is docbook: http://www.docbook.org It is not complex, in my opinion, and you only need a couple of basic tags (you can use existing docs as reference).
We usually generate READMEs before every release.
Thus, CVS-users must read sgml files drectly from the CVS to get documentation :-(
Users of CVS version should know how to generate up to date documentation from the sgml when necessary, otherwise there is no point for them to use CVS version in the first place.
-Maxim
Generation of the README should be done automatically - e.g. every night using a cron job.
Adding documentation is to complex. I already added asterisk documentation to voip-info because it is very easy to do.
Maybe we could find an easier way for providing documentation.
Suggestions welcome.
I would prefer a webbased solution. Everytime I resolve an issue about ser and I want to add a note to the documentation, I want to do it in a fast way. I would go the the webpage (need not be a wiki), enhance the existing document - done. Commiting the new documentation to CVS and generating the README should be done automatically.
I do not know if such tools exist.
btw: why do developers enhance ser without updating the documentation? I guess because it is too time-consuming.
regards, klaus
Maxim Sobolev wrote:
Klaus Darilion wrote:
Thus, CVS-users must read sgml files drectly from the CVS to get documentation :-(
Users of CVS version should know how to generate up to date documentation from the sgml when necessary, otherwise there is no point for them to use CVS version in the first place.
Thus, CVS users may not have an easy way to read documentation? Maybe we should delete all init.d scripts from CVS as CVS users must be able write them themself!
I tried once but failed installing the proper software and DTDs. When it really that easy, maybe someone can help us adding a "make documentation" to the Makefile.
Developers complain that too less users are WRITING documentation. I'm willing to WRITE documentation, but I don't like DEVELOPING documentation.
regards, Klaus
-Maxim
Generation of the README should be done automatically - e.g. every night using a cron job.
Adding documentation is to complex. I already added asterisk documentation to voip-info because it is very easy to do.
Maybe we could find an easier way for providing documentation.
Suggestions welcome.
I would prefer a webbased solution. Everytime I resolve an issue about ser and I want to add a note to the documentation, I want to do it in a fast way. I would go the the webpage (need not be a wiki), enhance the existing document - done. Commiting the new documentation to CVS and generating the README should be done automatically.
I do not know if such tools exist.
btw: why do developers enhance ser without updating the documentation? I guess because it is too time-consuming.
regards, klaus
Thus, CVS-users must read sgml files drectly from the CVS to get documentation :-(
Users of CVS version should know how to generate up to date documentation from the sgml when necessary, otherwise there is no point for them to use CVS version in the first place.
Uhm... it was not easy to find a way to convert them to html but its easy.
jw -u -o pathtooutputdir/ patchtothesgmlfile/nameofthesgmlfile jw is a dookbook tool.
bye, Ingo
On 06/16/05 19:40, Ingo Wolfsberger wrote:
Thus, CVS-users must read sgml files drectly from the CVS to get documentation :-(
Users of CVS version should know how to generate up to date documentation from the sgml when necessary, otherwise there is no point for them to use CVS version in the first place.
Uhm... it was not easy to find a way to convert them to html but its easy.
jw -u -o pathtooutputdir/ patchtothesgmlfile/nameofthesgmlfile jw is a dookbook tool.
There are some other useful tools (which actually are wrappers): docbook2txt docbook2html docbook2pdf
The makefile in the new fork has now command to automatically generate the documentation based on this tools, e.g., make modules-readme make modules-docbook-html ...
Daniel
bye, Ingo
Daniel-Constantin Mierla wrote:
There are some other useful tools (which actually are wrappers): docbook2txt docbook2html docbook2pdf
The makefile in the new fork has now command to automatically generate the documentation based on this tools, e.g., make modules-readme make modules-docbook-html ...
cool. btw: Will you "backport" such features to ser?
regards, klaus
On 06/17/05 09:59, Klaus Darilion wrote:
Daniel-Constantin Mierla wrote:
There are some other useful tools (which actually are wrappers): docbook2txt docbook2html docbook2pdf
The makefile in the new fork has now command to automatically generate the documentation based on this tools, e.g., make modules-readme make modules-docbook-html ...
cool. btw: Will you "backport" such features to ser?
sure, I will create a patch.
Daniel
regards, klaus
On 06/17/05 14:45, Daniel-Constantin Mierla wrote:
On 06/17/05 09:59, Klaus Darilion wrote:
Daniel-Constantin Mierla wrote:
There are some other useful tools (which actually are wrappers): docbook2txt docbook2html docbook2pdf
The makefile in the new fork has now command to automatically generate the documentation based on this tools, e.g., make modules-readme make modules-docbook-html ...
cool. btw: Will you "backport" such features to ser?
sure, I will create a patch.
It was impossible to create and applicable patch -- there were some other changes in the Makefile, so I considered better to send the new make commands as attachment. You just have to copy and paste at the end of your Makefile.
Daniel
Daniel
regards, klaus
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
.PHONY: modules-readme modules-readme: -@for r in $(modules_basenames) "" ; do \ if [ -d "modules/$$r/doc" ]; then \ cd "modules/$$r/doc" ; \ if [ -f "$$r".sgml ]; then \ echo "" ; \ echo "docbook2txt $$r.sgml" ; \ docbook2txt "$$r".sgml ; \ mv "$$r".txt ../README ; \ fi ; \ cd ../../.. ; \ fi ; \ done
.PHONY: modules-docbook-txt modules-docbook-txt: -@for r in $(modules_basenames) "" ; do \ if [ -d "modules/$$r/doc" ]; then \ cd "modules/$$r/doc" ; \ if [ -f "$$r".sgml ]; then \ echo "" ; \ echo "docbook2txt $$r.sgml" ; \ docbook2txt "$$r".sgml ; \ fi ; \ cd ../../.. ; \ fi ; \ done
.PHONY: modules-docbook-html modules-docbook-html: -@for r in $(modules_basenames) "" ; do \ if [ -d "modules/$$r/doc" ]; then \ cd "modules/$$r/doc" ; \ if [ -f "$$r".sgml ]; then \ echo "" ; \ echo "docbook2html -u $$r.sgml" ; \ docbook2html -u "$$r".sgml ; \ fi ; \ cd ../../.. ; \ fi ; \ done
.PHONY: modules-docbook-pdf modules-docbook-pdf: -@for r in $(modules_basenames) "" ; do \ if [ -d "modules/$$r/doc" ]; then \ cd "modules/$$r/doc" ; \ if [ -f "$$r".sgml ]; then \ echo "" ; \ echo "docbook2pdf $$r.sgml" ; \ docbook2pdf "$$r".sgml ; \ fi ; \ cd ../../.. ; \ fi ; \ done
.PHONY: modules-docbook modules-docbook: modules-docbook-txt modules-docbook-html modules-docbook-pdf
install-modules-docbook: $(doc-prefix)/$(doc-dir) -@for r in $(modules_basenames) "" ; do \ if [ -n "$$r" ]; then \ if [ -d modules/"$$r"/doc ]; then \ if [ -f modules/"$$r"/doc/"$$r".txt ]; then \ $(INSTALL-TOUCH) $(doc-prefix)/$(doc-dir)/"$$r".txt ; \ $(INSTALL-DOC) modules/"$$r"/doc/"$$r".txt \ $(doc-prefix)/$(doc-dir)/"$$r".txt ; \ fi ; \ if [ -f modules/"$$r"/doc/"$$r".html ]; then \ $(INSTALL-TOUCH) $(doc-prefix)/$(doc-dir)/"$$r".html ; \ $(INSTALL-DOC) modules/"$$r"/doc/"$$r".html \ $(doc-prefix)/$(doc-dir)/"$$r".html ; \ fi ; \ if [ -f modules/"$$r"/doc/"$$r".pdf ]; then \ $(INSTALL-TOUCH) $(doc-prefix)/$(doc-dir)/"$$r".pdf ; \ $(INSTALL-DOC) modules/"$$r"/doc/"$$r".pdf \ $(doc-prefix)/$(doc-dir)/"$$r".pdf ; \ fi ; \ fi ; \ fi ; \ done
Maxim Sobolev writes:
Users of CVS version should know how to generate up to date documentation from the sgml when necessary, otherwise there is no point for them to use CVS version in the first place.
how about including in each module Makefile a README entry, i.e., "make README" would generate the file from sgml sources.
-- juha
Juha Heinanen wrote:
Maxim Sobolev writes:
Users of CVS version should know how to generate up to date documentation from the sgml when necessary, otherwise there is no point for them to use CVS version in the first place.
how about including in each module Makefile a README entry, i.e., "make README" would generate the file from sgml sources.
That makes great sense, actually it should be in the Makefile.rules. Still one will need to have enough clue to install docbook and friends.
-Maxim
On 16-06-2005 11:35, Klaus Darilion wrote:
Hi!
I would provide additional documentation (to the modules I'm familiar with) - but the problem is the way how documentation must be added.
I'm not familiar with sgml. I do not know the syntax, I do not know how to create the README file out of the sgml file. I'm not a cvs expert.
Adding documentation is to complex. I already added asterisk documentation to voip-info because it is very easy to do.
Maybe we could find an easier way for providing documentation.
There is a whole section on SER in the voip-info wiki:
http://www.voip-info.org/tiki-index.php?page=SIP+Express+Router
And guess what, most of the documentation just points back to the documentation generated from the docbook files.
Why people are not using that ? It has been there for ages, it was announced on the mailing lists several times and there is a link to it from the offical SER web page. Or is this still not obvious enough ?
I must be missing something, because I don't know how to make it any easier. Do you want something like http://wiki.iptel.org ? Is this the major problem ? If so I would be happy to create it.
Jan.
On Thursday 16 June 2005 18:45, Jan Janak wrote:
On 16-06-2005 11:35, Klaus Darilion wrote: There is a whole section on SER in the voip-info wiki:
http://www.voip-info.org/tiki-index.php?page=SIP+Express+Router
iptel.org, berlios.de, onsip.org, voip-info.org... please tell me the missing SER developer/user info sites that I've missed, there are far too few for my taste.
Seriously, I think this is one of the main problems of the SER project. I've seen people talk about a bugtracker, but not a single one mentioned the bugtracker from Berlios. By which I extrapolate that even the developers have lost the overview.
I must be missing something, because I don't know how to make it any easier. Do you want something like http://wiki.iptel.org ?
Would be great.
Is this the major problem ? If so I would be happy to create it.
use tikiwiki, then its even possible to have a forum with votes.
bye, Ingo
Jan Janak wrote:
On 16-06-2005 11:35, Klaus Darilion wrote:
Hi!
I would provide additional documentation (to the modules I'm familiar with) - but the problem is the way how documentation must be added.
I'm not familiar with sgml. I do not know the syntax, I do not know how to create the README file out of the sgml file. I'm not a cvs expert.
Adding documentation is to complex. I already added asterisk documentation to voip-info because it is very easy to do.
Maybe we could find an easier way for providing documentation.
There is a whole section on SER in the voip-info wiki:
http://www.voip-info.org/tiki-index.php?page=SIP+Express+Router
And guess what, most of the documentation just points back to the documentation generated from the docbook files.
Things are a little different. asterisk didn't had any documentation at all, those the wiki was accepted by users and they started writing the docu. ser already had a good docu (admins guide), thus, adding documentation to the wiki generates either redundancy, or an information split (one function documented on iptel.org, another one documented on the wiki). IMO, this is the reason why a wiki for ser is not the best solution.
Why people are not using that ? It has been there for ages, it was announced on the mailing lists several times and there is a link to it from the offical SER web page. Or is this still not obvious enough ?
I must be missing something, because I don't know how to make it any easier. Do you want something like http://wiki.iptel.org ? Is this the major problem ? If so I would be happy to create it.
There is one thing that must be avoided - duplicated documentation. Thus, we should stay with README files, or move them into a wiki - not both of them. Furthermore we would need a wiki with branches - so that users see which features are supported in which versions.
btw: and the wiki (hardware+software) should be more powerful than voip-info :-)
regards, klaus
On 15-06-2005 14:12, Giudice, Salvatore wrote:
I am not an advocate for either ser or openser, but I would like to comment.
Is openser going to be equipped with a forum/ticket system where people can document bugs, feature requests, etc (non-configuration issues)?
This is just my observation and you may not agree, but I believe this project could be much better maintained if it used a more structured ticketing style system to manage development issues instead of the current mailing lists. In my experience, mailing lists like this foster a terrible user experience where many development issues can go on without response.
Ideally, if there was a mailing list to address user issues and ticketing system like the one Digium uses to manage Asterisk, I think everyone would benefit by being better informed and ser would ultimately be a better product for it. How many people out there feel that their issues have fallen through the cracks in the past couple years?
I agree. We had an internal discussion about this a long time ago and came to the conclusion that it might be a good idea to give a bug tracking system another try (we tried to use it at the beginning of the project but it did not work).
So I set up Jira at http://bugs.sip-router.org and announced it to serdev. There was no feedback and I did not want to push it at that time (which was a mistake, probably).
Jan.
On 06/15/05 21:12, Giudice, Salvatore wrote:
I am not an advocate for either ser or openser, but I would like to comment.
Is openser going to be equipped with a forum/ticket system where people can document bugs, feature requests, etc (non-configuration issues)?
Thanks to VoIPUser.org, which volunteered to host and maintain, the OpenSER has already a forum for its community.
Visit it at your convenience at:
http://www.voipuser.org/forum_view_24.html
Daniel
-
Alberto Cruz -
Daniel-Constantin Mierla -
Giudice, Salvatore -
Greger V. Teigre -
Ingo Wolfsberger -
Jan Janak -
Juha Heinanen -
Klaus Darilion -
Marc Haisenko -
Maxim Sobolev -
Soren Davidsen