release branches

[Andrei Pelinescu-Onciul]

To prepare for the kamailio 3.0 and sip-router 3.0 releases (according
to what we discussed at the sr meeting last week) I've created the
sr_3.0 and also enabled kamailio_3.0 (meaning that it can be created
anytime).

The "main" branches will look like:

master
|
* --- sr_3.0
      |
      * --- kamailio_3.0


Only fixes should be committed to sr_3.0. It should become a generic
stable branch, so it should not contain any specific changes (e.g. name
changes only for sr_3.0 a.s.o.). When we will release 3.0, we will
just create a sr_3.0_release branch and we will do any specific changes
there.

To minimize backporting/forwardporting work, if a bug is discovered on
master or on kamailio_3.0 it should be fixed in the sr_3.0 branch and
then  latter sr_3.0 can be pulled (in master or kamailio_3.0):

                   fix
                    |
                    | (commit)
                    |
         (merge)    v   (merge)
master <-------- sr_3.0 --------> kamailio_3.0


If by mistake a sr_3.0 relevant fix is committed first to another branch,
 git cherry-pick -x can (and should) be used to backport it.
E.g.:
git checkout sr_3.0
git cherry-pick -x <fix_commit_id>
git pull origin sr_3.0:sr_3.0

If in any doubt, please create another branch (e.g. tmp/3.0_update
 or <username>/3.0_proposed_updates) and request a pull/merge or commit
 it into master.
Be especially carefully not to merge by mistake master or kamailio_3.0
into sr_3.0. It's ok only to merge sr_3.0 into master and sr_3.0 into
kamailio_3.0. Any other merge combination is bad.


The kamailio_3.0 branch is not yet created, but it can be created any time
the kamailio release managers decide it's best.
It should be created from sr_3.0. E.g.:
git checkout -b kamailio_3.0 origin/sr_3.0
git push origin HEAD:kamailio_3.0 # this command will create it

If you think we should have some commit restrictions on this branch
(IMHO to avoid mistakes is better to restrict the people who are allowed
to commit on release branches) or sr_3.0, let me know.

It would be better to avoid deleting files on the kamailio_3.0 branch.
If a file is deleted then any merge or git cherry-pick that would
involve changes to the deleted file will fail, requiring manual
patching.


Andrei

_______________________________________________
sr-dev mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

[Jan Janak-2]

On Sat, Oct 10, 2009 at 3:27 AM, Andrei Pelinescu-Onciul
<[hidden email]> wrote:
> [...]
> The kamailio_3.0 branch is not yet created, but it can be created any time
> the kamailio release managers decide it's best.
> It should be created from sr_3.0. E.g.:
> git checkout -b kamailio_3.0 origin/sr_3.0
> git push origin HEAD:kamailio_3.0 # this command will create it

I think it is safer to write the last command as:

git push origin kamailio_3.0:kamailio_3.0

To explain the parameters:
 - origin is a shorthand for the remote repository URL

 - the name before the colon (:) is the name of the local branch you
want to push
   into the remote repository (the name after -b in git checkout above)

 - the name after the colon is the name of the branch you either want
to create or
   push to (if it exists) in the remote repository.

I think we should not be using HEAD in such commands because HEADs can
be detached (not referring to any branch).

  Jan.

_______________________________________________
sr-dev mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

[Daniel-Constantin Mierla]

Hello,

On 10.10.2009 3:27 Uhr, Andrei Pelinescu-Onciul wrote:

> To prepare for the kamailio 3.0 and sip-router 3.0 releases (according
> to what we discussed at the sr meeting last week) I've created the
> sr_3.0 and also enabled kamailio_3.0 (meaning that it can be created
> anytime).
>
> The "main" branches will look like:
>
> master
> |
> * --- sr_3.0
>       |
>       * --- kamailio_3.0
>  

thanks!

I was wondering about possibility to use something like "kamailio/3.0"
in the same way of "tmp/xyz".

Not sure if is better or whether is actually any difference in such
naming policy of git branches.

For K 3.0 we may need to add new files, rename files, remove some
modules, etc. which I understood will create troubles in merging. I
think by pushing to sr_3.0 first we ensure portability to master in an
easy way.

Cheers,
Daniel

