12 Oct
2009
12 Oct
'09
6:26 p.m.
Hello,
Attached are the minutes from the last meeting in Berlin. I also
uploaded them to the wiki:
http://sip-router.org/wiki/meetings/berlin_2009
The minutes are probably not complete because in addition to being a
scribe, I was also trying to be a meeting participant, well, I did my
best. Enjoy.
-- Jan
12 Oct
12 Oct
6:38 p.m.
i read the minutes and don't understand what the conclusion was if any.
i don't understand what daniel's comment means that his involvement in
sr will be zero, which is pretty hard to achieve if next k will be based
on sr.
based on bug reports, it looks to me that there is only a small number
of people testing sr today. for example, i have not seen many from
daniel recently. does it mean that daniel has already given up? should
i start porting my post-openser enhancement to opensips or what?
-- juha
7:10 p.m.
Hello Juha,
On 12.10.2009 17:38 Uhr, Juha Heinanen wrote:
i read the minutes and don't understand what the
conclusion was if any.
i don't understand what daniel's comment means that his involvement in
sr will be zero, which is pretty hard to achieve if next k will be based
on sr.
based on bug reports, it looks to me that there is only a small number
of people testing sr today. for example, i have not seen many from
daniel recently. does it mean that daniel has already given up? should
i start porting my post-openser enhancement to opensips or what?
the non-involvement I stated at the meeting was about sr devel release proposed
by Jan to happen more or less at the same time with Kamailio 3.0, because of lack of time
and, IMO, confusion that can be created by releasing two sip server apps at the same time
by same group, although SR is just devel release.
Also if there is going to be choosen a short name soon, then we should wait for that
first. Another concern was that additional tools (kamctl, kamdbctl) are not integrated at
all, some modules could be merged before a sr release to remove confusions (sl, rr,
a.s.o). But other people considered that these can wait since is going to be just a
_devel_ release. Fine with me if they undertake the work.
To be more precise, for the moment I focus only on releasing Kamailio 3.0, which is of
course based on sr. Since ser team has no intention in releasing ser 3.0, they can
allocate time for a sr devel release. Once K 3.0 is released, the development continues as
usual within SR source tree.
Kamailio 3.0 will have extra patches in core than sr, to offer easier migration of config
from kamailio 1.5 and to include some features that are in 1.5 but will be replaced by a
better version in the future of sr (e.g., core statistics).
My presence on mailing lists and testing was really affectted by heavy travelings in the
last week (among them, you country), but I am here and not going to leave soon :-).
Cheers,
Daniel
Daniel-Constantin Mierla
* Kamailio SIP Masterclass, Nov 9-13, 2009, Berlin
* http://www.asipto.com/index.php/sip-router-masterclass/
10:16 p.m.
Daniel-Constantin Mierla writes:
Also if there is going to be choosen a short name
soon, then we
should wait for that first. Another concern was that additional tools
(kamctl, kamdbctl) are not integrated at all, some modules could be
merged before a sr release to remove confusions (sl, rr, a.s.o). But
other people considered that these can wait since is going to be just
a _devel_ release. Fine with me if they undertake the work.
there is no such thing as "devel" release. there are only releases that
are intended for production use, like what we have had in k and what we
have in sems. the rest is trunk or master or whatever you want "work in
progress" to call.
To be more precise, for the moment I focus only on
releasing Kamailio
3.0, which is of course based on sr. Since ser team has no intention
in releasing ser 3.0, they can allocate time for a sr devel
release. Once K 3.0 is released, the development continues as usual
within SR source tree.
based on what branch of sr? in my opinion that branch needs to be a
stable branch, which is kept up to date regarding bug fixes no matter if
they are fixed by k or sr folks.. there should not be a k 3.0 release
unless it is based on some stable sr release. and if there is a stable
sr release on which k 3.0 is based, sr folks can and should make an
announcement of that release.
-- juha
7:14 p.m.
Juha,
On Mon, Oct 12, 2009 at 5:38 PM, Juha Heinanen <jh(a)tutpro.com> wrote:
i read the minutes and don't understand what the
conclusion was if any.
i don't understand what daniel's comment means that his involvement in
sr will be zero, which is pretty hard to achieve if next k will be based
on sr.
I only posted what I recorded during the meeting.
My understanding is that we will release sip-router sometime after
Kamailio release (so that it does not compete with the Kamailio
release). Daniel does not have time to work on both (kamailio and sr)
releases so he will focus on Kamailio and other people (myself,
Andrei) will work on sr release. We won't release another SER version
now so we have some extra cycles to put into releasing sip-router.
-- Jan
10:05 p.m.
Jan Janak writes:
My understanding is that we will release sip-router
sometime after
Kamailio release (so that it does not compete with the Kamailio
release). Daniel does not have time to work on both (kamailio and sr)
releases so he will focus on Kamailio and other people (myself,
Andrei) will work on sr release. We won't release another SER version
now so we have some extra cycles to put into releasing sip-router.
jan,
i'm picking my stuff for the next release from sr_3.0:
Branch sr_3.0 set up to track remote branch refs/remotes/origin/sr_3.0
i have no idea if that has anything to do with k 3.0 or not, but in
order to be able to use that branch, it needs to have bug fixing only
status and all bugs that someone fixes somewhere is sr or k 3.0 need to
to appear also in origin/sr_3.0.
let me know if that is not going to be the case and i'll draw my
conclusions.
-- juha
10:19 p.m.
On Mon, Oct 12, 2009 at 9:05 PM, Juha Heinanen <jh(a)tutpro.com> wrote:
Jan Janak writes:
Yes, that's exactly how it is supposed to work. Basically all bugs
discovered in Kamailio or sip-router will be fixed in the master
branch and then merged into respective stable branches for sip-router
and kamailio.
Branch sr_3.0 is supposed to be the stable branch which, once we
continue with development on the master branch, will receive bug fixes
only. The same will be true for the stable kamailio branch once it is
created.
Bugs found in Kamailio will be propagated to the stable sr branch and
vice versa.
Basing your code on sr_3.0 is therefore safe and you should receive
all bug fixes.
-- Jan
My understanding is that we will release
sip-router sometime after
Kamailio release (so that it does not compete with the Kamailio
release). Daniel does not have time to work on both (kamailio and sr)
releases so he will focus on Kamailio and other people (myself,
Andrei) will work on sr release. We won't release another SER version
now so we have some extra cycles to put into releasing sip-router.
jan,
i'm picking my stuff for the next release from sr_3.0:
Branch sr_3.0 set up to track remote branch refs/remotes/origin/sr_3.0
i have no idea if that has anything to do with k 3.0 or not, but in
order to be able to use that branch, it needs to have bug fixing only
status and all bugs that someone fixes somewhere is sr or k 3.0 need to
to appear also in origin/sr_3.0.
10:28 p.m.
Jan Janak writes:
Branch sr_3.0 is supposed to be the stable branch
which, once we
continue with development on the master branch, will receive bug fixes
only. The same will be true for the stable kamailio branch once it is
created.
Bugs found in Kamailio will be propagated to the stable sr branch and
vice versa.
Basing your code on sr_3.0 is therefore safe and you should receive
all bug fixes.
fine, then we can release sr_3.0 at the same time when k 3.0 is
released. it does not mean that the release could be used by an end
user "out of the box", but it still is a release on top of which
software integrators (like k, ser, and other folks can base their
releases).
perhaps there will never be an "end user" release of sr, but what there
is has to be a solid base for software integrators. what i think still
needs to be done is to have no fixed references to "ser" in sr_3.0 code
or documents, but only variables that allow people to call the thing
anything they like. now at least sercmd reference is still fixed in
sr_3.0.
-- juha
10:47 p.m.
On Mon, Oct 12, 2009 at 9:28 PM, Juha Heinanen <jh(a)tutpro.com> wrote:
[...]
what i think still
needs to be done is to have no fixed references to "ser" in sr_3.0 code
or documents, but only variables that allow people to call the thing
anything they like. now at least sercmd reference is still fixed in
sr_3.0.
This is being worked on and it will be fixed before the release. I'm
currently collecting all the stuff needed for the short name change
and we will vote until we select once, then we will change all the
name references. Please hold on.
-- Jan
13 Oct
13 Oct
8:25 a.m.
I agree with Juha here. A development release is not a concept that
people will understand and releasing k 3.0 on a non-released sr core
seems a bit odd to me. Isn't there a need for some kind of fixed
reference to which version of sr core that k 3.0 is based on?! Sounds a
bit similar to a linux distro being released using a non-released kernel
version.
What about at least making an sr 3.0 beta that k 3.0 can be based on and
then later move towards a release of sr 3.0 "developer/integrator edition"?
g-)
Juha Heinanen wrote:
Jan Janak writes:
Branch sr_3.0 is supposed to be the stable branch
which, once we
continue with development on the master branch, will receive bug fixes
only. The same will be true for the stable kamailio branch once it is
created.
Bugs found in Kamailio will be propagated to the stable sr branch and
vice versa.
Basing your code on sr_3.0 is therefore safe and you should receive
all bug fixes.
fine, then we can release sr_3.0 at the same time when k 3.0 is
released. it does not mean that the release could be used by an end
user "out of the box", but it still is a release on top of which
software integrators (like k, ser, and other folks can base their
releases).
perhaps there will never be an "end user" release of sr, but what there
is has to be a solid base for software integrators. what i think still
needs to be done is to have no fixed references to "ser" in sr_3.0 code
or documents, but only variables that allow people to call the thing
anything they like. now at least sercmd reference is still fixed in
sr_3.0.
-- juha
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
noon
On 13.10.2009 7:47 Uhr, Juha Heinanen wrote:
Greger Viken Teigre writes:
if you do this analogy, then the kernel is the core+tm and the modules
are the applications, since there are different versions of several
modules, different tools around them. sr_3.0 branch was created, being
the source for kamailio_3.0. core+tm are quite stable right now and we
work to make the other modules stable using them, my focus being K
modules, in accord with what was planned about one year ago.
If you think of having sr release with everything included as the
kernel, and then K as a subset of it, then it is odd, since I haven't
seen this approach elsewhere and makes no sense imo.
Cheers,
Daniel
--
Daniel-Constantin Mierla
* Kamailio SIP Masterclass, Nov 9-13, 2009, Berlin
* http://www.asipto.com/index.php/sip-router-masterclass/
Sounds a
bit similar to a linux distro being released using a non-released kernel
version.
good analogy. in fact we could call sr_3.0 sip-router kernel release.
12:33 p.m.
Daniel-Constantin Mierla wrote:
On 13.10.2009 7:47 Uhr, Juha Heinanen wrote:
Good point. You're right.
g-)
Greger Viken Teigre writes:
if you do this analogy, then the kernel is the core+tm and the modules
are the applications, since there are different versions of several
modules, different tools around them. sr_3.0 branch was created, being
the source for kamailio_3.0. core+tm are quite stable right now and we
work to make the other modules stable using them, my focus being K
modules, in accord with what was planned about one year ago.
If you think of having sr release with everything included as the
kernel, and then K as a subset of it, then it is odd, since I haven't
seen this approach elsewhere and makes no sense imo. Sounds a > bit similar to a linux distro
being released using a
non-released kernel > version.
good analogy. in fact we could call sr_3.0 sip-router kernel release.
Cheers,
Daniel
1:29 p.m.
On Tue, Oct 13, 2009 at 7:25 AM, Greger Viken Teigre <gregert(a)teigre.com> wrote:
I agree with Juha here. A development release is not
a concept that people
will understand and releasing k 3.0 on a non-released sr core seems a bit
odd to me. Isn't there a need for some kind of fixed reference to which
version of sr core that k 3.0 is based on?! Sounds a bit similar to a linux
distro being released using a non-released kernel version.
What about at least making an sr 3.0 beta that k 3.0 can be based on and
then later move towards a release of sr 3.0 "developer/integrator edition"?
g-)
Although I personally agree, we could not reach an agreement in a
previous email discussion and in the meeting, so we have to
compromise.
The current plan is that Daniel releases next Kamailio from unreleased
sip-router code. After that is done we start working on a sip-router
release (without Daniel's involvement) and release it a bit later.
This way we can get the next Kamailio out of the door and also finish
the initial merge of sip-router.
I guess none of us really like it, but it is a compromise. This only
applies to the next release, we can do it differently for future
releases.
-- Jan
12 Oct
12 Oct
10:28 p.m.
On Oct 12, 2009 at 22:05, Juha Heinanen <jh(a)tutpro.com> wrote:
Jan Janak writes:
Yes, it will.
My understanding is that we will release
sip-router sometime after
Kamailio release (so that it does not compete with the Kamailio
release). Daniel does not have time to work on both (kamailio and sr)
releases so he will focus on Kamailio and other people (myself,
Andrei) will work on sr release. We won't release another SER version
now so we have some extra cycles to put into releasing sip-router.
jan,
i'm picking my stuff for the next release from sr_3.0:
Branch sr_3.0 set up to track remote branch refs/remotes/origin/sr_3.0
i have no idea if that has anything to do with k 3.0 or not, but in
order to be able to use that branch, it needs to have bug fixing only
status and all bugs that someone fixes somewhere is sr or k 3.0 need to
to appear also in origin/sr_3.0.
let me know if that is not going to be the case and i'll draw my
conclusions.
There was very strong disagreement during the meeting on the opportunity
of making a sr 3.0 release at this time, from various reasons.
Daniel would have preferred to have only k 3.0 now and sr 3.0 when we
have more modules merged a.s.o.
In the end we agreed (with one exception) to have a development sr 3.0
release in the near future (after the k 3.0 release). It will be
called a development release because there are still a lot of modules
which are not merged (e.g. sl, auth, rr ...), lacking docs and there
will be very limited support (its intended audience are developers and
not normal users).
OTOH most of us think the code is quite ok and would want to have something
to try.
Daniel will not participate on the sr3.0 dev release, he will
concentrate on k 3.0 (which will be derived from the sr3.0 branch).
Hope I cleared a bit the confusion :-)
If anybody else (not present at the meeting) disagrees with making a
sr 3.0 development release at this point, then please speak-up.
Andrei
6:53 p.m.
Jan,
thanks for sharing the minutes.
Cheers,
-Victor
On Mon, Oct 12, 2009 at 5:26 PM, Jan Janak <jan(a)ryngle.com> wrote:
Hello,
Attached are the minutes from the last meeting in Berlin. I also
uploaded them to the wiki:
http://sip-router.org/wiki/meetings/berlin_2009
The minutes are probably not complete because in addition to being a
scribe, I was also trying to be a meeting participant, well, I did my
best. Enjoy.
-- Jan
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
--
Victor Pascual Ávila
7:33 p.m.
Also, on behalf of all meeting participants, I would like to take this
opportunity and thank Dragos Vingarzan and Ancuta Onofrei of FhG FOKUS
for perfect organization of the meeting. Thank you very much!
-- Jan
On Mon, Oct 12, 2009 at 5:26 PM, Jan Janak <jan(a)ryngle.com> wrote:
Hello,
Attached are the minutes from the last meeting in Berlin. I also
uploaded them to the wiki:
http://sip-router.org/wiki/meetings/berlin_2009
The minutes are probably not complete because in addition to being a
scribe, I was also trying to be a meeting participant, well, I did my
best. Enjoy.
-- Jan
10:06 p.m.
This does not make me very optimistic.
Hopefully it is due to my failure to understand the details.
Jan Janak wrote:
Hello,
Attached are the minutes from the last meeting in Berlin. I also
uploaded them to the wiki:
http://sip-router.org/wiki/meetings/berlin_2009
The minutes are probably not complete because in addition to being a
scribe, I was also trying to be a meeting participant, well, I did my
best. Enjoy.
-- Jan
------------------------------------------------------------------------
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
--
Alex Balashov - Principal
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
5520
days inactive
5521
days old
17 comments
7 participants
participants (7)
-
Alex Balashov -
Andrei Pelinescu-Onciul -
Daniel-Constantin Mierla -
Greger Viken Teigre -
Jan Janak -
jh＠tutpro.com -
Victor Pascual Avila