Date:

• Proposed: 14:00 UTC, Wednesday, Sep 27, 2017
  • can attend: dcm, vseva, qxork
  • cannot attend:
• Alternatives (add your id if you can attend)
  • Sep 28: dcm, vseva

Time of the meeting across the world:

• 16:00 - Berlin, Germany
• 15:00 - London, UK
• 10:00 - New York, USA

Utilities:

• Time Converter
• IRC webchat: http://webchat.freenode.net/
• IRC client apps: http://en.wikipedia.org/wiki/Internet_Relay_Chat#Clients

Place:

• #kamailio IRC channel on irc.freenode.net server

Participation is open to anyone, just join the IRC channel if you want to participate.

People adding notes in the agenda using abbreviations:

• dcm - Daniel-Constantin Mierla
• qxork - Fred Posner

Kamailio Development Status:

• open issues (dcm)
• minor releases for 4.4 and 5.0 branches (dcm)

Administration:

• servers maintenance
• community interaction and communication channels
• existing/new mailing lists review (security, announce, …)
• admin team

Project Development

• more cleanup
  • remove/relocate ser packaging specs
  • cleanup etc/ folder (basic, advanced cfgs to examples; radius dictionary to a module)
• features
  • anything relevant that is missing?
  • priorities
• coding style
  • code formatting (clang format)
  • naming for structures, types, functions, variables, …
• unit testing
• documentation
  • tutorials/cookbooks – wiki vs mkdocs (github markdown)
  • kemi documentation – where to write it
• packaging
  • rpms via obs and varios distros
• virtualization and containers (mailing list topic)
  • docker images

Collaborative Projects & Events:

• online meetings (code/docs sprints)
• onsite meetings (devel meetings)

Kamailio 5.1 (next major release):

• roadmap

