http://www.kamailio.org/dokuwiki/doku.php/development:irc-meeting-agenda-draft this is the irc meeting agenda not the Karlsruhe agenda :-) ;) yes hi everybody! I guess we can start Hiiiiiii Daniieeeelll I believe 1.3 is still the most used version out there so we do put a lot of effort in keeping it up to date any critical issue you are aware in 1.3 branch? shall we release 1.3.4? i think we should release those questions need some answers ok, so 1.3.4, probably next week is not good time i'm not aware of any issues special to the 1.3 branch as many travels yes if you released 1.3.4 what will be the new stuff to add to it ? I saw couple of fixes in the last time to 1.3 branch, so I guess we are ok for 1.3.4, we just need the time minor releases are just for bug fixes no new features ah , ok those come with major releases good , then agree with that so, 2 weeks from now on? for 1.3.4? 18th november? 20th november? 20? 20 I suggest rouning releases dates to the next monday in general why monday? Start of business week People usually do not fiddle too much on weekends with new versions ok, new week, new release, understand :) leaves the in-between "extra-time"for release Developpers usually have more work done on weekends than users usually people wait 1-2 day until they do upgrade or it is just me :-) :) mondays proved to me very busy yup yes I could not say, I usually set up a staging sever for 1 week at least before upgrading production and as involved in releasing, might not be appropriate This makes sense perhaps we can move from thursday to wednesday or tuesday I don't think than setting up a rule like this is crucial ... this is also true sorry then :-) (I agree it is not critical) let's move on with important things ok, so 1.3.4 is closed? 20, ack anyhting else regarding 1.3.x? that mem leak from avpops I think that's the only issue in 1.3 not sure if it's present in 1.4 osas: is on the tracker, right? I will review before 1.3 I will have soon a server in 1.4 (the one that was experiencing issues in 1.3) and I will report I know that it was on the ml If I may dunno about the tracker let me check ... The benchmark bugs are common to 1.3 and 1.4 and are anoying But low priority Definatily not worth rushing for 1.3 In tracker, DNS_name to IP coredump is high is this on 1.3.x? tagged as such http://sourceforge.net/tracker/index.php?func=detail&aid=2102541&group_id=139143&atid=743020 But I do not know firsthand i think i discussed this with Klaus privatly with the reporter he wanted to created another trace/ core dump, and send it to us. but i did not receive anything so far, did not asked though asked a few times, but not recently ok, 1.4.x last one was Oct 23 several fixes meanwhile ... when to go for 1.4.3? there is a thing related to the SRV randomisation that needed to backported, the bugs for usrloc and cr apply also for 1.4 (bugs in registrar) i'd suggest after 1.3.4 ... and benchmark counters (I am lobbying for this one) i think bastian created the benchmark module, perhaps i can ask him, don't know the code that much ok, I will take care of contacting him as I am the one begging for this. ok, good in my todo bug created for PKG mem leak issue: https://sourceforge.net/tracker/index.php?func=detail&aid=2229966&group_id=139143&atid=743020 osas: thanks np hmmm we get just before the Christmas travelings anyone proposing a date? for next 1.4.x release Well, if it is not around dec. 20th it has to be around jan 3 Not before for obvious reasons let's plan for December and we will set up the date later on begining of december, ok ok, let's what we can get then so, now to most interesting parts roadmap to 1.5.0 you have details at: http://www.kamailio.org/dokuwiki/doku.php/features:new-in-1.5.x its already quite a lot of stuff :) http://www.kamailio.org/dokuwiki/doku.php/roadmap:1.5.x so, should we release :-)? not yet ok :-) so, where shoud we set higher priority? what is really lacking in 1.4 guys I cannot pass over this: INVITE sip:1234 -> timeout in failure route so forward to another sip:abcd. The problem is that 200 OK from abcd is passed to sip:1234 so the ACK from 1234 has new branche and thus it is not routed back to abcd. hope you understand this :) <-> festr_> please wait a bit, we're just having a conference hmm henningw, why do you think that we should not release yet? i want to finish the cr reworking, make the route/ carrier lookup also O(log n) osas: some of the features are half done like htable module or PV migration to modules we've also one or two modules/ module extensions that we most probably like to contribute let's set a release date target and finish the work before that I, at least, planned to stick to 6-8 months release cycle yes, make sense Kamailio 1.4.0 released on August 7, 2008. there are already intersting features (like juha's lcr enhancements) and ppl would like to have them out maybe, from the perspective of using the common core and tm asap, we can do 1.5.0 a bit earlier I would like to have the cr enhancements on 1.5 :) anyhow, I doubt it can be done before the new year hehe :-) no, not before the new year then lets target Januar maybe we can freeze by mid january but end of january freeze by the end of the year (no new features) and in the freeze period: bug fixes and then release it sounds resonable and a minor release after two weeks ;) we can try .. he he :D well ... this is how it works ppl really start testing after the release date nobody tries a pre-release, :-/ yup you are so laizy, I do testing for my configs, of course ... :) ... and freeze before vacation guarantees no testing it is already difficult to get people to test before release ... how is the testing framework henning? can we do some performance regretion, etc... no to summarize if we do freeze before Christmas, nobody tests i added new/ extended old tests, buts its still a long way to a good coverage but not many do before release anyhow this came up in the past, perhaps we can release a beta, or RC candiate? not sure if this helps in this regards SER does it IMHO I don't think that it really helps just release and do a minor release in two weeks yes, its more or less the same, and we're used to it ;) I agree, only "final versions"really trigger a reaction from community ppl will not test a release candidate yup :) So we know it is a beta, let's call it final .0 :) I have many x.y.0 in production still but because it was tested for those configs before release ok, so to be really honenst about this, mention somewhere in the wiki that .0 is "for preproduction" if we say so, then nobody will use it before one is set production it is what we have for long time c'mon guys, we are burning to much gas here .... does not mater if it is called beta, rc or preproduction if one sees that won't use from my point of view, .0 is production ready I am not using all modules though but we cannot do more that that so, let's stick to .0 as major release no, rc, beta, preproduction or other namings ... all those shall be done before, if it is a need for such the issue is not the naming scheme, the issue is to get an organised community, and this is tuff work, requires people dedicated to it but this could be the topic of an other meeting and will probably be something raised for sip-router meeting we will need to go for a release manager and some assistants ... there are quite many devs, so we need to coordinate somehow probably we will have another irc discussion just before freezing When I was working at mandrakesoft, we used a 3 circles approch: circle one are developpers, circle 2 are reference users tat get a benefit for that status and in exchange test pre releases in their environment, circle 3 is the community at large. The challenge is to create that 2nd circle and MANAGE it Creating that subset can be done with develloppers time: exchaneg a commitment to test for some free support i tried to make testing easier, building this daily debian packages of trunk for example, but this should be extended you're right, it will be a challenge in creating such a circle It is possible, believe me I could give details at a proper time lets bring this topic on the table in the next week with the SER guys ok, I will mark in my todo list to send an email to developpers with my ideas about this well, ok, then I will prepare some doc for monday good, thanks another thing that I would like to discuss ... last time I was pushing for cvs to svn migration what about svn to git or hg migration? sip-router.org is already planned to run on git moving away form a centralized repo that's good I thought git was a requisite of sip-router it helps a lot in porting forward stuff the issue is that sf doesn't support git (afaik) is that right? i also think so so, what is the solution here? move away from sf? i'd suggest that we get some experiences with git in sip-router (i now nothing), and then see how we proceed The help page says : "CVS/Subversion/User Accounts/Mailing list Admins: Security issues related to project CVS/Subversion tools or lost user account passwords should be reported by submitting a Support Request. Project administrators may now reset their own mailing list admin passwords via the Mailing list Admin, Administer/Update list page." No Git in there (i know nothing atm about git) http://en.wikipedia.org/wiki/Comparison_of_free_software_hosting_facilities henningw, git is very nice in the sense that each repo is a stand alone entity i know the basics, did not used it yet and you can push and pull in any direction :) alioth and savannah offer git first, we need to see if there's enough traction for git another option would be to host this completly by ourself, as a free service has always some issues. i'm glad for example that they finally fixed the svn commit mails problem and if it is, then after 1.5 we can switch to it we should discuss this on the list too, as many users uses SVN atm to pull sources too ok I will send an e-mail to the list will collect feedback and we will go from there on what's next? sip-router.org any particular questions regarding it? or suggestion for the discussion on monday? so ... the plan is to have in 1.6 a common core, right? the modules will stay the same osas: too early to predict I think git would make perfect sense here since it can handle nested projects one git repo for the core, one git repo for kamailio modules and one git repo for ser modules this things needs to be discussed and clarified it is important if we want to make progress on it another issue: releases how are the releases going to be coordinated since the core will be common the two parties needs to come up with a common release cycle otherwise, it will be difficult to manage the core code and the fixes/backports also, a change in the core that affects the modules should trigger a new core release Well one good reason for this is because it is easier to release a set of modules tyested against a know core if both projects are in different repositories, then is should be not a problem to backport certain bugs backporting bugs is never an issue :-) or use different branches of the core it will be a pain to backport all this stuff there are already backports back and forth between opensips and kamailio and it is a pain yes, i know adding a third repo ,,,, so I would like to have three repo's Verlassen carstenbock hat den Kanal verlassen. core. kmodule and sermodules managed by git to super git repos: k and ser and one common nested git repo: the core with a scheduled release cycle for the core every 6 months regrdless of the modules release cycle at least it needs to be coordinated between the projects like this, if one project want's to release something, there is a stable core and there will be no interference between the projects until all the modules are merged just my 2c its planned to have the core as small and stable as possible, because of the reasons you just mentioned yeah, but you need a clear policy for core releases you mean core + TM I suppose ? s/core/core + common modules/ in the previous conversation ? maybe core and tm ... core and TM first, yes I'm not aware of any other common modules maybe pv ... osas: me neither, ut I assume at some poimnt it will make sense to deduplicate code for db drivers, etc... all this needs to be discussed and settled down in the long run it makes no sense, to e.g. have two usrlocs, this could be merged. but its more long term Well, so this is a point for monday: create a roadmap of modules that should be made common, and when, after the core merge i'll also take the suggestion with the repository layout with me for meeting on monday I won't be able to attend the meeting in Germany, but I would like to push the idea of three git repos and a stable release cycle for the core infrastructure sorry, a bit caught by something else osas: I'll make sure this gets mentionned we cannot foresee how things are going perhaps some modules will reside separately for quite sime time ...but we can SUBSCRIBE so at least we'll get notifications because of duplication, etc ... i wonder whether there is the possibility to create regression tests for fixed bugs from the tracker, so they don't reappear let's see the result over the time, some may feel tired to maintain a module in two places, so it simple goes in the common layer we need a clear strategy before proceeding with the merge, otherwise it will be a slippery slope :) this will not be an easy/trivial task we start from common core and tm plus two branches for the modules those will be replica of the ser and openser repositories I feel the issue of all this will depend a lot on the developpers feelings along the road. Trying to plan thing too much might make people feel "trapped"and this is not the goal adding more modules to the 'core' is a good idea sanchiii: i did this for a few bugs in the past, but there is no policy to do or similar we will continue to use nowadays svn and cvs we just need a clear release strategy Still, defining the "important set of modules"as an indication is important I think kamailio will stick to same release cycle yeah, but it will have a dependency on the 'core' nobody stops to branch, freeze and release so the core will be the one that will drive releases on both ends it is an agreements that we protect both projects unless you stick with an old core ... and we do not lose anything from both core and tm will be shared resource I want to really push for scheduled core releases in the first phase even if this will not trigger a project release core alone is useless anyhow, we will discuss it on Monday i agree, even more after we ripped out some stuff, like PVs well, it's the base for all modules ... don't expect to get that much new stuff in the core If I may point to an example I know, maybe some people could look at it: openAIS core without modules is useless and modules without core is useless .... this is the reason we reshape what goes there it is needed by several project, each of wich maintain a "patched"version of it doing too many releases will confuse a lot And then it eventually merges, and start again why just core, when the modules, etc ... i try to avoid that if one sides decide to branch a release, then takes care of porting bugs found to main stream anyhow, it is indeed something that needs better specs in how is going to be I don't see an issue with several releases on the core ... even if the fixes are minor each project can decide which core release to incorporate ... instead of backporting stuff, just switch to the next core minor release well, a release its just a tag, we don't need to announce it that much, for example, so it will not create confusion yup i'll take a look at this openAIS project, and how they do it henning: it is not done by intent I did not finish ok But it is actually an example of what not to do hehe, ok :) Look at pacemaker which uses it It needs a separate repo of a patched stable patches do not get back into openais because it would break other things more repositories and patches is something what i clearly don't need all in all the point is the same when you consider a project using an API (in the larger sense of the terms) apache - libapr The API must be stable enough so bug fixes are really bug fixes, and are not subject to interpretation it is the condition to get a core that does not need explicit releases to be use think "continuous integration" we'll reach that stability probably only after some time yep this is why things must be clear from the start if the goal is to deduplicate work so each project can focus on its specific code (in modules) then the core must be THE ultimate goal If that goal is reached, then it will be time to think about more ambitious ideas BUT the example of TM , maybe usrloc, subsribers, sl, etc.... makes a case so the line must be drawn somewhere with tentative steps in a roadmap The consensus sems to be core + TM in step 1 yes, i also think hard to predict dates, but this should be something that is feasible for 1.6.0 so 10 month from now approx date ? its depends of course on the ammount of work we invest in this merging but 1.6.0 will be somewhere next summer i think yes we may do a quick release if we get good work out there but let's stick to what we have today so, those points will be brought to discussions in Karlsruhe something else we should approach now? I have one question to all yes, beer is good in Germany and wine is France :-) Am I the only one dreaming about integrating more dialog-related features ? miconda :-) yes, you are dreaming :) I mean I made several attempts to gather opinions about a usage scheme related to telco-like usage of kamailio for phone calls using dialog But that never triggered any response tramjoe_merin, if you look at SASI in ser, this is a way to add applications with dialog state as external processes to ser, in a scalable way I understand the pros and cons I think And also the benefit of "light proxy" tramjoe_merin, what exactly are you looking for? But still, I think there is room for a non-RFC, not-yet-formerly-described network entity between a B2BUA and a statefull proxy using the dialog doesn't mean that the proxy won't be light osas: I agree I'm using the dialog module while handling > 100cps for profiling and it is working great Well, I think that while keeping a proxy core, it is possible to do one-stop topology hiding, call accounting, dialog-statefull security checks, etc... osas: me too, this is not the point hi unless I put something on top of it, but that's a different story hi irc i have kamailio runing with tls i have eyebeam Fehler patito: Unbekannter Befehl. patito, there's a meeting going on here .... <-> patito> we're still in a meeting, wait please a few minutes i need to install certificate in my user oh sorry np osas: with full DB (call start AA + routing stop + call stop) + dialog module we do 80cps ah ... DB :) Verlassen l-fy hat den Kanal verlassen. hi Diana :) well, per DB server, of course :-) yeah ... DB is a bottleneck Verlassen patito hat den Kanal verlassen ("Saindo"). osas: indeed. Daniel and I talked about a DB load balancer / failover module