On 07.05.19 18:34, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
This will be fixed, just a time when a lot of devs are traveling to Berlin. It's a regression by a large enhancement of the module, there are many commits there, so reverting is not the easiest option here, because the enhancement has to stay, only the regression needs to be fixed.
It is very easy to revert to 5.2 level:
- copy *.c and *.h from 5.2 siptrace to master
- git commit -a
You can also do that on your local clone
I don't understand why it cannot be done while waiting for the fix to current master.
Because the review was done, reverting means doing again a lot of work which was done already. Reverting is for the cases when something was pushed without wanting that at all (like a backport of a new feature in a stable branch, or code that should not be accepted at all). In this case it is a regression/a bug introduced with couple of new features that stay -- there were many such cases in the past and they will be in the future. That is the purpose of master branch -- to add new features and fix their bugs till next stable release.
It may happen that some issue stays a bit unresolved in the master branch, due to certain conditions our of the willingness of the developer. If a developer says that "a bug" won't be fixed because he doesn't want, then it can also be the case for a revert, but if a developer (does not have to be the initial author of the commits) says it is going to take care of it but it is in holidays/traveling/etc... for few days, it is not a critical case with a master branch. Reverting is messing up the commit history as well, which we use for release notes of major versions.
Anyhow, with Kamailio World finished, I just got a bit of time and pushed a commit -- no time to test right now, but maybe you can give it a try and then report if works. If not, I will dig further soon, just give the new error messages/details/...
Cheers, Daniel
I have GUI for siptrace, not for sipdump.