[sr-dev] commit policies

Daniel-Constantin Mierla miconda at gmail.com
Tue Jun 1 23:45:46 CEST 2010


Hello,

On 5/31/10 7:55 PM, Juha Heinanen wrote:
> Jon Bonilla (Manwe) writes:
>
>    
>> A question about development and commit policies. I am going to make different
>> changes in the debian packaging files. I have commited a couple of
>> changes into
>> kamailio_3.0 branch but I am not sure about if that's the right thing
>> to do.
>>      
>    
>> Should I create my own branch and merge after the changes?
>> Commit to master? To kamailio branch?
>>      
usually, if it is a commit to fix the code/documentation, should be done 
in master then picked up (git cherry-pick -x _hash_id_) to stable 
branches. Of course, it is not a big deal if first commit is done in a 
branch then pushed to master, just that is not the natural way.

Now, for this particular case, since the work is strictly related to 
kamailio 3.0 packaging, it is ok to finish the work on kamailio_3.0 
branch and then push it to master, either via cherry-pick or as one new 
standalone commit with latest version from kamailio_3.0 -- then this one 
will be used as startup for next 3.1 (current devel) by adding the new 
modules.

Thanks,
Daniel

> jon,
>
> i'm not an expert, but if i fix a bug in 3.0, i commit/push it to
> kamailio_3.0 or sr_3.0 branch and then cherry pick it to the other one.
> if the bug also exist in master branch, i cherry pick it also there.
>
> hopefully when 3.1 is released there will not be sr and kamailio
> branches anymore because otherwise fixing bugs becomes un-manageable
> because of too many branches.
>
> -- juha
>
> _______________________________________________
> sr-dev mailing list
> sr-dev at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>
>    

-- 
Daniel-Constantin Mierla
Kamailio (OpenSER) Advanced Training
Miami, Fl, USA - June 21-23, 2010
http://www.asipto.com/index.php/kamailio-advanced-training/




More information about the sr-dev mailing list