User Tools

Site Tools


devel:irc-meetings:2019a

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
devel:irc-meetings:2019a [2019/03/09 17:26]
qxork
devel:irc-meetings:2019a [2019/03/11 20:22] (current)
qxork add transcript of meeting
Line 69: Line 69:
   * development, unit testing, documentation, etc.   * development, unit testing, documentation, etc.
  
 +===== Transcript of Meeting =====
 +
 +Note: Times are in EDT (UTC -4)
 +
 +<code>
 +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!
 +</code>
devel/irc-meetings/2019a.txt ยท Last modified: 2019/03/11 20:22 by qxork