IRC Meeting minutes 17.02.2009, 15:00 UTC

<henningw> hi all <miconda> hello! <ibc> hi <ramona> hi! <henningw> hi carsten <henningw> := <henningw> ) <carstenbock> Hi! <carstenbock> I hope, i'm not too late…. <henningw> just started <carstenbock> Great <oej> Hi all <SebastianS> hi <henningw> ok, i think we can start now <miconda> yes

<henningw> first point on the agenda: 1.5.0 <miconda> release data … 2nd March? <miconda> … date… <henningw> is that what we originally proposed? <miconda> I guess it was 26th Feb, one month later than freeze date <henningw> ok, what about end of next week? this would be one month <miconda> which is Thursday, rather than Monday … which reminds me that Monday is not a good day for lot of work :) <miconda> it is more or less same date <henningw> yes <miconda> the issue with releasing on weekend is availability <miconda> and audience … <henningw> yes, we discussed, i remember ;) <miconda> anyhow, somehow I jumped to the end of the topic <miconda> let's see the state of the code … <miconda> I have testing presence and fixing stuff there <henningw> i started with pre-production tests last weeks, but mainly for cr and core <miconda> then I have a bit of dialog testing to do … <miconda> then I am ready – once I have presence updated, I will put it on same live system <miconda> with a pretty complex config file <miconda> covering most of the main modules <miconda> expect that tomorrow/the day after <henningw> ok. there are some smaller bugs open, e.g. some DB schema updates, and packaging fixes, but this will be possible for me to do in the next week <henningw> anybody see any critical issues open with the code we've now in the trunk? <miconda> I have many new modules in 1.5.0 running in production (e.g., sqlops, htable…) <miconda> good thing is that we haven;t touched the core that much <henningw> yes, i also though this.. <miconda> and the new features in the main modules came as standalone <miconda> which is good, and I think no much to do with database schema upgrade <henningw> its not that much work <miconda> not many old modules changed table structures … <miconda> ok, so we are standing well here … <henningw> then lets try to finish until next friday, and then release on monday, or tuesday (2/ 3th march) <miconda> ok <henningw> i'll send a packaging update to the devel list also <henningw> (for != debian) <miconda> thanks <osas> miconda, have you had a chance to take a look at the $T_rpl() issue? <miconda> something else about 1.5? <miconda> osas: it is on my todo …. <osas> I think that issue needs to be fixed before the release date <miconda> but I think you didn;t sent me all the sip trace I asked for <miconda> it will, if we discover the cause … I have to reproduce it … <osas> I will get some more SIP traces, but I sent you the config … <miconda> I will check the emails I have with you <osas> ok <miconda> yes, you sent it, I am using it … <ibc> Is it planned a script to migrate DB's? when upgrading Kamailio some table version numbers are incremented so the old database cannot be used and require some manual and dirty workaround by copying databases, dumps, and so… <miconda> but cannot reproduce … could be that I am using same kind of sip request to reproduce <henningw> ibc: there used to be some code (at least for mysql) in kamdbctl, but this is not up to date i think <osas> miconda, I will see what else I can investigate with respect to this issue <miconda> osas: ok, thanks <henningw> ibc: you've tried the kamdbctl migrate? <miconda> ibc, henningw: maybe we can get something better now <miconda> if there are not many changes in the old db schema <miconda> maybe we can provide an script with alter table … statements and updates to version table <miconda> to be investigated though … <henningw> on the 1.5 migrate page there are some tables update hints <henningw> in the wiki <ibc> what I do is a slq dump (just data, no tables structure) and import it in the new table. If it returns an error I already know that the old data is not compatible with the new version, but this is not very usual. <miconda> http://www.kamailio.org/dokuwiki/doku.php/install:1.4.x-to-1.5.0 <henningw> the old migrate command should be at least updated, that it don't produce any errors <miconda> I think LCR has some updates as well … <henningw> yes <miconda> ok … we can check all and have a script … <miconda> something else with 1.5? <henningw> it seems not.. <miconda> ok

