8 Dec
2012
8 Dec
'12
7:24 a.m.
Module: sip-router
Branch: master
Commit: 571e4e3fceeff5b4d32d1ac34649e9c4031d6543
URL:
http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=571e4e3…
Author: Juha Heinanen <jh(a)tutpro.com>
Committer: Juha Heinanen <jh(a)tutpro.com>
Date: Sat Dec 8 14:17:46 2012 +0200
core and several modules: instance and reg_id in branch_t
- added instance and reg_id fields to branch_t
- added instance and reg_id arguments to append_branch function
- modified append_branch calls in core and several modules
- did not touch obsolete or modules_s modules (which are to be
removed from next release)
---
action.c | 5 ++-
config.h | 6 +++-
dset.c | 31 +++++++++++++++++++++++++----
dset.h | 43 +++++++++++++++++++++++------------------
modules/avpops/avpops_impl.c | 5 ++-
modules/corex/corex_lib.c | 4 +-
modules/dialplan/dialplan.c | 2 +-
modules/enum/enum.c | 5 ++-
modules/tm/t_serial.c | 2 +-
modules_k/alias_db/alookup.c | 3 +-
modules_k/cpl-c/cpl_sig.c | 8 ++++--
modules_k/exec/exec.c | 3 +-
12 files changed, 76 insertions(+), 41 deletions(-)
Diff:
http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commitdiff;h=571…
8 Dec
8 Dec
7:30 a.m.
New subject: git:master: core and several modules: instance and reg_id in branch_t
Hello,
you patch changes the values for server and user-agent value in config.h.
Could be better to split such large commits (when there are internal api
changes) on affected components, because it is easier to look at the
patches (e.g., doing one commit for each affected module and one for the
core) -- not a rule, just an observation based on past experiences.
Cheers,
Daniel
On 12/8/12 1:24 PM, admin(a)sip-router.org wrote:
Module: sip-router
Branch: master
Commit: 571e4e3fceeff5b4d32d1ac34649e9c4031d6543
URL:
http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=571e4e3…
Author: Juha Heinanen <jh(a)tutpro.com>
Committer: Juha Heinanen <jh(a)tutpro.com>
Date: Sat Dec 8 14:17:46 2012 +0200
core and several modules: instance and reg_id in branch_t
- added instance and reg_id fields to branch_t
- added instance and reg_id arguments to append_branch function
- modified append_branch calls in core and several modules
- did not touch obsolete or modules_s modules (which are to be
removed from next release)
---
action.c | 5 ++-
config.h | 6 +++-
dset.c | 31 +++++++++++++++++++++++++----
dset.h | 43 +++++++++++++++++++++++------------------
modules/avpops/avpops_impl.c | 5 ++-
modules/corex/corex_lib.c | 4 +-
modules/dialplan/dialplan.c | 2 +-
modules/enum/enum.c | 5 ++-
modules/tm/t_serial.c | 2 +-
modules_k/alias_db/alookup.c | 3 +-
modules_k/cpl-c/cpl_sig.c | 8 ++++--
modules_k/exec/exec.c | 3 +-
12 files changed, 76 insertions(+), 41 deletions(-)
Diff:
http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commitdiff;h=571…
_______________________________________________
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 - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
7:36 a.m.
New subject: git:master: core and several modules: instance and reg_id in branch_t
Daniel-Constantin Mierla writes:
you patch changes the values for server and user-agent
value in
config.h.
sorry, that was my mistake. i'll fix it.
Could be better to split such large commits (when
there are internal api
changes) on affected components, because it is easier to look at the
patches (e.g., doing one commit for each affected module and one for the
core) -- not a rule, just an observation based on past experiences.
if i had spit it, people would have complained that master is not
compiling. i would not have likes someone to do that to me.
-- juha
7:47 a.m.
New subject: git:master: core and several modules: instance and reg_id in branch_t
On 12/8/12 1:36 PM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
You can commit locally
and push all at once, so practically all of them
will be available on remote repository at the same time. I did it many
times (it is actually the usual way because it easier to review later or
send only specific links to the authors of the components I want to be
reviewed).
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
you patch changes the values for server and
user-agent value in
config.h.
sorry, that was my mistake. i'll fix it.
Could be better to split such large commits (when
there are internal api
changes) on affected components, because it is easier to look at the
patches (e.g., doing one commit for each affected module and one for the
core) -- not a rule, just an observation based on past experiences.
if i had spit
it, people would have complained that master is not
compiling. i would not have likes someone to do that to me.
7:55 a.m.
New subject: git:master: core and several modules: instance and reg_id in branch_t
Daniel-Constantin Mierla writes:
You can commit locally and push all at once, so
practically all of them
will be available on remote repository at the same time. I did it many
times (it is actually the usual way because it easier to review later or
send only specific links to the authors of the components I want to be
reviewed).
this was all or nothing change. making several commit locally would
just meant more work for me.
rather than argue about administrative things, i would like to get
comments on this, because it needs to be done one way or the other next:
if we do that, then for consistency, get_branch and
next_branch should
be dropped altogether and replaced by get_sip_branch (which already
exists) and get_next_sip_branch (which would be new).
so either new arguments to get_branch and next_branch or replace them
with get_sip_branch and get_next_sip_branch.
-- juha
8:48 a.m.
New subject: git:master: core and several modules: instance and reg_id in branch_t
On 12/8/12 1:55 PM, Juha Heinanen wrote:
It is no really need to replace them
(the old ones). You can add a new
function returning the pointer to the next branch and use it. For long
term, I think the one with the pointer is easier to maintain whenever we
need to add new members in the structure, I would go for that.
However, the old ones can be kept, so not much code is affected,
probably not all places where get_branch/next_branch are used need the
instance/reg-id.
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Daniel-Constantin Mierla writes:
I think this is not really a standing argument in the overall context.
It is very important to keep robustness of the application, meaning that
when one affects the components of other developers, it has to be an
easy way for them to spot the changes.
It is just about running several commit commands instead of one, the
push to remote is one command. What would change is the subject saying
what component was affected. If there is no proper time at the moment
for something, better don't rush it, could be harder later to sort it out.
You can commit locally and push all at once, so
practically all of them
will be available on remote repository at the same time. I did it many
times (it is actually the usual way because it easier to review later or
send only specific links to the authors of the components I want to be
reviewed).
this was all or nothing change. making several commit locally would
just meant more work for me.
rather than argue about administrative things,
I don't think this is an administrative thing, it is related to
development. Again, it was a suggestion. I did it because it happened to
bring in an invalid change. It was not an enforcement. Looking at very
large commits require also lot of time, usually has to be done in one
time frame. Smaller commits can be reviewed easier sequentially, at
different points in time.
i would like to get
comments on this, because it needs to be done one way or the other next:
Well, the master branch doesn't compile, pv module throws errors.
Also, the modules in modules_s have to be made to compile for the
moment, otherwise master branch compilation fails anyhow. They may be
removed, but that will still take time, it will not happen in the next
hours.
if we do that, then for consistency, get_branch
and next_branch should
be dropped altogether and replaced by get_sip_branch (which already
exists) and get_next_sip_branch (which would be new).
so either new arguments to
get_branch and next_branch or replace them
with get_sip_branch and get_next_sip_branch.
9:12 a.m.
New subject: git:master: core and several modules: instance and reg_id in branch_t
Daniel-Constantin Mierla writes:
Well, the master branch doesn't compile, pv module
throws errors.
thanks for reporting. should be fixed now.
Also, the modules in modules_s have to be made to
compile for the
moment, otherwise master branch compilation fails anyhow. They may be
removed, but that will still take time, it will not happen in the next
hours.
modules_s modules using append_branch should be now ok too.
It is no really need to replace them (the old ones).
You can add a new
function returning the pointer to the next branch and use it. For long
term, I think the one with the pointer is easier to maintain whenever we
need to add new members in the structure, I would go for that.
However, the old ones can be kept, so not much code is affected,
probably not all places where get_branch/next_branch are used need the
instance/reg-id.
ok, i'll look into it tomorrow.
-- juha
4414
days inactive
4414
days old
6 comments
3 participants
participants (3)
-
admin＠sip-router.org -
Daniel-Constantin Mierla -
Juha Heinanen