Date:

• Proposed: 15:00 UTC, Monday, Mar 11, 2019
  • can attend: dcm, vseva, fisp
  • cannot attend:
• Alternatives (add your id if you can attend)
  • Mar 04, Monday: vseva
    • cannot attend: dcm
  • Mar 06, Wednesday: vseva
    • cannot attend: dcm
  • Mar 07, Thursday: dcm
    • cannot attend: vseva

Time of the meeting across the world:

• 16:00 - Berlin, Germany
• 15:00 - London, UK
• 10:00 - New York, USA
• 07:00 - Seattle, 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
• vseva - Victor Seva (linuxmaniac)
• fisp - Fred Posner (qxork)

Kamailio Development Status:

• open issues (dcm)
• minor releases for 5.1 and 5.2 branches (dcm)
• end of maintenance for 5.0 branch

Administration:

• servers maintenance
• community interaction and communication channels
• existing mailing lists review

Kamailio 5.3 (next major release):

• roadmap
• features
  • anything relevant that is missing?
  • priorities
• default config with rtpengine
• packaging rtpengine on deb.kamailio.org and rpms ..

Documentation:

• tutorials/cookbooks – wiki vs mkdocs (github markdown)

Collaborative Projects:

• development, unit testing, documentation, etc.

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[25956]: 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 sr-users@lists.kamailio.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!