[sr-dev] merging back to master branch

[Andrei Pelinescu-Onciul]

On Jan 29, 2010 at 11:28, Daniel-Constantin Mierla <miconda at 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:
> >>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 at 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
> >>
> >
> 
> -- 
> Daniel-Constantin Mierla
> * http://www.asipto.com/