>
> Only fixes should be committed to sr_3.0. It should become a generic
> stable branch, so it should not contain any specific changes (e.g. name
> changes only for sr_3.0 a.s.o.). When we will release 3.0, we will
> just create a sr_3.0_release branch and we will do any specific changes
> there.
>
> To minimize backporting/forwardporting work, if a bug is discovered on
> master or on kamailio_3.0 it should be fixed in the sr_3.0 branch and
> then  latter sr_3.0 can be pulled (in master or kamailio_3.0):
>
>                    fix
>                     |
>                     | (commit)
>                     |
>          (merge)    v   (merge)
> master <-------- sr_3.0 --------> kamailio_3.0
>
>
> If by mistake a sr_3.0 relevant fix is committed first to another branch,
>  git cherry-pick -x can (and should) be used to backport it.
> E.g.:
> git checkout sr_3.0
> git cherry-pick -x <fix_commit_id>
> git pull origin sr_3.0:sr_3.0
>
> If in any doubt, please create another branch (e.g. tmp/3.0_update
>  or <username>/3.0_proposed_updates) and request a pull/merge or commit
>  it into master.
> Be especially carefully not to merge by mistake master or kamailio_3.0
> into sr_3.0. It's ok only to merge sr_3.0 into master and sr_3.0 into
> kamailio_3.0. Any other merge combination is bad.
>
>
> The kamailio_3.0 branch is not yet created, but it can be created any time
> the kamailio release managers decide it's best.
> It should be created from sr_3.0. E.g.:
> git checkout -b kamailio_3.0 origin/sr_3.0
> git push origin HEAD:kamailio_3.0 # this command will create it
>
> If you think we should have some commit restrictions on this branch
> (IMHO to avoid mistakes is better to restrict the people who are allowed
> to commit on release branches) or sr_3.0, let me know.
>
> It would be better to avoid deleting files on the kamailio_3.0 branch.
> If a file is deleted then any merge or git cherry-pick that would
> involve changes to the deleted file will fail, requiring manual
> patching.
>
>
> Andrei
>
> _______________________________________________
> sr-dev mailing list
> [hidden email]
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>
>  

--
Daniel-Constantin Mierla
* Kamailio SIP Masterclass, Nov 9-13, 2009, Berlin
* http://www.asipto.com/index.php/sip-router-masterclass/


_______________________________________________
sr-dev mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

[Andrei Pelinescu-Onciul]

On Oct 11, 2009 at 10:54, Daniel-Constantin Mierla <[hidden email]> wrote:

> Hello,
>
> On 10.10.2009 3:27 Uhr, Andrei Pelinescu-Onciul wrote:
> >To prepare for the kamailio 3.0 and sip-router 3.0 releases (according
> >to what we discussed at the sr meeting last week) I've created the
> >sr_3.0 and also enabled kamailio_3.0 (meaning that it can be created
> >anytime).
> >
> >The "main" branches will look like:
> >
> >master
> >|
> >* --- sr_3.0
> >      |
> >      * --- kamailio_3.0
> >  
>
> thanks!
>
> I was wondering about possibility to use something like "kamailio/3.0"
> in the same way of "tmp/xyz".
>
> Not sure if is better or whether is actually any difference in such
> naming policy of git branches.

There wouldn't be any difference from git's point of view.
The access policy is based on matching a regular expression on the
branch name, so it wouldn't make any difference there either.
The only problem is cvs access: branches containing '/'  cannot be
exported to cvs, so if someone is using cvs to access the sip-router
repository, they wouldn't be able to access these branches.

However it might be a little confusing
(e.g. git checkout -b kamailio/3.0 origin/kamailio/3.0
       git push origin kamailio/3.0:kamailio/3.0).

Let me know if you want to change it.

>
> For K 3.0 we may need to add new files, rename files, remove some
> modules, etc. which I understood will create troubles in merging. I
> think by pushing to sr_3.0 first we ensure portability to master in an
> easy way.

Yes, it would be best to push all common changes to sr_3.0 first
(less work for everybody).

Just to clarify a bit: the problems will be only for people maintaining
the kamailio_3.0 branch, which will not be able to get changes from
sr_3.0 by merging, if the changes "touch" a file which was deleted on
the kamailio_3.0 branch => you will have to do manual patching in this
cases (or if the commit touching the deleted files can be clearly
separated, you could use git cherry-pick -x  <the_other_commits>).
Adding new files, moving and renaming won't introduce any problems
(merge tracks them in most cases with a few exceptions, like replacing a
file with a directory with the same name and then moving the file in
that directory).

