I am trying to summarize the outcome of the IRC devel meeting from last Thursday, Nov 06, 2008. The log is available here...
Regarding the 1.3.x series, we set the 20th of November as the date for 1.3.4 release. There are several fixes and this branch is still used in many production environments, so it worths investing time in it. There are some updates in 1.4.x to be ported and some issues to be investigated.
For a new 1.4.x release (the 1.4.3) we look for the beginning of December as the time frame for setting the date of the release.
The 1.5.x rises in the first phase the question of a shorter time release, as we have lot of new features already implemented, see:
http://www.kamailio.org/dokuwiki/doku.php/features:new-in-1.5.x
http://www.kamailio.org/dokuwiki/doku.php/roadmap:1.5.x
Unfortunately some of the new features are not completed yet (e.g., htable, carrierroute updates, PV migration) so we will stick to 6-8 months release cycle. The next major one that will use the common layer (core and tm) from sip-router could be done in a shorter time than
usual. So, beginning to mid of January should be the time to freeze the code for a release date somewhere in end of January or February.
An important aspect approached during the discussions was the release management and testing management. Perhaps we need to appoint a person to manage releasing process in order to have a better synchronization of the developers. As everyone agrees, testing is very important and we try to improve it. There is a testing suite included in the source tree right now, used for static testing.
The idea of a dynamic testing and testing community was introduced and hopefully we can attract people and build a group of beta testers. There is a proposal of how to implement and what to take care of, probably this one has to continue on devel and users mailing lists for a proper
organizational structure.
GIT became as a subject of migrating from SVN, because of its features for a distributed development environment. However, sourceforge.net does not have such offerings, so it is not possible now anyhow. However the sip-router.org will use it.
Regarding the sip-router.org project, we focused on short term goals, acknowledging that we have several modules offering same functionality but relying on different underlaying data structures, this have to co-exists for a longer time. For the first phase, core + tm the overlapping is rather small, the two projects insisting in the past to improve different aspects of them.
Unfortunately I forgot to bring up some punctual topics proposed, mainly related to tm failure route calling in case of sending error and reply handling/dropping in onreply_routes.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment