[Kamailio-Users] [Fwd: [Kamailio-Devel] Karlsruhe meeting minutes]

-------- Original Message -------- Subject: [Kamailio-Devel] Karlsruhe meeting minutes Date: Thu, 20 Nov 2008 01:35:25 +0100 From: Andrei Pelinescu-Onciul <andrei(a)iptel.org> To: sr-dev(a)lists.sip-router.org, devel(a)lists.kamailio.org, serdev(a)iptel.org Hi, I've attached a very brief version of the Karlsruhe meeting minutes. It contains input mostly from me and Daniel (so that you know who to blame :-)). Sorry for the long delay. Hope we haven't missed anything and if we did feel free to reply to this thread. Thanks a lot to 1&1 for hosting the meeting and to everyone who was able to come on such a short notice. Andrei - move forward, sip-router.org repo should be up next week - end of January we should have a runable core+tm with support for the most used features from both kamailo and ser (100% support might be a little delayed) - kamailo next-next release (probably after spring next year) will be based on sip-router core+tm - next or next-next ser release will be based on sip-router (ser might make another 2.1 release from the current cvs, since the code is ready - to be discussed) - future releases will most likely be common and will unify all or most of the modules (depending on everything up to that point working ok) - copyright: patches that are not accompanied by (c) claims will not add to the (c). We should put this on a web page and when in doubt we can ask the patch author for confirmation. While it's likely this has no or very limited legal value (especially in Europe), it will server at least as a gentleman agreement. We need this because: 1. we need the agreement of all (c) holders for the GPL code to add licensing exemptions (e.g. we need to add an openssl linking exemption) and it's easy if we have a known "small" set of (c) holders 2. people might not like having multiple (c) notices on files they created, just because someone did send a trivial or not so significant patch (note: "trivial" and "significant" are very relative) On problems, probably the board will decide, if nobody gives up the claim we'll fork the module (worst case, to be avoided as hard as possible). - forking modules: highly discouraged, but allowed - unmantained and rarely used modules: removed after a grace period - board: for now we continue to have 2 boards, ser and kamailo at least until we have something runable. In the meantime we should think/discuss how the common board will look like: how it will be elected and for how long, "composition" (how many devels, how many from the user community, testers a.s.o) - testing: very important, Jerome proposed having beta-tester groups and stressed out the importance of dynamic tested. Everybody seems to agree, but there are doubts about finding beta-testers volunteers. - release management: we need a release manager for each release - documentation: kamailo uses a wiki for core, and docbook .xml for modules ser use NEWS (txt file) for core and docbook for modules, but it's in the process of migrating to a more man page friendly format (still .xml) More discussion is needed, between the main doc writers from both sided. sip-router.org: - repo should be up next week - sr-dev should be used for technical dicussions related to merging the cores - new features mails should be cc'ed to sr-dev too (very important especially when core or tm is involved). - todo: find easy to remember short name related projects: - some modules may be on separate repos for a while (e.g., openimscore), maintaned by their devs for using them out of the box with sip-router - stand-alone application servers (Voztelecom/WeSIP, Iptego/SASI) may merge the communication interface specs in the future. - it is a need for a place where to collect basic info about related projects further steps: - new meeting, to be organized somewhere end of winter/beginning of spring 2009 (topics: celebrate first integrated working version, discuss further development of sip-router) - setup of adjacent tools that help developing code and documentation (e.g., wiki, tracker) general opinions: - there are x-ser platforms running milions of users, sip-router must provide a rock-solid SIP server, esure trust and project reliability - while having a strong focus on above item, innovation shall not be stopped, new features to be added as module to avoid effects to core and main modules - very important modules (e.g., usrloc, registrar, ...) should be protected as much as possible, patches and new features to be carefully reviewed not to affect stability and interoperability - improvements to most important parts to be discussed on sr-dev mailing list _______________________________________________ Devel mailing list Devel(a)lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/devel