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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev