[Kamailio-Devel] Karlsruhe meeting minutes

[Andrei Pelinescu-Onciul]

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
-------------- next part --------------

- 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