Hi,
We've reached the point where we should start adding modules. Me and Jan would like to start moving ser modules to sip-router. ser modules are particularly easy because we can move changes from ser cvs semi-automatically (only a git pull required), so we don't need to stop development on cvs.
Soon we will have to add kamailio modules too, but for kamailio it would be more painful, both because of the bigger number of changes required and because it's difficult to update from svn (so it would be better if all developers would move to git or use patches).
We must decide if we use separate repositories or a branch in sip-router and we should also start thinking about the version number of the first ser and first kamailio based on sip-router.
Repositories:
1. we use branches inside sip-router: master - like now, only core, tm and common modules ser_30 - master merged with ser_modules, next version of ser will come out of it kamailio_30 - same like above
Disadvantages: - one big repo - people must be careful _not_ to merge ser_30 or kamailio_30 into master (that would bring all the modules into master which is not what we want) - if someone working on the ser_30 branch (for example) finds a problem in the core and wants to fix it, it has to do it on the master branch. - if the above requirement cannot be avoided and someone does a specific core change in ser_30 or k_30 (e.g. name in makefile), it should always do it in a separate commit (no commits touching both core/tm and some project specific module, instead separate commits for the common part so that they might be cherry-picked)
2. we use 3 repositories: sip-router - like now, only the common part: core, tm and common modules ser-ng - sip-router + ser modules kamailio-ng - sip-router + k modules
Advantages: - 3 smaller repos - more difficult to make mistakes and merge kamailio or ser into sip-router/master Disadvantages: - 3 smaller repos :-) - same as for (1)
In general whatever we can do with branches in the same repo we can with branches in different repos, so a complete kamailio-ser merge would not be affected if we use separate repos.
Version numbers:
I think it would be a good idea to come up with a versioning scheme that would reflect the common part used for future ser and kamailio releases. Maybe 3.x (3 being > then both current ser and kamailio version), or mabye v.v.X , where v.v is the sip-router version (common part) and X is the project version (ser or kamailio).
What's important is to (very) quickly decide on the repository layout (because this will slow us down) and on the names for the branches or for the different repos. Once this is decided we want to quickly make a test ser version based on sip-router and start testing it. If everything looks ok we want to start using it on iptel.org.
Andrei
Hello,
On 02/24/2009 01:13 PM, Andrei Pelinescu-Onciul wrote:
Hi,
We've reached the point where we should start adding modules.
indeed, we got to a good milestone already, thanks everybody. I have also couple of kamailio/openser modules updated for sip router, some available for download, but it is better with a repository.
Me and Jan would like to start moving ser modules to sip-router. ser modules are particularly easy because we can move changes from ser cvs semi-automatically (only a git pull required), so we don't need to stop development on cvs.
Soon we will have to add kamailio modules too,
I expect that we will start adding kamailio/openser modules after 1.5.0 release which should happen next Monday/Tuesday.
We had a IRC devel meeting and decided to use the git for development of core and common modules and pull them in SVN so people can take everything from one place, until everything is integrated in git. Practically here the issues are duplicated modules, that will take some time to combine and get all functionalities from both versions in one module.
Henning has some tool in place able to get the sip-router git in SVN. Over time, we will get everything in GIT.
but for kamailio it would be more painful, both because of the bigger number of changes required and because it's difficult to update from svn (so it would be better if all developers would move to git or use patches).
We must decide if we use separate repositories or a branch in sip-router and we should also start thinking about the version number of the first ser and first kamailio based on sip-router.
Repositories:
- we use branches inside sip-router: master - like now, only core, tm and common modules ser_30 - master merged with ser_modules, next version of ser will come out of it kamailio_30 - same like above
Disadvantages: - one big repo - people must be careful _not_ to merge ser_30 or kamailio_30 into master (that would bring all the modules into master which is not what we want) - if someone working on the ser_30 branch (for example) finds a problem in the core and wants to fix it, it has to do it on the master branch. - if the above requirement cannot be avoided and someone does a specific core change in ser_30 or k_30 (e.g. name in makefile), it should always do it in a separate commit (no commits touching both core/tm and some project specific module, instead separate commits for the common part so that they might be cherry-picked)
- we use 3 repositories: sip-router - like now, only the common part: core, tm and common modules ser-ng - sip-router + ser modules kamailio-ng - sip-router + k modules
Advantages: - 3 smaller repos - more difficult to make mistakes and merge kamailio or ser into sip-router/master Disadvantages: - 3 smaller repos :-) - same as for (1)
In general whatever we can do with branches in the same repo we can with branches in different repos, so a complete kamailio-ser merge would not be affected if we use separate repos.
Having one for core+tm+common modules and two other for the rest of modules in each side should be ok. Jan's email explains how to get core+ser_modules, it is not very complex.
I do not like working on three repos with replicated code tree -- to much overhead to manage and quite exposed to mistakes. I am already tired of tracking core+tm in sip-router and kamailio. Each piece of code should reside in one place, with proper documentation of how to fetch them to get entire source tree.
Version numbers:
I think it would be a good idea to come up with a versioning scheme that would reflect the common part used for future ser and kamailio releases. Maybe 3.x (3 being > then both current ser and kamailio version), or mabye v.v.X , where v.v is the sip-router version (common part) and X is the project version (ser or kamailio).
3 sounds like a good idea as major for version number. The issue I see with v.v.X is just one number for project releases, while both used 2, last one being for minor/patch releases. I expect core releases to be less often, so we can have v.X.X, or to use 4 numbers for relase v.v.X.X, but this is not very common.
What's important is to (very) quickly decide on the repository layout (because this will slow us down) and on the names for the branches or for the different repos.
I guess I map myself better to second choice you proposed (hope I got it right, kamailio-ng pulling sip-router from sip-router repo and kamailio modules from "k modules" repo).
Cheers, Daniel
Once this is decided we want to quickly make a test ser version based on sip-router and start testing it. If everything looks ok we want to start using it on iptel.org.
On Feb 24, 2009 at 15:43, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
On 02/24/2009 01:13 PM, Andrei Pelinescu-Onciul wrote:
Hi,
We've reached the point where we should start adding modules.
indeed, we got to a good milestone already, thanks everybody. I have also couple of kamailio/openser modules updated for sip router, some available for download, but it is better with a repository.
Me and Jan would like to start moving ser modules to sip-router. ser modules are particularly easy because we can move changes from ser cvs semi-automatically (only a git pull required), so we don't need to stop development on cvs.
Soon we will have to add kamailio modules too,
I expect that we will start adding kamailio/openser modules after 1.5.0 release which should happen next Monday/Tuesday.
We had a IRC devel meeting and decided to use the git for development of core and common modules and pull them in SVN so people can take everything from one place, until everything is integrated in git. Practically here the issues are duplicated modules, that will take some time to combine and get all functionalities from both versions in one module.
Great, that would make things much easier.
Henning has some tool in place able to get the sip-router git in SVN. Over time, we will get everything in GIT.
but for kamailio it would be more painful, both because of the bigger number of changes required and because it's difficult to update from svn (so it would be better if all developers would move to git or use patches).
We must decide if we use separate repositories or a branch in sip-router and we should also start thinking about the version number of the first ser and first kamailio based on sip-router.
Repositories:
- we use branches inside sip-router:
master - like now, only core, tm and common modules ser_30 - master merged with ser_modules, next version of ser will come out of it kamailio_30 - same like above
Disadvantages: - one big repo - people must be careful _not_ to merge ser_30 or kamailio_30 into master (that would bring all the modules into master which is not what we want) - if someone working on the ser_30 branch (for example) finds a problem in the core and wants to fix it, it has to do it on the master branch. - if the above requirement cannot be avoided and someone does a specific core change in ser_30 or k_30 (e.g. name in makefile), it should always do it in a separate commit (no commits touching both core/tm and some project specific module, instead separate commits for the common part so that they might be cherry-picked)
- we use 3 repositories:
sip-router - like now, only the common part: core, tm and common modules ser-ng - sip-router + ser modules kamailio-ng - sip-router + k modules
Advantages: - 3 smaller repos - more difficult to make mistakes and merge kamailio or ser into sip-router/master Disadvantages: - 3 smaller repos :-) - same as for (1)
In general whatever we can do with branches in the same repo we can with branches in different repos, so a complete kamailio-ser merge would not be affected if we use separate repos.
Having one for core+tm+common modules and two other for the rest of modules in each side should be ok. Jan's email explains how to get core+ser_modules, it is not very complex.
The problem is not that's it's very complex, the problem is that's too difficult to do development on modules. What Jan did, was create a local branch in his local repository (derived from sip-router = core+ common) and then merge/pull into it ser modules (from the ser_modules repo). This is easy and good for testing. However suppose I do a fix/update to the tls module. Now if I want to push the changes to ser_modules things get complicated: I cannot push directly, because that would push also core+tm in ser_modules, so I have to checkout the ser_modules repository, apply all the changes to tls I did in my local repo (either using git cherry-pick or plain old diff & patch) and then push the changes back. So for every module change (which I expect to happen quite frequently) there are more steps involved.
I do not like working on three repos with replicated code tree -- to much overhead to manage and quite exposed to mistakes. I am already tired of tracking core+tm in sip-router and kamailio. Each piece of code should reside in one place, with proper documentation of how to fetch them to get entire source tree.
I think (1) or (2) are superior to working with separate modules only repositories (let's name this option (3)), because of the less steps involved in pushing changes to modules. One would still have to use more steps when changing core, but that happens less.
Actually I'm slightly in favor of using the sip-router repo with ser and kamailio branches (1). I don't find (2) bad either. The biggest danger is somebody pushing by mistake the whole kamailio or ser into the master branch, but we could restrict the access to the master branch to only a small number of people and if a big mistake would happen we can still revert (albeit everybody who updated in the meantime would have to do a git fetch -f).
Version numbers:
I think it would be a good idea to come up with a versioning scheme that would reflect the common part used for future ser and kamailio releases. Maybe 3.x (3 being > then both current ser and kamailio version), or mabye v.v.X , where v.v is the sip-router version (common part) and X is the project version (ser or kamailio).
3 sounds like a good idea as major for version number. The issue I see with v.v.X is just one number for project releases, while both used 2, last one being for minor/patch releases. I expect core releases to be less often, so we can have v.X.X, or to use 4 numbers for relase v.v.X.X, but this is not very common.
At least in the beginning I hope core changes will happen quite often (I have a huge backlog :-)). The problem with 3.x.y is what happens when we release a new core, do we go to 4?
What's important is to (very) quickly decide on the repository layout (because this will slow us down) and on the names for the branches or for the different repos.
I guess I map myself better to second choice you proposed (hope I got it right, kamailio-ng pulling sip-router from sip-router repo and kamailio modules from "k modules" repo).
Actually what I meant was:
kamailio-ng = sip-router + kamailio_modules, where kamailio_modules is a read-only repository (it's just for svn->git). All modules developement goes on kamailio-ng. The core is merged from time to time from sip-router.
With git you cannot push only a subtree (so if you have sip-router + modules and you do a push everything will be pushed), so it's hard to work with a separate module-only repository. It would be nice to have completely separated modules and core repos, but that would involve extra steps both for changes to core and modules. Given the alternative I think easier to change/work-on modules are preferable to the core (to work on a module in general you need the core for testing, while for working on the core you need the modules only in some limited cases).
Things like using git submodules will not work because we do no have completely separated directories (it would work only if we would have a /common dir and a /project_specific dir). There is also the alternative of declaring each module as a git submodule, but that would be a lot of work and would make for lots of repositories (we would need one repository for _each_ module, so for both project we will end up with something close to 150 repositories).
Andrei
[...]
On 24-02 15:43, Daniel-Constantin Mierla wrote:
Hello,
Soon we will have to add kamailio modules too,
I expect that we will start adding kamailio/openser modules after 1.5.0 release which should happen next Monday/Tuesday.
We had a IRC devel meeting and decided to use the git for development of core and common modules and pull them in SVN so people can take everything from one place, until everything is integrated in git. Practically here the issues are duplicated modules, that will take some time to combine and get all functionalities from both versions in one module.
Yes, this will take a lot of time and several releases at least, because we made lots of significant changes in some basic modules, such as authentication, multiple domains, registrar, and so on. They are all related to the changes in the database and the data model.
On SER side we will probably try to move to git as quickly as possible, I use git for all my local developments and Andrei does the same, as far as I know. So I guess that we will announce the end of the ser cvs repository as soon as we have all ser modules in git, updated for the sip-router core and tested on iptel.org.
Regarding kamailio modules: Although it takes a some effort to convert them to the shared core, I am optimistic and I think we will be able to make them all work with the sip-router core relatively soon. If everything goes well then we should be able to replace both our cores with the sip-router core in a few months.
Jan.
On 24-02 12:13, Andrei Pelinescu-Onciul wrote:
Hi,
We've reached the point where we should start adding modules. Me and Jan would like to start moving ser modules to sip-router. ser modules are particularly easy because we can move changes from ser cvs semi-automatically (only a git pull required), so we don't need to stop development on cvs.
Soon we will have to add kamailio modules too, but for kamailio it would be more painful, both because of the bigger number of changes required and because it's difficult to update from svn (so it would be better if all developers would move to git or use patches).
We must decide if we use separate repositories or a branch in sip-router and we should also start thinking about the version number of the first ser and first kamailio based on sip-router.
Repositories:
- we use branches inside sip-router: master - like now, only core, tm and common modules ser_30 - master merged with ser_modules, next version of ser will come out of it kamailio_30 - same like above
Disadvantages: - one big repo - people must be careful _not_ to merge ser_30 or kamailio_30 into master (that would bring all the modules into master which is not what we want)
I would say that this is ultimately what we want to. Ideally we would add more and more modules to the master branch as we expand our common ground. Surely it will be a lenghty process, but from what I can tell so far from my migration attempts of ser and kamailio modules, we should be able to move a decent group of modules to the master branch quickly--should we want to.
If we decide that we will keep both projects as branches inside the main repository, how do we guarantee that people do not commit lots of unrelated stuff into the master branch by accident? This probably calls for some draconian access control rules on the master branch and I am not sure that this is something we should do.
Besides this one big repository will contain commits from both projects, I mean commits in which developers of the other project might not be interested and which are not related to the common parts.
- if someone working on the ser_30 branch (for example) finds a problem in the core and wants to fix it, it has to do it on the master branch.
Switching branches in git is not that convenient if you are in the middle of some bigger changes and you have lots of uncommited changes. That practically means that you would have to clone the repository again, discard your local changes in the new clone and checkout another branch (master). Then you need to switch back to your original repository and merge the changes you just did on the master branch.
Because of this I tend to keep multiple local repositories with different branches checked out, so speaking for myself I am already used to having multiple repositories and having separate repositores would feel natural.
- if the above requirement cannot be avoided and someone does a specific core change in ser_30 or k_30 (e.g. name in makefile), it should always do it in a separate commit (no commits touching both core/tm and some project specific module, instead separate commits for the common part so that they might be cherry-picked)
- we use 3 repositories: sip-router - like now, only the common part: core, tm and common modules ser-ng - sip-router + ser modules kamailio-ng - sip-router + k modules
Advantages: - 3 smaller repos - more difficult to make mistakes and merge kamailio or ser into sip-router/master Disadvantages: - 3 smaller repos :-) - same as for (1)
In general whatever we can do with branches in the same repo we can with branches in different repos, so a complete kamailio-ser merge would not be affected if we use separate repos.
I would personally vote for 3 smaller repositories. If things are separated then people will be less worried about screwing the work of other people, their mistakes will be isolated.
Also pulling/pushing from/to multiple separate repositories, each of which contains parts of a large project is one of the key features of git. This is what is described in most howtos and guides on git.
I have also viewed the repositories we have on git.sip-router.org as nothing more than a rendezvous point, a place where people synchronize their work and where we can do automated things such as doxygen generation, packging, and so on.
Even on my local machine I have several git repositories with various modifications of the ser code.
Version numbers:
I think it would be a good idea to come up with a versioning scheme that would reflect the common part used for future ser and kamailio releases. Maybe 3.x (3 being > then both current ser and kamailio version), or mabye v.v.X , where v.v is the sip-router version (common part) and X is the project version (ser or kamailio).
Yeas, I fully agree.
Jan.
On Feb 26, 2009 at 02:15, Jan Janak jan@iptel.org wrote:
On 24-02 12:13, Andrei Pelinescu-Onciul wrote:
[...]
- if someone working on the ser_30 branch (for example) finds a problem in the core and wants to fix it, it has to do it on the master branch.Switching branches in git is not that convenient if you are in the middle of some bigger changes and you have lots of uncommited changes. That practically means that you would have to clone the repository again, discard your local changes in the new clone and checkout another branch (master). Then you need to switch back to your original repository and merge the changes you just did on the master branch.
That could be done much more easier with git stash (I use it a lot): git stash save "my changes" git checkout master ... git stash pop # applies saved changes
Moreover I don't expect that the situation in which you are working on some project specific branch and you have to do some changes on the common part will occur so often (it does now, because we still need to do frequent "adjustments" as testing/integration progresses, but it will change).
Note also that having 3 repos will not help here (you'll still have to do common part changes on the sip-router repo/main) and I don't think you could use git stash in this case (unless you import all into the same local repository).
Because of this I tend to keep multiple local repositories with different branches checked out, so speaking for myself I am already used to having multiple repositories and having separate repositores would feel natural.
- if the above requirement cannot be avoided and someone does a specific core change in ser_30 or k_30 (e.g. name in makefile), it should always do it in a separate commit (no commits touching both core/tm and some project specific module, instead separate commits for the common part so that they might be cherry-picked)
- we use 3 repositories: sip-router - like now, only the common part: core, tm and common modules ser-ng - sip-router + ser modules kamailio-ng - sip-router + k modules
Advantages: - 3 smaller repos - more difficult to make mistakes and merge kamailio or ser into sip-router/master Disadvantages: - 3 smaller repos :-) - same as for (1)
In general whatever we can do with branches in the same repo we can with branches in different repos, so a complete kamailio-ser merge would not be affected if we use separate repos.
I would personally vote for 3 smaller repositories. If things are separated then people will be less worried about screwing the work of other people, their mistakes will be isolated.
Also pulling/pushing from/to multiple separate repositories, each of which contains parts of a large project is one of the key features of git. This is what is described in most howtos and guides on git.
I have also viewed the repositories we have on git.sip-router.org as nothing more than a rendezvous point, a place where people synchronize their work and where we can do automated things such as doxygen generation, packging, and so on.
From my point of view these 2 option are almost equivalent, so any one
of them will be ok for me. What I wouldn't like is keeping modules-only repositories (that would make module work too difficult).
Andrei [...]
On 26-02 02:43, Andrei Pelinescu-Onciul wrote:
On Feb 26, 2009 at 02:15, Jan Janak jan@iptel.org wrote:
On 24-02 12:13, Andrei Pelinescu-Onciul wrote:
[...]
- if someone working on the ser_30 branch (for example) finds a problem in the core and wants to fix it, it has to do it on the master branch.Switching branches in git is not that convenient if you are in the middle of some bigger changes and you have lots of uncommited changes. That practically means that you would have to clone the repository again, discard your local changes in the new clone and checkout another branch (master). Then you need to switch back to your original repository and merge the changes you just did on the master branch.
That could be done much more easier with git stash (I use it a lot): git stash save "my changes" git checkout master ... git stash pop # applies saved changes
Moreover I don't expect that the situation in which you are working on some project specific branch and you have to do some changes on the common part will occur so often (it does now, because we still need to do frequent "adjustments" as testing/integration progresses, but it will change).
Note also that having 3 repos will not help here (you'll still have to do common part changes on the sip-router repo/main) and I don't think you could use git stash in this case (unless you import all into the same local repository).
I've tried git stash but it does not integrate well with my emacs editing workflow. I'm much faster with multiple repositores because I can access them all at the same time from emacs.
Anyway, I feel easy about switching to branches inside one repository and I would not impose any restrictions on the master branch now, let's be open and see if we can get away with it.
I should also add that our current workflow is most likely more difficult than it will be in the future as we consolidate our stuff. We now have all the cvs/svn synchronization going on, in various repositories, filtered and unfiltered. That won't be needed in the future (at least not that much).
Jan.
Jan Janak writes:
- we use 3 repositories: sip-router - like now, only the common part: core, tm and common modules ser-ng - sip-router + ser modules kamailio-ng - sip-router + k modules
why can't ser-ng and kamailio-ng contain just the modules so that sip-router would be only on place?
-- juha
On Feb 26, 2009 at 04:50, Juha Heinanen jh@tutpro.com wrote:
Jan Janak writes:
- we use 3 repositories: sip-router - like now, only the common part: core, tm and common modules ser-ng - sip-router + ser modules kamailio-ng - sip-router + k modules
why can't ser-ng and kamailio-ng contain just the modules so that sip-router would be only on place?
Because it would be quite hard to do development on modules. To test one module you'll need the core. If you bring the core (merge the core over the modules or the modules over the core), when you'll try to push the change it will bring everything with it (if you're trying to push to ser-ng-modules for example it will push also the core or if you're pushing to sip-router it will add also the modules). So you'll have to take all the changes you did while testing the complete stuff as patches and apply them on a clean local clone of the modules repo. There are some variations possible like using git cherry-pick (depending on how you do the sip-router - modules merge), but in essence is not significant less work then applying patches (via git: git format-patch to create them, git am to apply).
Basically the problem is that you cannot push only the changes made to a subdirectory (you cannot do git push modules/*), you always push the changes to the entire project. We cannot use other workarounds (like git submodule), because of our directory structure (git submodule will work only if a subproject is contained in a subdirectory of another, which is not true in our case: sip-router contains core + modules/tm +modules/db_*, while the other repos will contain modules/*). The only alternative I can think off is to re-organize the modules: have a modules directory containing only the common part (tm and db_* for now), a kmodules containing kamailio modules and smodules ser modules (this way we can have kmodules and smodules as git submodules).
Andrei
Andrei Pelinescu-Onciul writes:
why can't ser-ng and kamailio-ng contain just the modules so that sip-router would be only on place?
Because it would be quite hard to do development on modules.
i don't understand.
i could have a script that copies core and common modules from sip-router repo and k-only modules from k repo to a tm src directory and then calls k-make to build the thing.
if i make a commit on a k module, i just call the script again and get a new version of k compiled.
-- juha
Juha Heinanen writes:
i could have a script that copies core and common modules from sip-router repo and k-only modules from k repo to a tm src directory and then calls k-make to build the thing.
there was typo in above, i meant tmp src directory.
-- juha
On Feb 26, 2009 at 11:15, Juha Heinanen jh@tutpro.com wrote:
Andrei Pelinescu-Onciul writes:
why can't ser-ng and kamailio-ng contain just the modules so that sip-router would be only on place?
Because it would be quite hard to do development on modules.
i don't understand.
i could have a script that copies core and common modules from sip-router repo and k-only modules from k repo to a tm src directory and then calls k-make to build the thing.
if i make a commit on a k module, i just call the script again and get a new version of k compiled.
Yes, that would work (manually copying), but I find that more difficult than it should be (everybody will have to use some script and have at least 2 local repos, one for sip-router and one for the modules).
Andrei
Andrei Pelinescu-Onciul writes:
if i make a commit on a k module, i just call the script again and get a new version of k compiled.
Yes, that would work (manually copying), but I find that more difficult than it should be (everybody will have to use some script and have at least 2 local repos, one for sip-router and one for the modules).
i don't see having two repos on the local disk as a problem. before copying, the script updates both automatically to latest level. i can write the script and post it on the list once the repos are in place.
i see it a much bigger problem if the same thing (sip-router) source is in two different places.
-- juha
Hello,
I was thinking to a new idea of repository structure.
The core and libraries do not overlap, so no conflict here. For modules have three directories: - modules - store common integrated modules now (tm, db drivers) and modules that exist only in one project - modules-k - K modules that overlap in name with S modules or other particular K modules not moved to "modules" directory - modules-s - S modules that overlap in name with K modules or other particular S modules not moved to "modules" directory
As soon a new integration is done for overlappin modules, it will be moved to modules and removed for modules-k/modules-s
The advantage I see is only one repository. The disavantage is updating the makefile to work with three module directories for a period of time.
Opinions?
Cheers, Daniel
On 02/26/2009 09:53 PM, Juha Heinanen wrote:
Andrei Pelinescu-Onciul writes:
if i make a commit on a k module, i just call the script again and get a new version of k compiled.
Yes, that would work (manually copying), but I find that more difficult than it should be (everybody will have to use some script and have at least 2 local repos, one for sip-router and one for the modules).
i don't see having two repos on the local disk as a problem. before copying, the script updates both automatically to latest level. i can write the script and post it on the list once the repos are in place.
i see it a much bigger problem if the same thing (sip-router) source is in two different places.
-- juha
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
On 27-03 11:00, Daniel-Constantin Mierla wrote:
Hello,
I was thinking to a new idea of repository structure.
The core and libraries do not overlap, so no conflict here. For modules have three directories:
- modules - store common integrated modules now (tm, db drivers) and
modules that exist only in one project
- modules-k - K modules that overlap in name with S modules or other
particular K modules not moved to "modules" directory
- modules-s - S modules that overlap in name with K modules or other
particular S modules not moved to "modules" directory
As soon a new integration is done for overlappin modules, it will be moved to modules and removed for modules-k/modules-s
The advantage I see is only one repository. The disavantage is updating the makefile to work with three module directories for a period of time.
I guess it all depends on whether or not you want to move the whole kamailio project to git. If yes then then the suggestion above makes sense, because it would be much easier to have just one repository.
If you want to stick to svn then we are better off with two separate repositories because we can synchronize one of them with the svn repository at sourceforge.
Jan.
On Mar 27, 2009 at 11:00, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
I was thinking to a new idea of repository structure.
The core and libraries do not overlap, so no conflict here. For modules have three directories:
- modules - store common integrated modules now (tm, db drivers) and
modules that exist only in one project
- modules-k - K modules that overlap in name with S modules or other
particular K modules not moved to "modules" directory
- modules-s - S modules that overlap in name with K modules or other
particular S modules not moved to "modules" directory
As soon a new integration is done for overlappin modules, it will be moved to modules and removed for modules-k/modules-s
The advantage I see is only one repository. The disavantage is updating the makefile to work with three module directories for a period of time.
Opinions?
What should: make all and make install do? (which set of modules) How would the installed version look like? (all module in the same dir?) If you run make all and then start ./sr with loadmodule "textops" in sr.cfg, which textops version will be used, the on from k or from s?
If we manage to find some good answers to the above questions, then we could go for it. BTW: we don't even need same repos, if we have separate dirs, we could experiment with git submodules (which basically tell that a subdir content should be fetched from another repo).
Andrei
On 02/26/2009 09:53 PM, Juha Heinanen wrote:
Andrei Pelinescu-Onciul writes:
if i make a commit on a k module, i just call the script again and
get a
new version of k compiled.
Yes, that would work (manually copying), but I find that more difficult than it should be (everybody will have to use some script and have at least 2 local repos, one for sip-router and one for the modules).
i don't see having two repos on the local disk as a problem. before copying, the script updates both automatically to latest level. i can write the script and post it on the list once the repos are in place.
i see it a much bigger problem if the same thing (sip-router) source is in two different places.
-- juha
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- Daniel-Constantin Mierla SIP Router Masterclass - Kamailio (OpenSER) Training http://www.asipto.com/index.php/sip-router-masterclass/
On 03/27/2009 01:08 PM, Andrei Pelinescu-Onciul wrote:
On Mar 27, 2009 at 11:00, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
I was thinking to a new idea of repository structure.
The core and libraries do not overlap, so no conflict here. For modules have three directories:
- modules - store common integrated modules now (tm, db drivers) and
modules that exist only in one project
- modules-k - K modules that overlap in name with S modules or other
particular K modules not moved to "modules" directory
- modules-s - S modules that overlap in name with K modules or other
particular S modules not moved to "modules" directory
As soon a new integration is done for overlappin modules, it will be moved to modules and removed for modules-k/modules-s
The advantage I see is only one repository. The disavantage is updating the makefile to work with three module directories for a period of time.
Opinions?
What should: make all and make install do? (which set of modules)
all modules
How would the installed version look like? (all module in the same dir?)
different dirs: /usr/local/lib/sip-router/modules /usr/local/lib/sip-router/modules-k /usr/local/lib/sip-router/modules-s
If you run make all and then start ./sr with loadmodule "textops" in sr.cfg, which textops version will be used, the on from k or from s?
there could be full path or mpath for each: mpath="/usr/local/lib/sip-router/modules" loadmodule "tm.so"
mpath="/usr/local/lib/sip-router/modules-k" loadmodule "textops.so"
mpath="/usr/local/lib/sip-router/modules-s" loadmodule "auth.so"
Cheers, Daniel
If we manage to find some good answers to the above questions, then we could go for it. BTW: we don't even need same repos, if we have separate dirs, we could experiment with git submodules (which basically tell that a subdir content should be fetched from another repo).
Andrei
On 02/26/2009 09:53 PM, Juha Heinanen wrote:
Andrei Pelinescu-Onciul writes:
if i make a commit on a k module, i just call the script again and
get a
new version of k compiled.
Yes, that would work (manually copying), but I find that more difficult than it should be (everybody will have to use some script and have at least 2 local repos, one for sip-router and one for the modules).
i don't see having two repos on the local disk as a problem. before copying, the script updates both automatically to latest level. i can write the script and post it on the list once the repos are in place.
i see it a much bigger problem if the same thing (sip-router) source is in two different places.
-- juha
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- Daniel-Constantin Mierla SIP Router Masterclass - Kamailio (OpenSER) Training http://www.asipto.com/index.php/sip-router-masterclass/
Kamailio (OpenSER) - Devel mailing list Devel@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/devel http://lists.openser-project.org/cgi-bin/mailman/listinfo/devel
On Mar 27, 2009 at 13:22, Daniel-Constantin Mierla miconda@gmail.com wrote:
On 03/27/2009 01:08 PM, Andrei Pelinescu-Onciul wrote:
On Mar 27, 2009 at 11:00, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
I was thinking to a new idea of repository structure.
The core and libraries do not overlap, so no conflict here. For modules have three directories:
- modules - store common integrated modules now (tm, db drivers) and
modules that exist only in one project
- modules-k - K modules that overlap in name with S modules or other
particular K modules not moved to "modules" directory
- modules-s - S modules that overlap in name with K modules or other
particular S modules not moved to "modules" directory
As soon a new integration is done for overlappin modules, it will be moved to modules and removed for modules-k/modules-s
The advantage I see is only one repository. The disavantage is updating the makefile to work with three module directories for a period of time.
Opinions?
What should: make all and make install do? (which set of modules)
all modules
How would the installed version look like? (all module in the same dir?)
different dirs: /usr/local/lib/sip-router/modules /usr/local/lib/sip-router/modules-k /usr/local/lib/sip-router/modules-s
If you run make all and then start ./sr with loadmodule "textops" in sr.cfg, which textops version will be used, the on from k or from s?
there could be full path or mpath for each: mpath="/usr/local/lib/sip-router/modules" loadmodule "tm.so"
mpath="/usr/local/lib/sip-router/modules-k" loadmodule "textops.so"
mpath="/usr/local/lib/sip-router/modules-s" loadmodule "auth.so"
Cheers, Daniel
If we manage to find some good answers to the above questions, then we could go for it. BTW: we don't even need same repos, if we have separate dirs, we could experiment with git submodules (which basically tell that a subdir content should be fetched from another repo).
I've added support for multiple modules dirs (the list of modules dirs is defined in Makefile.dirs). It's on andrei/modules_dirs branch (see http://lists.sip-router.org/pipermail/sr-dev/2009-March/001179.html for more details).
There are some changes when running make install: - each set of modules is installed in its own dir (e.g.: /usr/local/lib/sip-router/modules, /usr/local/lib/sip-router/modules-k ...) - the modules docs are now installed in separate dirs (instead of /usr/local/share/doc/sr/ in /usr/local/share/doc/sr/{modules,modules_s,modules_k} )
One potential problem is that all the man pages are installed in the same dir, so modules with the same name might overwrite their man page. However only a small number of ser modules have man page support so far, so at least for now this is not a problem.
The modules using includes from tm would need to be updated (../tm/ should be replaced with ../../modules/tm/).
If we agree that this is the best way to organize the repos, we should decide on the names for the 3 modules directories and I'll merge my branch into master. Regarding the names, they should not contain a '-' (to avoid potential future problems with shells that don't allow '-' in env. vars), and they should be different from any make variable name (so if you come up with a name grep it first in Makefile* to see if it's already used).
We might consider renaming modules/ to something different (e.g. common_mods) to avoid some confusion with old make commands (right now make modules will make only the modules in the modules/ dir, using a different dir name. would permit changing make modules to make all the modules from all the dirs).
BTW: we are not limited to 3 modules dirs, we could use as many as we want, we could even divide them alphabetically :-)
Andrei
On 03/28/2009 12:26 AM, Andrei Pelinescu-Onciul wrote:
[...]
I've added support for multiple modules dirs (the list of modules dirs is defined in Makefile.dirs). It's on andrei/modules_dirs branch (see http://lists.sip-router.org/pipermail/sr-dev/2009-March/001179.html for more details).
There are some changes when running make install:
- each set of modules is installed in its own dir
(e.g.: /usr/local/lib/sip-router/modules, /usr/local/lib/sip-router/modules-k ...)
- the modules docs are now installed in separate dirs (instead of /usr/local/share/doc/sr/ in /usr/local/share/doc/sr/{modules,modules_s,modules_k} )
One potential problem is that all the man pages are installed in the same dir, so modules with the same name might overwrite their man page. However only a small number of ser modules have man page support so far, so at least for now this is not a problem.
The modules using includes from tm would need to be updated (../tm/ should be replaced with ../../modules/tm/).
If we agree that this is the best way to organize the repos, we should decide on the names for the 3 modules directories and I'll merge my branch into master. Regarding the names, they should not contain a '-' (to avoid potential future problems with shells that don't allow '-' in env. vars), and they should be different from any make variable name (so if you come up with a name grep it first in Makefile* to see if it's already used).
We might consider renaming modules/ to something different (e.g. common_mods) to avoid some confusion with old make commands (right now make modules will make only the modules in the modules/ dir, using a different dir name. would permit changing make modules to make all the modules from all the dirs).
BTW: we are not limited to 3 modules dirs, we could use as many as we want, we could even divide them alphabetically :-)
for me it is ok to prefix them with modules_ or mods_ (e.g., modules_k or mods_s). I prefer the module-related prefix to be first (e.g., mods_common instead of common_mods)
Another idea that popped up, but this will require changes in all modules for includes to have: - modules/common/* - modules/kamailio/* - modules/ser/*
But probably in Makefile.defs the dir names have to be simple and as we have first version, let's go for it.
The idea to group them in the future is very good IMO, because number of the modules increases as we go. So we can have: - modules_db - db drivers - modules_presence- presence related modules ... a.s.o.
Daniel
On 27-03 12:08, Andrei Pelinescu-Onciul wrote:
On Mar 27, 2009 at 11:00, Daniel-Constantin Mierla miconda@gmail.com wrote: What should: make all and make install do? (which set of modules) How would the installed version look like? (all module in the same dir?) If you run make all and then start ./sr with loadmodule "textops" in sr.cfg, which textops version will be used, the on from k or from s?
If we manage to find some good answers to the above questions, then we could go for it. BTW: we don't even need same repos, if we have separate dirs, we could experiment with git submodules (which basically tell that a subdir content should be fetched from another repo).
I follow (well, try to) the git mailing list and it seems to me that the submodule implementation is still a bit problematic because there were lots of questions/problems reported on the list.
Also debian lenny currently has git 1.5.6.5 and the latest stable is 1.6.2.1, so most of won't have the most recent features and fixes.
Jan.
Daniel-Constantin Mierla writes:
The advantage I see is only one repository. The disavantage is updating the makefile to work with three module directories for a period of time.
Opinions?
sounds good if it is easy to give a parameter to make or to have a environment variable similar to TLS telling if k or s is build.
-- juha
-
Andrei Pelinescu-Onciul -
Daniel-Constantin Mierla -
Jan Janak -
jh＠tutpro.com