• 14:56 miconda: hello everyone! we should start in about 5min …
• 15:01 miconda: ok, ready to start here …
• 15:02 qxork:
• 15:02 miconda: hope everyone had a great summer (or winter, if in the south parth)
• 15:03 miconda: as usual, we will follow the agenda from the wiki
• 15:03 miconda: https://www.kamailio.org/wiki/devel/irc-meetings/2017b#agenda
• 15:03 miconda: then discuss freely at the end
• 15:04 grumvalski: hi all :)
• 15:04 miconda: hello!
• 15:04 miconda: * open issues *
• 15:04 miconda: any issue you are aware of and not yet reported to bug tracker?
• 15:05 qxork: silence is golden
• 15:05 miconda: ok
• 15:05 miconda: then next to minor releases
• 15:06 miconda: my plan is to do the next in 5.0 series after Astricon, so it's in like 2 weeks
• 15:06 miconda: hopefully by then we will sort out some of the open issues from tracker
• 15:06 miconda: for 4.4 I haven't made any plan yet, but could follow shortly after the 5.0.x one
• 15:07 miconda: so, next topic if no other comments/proposals here
• 15:08 miconda: * administration *
• 15:08 grumvalski: sounds fine :)
• 15:08 grumvalski: the release plan
• 15:08 notthatdaniel: Till when will 4.4.x be supported?
• 15:08 linuxmaniac: till 5.1 is out?
• 15:08 linuxmaniac: or is 5.2?
• 15:09 miconda: notthatdaniel: like linuxmaniac said, typically few months after the first 5.1 release
• 15:09 miconda: linuxmaniac: 5.1
• 15:09 notthatdaniel: ack
• 15:09 linuxmaniac: ack
• 15:09 miconda: last two releases are maintained
• 15:09 miconda: it will be 5.0 and 5.1
• 15:09 miconda: back to admin
• 15:10 miconda: somehow we left open few things from irc devel meeting before the summer
• 15:10 miconda: like security alerts, an admin/notification team …
• 15:11 miconda: I just wanted to refresh about it
• 15:11 linuxmaniac: I don't recall
• 15:11 miconda: we sort of discussed all about, just need to act
• 15:11 linuxmaniac: what do we have to do?
• 15:11 miconda: linuxmaniac: is it even before?!?
• 15:11 linuxmaniac: email for contact?
• 15:12 miconda: linuxmaniac: there was a proposal to make an address (email) where sensitive security issue to be sent
• 15:12 qxork: With it's own pgp key
• 15:12 miconda: with a (trusted) group of people behind
• 15:12 miconda: should be for incomming notifications
• 15:13 miconda: I think we can use announce mailing list managed by qxork now ( ) or make a new one like security-alerts
• 15:13 qxork: I'm up for it
• 15:13 miconda: to send out reports
• 15:14 linuxmaniac: security-alerts sounds nice
• 15:14 qxork: This method seems to work for gpg and ssl projects
• 15:14 linuxmaniac: is going to be empty…
• 15:14 linuxmaniac:
• 15:15 miconda: then tech-admin group was created at some point, but somehow not used at all. this one is for internal tasks (like upgrading our servers on security issues with other apps, e.g., web server, db server, …)
• 15:16 linuxmaniac: yes, there is no much coordination
• 15:16 linuxmaniac: you are always doing all the work
• 15:16 miconda: I and qxork do that when we can, I guess
• 15:16 grumvalski: I am available to give an hand on this
• 15:16 grumvalski: if we want to create an internal group for such tasks
• 15:16 miconda: linuxmaniac: is a backup for access to main server,
• 15:17 miconda: grumvalski: ok, noted, thanks to jump in, it is needed
• 15:17 linuxmaniac: but problem is that we don't know what has to be done
• 15:17 miconda: also for access to main server, the guys from voztelecom (that host the server) are available: Oriol and Jesus
• 15:18 miconda: linuxmaniac: we also have to define that
• 15:18 miconda: it is mainly about doing upgrades to debian systems
• 15:19 qxork: probably time to update the dist for the lod servers. I can do that if no objections.
• 15:19 miconda: it's not huge stuff (apart of version upgrades), I managed myself for main server
• 15:19 linuxmaniac: I can do that
• 15:19 miconda: but sometime I travel and if there is a serious issue with apache or openssh, etc. someone should do it
• 15:19 miconda: linuxmaniac: I know, but we need to coordinate all these, that's why I wanted to discuss
• 15:20 linuxmaniac: maybe first we have to document what we have
• 15:20 qxork: thats a good idea
• 15:21 miconda: actually, I plan to start a more detailed discussion on mailing list about all project management and administration, so we do it properly, right now is a bit foggy in this area
• 15:21 linuxmaniac: maybe trying to migrate the configuration to ansible can be good too
• 15:21 miconda: people do not know who to aproach in some situations
• 15:21 miconda: linuxmaniac: that would be great if we can automate
• 15:21 miconda: but needs time
• 15:22 linuxmaniac: sure
• 15:22 linuxmaniac: but first we need to know what we have and what we want
• 15:22 linuxmaniac: I mean in terms of migrating to ansible
• 15:23 miconda: ok
• 15:23 miconda: anything new in terms of community interaction/communications that people would like to use?
• 15:23 miconda: maiing lists, github tools and irc are what we do for many years
• 15:24 qxork: they still work well
• 15:24 linuxmaniac: and I think is fine
• 15:24 linuxmaniac: do we really need anything else?
• 15:24 miconda: ok … it can be only parts of community that want to use something else, I ask only in the case we can facilitate that (e.g., host it)
• 15:25 miconda: good then, next topic
• 15:25 miconda: * project developent *
• 15:25 miconda: – repository cleanup
• 15:26 miconda: I think we can get rid of packaging specs specific for ser
• 15:26 miconda: nobody touched them for so long time
• 15:26 linuxmaniac: agreed
• 15:26 qxork: +!
• 15:26 miconda: eventually we can relocate in kamailio-obsolete repo
• 15:26 carsten_ng-voice: +1
• 15:27 miconda: not a cleanup per se, but many examples from misc/examples needs a bit of care
• 15:28 miconda: and then, some files from etc/ should be moved in examples
• 15:28 qxork: I'll see which ones I can work on for examples… was thinking the same about some tutorials
• 15:28 carsten_ng-voice: I totally agree - my examples for the IMS components are outdated, too.
• 15:29 miconda: from etc/ – should the radius dictionary be moved to auth_radius or misc_radius … what do you find more natural?
• 15:30 qxork: +1 for misc_
• 15:30 miconda: then the basic and advanced (oob) cfgs should be moved to examples
• 15:30 grumvalski: +1
• 15:30 miconda: the sip-router cfgs probably removed
• 15:30 miconda: the question is if the basic and advanced configs should still be installed in etc/
• 15:31 miconda: some people told me they are confusing
• 15:31 grumvalski: agree
• 15:31 linuxmaniac: radius dictionary… auth_radius?
• 15:31 grumvalski: may we have just an etc/ directory?
• 15:31 miconda: maybe we can install them in a shared subfolder (like subfolder of docs)
• 15:32 miconda: radius dict – some want auth_ some want misc_ …
• 15:32 grumvalski: yes, also because they are meant to be working configs
• 15:32 grumvalski: not examples
• 15:32 miconda: grumvalski: the thing is that with the time, they are not maintained same as main kamailio.cfg
• 15:33 grumvalski: time for testing tools
• 15:33 miconda: so maybe we can have a note at the top of kamailio.cfg that more examples are located in /…/share/…
• 15:33 grumvalski: but I agree that not everything should go there
• 15:34 grumvalski: and maybe have maintainers for them too?
• 15:34 miconda: so eventually /etc/kamailio/ has only what is actually used at runtime
• 15:34 linuxmaniac: yes please
• 15:34 qxork: I like this approach
• 15:34 grumvalski: miconda: like it
• 15:35 miconda: anything else that you think we should get rid of?
• 15:35 miconda: remove or relocate to kamailio-obsolete repo
• 15:35 linuxmaniac: miconda: maybe /etc/kamailio/radius/ for the radius dict?
• 15:35 miconda: linuxmaniac: it is not where is going to be installed
• 15:35 miconda: it can be in /etc/kamailio/
• 15:35 miconda: but where it is in the repo and how it is installed
• 15:36 miconda: for example, tls.cfg is in tls module folder and installed by tls module
• 15:36 miconda: tls.cfg is installed in etc/kamailio/
• 15:36 linuxmaniac: but that belongs to both auth_radius and misc_radius?
• 15:36 miconda: also dispatcher.list is in /etc/kamailio/
• 15:37 miconda: linuxmaniac: when we package, both modules are in the same package
• 15:37 Sergey: Think tls cert ned to store in /etc/kamailio
• 15:37 Sergey: Think tls cert need to store in /etc/kamailio
• 15:38 miconda: it is indeed a bit of a shared resource, but keeping it in core might not be the right place, it's what I try to sort out here
• 15:38 miconda: Sergey: yes, tls certs are generated in /etc/kamailio/
• 15:39 miconda: we can discuss further about radius dictionary via mailing list
• 15:39 linuxmaniac: ack
• 15:39 miconda: doesn't have to be a decission here
• 15:39 miconda: was more to start the topic and see what people think about
• 15:40 miconda: carsten_ng-voice: it's a long flight to Astricon, good time to update the ims examples
• 15:40 miconda: – missing features
• 15:40 miconda: as a next subtopic
• 15:40 miconda: is anything that you need and is not yet in kamailio?
• 15:41 qxork: not need, but would still love a b2bua module
• 15:41 miconda: (re: cleanup, to properly conclude – whenever you find something obsolete or think it should be relocate outside, just write to sr-dev)
• 15:42 carsten_ng-voice: Travelling with Wife and Kid…
• 15:42 miconda: carsten_ng-voice: then you have a good excuse that you need to work
• 15:43 miconda: no other feature missing?!
• 15:43 miconda: that's quite good then
• 15:43 carsten_ng-voice: I would love to use topos on an outbound proxy (for originating and terminating at the same time)
• 15:43 miconda: till 5.1 I have in mind 1-2 new modules
• 15:44 miconda: let's see how time is available
• 15:44 notthatdaniel: second topos wish
• 15:44 lazedo: not a feature, a devel release, that one could install and compile a module outside of kamailio tree and still have it load and run
• 15:44 miconda: carsten_ng-voice: probably it will get there, it's young and needs more time to keep adding stuff there
• 15:44 jchavanton: We started testing on topos recently, so far so good, we will do a lot more tests in the coming months
• 15:45 carsten_ng-voice: miconda: I totally understand
• 15:45 carsten_ng-voice: miconda: Too many topics on the agenda right now….
• 15:45 miconda: jchavanton: ok, testing and feedback helps a lot
• 15:45 grumvalski: join the wish for oubound support in topos :)
• 15:46 miconda: lazedo: not sure I get it
• 15:46 miconda: lazedo: can you elaborate a bit more?
• 15:46 notthatdaniel: guess lazedo wants to load modules by specifing a complete path
• 15:47 miconda: notthatdaniel: you can give absolute path to a module pointing anywhere on the system
• 15:47 lazedo: right now, we have to build kamailio locally in order to test new modules
• 15:47 linuxmaniac: I would say he wants kamailio-dev package and be able to build from there
• 15:48 Sergey: About new feature. I not tested but dor docker need to set memory config using environment vars.
• 15:48 lazedo: linuxmaniac: you are correct
• 15:48 Sergey: About new feature. I not tested but for docker need to set memory config using environment vars.
• 15:48 miconda: lazedo: you can build packages on another system
• 15:49 miconda: linuxmaniac, lazedo: like a package only with header files?
• 15:49 lazedo: miconda: well, i tried it the other day to build a module and apply it to a running env (stop/start), but the flags did not correspond and the module culdn’t be loaded
• 15:50 miconda: I guess this is only about someone taking the time to put this in a pkg and eventualluy update some include paths or flags to compiler in Makefile
• 15:50 lazedo: if i had the devel release of that installation , i could build my module (or patch an existing one) and only update/add that module
• 15:50 miconda: lazedo: the version has to be the same for core and modules
• 15:50 lazedo: version was the same, i guess its the flags that are compiled
• 15:50 lazedo: haven’t dig much into this
• 15:51 miconda: lazedo: we can tune on it, just open an issue and give some example there, so we can analyze and see what can be done
• 15:51 linuxmaniac: asterisk has something like that
• 15:51 miconda: Sergey: we will get to pkg and docker in the next topics
• 15:51 linuxmaniac: there is a asterisk-dev package with everything you need to build a module
• 15:51 lazedo: same for freeswitch
• 15:52 lazedo: and since they loadable modules, we can even doing it live :)
• 15:52 lazedo: but in kamailio, due to script binding i’m not expecting that
• 15:53 Sergey: lazedo: looks like need kamailio config reload without process restart.
• 15:53 linuxmaniac: is a good idea, but I don't know what we need to accomplish the kamailio-dev
• 15:54 miconda: Sergey: config routing rules writen in Lua, Squirrel and JS can be reloaded (and I think also python) without restarting
• 15:54 miconda: re -dev package, let's approach it over tracker/mailing lists, as lazedo comes with some details and example
• 15:55 lazedo: miconda: agreed
• 15:55 miconda: anything else? or next topic …
• 15:55 miconda: – conding style
• 15:56 miconda: we kind of have a gentlemen agreement that one can use it's own coding style, the other will try to follow when contributing to that part of code
• 15:56 miconda: but over the time, devs come and go
• 15:57 miconda: some components lost the maintainer and the coding style is different, in some cases quite odd I would say …
• 15:57 miconda: I was wondering if we should require a specific conding style that we can agree on
• 15:57 miconda: clang-format is rather good at doing it
• 15:57 miconda: with that the code format will look the same everywhere
• 15:58 miconda: there is already a .clang-format in the root folder that can be used
• 15:59 miconda: I do it from time to time
• 15:59 qxork: I know that can integrate in vim… does it in other writers?
• 15:59 miconda: qxork: it can even be enforced via some git hooks
• 15:59 linuxmaniac: We need a common code style
• 15:59 miconda: I use clang-format from command line
• 16:00 lazedo: +1 common code style
• 16:00 linuxmaniac: We need to force it
• 16:00 linuxmaniac: enforce
• 16:00 miconda: the topic here is to see if people consider that a good thing and be approached via mailing list with the rest of devs, or they feel unconformtable and should leave it like it is now
• 16:00 miconda: ok, so nobody against it here …
• 16:00 miconda: … yet
• 16:01 miconda: I will prepare an email and send it over the mailing lists
• 16:01 linuxmaniac: https://github.com/andrewseidl/githook-clang-format
• 16:01 linuxmaniac: examples of different editors and clang-format
• 16:02 miconda: with this email I will also try to propose some rules for naming vars/functions/etc (mainly the ones that are exported to config)
• 16:02 miconda: linuxmaniac: will check it
• 16:03 miconda: next topic?!?
• 16:03 miconda: – unit tests
• 16:03 linuxmaniac: I would say functional tests
• 16:04 miconda: approached few times in the past, not actual work on it, appart of Mikki who cleaned up what we had and added few new
• 16:04 miconda: linuxmaniac: more types of tests, the better
• 16:05 miconda: we need to approach this somehow, but likely it needs an onsite meeting to get things moved on
• 16:05 miconda: let's see what we can do in the near future
• 16:05 miconda: we'll follow up via mailing lists
• 16:06 miconda: – documentation
• 16:06 miconda: the main one here is how to document the kemi exports
• 16:07 miconda: they follow more or less the standard cfg exports, but sometimes there are variants
• 16:07 miconda: shall we put them in the docbook file used now?
• 16:07 miconda: if yes, how?
• 16:07 miconda: or make new docs dedicated for them?
• 16:07 miconda: maybe doxygen?
• 16:08 miconda: for kemi exports is quite important to document the return codes
• 16:08 linuxmaniac: doxygen seems right, documentation in the code
• 16:09 linuxmaniac: enforcing documentation for kemi exports seems a nice idea
• 16:09 miconda: linuxmaniac: there is a slightly difference in the signature, as sip msg pointer is not given from kemi scripts, but that can be documented somewhere else
• 16:10 miconda: then, should other tutorials be migrated from wiki to markdown and kept in github?
• 16:10 miconda: I started with the installation guide, being specific per version
• 16:10 miconda: we discussed last time, from the perspective of having devs commiting in github, rather that going to an external wiki site
• 16:11 linuxmaniac: I think the changes to DB
• 16:12 linuxmaniac: I mean … the upgrade from one mayor version to another
• 16:12 carsten_ng-voice: Got to run - CU next time!
• 16:12 miconda: linuxmaniac: right, I wanted to discuss also about changes to db
• 16:12 miconda: when to increase the version number or find an alternative
• 16:13 miconda: linuxmaniac: ok with upgrade guide
• 16:13 miconda: more stuff for mailing list …
• 16:13 miconda: next topic …
• 16:13 miconda: – packaging
• 16:14 miconda: thanks to Sergey (I guess), rpm packaging gets better and better
• 16:14 Sergey: I suggest to use one RPM SPEC file for all RPM based dists
• 16:14 miconda: the question is how to keep that
• 16:15 miconda: Sergey: can obs spec be used to build rpms on a local system (e.g., centos 7)?
• 16:15 Sergey: I prepared OBS SEPC file with support HEL, Fedora, OpenSUSE dist
• 16:15 Sergey: Yes, obs may be used to build local dist. OBS macro is removed now
• 16:15 miconda: Sergey: yes, but I need to use that spec on OBS, right?
• 16:15 linuxmaniac: see pkg/kamailio/deb/backports as a reference of what I do in deb world
• 16:16 Sergey: No, you can use this SPEC on local PC too
• 16:16 miconda: Sergey: I would try to avoid keeping symlinks in repo
• 16:16 linuxmaniac: I mean… I use one as reference and the script updates the files as needed
• 16:16 linuxmaniac: and I commit them
• 16:16 miconda: we can add makefile rules to create them as needed
• 16:16 miconda: for exampe 'make deb' creates the 'debian' symlink in root folder pointing to pkg/kamailio/deb/…
• 16:17 miconda: the problem with symlinks is that if a spec has to be diverged, the object in git repo cannot be replaced (afaik)
• 16:17 Sergey: miconda we can to as you say. But what is bad in simlink?
• 16:18 Sergey: Ok. Accepted
• 16:18 miconda: we used to have pkg/kamailio/debian
• 16:18 miconda: then we needed to have specs for each debian version (the latest)
• 16:18 miconda: we couldn't reuse pkg/kamailio/debian, we had to do pkg/kamailio/deb/subfolder
• 16:19 miconda: I can't remeber exactly the issue
• 16:19 miconda: but if you remove a folder (file or path) and try to add it again, there are some issue with git objects and references
• 16:19 Sergey: RPM packaging is different than deb. Think debin folder cannot be used
• 16:19 linuxmaniac: and as I said, I maintain them with backports/*
• 16:19 miconda: that is what I have in mind from that moment
• 16:20 miconda: so, as a symlink is just a shortcut that is needed for the time of building something, I would not store it in git
• 16:21 qxork: sorry I just caught up
• 16:21 qxork: I need to become more familiar with doxygen but am committed to help more with docuentation
• 16:22 Sergey: I not have big experience with git. Than i simple trust that is mor simple to manage git repo and prevents conflicts.
• 16:22 miconda: qxork: ok, thanks
• 16:22 Sergey: Also one more question
• 16:23 miconda: Sergey: not much of a git expert here, that's why I try not to put there what is not needed
• 16:23 skrusty: can someone tell me what the lifetime of $var is please? I am setting a $var in accounting, but getting values that are from other calls (it would seem). Just trying to understand in what context that value would persist.
• 16:23 Sergey: We also can simple package kamailio for Oracle linux. But this dist not provided by OBS. May be also package using other staff?
• 16:24 skrusty: oh sorry, didn't realise it was dev meeting
• 16:24 andrew_p: skrusty: it's set per lifetime of kamailio child serving the request…
• 16:25 linuxmaniac: Sergey: I don't get the question
• 16:25 miconda: Sergey: I propose to have obs folder as now, then for each distro supported by obs, have own folder with a README giving instructions how to build it
• 16:25 skrusty: andrew_p: thanks
• 16:26 miconda: Sergey: and also a Makefile to create subfolders for each OS version
• 16:26 miconda: Sergey: I can probably add something in the next days as an example
• 16:27 Sergey: miconda understand.
• 16:28 miconda: Sergey: really apreciating your efforts here, it's been a long time when rpm specs were not properly maintained
• 16:28 miconda: so we do need a cleanup
• 16:29 Sergey: I can simple remove not supported dists like fedora 18, 19
• 16:29 miconda: remove old stuff that I typically just increase version number, but they were not maintained, just kept in case someone will pick up
• 16:30 miconda: Sergey: ok, let's first get an agreement on how to link everything with obs, then remove what's old/not needed
• 16:30 Sergey: Also CentOS SPEC. How about this also remove and create REAME how to build?
• 16:30 miconda: will continue via email or tracker on github
• 16:30 miconda: – virualization and/or containers
• 16:30 miconda: as next topic
• 16:31 miconda: also from Sergey, a docket container file
• 16:31 miconda: linuxmaniac does already some stuff with docker for travis-ci
• 16:31 Sergey: I also packaged and suggest to publish this on docker hub
• 16:31 miconda: how should we structure that?
• 16:32 miconda: linuxmaniac: can we make a new sub-project on doker hub?
• 16:32 miconda: I think yiou have one dedicated for travis
• 16:33 linuxmaniac: We can create kamailio/kamailio
• 16:33 miconda: onther question in this topic: do you think preparing some vm images will help?
• 16:33 miconda: linuxmaniac: should it be also with os name
• 16:33 miconda: like kamailio/kamailio-debian
• 16:33 lazedo: oops, this topic reminded me of a feature question/wish, are we already able to use environment variables in kamailio config script ?
• 16:34 linuxmaniac: uhm… not sure about that
• 16:34 miconda: lazedo: someone added that feature, iirc
• 16:34 lazedo: the docker images for travis aet awesome for making builds, wanted to thank you linuxmaniac :)
• 16:34 Sergey: This easily resolve as tags like kamailio/kamailio:debian or kamailio/kamailio:alpine
• 16:34 linuxmaniac: lazedo: thanks!
• 16:34 miconda: lazedo: as a pv, not as a predefine replacemet
• 16:34 miconda: lazedo: https://www.kamailio.org/wiki/cookbooks/devel/pseudovariables#env_name_-_environment_variables
• 16:35 linuxmaniac: we need to think about versions too
• 16:35 lazedo: miconda: ah, that was i was looking for (replacement). tks
• 16:35 miconda: lazedo: you can use -A to replace a define in config
• 16:36 lazedo: miconda: looks interesting, looking into that. tks again
• 16:37 Sergey: How about kamailio on docker hub? We crating this
• 16:37 miconda: lazedo: iirc: kamailio -A DBHOST='localhost' to relplace DBHOST with localhost all over config
• 16:37 miconda: Sergey: yes, the question is about naming the repo
• 16:37 miconda: should it be like: kamailio/kamailio-debian
• 16:38 Sergey: i suggest simple kamailio/kamailio
• 16:38 miconda: or: kamailio/kamailio-debian-wheezy
• 16:38 miconda: Sergey: but for kamailio/kamailio, can we host many OS under the same?
• 16:38 qxork: +1 for dist-version
• 16:38 Sergey: Please look this https://hub.docker.com/_/rabbitmq/
• 16:39 miconda: miconda: I am not familiar with docker, I just ask questions coming in my mind based on past experience with similar stuff
• 16:39 lazedo: kamailio/kamailio (choose a dist), then provide other dist kamailio/kamailio:stretch , …
• 16:39 Sergey: one one place you can see all version. Tags is designed for this
• 16:39 miconda: Sergey: I am fine with it, then
• 16:39 lazedo: Tags is the way to go
• 16:39 qxork: nice
• 16:40 miconda: anything else left here?
• 16:40 miconda: still the question about if vm images will help the community somehow
• 16:40 miconda: I do install from sources or debs, and that works fine and fast for me
• 16:40 linuxmaniac: wait
• 16:40 miconda: so just asking …
• 16:41 linuxmaniac: the docker naming thing needs to be discussed
• 16:41 Sergey: Docker containers isconfigred using environment vars. Need to configure kamailio memory using vars
• 16:41 qxork: if we're going to do vm, are we going to fight over which OS?
• 16:41 Sergey: with out keys
• 16:41 linuxmaniac: I propose a new repo for the docker files
• 16:42 linuxmaniac: so there we can keep the different files needed for dockerhub
• 16:42 lazedo: agree with linuxmaniac
• 16:42 miconda: Sergey: does not work with command line params? -m $SHMSIZE -M $PKGSIZE
• 16:42 Sergey: no is bad. If dockerfiles located in main repo then on each update on main repo docker hub automticali rebuild required imags.
• 16:43 miconda: linuxmaniac: you propose like kamailio-docker on github.com/kamailio ?
• 16:43 Sergey: Es example when you make commit to master verions then you alwais have latest kamailio:master
• 16:43 linuxmaniac: I don't plan to have kamilio:master
• 16:43 Sergey: Or kamailio:5.1 or kamailio:5.1.0
• 16:43 linuxmaniac: more like kamailio5.1:stretch
• 16:43 Sergey: master is tag.
• 16:44 Sergey: not repo
• 16:44 linuxmaniac: kamailio5.1:alphine
• 16:44 linuxmaniac: not really sure about the underlying distrubution
• 16:45 linuxmaniac: in docker it doesn't matter
• 16:46 lazedo: but if one wants to extend the existing images, he can choose the base thhat best suits him
• 16:46 miconda: Sergey, linuxmaniac - maybe you can agree in between you with naming, then email or add on github tracker for an overall opinion and then go ahead
• 16:46 linuxmaniac: if we decide to use debian as base distribution… is quite simple to provide a docker with our own debs
• 16:46 Sergey: miconda: to pass keys -m and -M need to use entrypoin.sh script I want to remove this
• 16:46 eloycoto: lHello! I think that the best way to organize is like python https://hub.docker.com/_/python/
• 16:47 linuxmaniac: eloycoto: great thanks
• 16:48 eloycoto: ping me if you need help
• 16:48 Sergey: all official docker images is have version and dist in tags. I suggest do to same way
• 16:50 miconda: so we have a team here: eloycoto, lazedo, linuxmaniac and Sergey
• 16:50 linuxmaniac: https://hub.docker.com/r/library/python/tags/
• 16:50 linuxmaniac: so 5.0-stretch 5.1-alpine
• 16:50 miconda: you can try to find something that works the best for everyone, for me it's all ok
• 16:51 miconda: anything else to be discussed?
• 16:51 miconda: if not, next topic
• 16:51 Sergey: linuxmaniac accepted
• 16:51 miconda: collaborative projects/events
• 16:52 Sergey: miconda: to pass keys -m and -M need to use entrypoin.sh script I want to remove this
• 16:52 miconda: Sergey: I will try to see what implies and then follow up
• 16:52 miconda: maybe you open an issue on tracker just not to forget about
• 16:52 Sergey: Ok
• 16:53 miconda: back to collaboration – also from last irc devel meeting … a proposal to try to have some online sessions for working on some stuff
• 16:53 miconda: like docs migrations
• 16:54 miconda: it didn't happen so far, summer holidays, but we can look at doing one for a test and see who joins
• 16:54 miconda: then, it was also about having a developeres meeting in person for 2-3 days
• 16:54 linuxmaniac: just propose a date for the on-line session
• 16:55 linuxmaniac: or dates
• 16:55 linuxmaniac: like you do for IRC meetings
• 16:55 miconda: linuxmaniac: I will try to do it soon
• 16:55 miconda: need also to propose the topic of work
• 16:56 miconda: for onsite meeting, Olle was interested, but he is not here …
• 16:57 miconda: if there is interest, our friends at sipgate in Dusseldorf can host, I can arrange something for Berlin, maybe others can do it at other locations, but first we have to see if there is interest
• 16:57 miconda: one will have to conver traveling/accommodation costs
• 16:57 miconda: s/conver/cover/
• 16:58 linuxmaniac: I think that would be really nice
• 16:58 miconda: I would say we need 5-6 people that want, to just start planning it
• 16:58 linuxmaniac: count with me
• 16:58 miconda: linuxmaniac: ok
• 16:58 miconda: I will ping other devs that are not here today and see
• 16:58 qxork: this is for dev, right?
• 16:58 eloycoto: miconda, I think that Fosdem can host pre/post events for communities
• 16:58 miconda: likely cannot be done before end of noveber or so
• 16:58 miconda: eloycoto: that's an idea, too
• 17:00 miconda: eloycoto: the only issue with fosdem is that people are in mood for beer at that event
• 17:00 miconda: let's see what comes up after discussing with other devs not here now
• 17:00 miconda: I and linuxmaniac are counted
• 17:01 miconda: qxork: not only for devs, but for dev related work (e.g., write docs)
• 17:01 grumvalski: coun also on me for a live meeting
• 17:01 qxork: ack
• 17:01 miconda: qxork: I mean, not an event to share how to use kamailio, but an event for working on stuff (code, docs, administration, …)
• 17:01 miconda: grumvalski: ok
• 17:02 miconda: two hours already … long agenda this time
• 17:02 lazedo: not commiting but, i have interest in such meeting
• 17:02 miconda: lazedo: ok – Lisbon is not a bad place to do it
• 17:03 grumvalski: +1
• 17:03 miconda: to finish the (written) agenda, last topic
• 17:03 miconda: – roadmap to 5.1
• 17:04 miconda: proposed via mailing list few days ago:
• 17:04 miconda: - Mon, Oct 16, 2017 - freeze the development
• 17:04 miconda: - in 3-4 weeks after that, create the branch 5.1
• 17:04 miconda: - 2-3 weeks after, do the release of v5.1.0
• 17:05 miconda: anyone working on something that wants in 5.1 and not time for it according to above timelines?
• 17:05 qxork: works for me
• 17:05 grumvalski: fine for me
• 17:05 miconda: ok
• 17:06 miconda: then new topics, if you want to discuss
• 17:06 miconda: or just free discussions
• 17:07 qxork: I'm already looking forward to KamailioWorld 2018
• 17:07 miconda: I'll see some of you at Astricon … qxork, carsten, torrey, …
• 17:07 grumvalski: I've thinking since a while in a zmq module :)
• 17:07 miconda: qxork: hopefully we will be able to sort out the dates very soon
• 17:07 qxork: nice!
• 17:08 miconda: btw, any events in your area that you know it worth going and presenting about kamailio?
• 17:08 qxork: I'm hoping to add something to ITEXPO this year
• 17:08 miconda: if anyone does it (e.g., local group meetups), we can post a news about and store the slides for later view on kamailio.org
• 17:09 miconda: qxork: great! it can be also smaller events, like those organized via meetup.com
• 17:10 miconda: I tried also to go to some univeristies or institues when they have events about RTC or open source
• 17:10 linuxmaniac: have to go, see you later!
• 17:10 miconda: I would like to see more of the people in community doing it
• 17:11 miconda: linuxmaniac: thanks a lot, have a great evening!
• 17:11 grumvalski: linuxmaniac: hasta pronto!
• 17:11 qxork: take care linuxmaniac!
• 17:14 miconda: ok, then all finished for devel meeting!
• 17:14 miconda: thanks everyone!
• 17:14 lazedo: thank you for bringing this up miconda
• 17:14 qxork: thank you @miconda
• 17:14 grumvalski: thank you!
• 17:14 miconda: welcome!
• 17:14 notthatdaniel: thanks for the info and goodbye
• 17:15 miconda: bye!
• 17:16 jchavanton: good spirit guys ! have a nice day
• 17:17 miconda: jchavanton: thanks! do not forget about the issue you opened with processes, I asked more details there
• 17:18 jchavanton: sorry I was not notified automaticaly, I will follow up