24 Feb
2009
24 Feb
'09
1:13 p.m.
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
24 Feb
24 Feb
3:43 p.m.
New subject: [SR-Dev] sip-router: modules & repositories
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:
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.
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.
--
Daniel-Constantin Mierla
http://www.asipto.com
4:25 p.m.
New subject: [SR-Dev] sip-router: modules & repositories
On Feb 24, 2009 at 15:43, Daniel-Constantin Mierla <miconda(a)gmail.com> wrote:
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?
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
[...]
Hello,
On 02/24/2009 01:13 PM, Andrei Pelinescu-Onciul wrote:
Great, that would make things much easier.
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.
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.
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.
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.
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.
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). 
26 Feb
26 Feb
3:32 a.m.
New subject: [SR-Dev] [Serdev] sip-router: modules & repositories
On 24-02 15:43, Daniel-Constantin Mierla wrote:
Hello,
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.
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.
3:15 a.m.
New subject: [SR-Dev] [Serdev] sip-router: modules & repositories
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:
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)
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)
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.
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.
3:43 a.m.
New subject: [SR-Dev] [Serdev] sip-router: modules & repositories
On Feb 26, 2009 at 02:15, Jan Janak <jan(a)iptel.org> wrote:
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).
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.
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)
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.
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
[...]
4:14 a.m.
New subject: [SR-Dev] [Serdev] sip-router: modules & repositories
On 26-02 02:43, Andrei Pelinescu-Onciul wrote:
On Feb 26, 2009 at 02:15, Jan Janak
<jan(a)iptel.org> wrote:
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.
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. 
4:50 a.m.
New subject: [SR-Dev] [Serdev] sip-router: modules & repositories
Jan Janak writes:
> 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
why can't ser-ng and kamailio-ng contain just the modules so that
sip-router would be only on place?
-- juha
11:03 a.m.
New subject: [SR-Dev] [Serdev] sip-router: modules & repositories
On Feb 26, 2009 at 04:50, Juha Heinanen <jh(a)tutpro.com> wrote:
Jan Janak writes:
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
> 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
why can't ser-ng and kamailio-ng contain just the modules so that
sip-router would be only on place?
11:15 a.m.
New subject: [SR-Dev] [Serdev] sip-router: modules & repositories
Andrei Pelinescu-Onciul writes:
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
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.
11:17 a.m.
New subject: [SR-Dev] [Kamailio-Devel] [Serdev] sip-router: modules & repositories
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
11:30 a.m.
New subject: [SR-Dev] [Serdev] sip-router: modules & repositories
On Feb 26, 2009 at 11:15, Juha Heinanen <jh(a)tutpro.com> wrote:
Andrei Pelinescu-Onciul writes:
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.
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.
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
9:53 p.m.
New subject: [SR-Dev] [Serdev] sip-router: modules & repositories
Andrei Pelinescu-Onciul writes:
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
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).
27 Mar
27 Mar
11 a.m.
New subject: [SR-Dev] [Serdev] sip-router: modules & repositories
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:
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(a)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/
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).
11:44 a.m.
New subject: [SR-Dev] [Serdev] sip-router: modules & repositories
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.
1:08 p.m.
New subject: [SR-Dev] [Serdev] sip-router: modules & repositories
On Mar 27, 2009 at 11:00, Daniel-Constantin Mierla <miconda(a)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:
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(a)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/ > 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).
1:22 p.m.
New subject: [SR-Dev] [Kamailio-Devel] [Serdev] sip-router: modules & repositories
On 03/27/2009 01:08 PM, Andrei Pelinescu-Onciul wrote:
On Mar 27, 2009 at 11:00, Daniel-Constantin Mierla
<miconda(a)gmail.com> wrote:
all modules
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?)
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
--
Daniel-Constantin Mierla
SIP Router Masterclass - Kamailio (OpenSER) Training
http://www.asipto.com/index.php/sip-router-masterclass/
On 02/26/2009 09:53 PM, Juha Heinanen wrote:
_______________________________________________
Kamailio (OpenSER) - Devel mailing list
Devel(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/devel
http://lists.openser-project.org/cgi-bin/mailman/listinfo/devel
Andrei Pelinescu-Onciul writes:
--
Daniel-Constantin Mierla
SIP Router Masterclass - Kamailio (OpenSER) Training
http://www.asipto.com/index.php/sip-router-masterclass/
> 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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
28 Mar
28 Mar
12:26 a.m.
New subject: [SR-Dev] sip-router: modules & repositories
On Mar 27, 2009 at 13:22, Daniel-Constantin Mierla <miconda(a)gmail.com> wrote:
On 03/27/2009 01:08 PM, 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 :-)
Andrei
On Mar 27, 2009 at 11:00, Daniel-Constantin Mierla
<miconda(a)gmail.com>
wrote:
all modules
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?)
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).
1 p.m.
New subject: [SR-Dev] sip-router: modules & repositories
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
--
Daniel-Constantin Mierla
SIP Router Masterclass - Kamailio (OpenSER) Training
http://www.asipto.com/index.php/sip-router-masterclass/
27 Mar
27 Mar
1:41 p.m.
New subject: [SR-Dev] [Serdev] sip-router: modules & repositories
On 27-03 12:08, Andrei Pelinescu-Onciul wrote:
On Mar 27, 2009 at 11:00, Daniel-Constantin Mierla
<miconda(a)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.
28 Mar
28 Mar
8:19 a.m.
New subject: [SR-Dev] [Serdev] sip-router: modules & repositories
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
5718
days inactive
5750
days old
20 comments
4 participants
participants (4)
-
Andrei Pelinescu-Onciul -
Daniel-Constantin Mierla -
Jan Janak -
jh＠tutpro.com