[sr-dev] merging back to master branch

Daniel-Constantin Mierla miconda at gmail.com
Fri Jan 29 15:16:53 CET 2010



On 1/29/10 3:03 PM, Andrei Pelinescu-Onciul wrote:
> 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.
>    
yes, I know, I was referring to the remaining ones.

I imported separately the updates from Makefile and etc/radius 
dictionary for k.

> 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).
>    
tm things I committed later indeed, to fix issues occurred in uac and 
sip trace modules, would be good to put higher priority on them.

> I'll try to do it this weekend.
> Are there ones that should get faster into master then the others?
>    
There are not many of them, but anyhow, the order:
- drop onreply route
- the new tm stuff (since they are fixes)
- sanity moved from modules_s to modules (modules_k version is broken 
with 3.0 core parser, so removed
- statistics
- xavp

The error for integer parameters of module function should be skipped. I 
think these are all now.

Thanks,
Daniel

>> 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/
>>      

-- 
Daniel-Constantin Mierla
* http://www.asipto.com/




More information about the sr-dev mailing list