[sr-dev] merging back to master branch

[Andrei Pelinescu-Onciul]

On Jan 13, 2010 at 17:35, Andrei Pelinescu-Onciul <andrei at iptel.org> wrote:
> On Jan 13, 2010 at 17:32, Andrei Pelinescu-Onciul <andrei at iptel.org> wrote:
> > On Jan 12, 2010 at 13:47, Daniel-Constantin Mierla <miconda at gmail.com> wrote:
> > > Hello,
> > > 
> > > what is the recommended way to merge back into master branch the fixes 
> > > done in 3.0 releases?
> > 
> > git merge --log --no-ff origin/sr_3.0
> > 
> > (the long version it's documented on 
> >  http://sip-router.org/wiki/git/merge-into-master ).
> > 
> > > 
> > > The master is now behind of sr_3.0 and kamailio_3.0 with many fixes. 
> > 
> > I've just merged sr_3.0 into master.
> > 
> > > kamailio_3.0 should be pretty much sync'ed with sr_3.0, but has some 
> > > kamailio specific updates that need to be discussed before pushing to 
> > > master.
> > 
> > To see the differences you can use:
> > git log --oneline --left-right --cherry-pick origin/sr_3.0...origin/kamailio_3.0 | grep "^>"
> > This will skip over cherry-picked commits.
> > There are 139 commits on k_3.0 which are not on sr_3.0. Some of them are
> > false positives (e.g. version number changes).
> > > 
> > > I think fixes in modules_k can get bulk in master, for the rest I will 
> > > try to compile a summary.
> > 
> > Please cherry-pick anything that should go into modules_k or is obvious. When
> > the list gets smaller we can start discussing them individually. I think
> >  that almost all the core & tm changes should go to sr_3.0 too, but it
> >  might be better to review them one more time.
> 
> 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).

Andrei