15 Oct
2009
15 Oct
'09
6:14 p.m.
i didn't get any answer to my question about this commit.
it looks to me that there is now two versions of sip-router core. i
thought that the agreement was that there is only one core and that all
commits to core are done to sr_3.0 branch.
can someone explain to me what is going on? am i missing something?
why this commit could not use done to sr_3.0 perhaps #ifdef kamailio or
something like that so that there would be only one core?
-- juha
15 Oct
15 Oct
7:46 p.m.
Hello Juha,
On 15.10.2009 17:14 Uhr, Juha Heinanen wrote:
i didn't get any answer to my question about this
commit.
it looks to me that there is now two versions of sip-router core. i
thought that the agreement was that there is only one core and that all
commits to core are done to sr_3.0 branch.
can someone explain to me what is going on? am i missing something?
why this commit could not use done to sr_3.0 perhaps #ifdef kamailio or
something like that so that there would be only one core?
the aim for Kamailio 3.0 is to ensure easy migration and no-feature-loss
(as much as possible) from Kamailio 1.5.
There are some features that could not be included in SR core because of
decision to go for a better version in the near future. The "completely
same core+tm framework" is targeted with the next release, after
Kamailio 3.0/SER 3.0 milestone.
Since K 3.0 has pretty tight schedule in release policy, some of these
patches go first there, but can be ported to sr3.0 if people find them
useful and if there are devs having time for them in this period, or
after K3.0 release, either directly or in defines.
Cheers,
Daniel
--
Daniel-Constantin Mierla
* Kamailio SIP Masterclass, Nov 9-13, 2009, Berlin
* http://www.asipto.com/index.php/sip-router-masterclass/
7:59 p.m.
Daniel-Constantin Mierla writes:
Since K 3.0 has pretty tight schedule in release
policy, some of these
patches go first there, but can be ported to sr3.0 if people find them
useful and if there are devs having time for them in this period, or
after K3.0 release, either directly or in defines.
in my opinion tight schedule is no excuse to break the one core + tm
policy. now there is two versions of core, which makes testing and bug
reporting much more difficult. i'm not going to use k version of core
and this kind of rule breaking makes me feel very bad about the whole
project.
-=- juha
8:12 p.m.
On 15.10.2009 18:59 Uhr, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
this was set from the initial meeting and they way everything is
supposed to evolve. It is nothing broken here, just we have to ensure
easy migration, otherwise nobody will be able to update. Gradually these
features (unique or duplicated) will be removed/replaced. You can use
what ever version you want being very familiar with SR code tree, K 3.0
has a clear target: Kamailio 1.5 users.
If there won't be any difference then is no point in having two names
for same release.
Cheers,
Daniel
--
Daniel-Constantin Mierla
* Kamailio SIP Masterclass, Nov 9-13, 2009, Berlin
* http://www.asipto.com/index.php/sip-router-masterclass/
Since K 3.0 has pretty tight schedule in release
policy, some of these
patches go first there, but can be ported to sr3.0 if people find them
useful and if there are devs having time for them in this period, or
after K3.0 release, either directly or in defines.
in my opinion tight schedule is no excuse to break the one core + tm
policy. now there is two versions of core, which makes testing and bug
reporting much more difficult. i'm not going to use k version of core
and this kind of rule breaking makes me feel very bad about the whole
project.
16 Oct
16 Oct
12:30 p.m.
On Donnerstag, 15. Oktober 2009, Juha Heinanen wrote:
Hello Juha,
i agree with you that its important that try to minimize the difference
between the kamailio and sip-router 3.0. branch. But i also understand Daniel,
we should try to get a kamailio 3.0 release out of the door soon, so that
there is something usable for the folks upgrading from the version 1.5.
The feature in question (Core statistics) are not in the sr core for
performance reasons, but i think should be able to merge them enclosed in an
ifdef, if we not get to a technical better solution soon.
Regards,
Henning
Since K 3.0
has pretty tight schedule in release policy, some of these
patches go first there, but can be ported to sr3.0 if people find them
useful and if there are devs having time for them in this period, or
after K3.0 release, either directly or in defines.
in my opinion tight schedule is no excuse to break the one core + tm
policy. now there is two versions of core, which makes testing and bug
reporting much more difficult. i'm not going to use k version of core
and this kind of rule breaking makes me feel very bad about the whole
project.
5517
days inactive
5518
days old
4 comments
3 participants
participants (3)
-
Daniel-Constantin Mierla -
Henning Westerholt -
jh＠tutpro.com