Irrespective of what changes happen or not in the kamailio branch, one
should never attempt to merge it back to sr_3.0 or master
(sr_3.0 to kamailio_3.0 is ok, kamailio_3.0 to sr_3.0 is _not_ since we
 do not want k specific changes in sr_3.0).


Andrei

_______________________________________________
sr-dev mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

[Daniel-Constantin Mierla]

On 11.10.2009 11:40 Uhr, Andrei Pelinescu-Onciul wrote:

> On Oct 11, 2009 at 10:54, Daniel-Constantin Mierla <[hidden email]> wrote:
>  
>> Hello,
>>
>> On 10.10.2009 3:27 Uhr, Andrei Pelinescu-Onciul wrote:
>>    
>>> To prepare for the kamailio 3.0 and sip-router 3.0 releases (according
>>> to what we discussed at the sr meeting last week) I've created the
>>> sr_3.0 and also enabled kamailio_3.0 (meaning that it can be created
>>> anytime).
>>>
>>> The "main" branches will look like:
>>>
>>> master
>>> |
>>> * --- sr_3.0
>>>      |
>>>      * --- kamailio_3.0
>>>  
>>>      
>> thanks!
>>
>> I was wondering about possibility to use something like "kamailio/3.0"
>> in the same way of "tmp/xyz".
>>
>> Not sure if is better or whether is actually any difference in such
>> naming policy of git branches.
>>    
>
> There wouldn't be any difference from git's point of view.
> The access policy is based on matching a regular expression on the
> branch name, so it wouldn't make any difference there either.
> The only problem is cvs access: branches containing '/'  cannot be
> exported to cvs, so if someone is using cvs to access the sip-router
> repository, they wouldn't be able to access these branches.
>
> However it might be a little confusing
> (e.g. git checkout -b kamailio/3.0 origin/kamailio/3.0
>        git push origin kamailio/3.0:kamailio/3.0).
>
> Let me know if you want to change it.
>  

it is ok then. I thought there might be a different path on the source
tree, with some benefits in handling.

Cheers,
Daniel

>> For K 3.0 we may need to add new files, rename files, remove some
>> modules, etc. which I understood will create troubles in merging. I
>> think by pushing to sr_3.0 first we ensure portability to master in an
>> easy way.
>>    
>
> Yes, it would be best to push all common changes to sr_3.0 first
> (less work for everybody).
>
> Just to clarify a bit: the problems will be only for people maintaining
> the kamailio_3.0 branch, which will not be able to get changes from
> sr_3.0 by merging, if the changes "touch" a file which was deleted on
> the kamailio_3.0 branch => you will have to do manual patching in this
> cases (or if the commit touching the deleted files can be clearly
> separated, you could use git cherry-pick -x  <the_other_commits>).
> Adding new files, moving and renaming won't introduce any problems
> (merge tracks them in most cases with a few exceptions, like replacing a
> file with a directory with the same name and then moving the file in
> that directory).
>
> Irrespective of what changes happen or not in the kamailio branch, one
> should never attempt to merge it back to sr_3.0 or master
> (sr_3.0 to kamailio_3.0 is ok, kamailio_3.0 to sr_3.0 is _not_ since we
>  do not want k specific changes in sr_3.0).
>
>  

--
Daniel-Constantin Mierla
* Kamailio SIP Masterclass, Nov 9-13, 2009, Berlin
* http://www.asipto.com/index.php/sip-router-masterclass/


_______________________________________________
sr-dev mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

[Henning Westerholt]

Some javascript/style in this post has been disabled (why?)

On Samstag, 10. Oktober 2009, Andrei Pelinescu-Onciul wrote:
> If by mistake a sr_3.0 relevant fix is committed first to another branch,
> git cherry-pick -x can (and should) be used to backport it.
> E.g.:
> git checkout sr_3.0
> git cherry-pick -x <fix_commit_id>
> git pull origin sr_3.0:sr_3.0

Hi Andrei,

i'Ve tried today to cherry-pick some changes from master to the sr_3.0 branch. Here is what i did:

henning@ca:~/sip-router$ git checkout --track -b marius-tmp origin/sr_3.0
Branch marius-tmp set up to track remote branch refs/remotes/origin/sr_3.0.
Switched to a new branch "marius-tmp"

henning@ca:~/sip-router$ git cherry-pick -x e06a69d625d4c1293fceef13f9eca22e14662f9f
Auto-merged modules/carrierroute/cr_func.c
Finished one cherry-pick.
Created commit 084ad8a: If the user parameter is "<null>" (e.g a empty username in the request URI), do not copy this value to the rewritten uri.
1 files changed, 21 insertions(+), 10 deletions(-)
[some more cherry picks..]

