29 Jan
2010
29 Jan
'10
9:03 a.m.
On Jan 29, 2010 at 11:28, Daniel-Constantin Mierla <miconda(a)gmail.com> wrote:
since no comment so far, I guess everyone is fine to
get the changes in
the master branch. Are they wanted in sr_3.0?
Most of them (except the ones listed in this mail and new commits on
k3.0) are already merged to sr_3.0 and master.
For the other I didn't have time to look at them in more detail
(especially the changes to the tm callbacks and the params).
I'll try to do it this weekend.
Are there ones that should get faster into master then the others?
Andrei
I can cherry pick them, if there is no other volunteer.
Cheers,
Daniel
On 1/19/10 12:47 PM, Daniel-Constantin Mierla wrote:
probably we should set some timeline for people that want to comment
on some commits, otherwise we may wait for ever. I would prefer to
happen asap, to open new development within all source code.
Cheers,
Daniel
On 1/15/10 3:31 PM, Daniel-Constantin Mierla wrote:
--
Daniel-Constantin Mierla
* http://www.asipto.com/ Hi Andrei,
thanks, I have free afternoon now :-) ... more comments inline.
On 1/15/10 3:07 PM, Andrei Pelinescu-Onciul wrote:
On Jan 15, 2010 at 13:06, Andrei
Pelinescu-Onciul<andrei(a)iptel.org>
wrote:
[...]
>>BTW: please cherry-pick into sr_3.0 and not into master. We'll
>>merge sr_3.0
>>again into master when we're done.
>I've created another branch (tmp/k_3.0_sr_backports) on which I
>started
>cherry-picking commits from kamailio_3.0. So far I've started adding
>stuff that affects only kamailio modules, kamailio config, kamailio
>packaging or only the kamailio mode and also some other simpler
>changes
>that I reviewed.
>I'll leave more debatable or more complex stuff at the end.
>
>When we are ready, we can just merge this branch into sr_3.0.
>Of course if somebody else wants to do some cherry-picking, be my
>guest
>(just make sure you don't add stuff that shouldn't be on sr_3.0 and
>that
>you use the tmp/k_3.0_sr_backports branch).
So far I've cherry-picked everything except:
* kamailio specific version and makefile changes:
b40bf31 version set to 3.0.0-rc3
9b48242 version set to 3.0.0-rc2
6d1e9f7 pkg: set version to 3.0.0 in debian changelog
this should be in pkg/kamailio/debian/ (kamailio specific deb specs)..
0a0bd9e ChangeLog: imported v1.5.x file
19cb9a0 Makefile: version set to 3.0.0
393027b sanity modules in now in modules/
39ce774 Merge remote branch 'origin/sr_3.0' into kamailio_3.0
adef635 version set to 3.0.0-rc1
d2de5be Makefile: removed modules_s from default compile list
f771b05 sanity: fix include file due to previous re-location
011cc3f sanity: moved module from modules_s to modules
this one should go -- former modules_k/sanity was imported in 1.5
from ser version. I removed it from modules_k and moved
modules_s/sanity in modules./
6a0c4de Merge commit 'origin/sr_3.0' into
kamailio_3.0
224faa3 etc: renamed dictionary.radius to dictionary.kamailio
8d668eb core: updated of CFG_NAME
3259e89 core: combined Makefile with sr_3.0 version
3996abc Makefile: tunnings for K-3.0
There were some additions which should impact only kamailio (e.g.,
kamailio module groups used for packaging) and ease building with
custom name -- but I think those were picked already.
c7b6396 k-3.0: creating the branch kamailio_3.0
* stats (I did not have time to look through them yet, they might be
impact
free enough for sr_3.0):
if kex is not loaded, all these will be close to zero impact. The
event framwork in core is already there in use by topoh.
(BTW, master branch has latest version on topoh -- i picked from
there into k_3.0)
f4b64fc update drp_reqs statistics
770ced3 update drp_rpls statistics
058f978 update fwd_rpls statistics
e524a95 update err_reqs statistics
b542c1c update err_rpls statistics
feef8d6 update bad_URIs statistics
0c7926f update bad_msg_hdr statistics
6a84eee core: update fwd_reqs stat
ea5ee19 kex: support to update core stats via core events
47c8917 core: added new event SREV_CORE_STATS
* drop from some routes (this is debatable since it will slightly alter
the behaviour, but if nobody opposes I'll backport it too):
8a43c6f core: usage of drop in onsend_route for Kamailio compatibility
0621319 core: drop reply in K compatible style
These are good, I doubt someone was using drop to exit onreply_route
but expecting reply to be forwarded.
* xavps stuff
05f40fa pv: export new PV class $xavp(name)
0cb4c9f core: introducing xavp (eXtended AVP)
a6ab145 tm: set/reset head of xavps on TM events
a827000 pv: new pv class $xavp(...)
bca7a65 core: destroy xavp list once sip msg processing is done
They are within define, so impact 0 by default. I would prefer them
in master, still disabled for now, but I am using them and in the
future I plan to update some modules since they are better structured
and will get rid of some module parameters and internal code.
* other
eb687b7 throw error if parameters to module functions are int
this should not be backported, I will remove it as well for the next
patch release of k 3.0.0.
8a43c6f core: usage of drop in onsend_route for
Kamailio compatibility
this was listed few lines above.
Overall, I think we are doing very well, merging went pretty
straightforward.
To summarize my opinions and answer your questions, I do not oppose
drop reply behavior in onreply routes and I want stats and xavps in
master as well (impact 0 by default). You can go ahead with rest of
commits.
That will create a good devel framework for the future and we can
replace some implementations as we get new versions (e.g., stats).
Daniel
* dupes (code already present in sr_3.0, these are
usually the
result of
backports w/o cherry-pick or cherry-picks that conflicted):
7956c73 Backport of the changes (see previous commits).
99d5e6c Backport of the changes (see previous commits).
f47abc0 core: fix the fixup_spve_uint() and fixup_spve_str()
07b90c0 tm: onreply_route executed under lock to protect the avps
dc2361c core: kamailio mode config parser fix
e494c2c cfg parser update for KAMAILIO compat mode
7a96791 fix typo in location flags settings
Andrei