Ladies and gentlemen,
I'm glad to invite you to a meeting of SER users and developers in March 2007, in Prague, Czech Republic. See more at http://www.iptel.org/ietf_meeting
I'm looking forward to seeing you there. In the meantime, please register yourself if you plan to attend and don't hesitate to make any agenda suggestions -- SER related ideally, even though any "social" suggestions are perfectly fine too.
I can promise you it will be a wonderful event -- Prague is beatiful, SER is beatiful, and so is the folks involved in SER development -- LET'S MEET!
-jiri
-- Jiri Kuthan http://iptel.org/~jiri/
Hi
for the SER meeting I would like to propose two items on the agenda:
* Migrate from CVS to Subversion.
Subversion gives us many advantages such as history on directories and atomic commits. Atomic changesets can be reviewed as one diff and applied to any branch, if needed. All changes should also be sent to -dev list (as today) but perhaps also include the full changeset, this makes the change more visible, easier for offline viewing and hopefully more eyeballs will spot potential bugs. I am sure there are many developers here on the list who have good experience with Subversion.
* SER config reload
It would be nice to add the possibility of reloading the config file without shutting down SER. Consider an instance of SER with 10000 active TCP connections to 10000 useragents. The TCP connections are maintained by the TCP processes, and if we had "ser reload" it would have been possible to reload the config file and keep the TCP processes running. Now, if this is feasible at all I do not know but it certainly would have been a great feature to have ;)
/alfred
Jiri Kuthan wrote:
Ladies and gentlemen,
I'm glad to invite you to a meeting of SER users and developers in March 2007, in Prague, Czech Republic. See more at http://www.iptel.org/ietf_meeting
I'm looking forward to seeing you there. In the meantime, please register yourself if you plan to attend and don't hesitate to make any agenda suggestions -- SER related ideally, even though any "social" suggestions are perfectly fine too.
I can promise you it will be a wonderful event -- Prague is beatiful, SER is beatiful, and so is the folks involved in SER development -- LET'S MEET!
-jiri
-- Jiri Kuthan http://iptel.org/~jiri/
Serdev mailing list Serdev@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serdev
On Feb 23, 2007 at 15:07, Alfred E. Heggestad aeh@db.org wrote:
Hi
for the SER meeting I would like to propose two items on the agenda:
Migrate from CVS to Subversion.
Subversion gives us many advantages such as history on directories and atomic commits. Atomic changesets can be reviewed as one diff and applied to any branch, if needed. All changes should also be sent to -dev list (as today) but perhaps also include the full changeset, this makes the change more visible, easier for offline viewing and hopefully more eyeballs will spot potential bugs. I am sure there are many developers here on the list who have good experience with Subversion.
I thought we've already discussed this on this list and we even had a vote. The conclusion was to stick with cvs.
I don't understand the part about the full changesets and making changes more visisble. Every commit log already has links to the diffs.
SER config reload
It would be nice to add the possibility of reloading the config file without shutting down SER. Consider an instance of SER with 10000 active TCP connections to 10000 useragents. The TCP connections are maintained by the TCP processes, and if we had "ser reload" it would have been possible to reload the config file and keep the TCP processes running. Now, if this is feasible at all I do not know but it certainly would have been a great feature to have ;)
It would be nice, but it's too difficult and time consuming (at least in the general case). It would require some major changes. So this is a "maybe" for ser 5.0 :-)
Andrei
At 18:06 23/02/2007, Andrei Pelinescu-Onciul wrote:
SER config reload
It would be nice to add the possibility of reloading the config file without shutting down SER. Consider an instance of SER with 10000 active TCP connections to 10000 useragents. The TCP connections are maintained by the TCP processes, and if we had "ser reload" it would have been possible to reload the config file and keep the TCP processes running. Now, if this is feasible at all I do not know but it certainly would have been a great feature to have ;)
It would be nice, but it's too difficult and time consuming (at least in the general case). It would require some major changes. So this is a "maybe" for ser 5.0 :-)
depends on how far we go. reloading AVPs can address many usecases without causing a big rewrite.
-jiri
-- Jiri Kuthan http://iptel.org/~jiri/
Alfred E. Heggestad wrote:
Hi
for the SER meeting I would like to propose two items on the agenda:
Migrate from CVS to Subversion.
Subversion gives us many advantages such as history on directories and atomic commits. Atomic changesets can be reviewed as one diff and applied to any branch, if needed. All changes should also be sent to -dev list (as today) but perhaps also include the full changeset, this makes the change more visible, easier for offline viewing and hopefully more eyeballs will spot potential bugs. I am sure there are many developers here on the list who have good experience with Subversion.
I started the discussion on serdev mailing list some time ago and it turned out that we were not able to get into any agreement regarding version control system changes. From some private discussions I understood that vast majority of people wanted to switch over to svn, but in a public poll the situation was a bit different.
SER config reload
It would be nice to add the possibility of reloading the config file without shutting down SER. Consider an instance of SER with 10000 active TCP connections to 10000 useragents. The TCP connections are maintained by the TCP processes, and if we had "ser reload" it would have been possible to reload the config file and keep the TCP processes running. Now, if this is feasible at all I do not know but it certainly would have been a great feature to have ;)
I think Andrei already replied this.
Jan.
-
Alfred E. Heggestad -
Andrei Pelinescu-Onciul -
Jan Janak -
Jiri Kuthan