1 Jun
2010
1 Jun
'10
11:45 p.m.
Hello,
On 5/31/10 7:55 PM, Juha Heinanen wrote:
Jon Bonilla (Manwe) writes:
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
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?
> 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(a)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/