<henningw> then lets proceed to the next topic, 1.4.4 <miconda> before or after 1.5? <miconda> if we do it after, we may have some extra fixes <miconda> to backport <henningw> i just checked, there are not that much changes in the logs yet, so later sounds more sensible <miconda> ok <osas> does anyone uses postgres with 1.4 <osas> ? <henningw> the most important fix is one mem leak for postgres, <miconda> <osas> I think there are some serious issues with postgres <osas> some crashes <osas> last time when I tried to upgrade a system from 1.4 to 1.4 it failed <osas> srry, from 1.3 to 1.4 <osas> henningw, I think you managed to reproduce a crash during some tests … <osas> or was it only a mem leak? <henningw> i've had a extensive debug session for 1.5 on postgres <henningw> there i fixed some bugs and some regressions <henningw> so far the 1.5.0 state of pg is now pretty stable, at least i did not received any reports from Bayan in the last month <osas> I see <henningw> osas: you've send me a mail for this, or its there a bug open? <osas> no, there's no bug opened <osas> I will see if I can reproduce it <henningw> ok, if you've a crash dump, just send it me. i can do some tests as well <osas> the crash doesn't tell you much <osas> the memory is polluted <fcois93> hello <fcois93> anybody tried to interconnect openser↔A2Billing ? <henningw> ok <osas> the crash is while trying to print a syslog <miconda> osas: compile with memory debug on <miconda> probably there is a overflow somewhere … <osas> it was on a live system …. <miconda> I see <henningw> i love this bugs.. :) <osas> hehe <osas> maybe I will try an upgrade to 1.5 <miconda> these with memory are easier to detect in debug mode … <henningw> anyway, i'll try to review the stuff i've done for 1.5.0, perhaps there is some oportunity to backport a fix <miconda> other experiences with 1.4? <miconda> ok, then new 1.4.4 release after 1.5.0 … <miconda> this will mark the end of releasing 1.3.x <miconda> although some fixes and updates will happen there from time to time … <henningw> yes <miconda> next?

<henningw> status update about sr project <miconda> I added it before 1.6 … <miconda> not sure how many followed sr-dev list <miconda> but there was lot of work in the last time <henningw> if you want to move it to the end, fine <miconda> practically the main components are integrated <henningw> yes, Jan merged the combined SER/ Kamailio DB for mysql in the last days.. <miconda> no, it is better before, as 1.6 depends on it … <ibc> yes, over 500 commits a day from Jan Janak XD <miconda> that because he imported the history <miconda> the commits from kamailio and ser in the past … <ibc> nice to know, thanks <henningw> or he've some super-human strengs.. ;D <henningw> yes, the list is a bit misleading <henningw> hard to keep up for reading.. <miconda> yes missing the real emails in the ocean of commits … <miconda> anyhow <henningw> Jan already managed to run two modules with DB from SER and kamailio in the same server process/ script <miconda> db api is there <miconda> both versions <miconda> named <miconda> db1 and db2 <miconda> 1 is kamailio/openser <miconda> 2 is ser <miconda> 2 has prepared statements and a different approach <miconda> 1 is the old ser 0.9.x style polished by us for some improvements over the time <miconda> so, practically, as henningw mentioned, you can run modules from both projects at the same time <miconda> other updates: MI is there as library <miconda> lib/kmi <miconda> small tweaks are required to mi transports <miconda> these days I will post the guideline … <henningw> how to port? <miconda> how to test … probably will end to some updates in kamailio or sr core after 1.5 <miconda> so won't be a need to tweak on the fly, just grab the module and run <henningw> yes, would be cool to make this as painless as possible <miconda> the issue is related to forking processes <miconda> it will be … just that we are locked now in K for 1.5 <miconda> one question here <miconda> there are some implementations in the core of mi and statistics – imo they do not belong there <miconda> should we move to modules? <miconda> e.g., printing statistics via mi … <miconda> a good place will be statistics module … <miconda> not this mi command is in statistics core … <miconda> s/not/now/ <henningw> i've nothing against it, we need to check if statistics don't install some callbacks or something other with possible side efects thought <miconda> statistics core (i just committed) is not lib/kstats <miconda> i still have to work a bit on it, we may get benefits from the atomic ops in ser … support for more archs and some other alternatives like barriers (good for read) <miconda> henningw: no, the core stats were removed … <henningw> I remember that Juha sometimes ago run into some limitations from our atomic ops, would be good to have better support here <miconda> we have to figure out a callback system … now were just plugged in some #defs <henningw> ok <miconda> so we are pretty done with these parts <miconda> big stuff to review: <miconda> - core extensions in kamailio <miconda> - tm extensions in kamailio <miconda> for first, SR already has the while <henningw> yes <miconda> improved with break support to jump out <miconda> switch is there for integers <miconda> string version to be committed soon <henningw> did we get one version for both? <miconda> also there are some improvements for speed <miconda> and probably regexp matching for strings (thanks ibc for idea) <miconda> yes, one for both … it is what i want there <henningw> very good :) <henningw> that was the core, what will be the plan with regards to the modules, should be start to move them to the sip-router repository? <henningw> (i think this already belongs to the 1.6.0 topic) <henningw> and where should new development happened, new modules..? <miconda> there might be modules in parallel for a while … <miconda> old modules (e.g., usrloc) … <miconda> let's finish about tm … <henningw> sure <miconda> one thing that I started to dislike is that tm gets bigger and bigger … <miconda> so I though we may have one basic module for transaction management <miconda> and another one for extensions … <miconda> e.g., related to something I added … $T_req(…) should get into tm extensions module <osas> this should be discussed on the sr project <miconda> in this way we have a light and performant tm core, for cases like load balancers … <osas> to get more imput <miconda> yes …

<osas> let's focus on the kam issue for now <miconda> just exposing here the intial thoughts … <osas> s/issue/topic/ <osas> yup :) <miconda> ok … <osas> but let's not spin on this … <osas> how are we going to proceed with kam on top of the sr core? <osas> are we goint to have all the code in one single place? <osas> moving the modules to git? <osas> or two repos: git for core/tm and svn for modules? <miconda> it is hard to say until we don;t decide about duplicate modules <miconda> I would prefer one place where to get all <osas> do we have a list of duplicated modules? <miconda> even if we have to mirror core and tm for a while <miconda> until we figure out the conflicts <henningw> i would also prefer to have one place, but the import of all modules will not happen over night.. <miconda> probably we will go with duplicate repos for a while anyhow <henningw> yes, a option would be to just import the core and tm into our repository for 1.6.0, and parallel starting to migrate our modules to git. <miconda> so, it could be: <miconda> import core and tm from sr <miconda> make modules to work as supposed … <miconda> then decide what to do with duplicates and eventually move to git the modules <osas> we need a clear strategy right from the beginning <osas> here's a proposal <osas> for 1.6, for kam, stick with svn <osas> import the new core and tm from git into svn <osas> all dev for kam will be done on svn <miconda> but devel for core and tm to be done in git, right? <osas> we will do dev for core and tm on git repo and import them back into svn <miconda> ok <osas> no dev for core and tm on svn <henningw> and new modules should also end up in git <osas> make all the changes for the modules on svn <osas> for 1.7, move everything into git <osas> well, even new modules should be in svn <osas> if the author wants to host them on git and import the changes into svn, that's fine by me <osas> all I want is a simple way to get the code out <miconda> yes, that should be a priority <henningw> ok, i also don't want that our users need to mix several repos <miconda> otherwise is hard to addopt <osas> if someone not familiar with kam wants to start meesing with it, it must be simple <osas> pull everything from svn in 1.6 <osas> and for 1.7, move to git <osas> everything <henningw> but i think we'll then try to release 1.6.0 fast, shorter than the usual 6 month <osas> what happens between git and svn for core/tm and maybe new modules, it's for devs <miconda> maybe 1.6 will include modules from ser found useful .. <osas> but for users it should be straight forward and simple <miconda> henningw: I hope to have at least frozen code in May <miconda> the focus should be integration <henningw> that means two month development <miconda> rather than much new devel <osas> if there are modules without conflict, then those modules can be hosted on git and mirrored on svn <henningw> May sounds good <miconda> yes, but we get dozens of improvements by core and other ser modules that can run out of the box <osas> this will need to be discussed with ser (the modules being hosted on git) <miconda> for our users will be lot of new features … <henningw> we should also discuss with the ser guys about their release plans.. <osas> so, for 1.7 we can aim mostly fot core/tm integration <osas> not a lot of new kam features <osas> in this case, we can make the release time short and stable <miconda> for 1.6… <miconda> not 1.7 <osas> srry, right <osas> so 1.6 will be mostly git/svn svn/git migration <miconda> osas: it is what I aim … release time short and stable <miconda> yes <osas> and for the regular users, the code will be available via svn <osas> just like before <miconda> with these new benefits: http://sip-router.org/benefits/ <henningw> so to get a rough idea, 1.7.0 will be then happen somewhere beginning next winter? <osas> or sooner :) <miconda> kind of <miconda> <miconda> ok then: 1.6 - one repo, the svn <miconda> core+tm done in git and mirrored to svn <osas> for users who want to buld from src <miconda> other modules: up to devels <osas> yup <miconda> but must be mirrored on svn anyhow <osas> yes <osas> the svn is the main repo for users <henningw> ok <miconda> something else related to this topic? <miconda> we covered sip-router and kamailio 1.6 <osas> we will need to coordinate with ser about duplicated modules <henningw> ok, what is with the DB side? when we want to use prep statements, we also need to import the drivers.. <osas> an dthe migration to git <miconda> as it is now, the drivers will be common <miconda> we will integrated them <miconda> db_mysql on sr implements both DB api versions <henningw> ok, then i really need to take a look to the diffs Jan posted. ;) <miconda> not sure will work with all db drivers … <miconda> like db_text <henningw> for some of them we've problably to few testing coverage, IMHO <miconda> for such complex cases, we probably can get db_text1 and db_text2 <miconda> I would say we are 60-70% done with sr integration <henningw> yes, most uses mysql and postgres anyway <miconda> after 1.5 release, I will have main devel effort directed there … <henningw> i'll port cr and friends, and also start with the DB migration on our side <miconda> so May is a good timeline for 1.6 … just to end the resume .. <osas> if everything works ok, why not :) <miconda> ok, done with these two (sr update and kam 1.6)? <osas> it seems so … <miconda> then next …

