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
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
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/
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
Juha,
On Mon, Oct 12, 2009 at 5:38 PM, Juha Heinanen jh@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
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
On Mon, Oct 12, 2009 at 9:05 PM, Juha Heinanen jh@tutpro.com wrote:
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.
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
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
On Mon, Oct 12, 2009 at 9:28 PM, Juha Heinanen jh@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
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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
On 13.10.2009 7:47 Uhr, Juha Heinanen wrote:
Greger Viken Teigre writes:
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.
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 wrote:
On 13.10.2009 7:47 Uhr, Juha Heinanen wrote:
Greger Viken Teigre writes:
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.
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.
Good point. You're right. g-)
Cheers, Daniel
On Tue, Oct 13, 2009 at 7:25 AM, Greger Viken Teigre gregert@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
On Oct 12, 2009 at 22:05, Juha Heinanen jh@tutpro.com wrote:
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.
Yes, it will.
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
Jan,
thanks for sharing the minutes.
Cheers, -Victor
On Mon, Oct 12, 2009 at 5:26 PM, Jan Janak jan@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
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@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
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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-
Alex Balashov -
Andrei Pelinescu-Onciul -
Daniel-Constantin Mierla -
Greger Viken Teigre -
Jan Janak -
jh＠tutpro.com -
Victor Pascual Avila