Time of the meeting across the world:
Participation is open to anyone, just join the IRC channel if you want to participate.
People adding notes in the agenda using abbreviations:
Kamailio Development Status:
Kamailio 5.3 (next major release):
Note: Times are in EDT (UTC -4)
11:02 miconda: ok, ready to start 11:02 miconda: not much in there, but the usual agenda is at: https://www.kamailio.org/wiki/devel/irc-meetings/2019a 11:04 miconda: if anything is wanted to be discussed, just propose here 11:04 miconda: we can start with the releases 11:04 miconda: 5.2.2 is fresh, released few hours before 11:04 abalashov: Have there been any bug fixes related to TM recently in 5.2? I encountered a crash I could not explain a few days ago, but unfortunately do not have a core dump. 11:05 abalashov: But it appeared to originate in TM. 11:05 miconda: hopefully it fixes an issue that was hunted during the past few months more or less, with various reports mainly related to the case when rtpengine was not available 11:05 abalashov: Ah yes - that's an important one. Can you remind what was done to deal with rtpengine being unavailable? Was it an issue only on startup, or any time calls to RTPengine were made? 11:06 miconda: @abalashov: yes, there is a fix for a race that happened in some cases, when the final response was received at the time the transaction was to be deleted 11:06 miconda: so the transaction was in terminated state for 5sec 11:06 abalashov: This is all I have unfortunately: 11:06 abalashov: kamailio: segfault at 190 ip 00007fb19c0d72d1 sp 00007ffc9697b7d0 error 4 in tm.so[7fb19c010000+136000] 11:07 abalashov: Which isn't very helpful, but I can look up those symbols/offsets for you if it would help. 11:07 miconda: could be that one 11:08 miconda: soon I will plan for 5.1, I think this needs to be backported there as well 11:08 linuxmaniac: debs jobs are already triggered 11:08 miconda: soon afterward, I will just do the last release from branch 5.0 to mark the end of official maintenance/packaging 11:08 linuxmaniac: https://kamailio.sipwise.com/view/kam52/ 11:10 linuxmaniac: ack, I will disable nightly build for 5.0 afterwards 11:10 miconda: otherwise, in terms of open issue, there is something reported with libcrypto, which I didn't get the time to look at 11:11 miconda: but I thought debian stable has libcrypto 1.1 and kamailio runs fine for me with tls on this distro 11:11 miconda: today I tried to clean up a bit the old items on issue tracker 11:11 miconda: some were fixed or alternatives added 11:12 miconda: there are mostly feature-request that are aging 11:13 miconda: anyone else having any other issue to discuss in terms of c code or related tools for kamailio? 11:13 abalashov: Is Kamailio known to have any problems when built against musl? 11:14 abalashov: I mean on a kind of general basis. 11:14 miconda: never tried 11:14 abalashov: It's a fairly common experience if one tries to build from source in Alpine. Oh, OK. 11:15 abalashov: How much longer will 5.1 be in active maintenance? 11:15 qxork: until 5.4 I assume 11:15 linuxmaniac: miconda: there were some concerns with libssl 1.1 : 11:16 qxork: I mean 5.3 11:15 linuxmaniac: "we recently upgraded to deb9 + kam5.2 and noticed very high memory usage. we did a custom build with `libssl1.0-dev` and memory usage went back to normal" 11:15 miconda: few months after release of 5.3 11:16 linuxmaniac: this was from the slack channel 11:16 miconda: linuxmaniac: where was that? 11:16 miconda: ok 11:17 miconda: what is slack?!? 11:17 qxork: :) 11:17 miconda: ;-) ahh, ok ... 11:17 abalashov: :D 11:17 lz1irq: linuxmaniac: idk about memory usage, but I can confirm I still see https://github.com/kamailio/kamailio/issues/1172 with libssl1.1 11:18 lz1irq: libssl1.0 works fine 11:19 miconda: ok, needs to be investigated 11:19 miconda: maybe someone can make a sipp sceraio to reproduce 11:19 miconda: it will help a lot 11:19 miconda: sipp scenario ... 11:20 miconda: anything else, or we move to kamailio 5.3 timeline? 11:20 miconda: ok ... kamailio 5.3 11:21 miconda: either freezing before the summer and do the release maybe in june, or postpone and do all in autumn 11:21 miconda: I think there are couple of new modules 11:21 miconda: and a set of new features as usual 11:22 miconda: any opinion? 11:22 abalashov: I am a bit concerned about this ... https://kamailio.org/docs/modules/devel/modules/rtp_media_server.html 11:22 ablashov: Has the maintainability of it been evaluated? It seems unwieldy. I remember that coming up before. 11:22 miconda: the developer is quite active 11:23 miconda: I think that the module is more a wrapper around some external libs, not a big one by itself 11:23 abalashov: Fair enough. 11:24 ablashov: So it does not internalise any of this media-bearing processes into Kamailio in problematic ways, just a communication conduit kind of like the RTPEngine control module? 11:25 linuxmaniac: rtpengine now is playing media https://github.com/kamailio/kamailio/commit/a5e7a56a374d76f701ac6503884d0f2c2e6f841e 11:25 miconda: it doesn't do a control protocol, afaik, just wraps around external libs for media processing 11:27 linuxmaniac: release timeline: I have no preference 11:27 miconda: linuxmaniac: I think the other one is more to answer and send some rtp, while rtpengine is mid session between two end points 11:27 abalashov: So it adds some specialised preforked worker processes which use external libs to do some media stuff? 11:28 miconda: abalashov: never checked the code, I wait for Kamailio World to ask Julien more about 11:28 qxork: when did 5.2 originally come out? 11:28 miconda: he will have a presentation about 11:28 miconda: anyone else with preferences for 5.3 release date? 11:29 miconda: qxork:: 5.2 was in late november 2018, iirc 11:29 qxork: My vote would be post summer then 11:29 abalashov: My personal view is to have relatively frequent minor releases but it depends on the amount of "next-generationally significant" new development. 11:29 abalashov: By minor I mean 5.3 vs. something like 6.0. 11:30 qxork: since we stop maintenance on 5.1, may be good to keep these ~10-12 months 11:31 abalashov: I like to contribute to testing by getting real-world installations to run new releases, but the problem with this is nobody will run a `master` HEAD ... it kind of has to be tagged as a "real release" before that becomes politically palatable. 11:31 abalashov: Or at least some kind of pre-release or RC. 11:31 miconda: qxork:: we somehow balance on maintenace interval to get around 2 years anyhow 11:31 qxork: ack 11:31 miconda: while 5.2 was released in nov 2018, the last 5.0.x will be released soon 11:32 miconda: abalashov: at some point was an idea to have sort of 5.2-backports branch 11:33 miconda: where some devs backport some of the features they want to run on 5.2 core 11:33 miconda: but it requires a group to manage that 11:33 miconda: just bringing that back as an idea, doesn't mean it is my proposal to do it 11:34 miconda: when we postpone after summer, the release likely to be again in november 11:34 miconda: July and August are low activity months 11:35 miconda: so no worth to do testing in that interval 11:35 miconda: and we need to sync after those summer months, so freezing would be after mid of september 11:36 miconda: 1-1.5 months for testing => getting into november easily 11:37 miconda: if frezzing before the summer, likely not so many new features, therefore (eventually) fewer things to test 11:38 miconda: if no other opinions, we can ask on mainling list for the rest of the communiy and see the feedback from there 11:38 linuxmaniac: then, release before summer seems more reasonable 11:39 miconda: any major missing feature that one would like to see in 5.3? 11:40 miconda: no ... ok. perfect then 11:40 miconda: one we have in the list, not as a development feature, but packaging of rtpengine 11:40 miconda: it seems to be the rtp relay most of the people prefer to run 11:41 linuxmaniac: initial effort was done already: https://kamailio.sipwise.com/view/rtpengine/ 11:41 miconda: but to make it easier for new people, we should package it 11:41 linuxmaniac: but I have a problem with dependences 11:41 miconda: linuxmaniac: ok, thanks 11:41 miconda: what is missing there? we need to package other projects? 11:42 linuxmaniac: If I recall libbcg729-dev 11:42 miconda: maybe we can build with some features disabled 11:42 miconda: ahh, right 11:42 miconda: I build always without support for it 11:42 linuxmaniac: but I would like to build it without it 11:42 miconda: there is a command line flat to set to build without it 11:43 miconda: ... command line flag ... 11:43 linuxmaniac: I have to investigate how to setup that in out environment 11:43 linuxmaniac: not had the time 11:43 miconda: ok 11:43 miconda: would the packages be named directly rtpengine? 11:44 miconda: or still keeping sipwise prefix 11:44 linuxmaniac: no, they will be ngcp-rtpengine 11:44 miconda: ngcp ... irc?!? 11:44 miconda: ok 11:44 linuxmaniac: I was packaging the Debian version too and those will be rtpengine 11:44 linuxmaniac: to avoid conflict 11:45 abalashov: I don't want to get too far off-topic, but I am curious - what is the rationale for this "iptables management" aspect of RTPEngine 6.0+? It seems to me adding a -j RTPENGINE target upon startup is a fairly straightforward matter... is that the only thing that feature intends to automate? 11:46 miconda: linuxmaniac: but that won't be confusing? ngcp-rtpengine on kamailio repo and only rtpengine on debian repo? 11:47 miconda: abalashov: I have no clue, in many cases I run user space only rtpengine daemon 11:48 linuxmaniac: we are building the sipwise flavour that's why ngcp-rtpengine 11:49 linuxmaniac: the debian version will be debian flavour ( and not yet available ) 11:49 miconda: I am fine when it saves on some extra work or so, just feels strange if you decide to do different names on different public repos 11:49 miconda: it will make install guidelines a little bit confusing 11:50 miconda: saying that if you install from official debian repo, use abc, when installing from kamailio repo, use xyz -- for the same application 11:50 miconda: anyhow, just my opionion here 11:50 miconda: we will have to see the RPMs, maybe Sergey can help there 11:52 miconda: abalashov: I see Julien (rtp_media_server) writes on list that he has some issues joining the meeting here 11:52 linuxmaniac: right now... if you want to install rtpengine in stretch... you would need to install the ngcp-* 11:53 miconda: linuxmaniac: it was only about decision to use different name on official debian distro 11:53 miconda: anyhow, we can move forward, this is not a technical issue anythow 11:54 miconda: the packager can decide the way to go 11:54 linuxmaniac: in debian I have to use rtpengine, is the same with kamailio... sipwise packages ngcp-kamailio 11:55 miconda: linuxmaniac: right, but deb.kamailio.org doesn have ngcp-kamailio, but just kamailio 11:55 miconda: our docs also refer to installing kamailio only 11:56 miconda: anything else for having a smooth 5.3 release with rtpengine in the default config? 11:56 linuxmaniac: because we build our version not the ngcp-* 11:56 miconda: or something else you want to have in the default config for 5.3? 11:56 abalashov: Does putting RTPEngine in the default config not seem a bit presumptuous? 11:57 miconda: speaking of that I was thinking to replace xmlrpc with jsonrpc in the default config 11:57 abalashov: My more general objections to the default config relate to all the route modularisation and compartmentalisation; from a programmer's point of view it's a lot cleaner, but it's also much harder for the newbie to follow, I've found consistently. The old 1.5.x-style config which kept most of the core reasoning about requests flat in the main request route was a lot easier to understand. 11:57 miconda: jsonrpcs module is loaded, needs xhttp 11:57 miconda: but feels like more people use jsonrpc than xmlrpc these days 11:57 abalashov: That is almost certainly correct. 11:59 miconda: abalashov: with the old style of default config was harder to reference where one has to do changes for specific features 11:59 miconda: the new one was easier to assist with on questions 12:00 miconda: everyone can have different preferences, I am fine to adjust if majority prefers a different way 12:00 qxork: I prefer the current style 12:00 qxork: for default 12:01 qxork: Alex, you should add a slim down version as an example config 12:01 miconda: right now if one wants to delete presence support, is easy to say: remove route[PRESENCE] and the lines where that is executed 12:02 miconda: abalashov seems to be on dial up -- disconnected frequently ;-) 12:02 abalashov: Sorry, switching machines. :-) 12:02 qxork: US Internet =) 12:04 miconda: ok, we can discuss more on mailing lists if needed 12:05 abalashov: But anyway trying to figure out what happens at every step in the main request route is actually quite contemplated, there's a lot of visual darting around. 12:05 abalashov: I would say if the goal is to make newbies understand it it might help to flatten it more. 12:05 abalashov: I don't usually take this position; being a programmer, clean functional decomposition obviously appeals to me. 12:05 abalashov: *quite complicated 12:06 verticelo: Hi! I missed the beginning of the meeting but have an idea regarding the kamailio-community, when (if ever) would be a good time to propose it here? 12:08 miconda: verticelo: what do you mean by kamailio-community? 12:08 abalashov: You know, die Kamailio-Gesellschaft :) 12:08 verticelo: :) 12:08 verticelo: more specifically, as a newcomer to kamailio interfacing with senior people 12:09 verticelo: senior people = long-term kamailio users hehe 12:09 miconda: i am mainly a guy of the mailing lists 12:09 abalashov: Senior people are attentive to your thought leadership. 12:10 miconda: but there are other people here on irc, or maybe other forums/chats 12:10 abalashov: verticelo, what's the idea? :) 12:10 miconda: verticelo: what you would like to see/get/...? 12:10 verticelo: sorry, tried to paste in my quick write-up but IRC is single-line only it seems 12:10 abalashov: It lacks the richness of Slack. >:) 12:10 verticelo: - Today, almost all questions regarding Kamailio are done via the mailing list 12:10 verticelo: - The mailing list is not very searchable 12:10 verticelo: - There are lot of repeat question 12:10 verticelo: - Some answers provided by the community are very high quality and would be beneficial to document 12:11 verticelo: Could questions instead be done via some type of knowledge base / QA site like StackOverflow? That way questions could be marked as solved and good answers promoted. For repeat questions it would be easy to link to that. It would be a lot easier to search this type of structure and index it. Questions could be tagged per module etc. This would also reduce the burden and repeat questions on the mailing list. 12:11 verticelo: Any questions asked could still be sent to the mailing list and answers as well thus not enforcing any change of how current community interfaces with the channel. 12:12 abalashov: Yeah, I think some sort of knowledge-base-wiki or Stack Overflow type site has been proposed before. The challenge is just always a) getting someone to maintain and/or moderate it and b) getting the critical mass/buy-in/mindshare to make it a mainstream communications channel and not just a small silo used by a few people. The best tools, while imperfect, are the ones that people actually use. 12:12 miconda: is there any such platform that we can host? 12:12 verticelo: agreed, I was thinking that any questions asked should be able to answer via email still so one doesn't have to click a link and register somewhere to answer a question 12:13 miconda: I am not a big fan on maintaining systems myself, on the other hand, I do not want to push the community to make accounts wih 3rd party companies 12:13 verticelo: there are a number of open-source SO clones, but haven't looked into it 12:13 verticelo: it would be nice to hook it into the mailing list somehow 12:13 abalashov: Yeah, I think the real problem is getting people to use it on any sort of sufficiently large-scale basis that it becomes self-sustaining. 12:13 abalashov: In practice such things just tend to languish / quietly die. 12:13 abalashov: This is irrespective of who hosts it, the choice of technology, etc. 12:14 abalashov: I mean, if you look, there are kamailio questions on Stack Overflow, etc. Just, only a small handful of people take part. 12:14 miconda: I had some hopes with mailman3 which was supposed to offer a nicer web interface and a forum like view 12:14 qxork: You can limit most searchengines to the domain lists.kamailio.org to search the maillist... example https://duckduckgo.com/?q=site%3Alists.kamailio.org+rtpengine&t=h_&ia=web 12:14 verticelo: one could even have a donation bonus, when someone asks more complicated questions, they could donate to the project as well as a carrot, I do understand that this would be controversial 12:14 miconda: but it seems it never took off, but haven't checked lately 12:15 abalashov: I do agree that the mailing list isn't very searchable and that's a problem. 12:16 abalashov: You pretty much just have to do queries like "site:lists.kamailio.org ims nosql make big profit" 12:16 miconda: qxork: is more that willing to offer infrastructure (3 wm's are already waiting) if we find something useful 12:16 miconda: that's why I keep this topic about community interaction on each irc meeting 12:17 qxork: yup. and we can always add more. 12:17 abalashov: I personally like the idea of a Stack Overflow-style Q&A vehicle as the main go-to for Kamailio questions and recipes very much, but I just don't see how to get everyone to start using it. Custom, habit, folk traditions... all play a very big role. Not to mention the virtue of mailing lists in that they are primarily passive rather than active, you don't have to really go out and check the mailing list to see if anything new has popped up. 12:18 miconda: verticelo: maybe you can summarize your proposal and sugest some solutions in an email addressed to firstname.lastname@example.org 12:18 abalashov: Indeed, I think that would be a great discussion to have. 12:18 verticelo: yes 12:19 verticelo: abalashov - i think we could place some of the burden on the person asking the question.. but then, we should have an extremely easy way for users to answer it, such as an email reply etc 12:20 verticelo: i think a few times stating in the mailing list that they should use the QA tool would suffice, I think people get the hint pretty quickly 12:20 miconda: there is a FAQ section in the wiki, but not many contribute there 12:20 verticelo: another suggestion, I know I raised this on the mailing list a while back, but it would be nice to recommend for KEMI which language the majority of KEMI users use so one doesn't have to build something in something that is not popular and dies 12:20 miconda: also the wiki seems to become unactractive (not only with out project) 12:21 verticelo: when we started experimenting with KEMI a long time ago we had to choose with LUA/Python and eventually decided on Python but we really just wanted to go with the one that had the most users 12:22 verticelo: I think this would make it easier for beginners as well, examples and tutorials could be in one recommended language 12:22 miconda: the app_xyz are quite minimal in relation with kemi framework 12:22 miconda: some of the old ones have a duplicate of some exports, those befere the kemi 12:23 miconda: I guess we can clean them by 6.0 (i.e., remove old exports from app_lua and app_python) 12:23 verticelo: yes, but image the person who doesn't know what to choose and chooses Squirrel, I think they would find it restricting later on with few examples and no-one who could answer their questions 12:32 miconda: and keep only kemi 12:24 miconda: I see ... the decision would be more on what scripting language you feel confortable and find the extensions you need 12:24 verticelo: Yes, but I think Kamailio should provide a hint on what to use, ie. what most companies actually use and which is most popular 12:25 verticelo: then code sharing, examples, tutorials etc would converge on that 12:25 qxork: I like that you use the language you like best 12:25 miconda: squirrel was done more as a pedagogic example, being like a search replace over app_lua or app_jsdt, but it can be suitable for embedded devices/IoT 12:26 qxork: There weren't many perl people to ask questions on when using app_perl in the past, but the point was if using it... hopefully perl isn't the question you're asking. 12:26 miconda: verticelo: from what I got from mailing lists, lua and python are the popular ones 12:26 miconda: if I have to do it, is Lua, but then I can't talk for others 12:26 miconda: and limiting to one option might not be something good in long term 12:27 miconda: because we also do not know what will happen with some of this external languages 12:27 miconda: in terms of maintenance inside kamailio, it should be minimal effort once all are cleaned from old code 12:28 miconda: as a reference, app_jsdt is a clean module, with no old exports, and it is what app_lua should look like in terms of size 12:28 miconda: I can't speak much about app_python/3, not doing much with them, but others have it in prodiction and they are well maintained 12:29 miconda: verticelo: anyhow, this could be another topic to (re)start on mailing lists, but come with some proposals for a solution, so people can see the benefits, etc... 12:29 verticelo: yepp, I'm not saying it should be limited to anything, just talking about a line in the KEMI docs saying "Most KEMI users are using app_X for their KEMI projects. If you are unsure which to use, this would be a good choice and has a wide user base" 12:30 miconda: maybe we can host a polling/voting system so community members can propose a topic and then we gather feedback 12:32 miconda: ok, so I guess we can move to the next topic 12:33 miconda: docs -- what we have, what can be done, where to host them 12:33 miconda: the issue tracker has an item to push new features in the git repo -- iirc, linuxmaniac proposed 12:34 verticelo: how does everyone feel about the KEMI docs today? as they differ from the Kamailio docs quite a bit 12:34 miconda: then there were couple of discussion what to do with the core cookbooks -- still wiki or move to markdown hosted in github, with html generated by mkdocs (or alternatives) and hosted on kamailio.org 12:35 miconda: I haven't seen much activity from non-devs on wiki and maybe having the pull requests available for improving docs can bring more contributions 12:35 miconda: if we decide to go that way, we would need a coordinated effort to migrate 12:35 verticelo: yes, I believe that is correct, it is a big pain to even consider register on the wiki site 12:36 miconda: again, it is not about all the docs, but some of them that are more in the hand of devs to maintain 12:36 verticelo: from personal experience, I contributed to the KEMI docs because it was on github, wouldn't have done it on the Wiki 12:36 miconda: like cookbooks 12:38 linuxmaniac: github seems the best approach 12:38 miconda: yeah, what I said, the wiki, if a standalone/independent system, seems to become unatractive -- not only in kamailio, I noticed to other projects I keep an eye on 12:39 miconda: ok, maybe we can have this goal at the next face to face devel meeting, or we can coordonate online to start it 12:40 miconda: next topic: administration of infrastructure, project, ... 12:40 miconda: we have the kadmin group, but haven't sync'ed to do much out there 12:41 miconda: anything that people can propose here 12:41 miconda: what is missing or what can be done to ease the "sysadmin" type of work around the project? 12:41 miconda: we have good availability of kamailio.org, from time to time we need to do distro upgrades, etc... 12:42 qxork: Definitely want to assist more with this and help where best able. 12:42 verticelo: is there a list of the tasks that needs to be done? 12:42 qxork: Distro upgrades, etc. I should be able to handle without issue 12:43 qxork: Been very happy with matrix and would also love to have a matrix server for the project. 12:43 miconda: verticelo: not having a list right now, can be made eventually, but I am also looking for tips/tools of what people use these days to make such work easier 12:44 verticelo: we have automated almost everything at work, do you have any examples of time consuming processes? 12:44 linuxmaniac: I already proposed that we move to devops approach 12:45 miconda: linuxmaniac: I think you gave a link at some point, can you post it again? 12:45 linuxmaniac: so it's easier to have a group of people maintaining servers 12:45 linuxmaniac: https://docs.debops.org/en/master/ 12:45 linuxmaniac: this is based on ansible 12:45 verticelo: ansible is nice, we run over 20 different technology stacks and projects with ansible 12:45 Llz1irq: qxork:: matrix sounds like a good idea, I am also happy with it and was thinking to propose it as a modern alternative to IRC (which can be bridged) that is not closed-off like slack 12:45 linuxmaniac: if qxork: gives me a toy to play 12:46 linuxmaniac: we can have a staging machine 12:46 linuxmaniac: or for now... just to play with debops 12:47 linuxmaniac: then the admin team can decide 12:47 miconda: linuxmaniac: I and qxork: can give access to some wm's 12:47 qxork: yup 12:48 miconda: verticelo: I will try to make the lists with some tasks to start with 12:48 JSdC: I can help with the ansible stuff if needed. 12:48 miconda: then post to sr-users and see what can be done to make it easier for all 12:48 verticelo: i think it would be great to prioritize by the most time consuming per month/year 12:49 miconda: sure 12:49 linuxmaniac: I will send an email to admin-team with my proposal 12:50 miconda: last topic I have in my list would be bounties/collaborative projects beyond those community oriented efforts 12:51 miconda: it was even today mentioned that sometimes people feel like a bounty program would be beneficial, to reward existing work or ask for new stuff 12:52 miconda: from my point of view, I was asked on several occasions about and wanted to see what is the general feeling and what solutions would be out there 12:52 miconda: my interest would be more on "mainteance" e]w 12:53 miconda: (send pressed instead of delete) 12:53 miconda: my interest would be more on "mainteance" tasks of large components that need from time to time some refactoring, which require significant effort, not only devel time 12:54 qxork: It's tough... I would like a way for people to financially donate to the project 12:54 miconda: an example will be the proper integration of ims/volte modules 12:54 qxork: for things like hosting, mainenance, travel, and project needs. I like the idea of a bounty as well. 12:54 miconda: they were imported from openimscore project, which was built on ser 0.9.x and I can see from the mailing lists that some parts were not integrated in the proper way with kamailio 12:55 miconda: then it will be also presence modules, which can benefit on scalability by relying on some no-sql backends (e.g., redis) for distributed systems 12:56 miconda: just to throw few of those mentioned to me in the past 12:56 qxork: fantastic 12:56 miconda: for ims is not only coding, it will also require some testing, and an ims testbed is not that simple to just deploy 12:57 linuxmaniac: but that needs some rules, no? 12:57 miconda: so, the idea is to have a group of developers that commit to take care of such "consistent work" and then have a mechanism to reward in a way or another 12:57 linuxmaniac: not sure about the financial side too 12:57 verticelo: are there any companies relying strongly on this that would be interested in being core backers? 12:58 miconda: verticelo: some told me they are 12:58 miconda: but we need to offer a way that they can do it 12:58 verticelo: the pypy.org project often posts "Calls for donations" for specific parts of the project that needs to updated and they set a funding target, when reached a dev gets hired to complete it 12:59 verticelo: so people donate to specific functions 12:59 miconda: for ims/volte extensions, I recall now like 3 companies 13:00 miconda: I would also be interested in sponsoring some other devs to lift from my plate if they can spend time on static analyzers, cleaning up issues reported by coverity, clang analyzers, ... 13:01 miconda: and by that I hope to get more contributors 13:01 miconda: also to the docs, not only the code 13:02 miconda: from my point of view, the major things to sort out here: 13:02 miconda: - the way to get the funds and split them 13:02 miconda: - project management for this kind of work 13:02 verticelo: general question about funding, how much money is required by the project? what is the yearly funding goal? could we have a patreon like system for companies that depend on Kamailio to donate monthly/yearly on a recurring basis and then have full transparency on how the funds are used? 13:03 verticelo: how many companies are depending on Kamailio for an important product somewhere in their stack? 13:03 miconda: now all is sort of distributed 13:03 miconda: not having a clear figure of costs 13:03 miconda: server and bandwidth offered by voztele.com 13:03 miconda: backups by lod.com 13:04 miconda: packaging infrastructure by sipwise 13:04 miconda: lot of sysadmin work by me, linuxmaniac, Henning Westerholt and qxork: 13:05 verticelo: I think a list of all work that is done, what work is required, what costs are is a good start. Knowing that, one could start to look at solutions for it. 13:05 verticelo: If it can be clearly communicated on the website, also makes it easier to ask for donations and one could show a percentage of funding completed etc 13:05 miconda: not sure what would cost to have a sysadmin subcontracted to spend like half a day per week on maintaining the infrastructure (up to date security and configs for web server, mailing lists, ...) 13:06 verticelo: i think most of it can be automated also so one wouldn't have to spend very much time on that 13:06 miconda: verticelo: ok, will try to make a list on this one as well 13:07 miconda: it is not about donations because of lack of funding, but more donations for someone that have the time and knowledge to do it properly 13:08 miconda: then for the non-sysadmin tasks, that would be spliting the effort of the work, allocating either time or funding the time of others, to share the benefits 13:08 miconda: anyhow, it seems that it is not an easy solution here 13:09 miconda: personally, I would not seem myself spending time on project management here, nor collecting the funds and splitting them 13:09 miconda: other topics anyone wants to discuss? 13:10 verticelo: well, knowing what needs to be done, if one time per year one lists the tasks and then just assigns the funds going from top > bottom of the list until the funds run out for the yearly cycle? 13:11 miconda: yep, but who does the funds management and tracks the work ... 13:12 verticelo: first task on the list is to hire someone to do that and fund that each year :) 13:12 miconda: leaving the sysadmin work aside now, I think of the next steps here 13:13 miconda: describe either the goals for ims or presence projects, post it online, ask devs to come a say what they would like to get in terms of funding 13:13 miconda: then see what we can get 13:14 miconda: it is good to see here that there is interest to contribute 13:14 miconda: but not to make it too longer today, let's see if anyone else want to discuss other topics 13:14 miconda: I think I don't have anything in my mind 13:15 verticelo: Could we have a sponsors page on the website, git repo, other places so for companies that donate reoccurring, they get some promotion placement? like this https://letsencrypt.org/sponsors/ 13:16 miconda: verticelo: definitely will be once we start this and we get funds 13:17 miconda: we should also list the companies that already "sponsor" in a way or another the project with infrastructure or other resources 13:17 verticelo: yes, I think it's super important to acknowledge the ones who contribute and really provide a promotional value for them 13:18 linuxmaniac: I really need to go, sorry 13:20 miconda: linuxmaniac: thanks for all! 13:21 miconda: if no one else has new topics to propose, we can end the meeting 13:21 miconda: everyone here with proposals, should follow up on mailing list for further discussions 13:23 qxork: thank you! 13:23 miconda: thank you everyone! 13:26 verticelo: thanks, cheers! 13:26 miconda: qxork:: will you digest the irc log and post on the wiki? 13:26 qxork: absolutely 13:29 miconda: enjoy the rest of the day, wherever you are!