<miconda> migration tools was kind of approached already <miconda> for db <miconda> but might refer to sr migration .. <miconda> as well … however, it is not the time for that … <miconda> one thing I forgot to add, is ideas for better indexing the docs <miconda> we have good examples on wiki, not very visible … <henningw> SER experimented in the past with some flash stuff, but this was also not that optimal.. <miconda> I started this page: <miconda> http://www.kamailio.org/dokuwiki/doku.php/cfg-scripts-bank:main-index <miconda> to collect config snippets … <miconda> but I am afraid will end up in the wiki crowd … <miconda> does this dokuwiki has tagging? <miconda> would be a form to index … <henningw> perhaps with some plugin? <miconda> e.g., pages with examples … <miconda> ok, to check … <miconda> I think ser had at a point a search engine <miconda> that could go over module docs, core docs. etc … I will check <miconda> maybe we can reuse … <henningw> we could use google with a restriction for kamailio.org <henningw> its easy to setup <miconda> one good step to start … <henningw> just a link/ form <miconda> I think can be added in wiki … <henningw> there is the build-in search in the wiki already, but this only index the wiki content <miconda> also, we should put together some tutorials <miconda> like Interaction with database – so people do not start developing c code to get db values <miconda> they can use sqlops or avpops module <henningw> would be useful, yes <miconda> first example I added in the link above is focusing on that <miconda> e.g., http://www.kamailio.org/dokuwiki/doku.php/cfg-scripts-bank:group-dial <henningw> you also added this 3rd party topics to the agenda.. <miconda> yes <miconda> from the discussions on mailing lists <henningw> with Stefan from SEMS? <miconda> yes … but not only, do you (all) feel we miss something in integration with other voip applications? <ibc> I think Kamailio is enough powerful to integrate with others, the problem are “the others” :) <miconda> (one question above was integration with a2billing … ) <ibc> yes yes, and “how Kamailio to handle media” XD <miconda> ibc: ok, then we are fine … <miconda> just wanted to see if something can be improved here based on your experiences <miconda> last one: additional applications … <miconda> we will get a CLI interface with sip-router <miconda> s/CLI interface/CLI/ <ibc> I've missed nothing when integrating Kamailio with other SIP applications (Asterisk, SEMS, FreeSwitch…) <henningw> ibc: the problem are always the others, but i agree here of course <miconda> :) <miconda> we have siremis for admins, and probably will be serweb for users (not sure if there is development in this project) <miconda> kamailio has the old shell base ctl tool, in ser is something perl or python, if I got it right … <henningw> i think they use python? but don't remember it correctly <henningw> anyway, probably better from an architectural POV then our scripts <miconda> “lovely” python: http://cvs.berlios.de/cgi-bin/viewvc.cgi/ser/serctl/ <henningw> better than perl ;) <miconda> anyway, do we miss something obvious from our horizons ?!? <ramona> I would like to ask some feedback about siremis .. is it easy and straightforward to use ? <henningw> i only used the web demo so far, but this looked really good <ramona> ok <osas> ramona, I think you will need to give the users a little bit more time (and let them migrate to 1.5) :) <ramona> :) <henningw> but its probably another thing to be a newbie and have no clue about the server at all.. <osas> ramona, thx for the hard work :) <ramona> welcome <henningw> i mean, its prettyhard for an application when the server don't know the basics. yes, thanks

<miconda> someone else willing to discuss new topics? <henningw> s/server/user.. <miconda> … if not, we should be done … <miconda> 30min over the 1h estimation <henningw> seems so.. yes :) <henningw> i can do the minutes as usual, what about the ser guys? do we want to write a short summary about our release plans or so? <miconda> we can send all over … <miconda> they should know about it from Karlsruhe meeting <henningw> ok, fine. if there is some volunteer for formatting the minutes i'm of course happy to step aside ;) <miconda> :) <henningw> seems not, ok <miconda> ok then, thanks everyone … back to coding <henningw> thank you <miconda> any new ideas, shot an email to devel list <miconda> or here, we will be around …