Hello,
during past on-site/online devel meetings as well as on mailing lists or
tracker, there were various discussions around the idea or requests to
make new features available quicker to stable branches.
Of course, one can do local git cherry-picking, but I thought to bring
this in discussion and see if makes sense to get something more
coordinated between developers and community. Therefore I am
cross-posting to sr-dev and sr-users to see if there is interest for it
from both communities.
Somehow inspired from Debian, my first idea would be to create a
"x.y-backports" branch, where "x.y" is the branch for the stable release
series. For example, with 5.6 release series built from branch "5.6",
there could be "5.6-backports" branch which is kept in sync in "5.6" but
also can get "selected" new features from devel (master branch) backported.
The "selected" new features should be mostly a matter of the people
willing to put effort in backporting, but I would consider a list
recommendations not to end up with devel and backports branches being
more or less the same. For example, in the "no-backporting" list:
- no backporting of completely new modules
- no backporting of significant changes to the config file language
and native scripting interpreter
In the "ok-to-backport":
- updates to enable use with newer versions of external libraries
- changes to make some functions/modules to cope better with the core
infrastructure or end points
Commits to the backports branch can be proposed via pull requests.
The backports branch should be done only for latest stable version,
picking from the development version. Right now it would be 5.6, but we
can wait till 5.7 is released and then have it for it.
No packaging and no official releases should be made from backports
branch, only a git branch to be maintained as a community effort. Of
course, if someone wants to put more resources into it, we can discuss
about.
Anyhow, the first questions would be if such branch sounds good to have
and if there are people that think they can also contribute to maintain it.
Cheers,
Daniel
--
Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference - June 5-7, 2023 - www.kamailioworld.com
Good morning everyone ,
My name is Wael Heni : https://www.linkedin.com/in/heniwael/
I would like to contribute to the project , i will start by resolving bugs
, then may be i will try to add feature
but i need a few docs about installing the dev env and getting the
permission to pushing to github repository
Any help is appreciated
Regards
Wael
Hello,
in about 1 hour the kamailio.org server will be rebooted for some system
upgrades, it should be quickly back running, but if anyone accesses the
web/wiki or mailing lists archives exactly during that time, they might
not respond -- just wait for a minute and try again.
Cheers,
Daniel
--
Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference - June 5-7, 2023 - www.kamailioworld.com
Hi all,
I looked at Kamailio 5.6.3 makefiles and saw mention of clang being
supported. Yet when I try to build it with clang (more precisely, I build a
C++ module using clang that includes some Kamailio C headers via "extern
C") I get following error:
In file included from /tmp/kamailio/kamailio/modules/tm/t_funcs.h:45:
/tmp/kamailio/kamailio/modules/tm/timer.h:204:2: error: no matching
function for call to 'atomic_cmpxchg_int'
Any suggestions on how to overcome this error or any general suggestions
for using Kamailio + clang?
clang version 14.0.6 (Red Hat 14.0.6-4.el9_1)
--
Ivan Ribakov
Software Engineer
www.zaleos.net