henning@ca:~/sip-router$ git log

Shows the correct changes

henning@ca:~/sip-router$ git status
# On branch marius-tmp
# Your branch is ahead of 'origin/sr_3.0' by 11 commits.

Also fine.

According to the tutorial i found i need now to push this, but i'm not sure if the command really does the right thing:

henning@ca:~/sip-router$ git push origin marius-tmp --dry-run
To ssh://[hidden email]/sip-router
* [new branch] marius-tmp -> marius-tmp

It seems that it want to create a new remote branch, which is not really what i want..

Best regards,

Henning

_______________________________________________
sr-dev mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

[Jan Janak-2]

Henning,

On Thu, Oct 29, 2009 at 2:00 PM, Henning Westerholt
<[hidden email]> wrote:

> On Samstag, 10. Oktober 2009, Andrei Pelinescu-Onciul wrote:
>> If by mistake a sr_3.0 relevant fix is committed first to another branch,
>> git cherry-pick -x can (and should) be used to backport it.
>> E.g.:
>> git checkout sr_3.0
>> git cherry-pick -x <fix_commit_id>
>> git pull origin sr_3.0:sr_3.0
>
> Hi Andrei,
>
> i'Ve tried today to cherry-pick some changes from master to the sr_3.0
> branch. Here is what i did:
>
> henning@ca:~/sip-router$ git checkout --track -b marius-tmp origin/sr_3.0
> Branch marius-tmp set up to track remote branch refs/remotes/origin/sr_3.0.
> Switched to a new branch "marius-tmp"
>
> henning@ca:~/sip-router$ git cherry-pick -x
> e06a69d625d4c1293fceef13f9eca22e14662f9f
> Auto-merged modules/carrierroute/cr_func.c
> Finished one cherry-pick.
> Created commit 084ad8a: If the user parameter is "<null>" (e.g a empty
> username in the request URI), do not copy this value to the rewritten uri.
> 1 files changed, 21 insertions(+), 10 deletions(-)
> [some more cherry picks..]
>
> henning@ca:~/sip-router$ git log
>
> Shows the correct changes
>
> henning@ca:~/sip-router$ git status
> # On branch marius-tmp
> # Your branch is ahead of 'origin/sr_3.0' by 11 commits.
>
> Also fine.
>
> According to the tutorial i found i need now to push this, but i'm not sure
> if the command really does the right thing:
>
> henning@ca:~/sip-router$ git push origin marius-tmp --dry-run
> To ssh://[hidden email]/sip-router
> * [new branch] marius-tmp -> marius-tmp
>
> It seems that it want to create a new remote branch, which is not really
> what i want..

You need to specify the name of the branch in the remote repository
you want to push to if the name of the local branch and the name of
the remote branch do not match:

  $ git push origin marius-tmp:sr_3.0

The manpage on git-push describes what happens if you omit the name of
the destination branch:

  The <dst> tells which ref on the remote side is updated with this
  push. Arbitrary expressions cannot be used here, an actual ref must
  be named. If :<dst> is omitted, the same ref as <src> will be
  updated.

  -- Jan

_______________________________________________
sr-dev mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

[Henning Westerholt]

Some javascript/style in this post has been disabled (why?)

On Donnerstag, 29. Oktober 2009, Jan Janak wrote:
> [..]
> > According to the tutorial i found i need now to push this, but i'm not
> > sure if the command really does the right thing:
> >
> > henning@ca:~/sip-router$ git push origin marius-tmp --dry-run
> > To ssh://[hidden email]/sip-router
> > * [new branch] marius-tmp -> marius-tmp
> >
> > It seems that it want to create a new remote branch, which is not really
> > what i want..
>
> You need to specify the name of the branch in the remote repository
> you want to push to if the name of the local branch and the name of
> the remote branch do not match:
>
> $ git push origin marius-tmp:sr_3.0
>
> The manpage on git-push describes what happens if you omit the name of
> the destination branch:
>
> The <dst> tells which ref on the remote side is updated with this
> push. Arbitrary expressions cannot be used here, an actual ref must
> be named. If :<dst> is omitted, the same ref as <src> will be
> updated.

Hello Jan,

thank you, that did the trick! :)

Regards,

Henning

_______________________________________________
sr-dev mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev