Merge pull request #24 from fredposner/patch-1

2022a.md: add transcript

docs/devel/irc-meetings/2022a.md

@@ -86,6 +86,418 @@ Collaborative Projects:
 
 ## Transcript
 
-```
-TBA
-```
+### Thu, Dec 8 2022
+
+**miconda**  
+fyi: on this channel, today at 15:00UTC (16:00Berlin) starts the online kamailio devel meeting
+
+**miconda**  
+starting devel meeting in about 10min
+
+**oej**  
+Ready with a cup of tea
+
+**Víctor Seva**  
+(hi)
+
+**Henning Westerholt**  
+Hello
+
+**miconda**  
+Hello everyone!  
+let's allow 2-3 more mins  
+if anyone has pre-meeting questions, we can discuss shorty  
+ok ... hopefully it was enough time for the late comers to join  
+we can start the online kamailio devel meeting  
+sort of draft for agenda: <https://github.com/kamailio/kamailio-wiki/blob/main/docs/devel/irc-meetings/2022a.md#agenda>  
+everyone feel free to propose topics, probably the best is at the end ...  
+first topic would the summary and follow up after Dusseldorf devel meeting  
+I worked on a few things, the largest being switch from int to long for cfg variables  
+which had impact pretty much everywhere  
+the work continued afterwards, I think right now the foundation for it is in place  
+many variables support it (avps, xavps, var, shv, ...)  
+the main reason was that most of the systems now have 64bit CPUs, time and many values are long, which no longer fit well on 32bit integer  
+on 32bit system, should be no impact, long and int are both using 32bit
+
+**miconda**  
+on 64bit CPU the memory is aligned to at least 64bit, so the impact should not be significant in terms of real usage of memory  
+now, various variables in different module might still use int internally, I havent checked everything, but that should happen over the time, when discovered that is needed  
+helping with testing and reporting issues are appreciated, of course!  
+another work was about propagating the return code value, because of the evaluation mode in kamailio (<0 is false, >0 is true), the return code from functions was "lost" in the config interpreter processing  
+<https://www.kamailio.org/wikidocs/cookbooks/devel/core/#return_mode>  
+this has impact on config expressions  
+is disabled by default  
+but allows to get to a style that is more "standard" in behaviour  
+I am planning to add a mode when return 0 is no longer automatically exit  
+so one would have to do it in config: `if(func()==0)` exit;
+
+**Henning Westerholt**  
+if we want to enable by default, we should review the modules, a few functions are using return 0 as exit  
+AFAIK  
+nothing against it, just need to be considered
+
+**miconda**  
+it will stay the same, return 0, just the config writer has to deal with  
+then, one small bit was adding a helper function that would allow evaluating the function parameter in a specified buffer, not in the core pv buffers  
+useful when it is expected to get a very large value ... Federico reported such a case  
+jansson got a special function to cope with the case, then I thought it would be useful to have the helper function in case it will be needed for other cases  
+now maybe Henning Westerholt wants to write about his work  
+not sure if Federico Cabiddu is online now, if yes, he can write as well
+
+**Henning Westerholt**  
+Thanks Daniel. I looked into the dialog module, they are some race-conditions that are still beeing reported. I also looked into the new wolfssl module and some IMS extensions/ pull-requests (like the new IMS db_mode that was merged some days ago).  
+Regarding dialog module, I removed some debugging functions which probably causes race-conditions, lets wait for more feedback on that issue on the tracker.  
+Not sure if Alexander is online as well, they were working on performance tracing topics and siptrace module extensions
+
+**Federico Cabiddu**  
+here I am sorry, busy afternoon :)  
+yes, we have deployed the new jansson function and everything works and no issue to report
+
+**Víctor Seva**  
+I would like to mention that we are having issues with transactions and shared memory. While a transaction is being processed, CANCEL comes and boom  
+
+**miconda**  
+Federico Cabiddu: no worries, I can make the summary further if you are busy
+
+**Víctor Seva**  
+I have to say that we are doing too much inside the processing
+
+**miconda**  
+Víctor Seva: there were some commits related to this case, didn't they fix it?
+
+**Federico Cabiddu**  
+on my side of development I still have to finalize the implemeteton of OpenMetrics for xhttp_prom modules and for internal statistics
+
+**miconda**  
+ok, so Henning listed what Alexandr was working on, let's see if he comes back with some commits
+
+**Víctor Seva**  
+we can talk about that another day, I just wanted to mention that the problem, at least for us is still there
+
+**miconda**  
+otherwise, to end about Dusseldorf, we worked "hard" on some very good breakfasts, lunches and evening event, all courtesy of sipgate.de, many thanks again to them and Markus for hosting us!  
+next year we hope to get a larger group of people, but this one was not bad at all, given the conditions world wide!
+
+**Henning Westerholt**  
+It was a great re-start indeed 
+
+**miconda**  
+if no questions about Dusseldorf, then we can move to: open issues  
+Víctor Seva reported one, it would be good to get new traces, after the previous commits  
+anything else to report?  
+from the tracker (and list), the kamcmd with no autocompletion anymore, apparently due to newer ncurses library  
+openssl 3.0 support ...
+
+**Henning Westerholt**  
+kamcmd is broken since a long time, like years  
+but as you wrote, there are alternatives for sure
+
+**Stefan Mititelu**  
+<https://github.com/kamailio/kamailio/issues/3274>   -> anyone encountered this too?
+
+**miconda**  
+not using python myself -- do you need 2.7? have you tried with 3.x?
+
+**Stefan Mititelu**  
+not tried, will do
+
+**Henning Westerholt**  
+on newer distributions app_python(2) is not available anymore anyway
+
+**miconda**  
+speaking of that, I actually just added app_python3s module ;)
+
+**Henning Westerholt**  
+yes :) can you explain in a nutshell what its about?
+
+**miconda**  
+but that mainly because I wanted to make a variant more similar to the other kemi modules  
+app_python3 was based on old module, with a design that create a message object
+
+**Henning Westerholt**  
+ok, got it
+
+**miconda**  
+which has to be initialized in the mod_init python callback and a kamailio class defined for it  
+the python3s is simply statically exports KSR object and expect global functions with name ksr_request_route()/ksr_reply_route() ... no object, no other parameters  
+from performance point of view, does not seem to be significant gain, maybe in range of microseconds, but the script becomes more similar to the other kemi interpreters
+
+**Henning Westerholt**  
+More similar is also a good thing. Regarding app_python, it probably make sense to deprecate it for next release 
+
+**miconda**  
+native config, lua, python3 and ruby give similar performace results, tested with registrations and db authentication  
+haven't tested python2  
+app_jsdt seems a bit slower, like 40-50 microseconds slower in average  
+but even so, it still processes like 3500-4000 registrations per second per udp worker process
+
+**Henning Westerholt**  
+regarding issues, already mentioned the dialog topic, waiting for feedback here  
+there is some crash about acc_json, but this was for a EOL release
+
+**miconda**  
+so I would not be worried about capacity of processing with any of the kemi modules  
+to be clear, the difference was in microseconds, not milliseconds  
+and to end about kemi, I reorganized a bit the code, so a lot of duplicated code that was in each kemi module is now in core ... beter modularity and easier to extend in the future
+
+**Stefan Mititelu**  
+Henning Westerholt: related to the EOL crash, can't be reproduced and happens seldom(few months interval); maybe upgrading and including the "print_lists" fix will fix the possible race conditions.
+
+**miconda**  
+we can continue to issues reported to the tracker, mainly from feature requests point of view  
+probably the very old ones should be closed, unless some devel wants to work on specific ones  
+in which case, should leave a comment there
+
+**Henning Westerholt**  
+regarding feature requests, the stir-shaken cert caching stuff looks ok now, this one can then be closed after merging
+
+**miconda**  
+ok  
+regarding next minor releases: I haven't checked how many commits got in the branches, probably there will be new releases in 5.5 and 5.6 either before the winter holidays, or in January 2023  
+I will have to review the branches  
+unless someone considers it is pretty urgent to hurry up because of some fixes  
+we do have nightly builds, though, if one needs to deploy ahead  
+well, for debian/ubuntu, not sure about rpms
+
+**Henning Westerholt**  
+CentOS RPMs will get over time less important, people will move away to Debian/Ubuntu or some other RPM based distros
+
+**miconda**  
+I think rpms are for a bunch of distros, including suse and fedora ...
+
+**Henning Westerholt**  
+the rpm service is AFAIK only for CentOS  
+opensuse, yes
+
+**miconda**  
+<https://rpm.kamailio.org/>
+
+**Henning Westerholt**  
+ah, you are right, my fault
+
+**miconda**  
+coming to CI and github actions  
+there is PR which seemed a bit strange, being related to CodeQL and LGTM  
+because github offered somehow integration with LGTM and it is active for kamailio  
+not sure if they are going to change it and needs to be moved to GH actions
+
+**Henning Westerholt**  
+yes, I looked into it
+
+**miconda**  
+or codeql is something different
+
+**Henning Westerholt**  
+Victor and I already reviewed, seems to be ok. They basically got bought from github  
+so the lgtm will be switched off  
+and the new service replaces it  
+its moved from gh app to gh actions
+
+**miconda**  
+ok
+
+**Henning Westerholt**  
+we will get some new reports, need probably some time to fine-tune it, as they extended it a bit
+
+**miconda**  
+anything else that we should add to GH actions?  
+if anyone has suggestions from their other projects ...
+
+**Víctor Seva**  
+It would be nice to have a clang format check 
+
+**Henning Westerholt**  
+you mean, like for coding style? or for correctness
+
+**Víctor Seva**  
+Coding style 
+
+**Henning Westerholt**  
+we still have different coding styles in the modules, which can be a bit confusing. maybe this needs to be harmonized first
+
+**miconda**  
+there is a clang-format file in root directory  
+that is used when calling clang format  
+I did it for a couple of modules  
+the only thing I was missing (or disliking) was the structure formatting  
+it is not done uniform, being a matter of line length  
+I mean about variables being assigned with a structure, like module exports  
+but can be dealt with by using clang format on/off
+
+**Víctor Seva**  
+If we want to unify coding style, we have to enforce it.  
+I can volunteer to generate the commits formating with clang tool
+
+**miconda**  
+I am not against using clang format, pretty ok for me
+
+**Víctor Seva**  
+One commit per module
+
+**miconda**  
+I think some were concerned about tracking changes (Henning?!?) ...  
+like when using git blame ...
+
+**Henning Westerholt**  
+yes, this is the only thing. but if we want to have a uniform style, there is no other way  
+one can of course also got back one release etc..  
+When changing the modules, we probably should exclude the "special" structures like Daniel mentioned
+
+**miconda**  
+so when it is done, has to be done for all code and have like a new tracking point 0
+
+**Henning Westerholt**  
+yes
+
+**miconda**  
+anything else for GH actions?
+
+**Víctor Seva**  
+I'm going to be blamed, no problema 
+
+**miconda**  
+ok, then infrastructure (maintenance), communication channels/mailing lists  
+for infrastructure, soon there should be a server upgrade for kamailio.org  
+to move to latest stable before old stable goes unmaintained ...  
+maybe even this year, if the time allows it, need to sync with Oriol just in case we have to revert to a backup snapshot  
+probably a bunch of 5-10 mins downtime intervals ... for reboots and tunnings  
+for communication channels/mailing lists, all fine for me, but if someone has new suggestions, I am open to discuss
+
+**Henning Westerholt**  
+sounds like a good plan, update would be nice
+
+**Fred Posner**  
+I think mail is more than enough notice
+
+**Henning Westerholt**  
+maybe we can get a bit more CPU power, the spam filter job is really inefficient implemented right now  
+maybe they can move it to a newer architecture/physical host, should already help a lot
+
+**miconda**  
+it is a 4 CPU system
+
+**Henning Westerholt**  
+i noticed that sometimes it takes like 10-15min to process a list to the mailing list due to the spam filter, but might be also some issues from time to time
+
+**miconda**  
+the load does not seem high, maybe the spam daemon needs some care
+
+**Henning Westerholt**  
+look after you send some messages to the list, then it goes up  
+it filters every messages many times basically  
+but it works, not critical sure
+
+**miconda**  
+ok -- we have spamassassin, maybe there are better options these days  
+I will check and if more cpu helps, we will ask for  
+anything else on ifrastructure?
+
+**Henning Westerholt**  
+github wiki seems to be fine, not that much PRs yet,though  
+nothing else from my side
+
+**miconda**
+indeed, at least we don't have to deal with user accounts and spam anymore
+
+**Henning Westerholt**
+yes, thats great
+
+**miconda**  
+still many pages need updates for proper markdown formatting, some old dokuwiki styles are still there  
+but they are readable ...  
+so then we covered "updates for wiki with markdown and mkdocs", if nobody wants to add on this topic  
+then: next major release  
+5.7 or 6.0?  
+anything relevant missing?  
+and roadmap/timelines ...  
+hard to decide ...  
+about 5.7 or 6.0, I guess  
+changes related to long and return code can lead to a 6.0 ...
+
+**Henning Westerholt**  
+I'd go for 6.0 if we make some breaking changes (like the earlier discussed return code topic) that needs some user cfg refactoring. Otherwise currently its more a 5.7, i think  
+if we leave it disabled, old status kept
+
+**miconda**  
+what about code format, should that matter for a 6.0?
+
+**Henning Westerholt**  
+coding style of modules? its more an internal topic, probably not that relevant for users
+
+**miconda**  
+yep, but as reference, about contribution styles ...
+
+**Henning Westerholt**  
+ok, sure if we get some more strict rules about it, got it
+
+**miconda**  
+backports might not be easy afterwards  
+with the current mode of cherry-picking
+
+**Henning Westerholt**  
+this is true  
+nothing against 6.0, but previously I thought its not yet decided if you want to go for switching the return code as default  
+etc..
+
+**miconda**  
+maybe also the today's PR discussion about log levels has to be sorted out for next release  
+then 5.7 vs 6.0 can be decided later, as things move on and see where they get  
+probably as a timeline, freezing should somewhere in the first part of spring 2023  
+not sure if earlier makes sense  
+aiming to release april-may 2023 ...
+
+**Henning Westerholt**  
+Sounds good  
+regarding further development, there are probably some more extensions for the IMS modules coming in, similar to the db_mode extensions merged some days ago
+
+**miconda**  
+@oej proposed SPDX identifiers for code (SBOM - Software Bill of Materials) ...
+
+**Henning Westerholt**  
+might be also a larger change with some impact on merging/code structure
+
+**miconda**  
+not sure if oej is still around at this time ...
+
+**Henning Westerholt**  
+he seems to be really interested in it, but of course difficult to guess about his schedule/plans regarding additions
+
+**miconda**  
+ok, we wait for him to write on mailing list ...  
+anything else to discuss?
+
+**Henning Westerholt**  
+there were some discussions/PR about async rtpengine - but it seems to be feasible by other (non-code) means, which is of course better  
+the other PRs are more extensions or some smaller changes
+
+**miconda**
+as for events next year: FOSDEM 2023 is going to be in person in Brussels, February 4-5  
+RTC devroom is half day on Feb 5 (Sunday)
+
+**Henning Westerholt**
+yes, I will be there if all works out with traveling  
+and not another virus comes around :)  
+have you decided already about your plans?
+
+**miconda**  
+and if world runs smooth, Kamailio World 2023 will be also in-person, in Berlin, June 5-7  
+for Fosdem, not decided yet, I will try to be there as every year, but booking the trip will be days before, because it is not easy to cancel and there is still high risk of not being able to travel  
+it is winter season and many viruses seem to have fun around :-)  
+that's the reason we pushed a bit Kamailio World more into warmer season  
+
+**Henning Westerholt**  
+Summer in Berlin is definitely better than Winter in Bruessel  
+
+**miconda**  
+CfP and more details about Kamailio World 2023 should be published at beginning of 2023  
+
+**Víctor Seva**  
+I'm in the train. So, connection will drop from time to time :)  
+
+**miconda**  
+anything else that somebody wants to discuss as part of devel meeting?  
+if not, then we can end it and switch to free discussion (will not be in the transcripts on wiki)  
+3  
+2  
+1  
+thank you everyone!