1 SIP-Router Development Meeting ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ FhG FOKUS Berlin 2nd October 2009 This is the minutes from the sip-router meeting held on the 2nd of October 2009 in FhG FOKUS in Berlin. The minutes were taken by Jan Janak. 1.1 Meeting Agenda =================== * Release of sip-router * Short name selection * Conflict resolution * SEMS Advertisement * Project Infrastructure 1.2 Participants ================= * Ancuta Onofrei * Dragos Vingarzan * Jan Janak * Andrei Pelinescu-Onciul * Bogdan Pintea * Stefan Sayer * Jesus Rodriguez * Henning Westerholt * Daniel-Constantin Mierla * Grzegorz Stanislawski * Ramona-Elena Modroiu * Marcus Gotzl * Markus Hungr * Jiri Kuthan * Christian Kaiser * Bogdan Harjoc 1.3 Minutes ============ 1.3.1 Release of sip-router ---------------------------- * Jan: Updating meeting participands on the status of the email discussion that took place before the meeting. * Daniel: - There is a lot of confusion about tools and modules. - We don't have a short name and renaming it again will generate additional confusion. - we planned to have separate release to help kamailio users to get adjusted to the new architecture. - I do not agree on having two releases at the same time. * Andrei: We always talked about the linux distribution model. * Jan: Shouldn't we release sip-router and then make a kamailio release from that? * Daniel: The statistics code is not multi-CPU ready. * Stefan: - You need to have a hook in the repository to release. - Isn't the branch that you create for release like a sr release? * Andrei: We want to release sip-router 3.0. * Daniel: I do not want to be involved in 2 projects. * Jan: You already are involved in two projects anyway. * Henning: How about having different branches for different flavors. * Daniel: We want to release Kamailio with all K. modules and selected SER modules. * Andrei: It's not a problem if you give users more sources, you do not have to remove modules/code that is not supported. * Daniel: We do not have the approach of "this is not supported" in Kamailio. * Jan: One reason why people haven't started testing the sr stuff is because we have not announced the intention to make a release. * Daniel: I don't see a solution to advertise two things, I cannot say which is better. * Jiri: To accomodate your customers, you are withdrawing from sip-router, so that you do not confuse them? * Andrei: if you say it is k 3.0 based on sip-router 3.0, is it ok? * Daniel: Yes, it's your sip-router release. * Gregorz: Is sip-router going to be a complete solution? * Jan: We hope that eventually it will. * Jiri: in order to have achievable milestones, it is too ambitious to have a full solution now. * Gregorz: ser has serweb, kamailio has siremis, can we treat a sip-router as tool, just like linux kernel, you will have independent distributions and it does not create confusion, you have invested into kamailio trade mark * Daniel: - My concern is one month being involved in two releases that do the same thing. - sip-router we started as project, we advanced more, we planned to have common core and tm. * Jiri: I am confused by the fact that you want to save labor, but have a different release at the same time. * Andrei: New versions are no longer Kamailio, they are Kamailio based on sip-router. * Daniel: OK, then my involvement in sr will be zero next year. * Jiri: it is about sharing the foundation. * Stefan: Isn't it ok to make 3.0 branch and everybody knows this is foundation for Kamailio and SER? * Andrei: It is fair to name it sip-router because this is what it is. * Daniel: there will be two products that do the same thing. * Jan: We already have multiple products that do roughtly the same, so this is nothing new. * Daniel: (drawing a diagram of the sources and release) * Andrei: There is a lot of confusion about whether we are aiming for a full release or not. * Jiri: maybe we shall forget the perceptional stuff for a while? and look at code sharing? * Jan as scribe: (the discussion is getting a bit confusing and difficult to follow and write down)... * Henning: I talked to some users, there is confusion about differences between sip-router and kamailio, but it can be explained... * Jan: People ask me for public tarball of sip-router for installations I maintain. * Henning: It is common to have alpha and beta releases. (there is a general agreement in the room with Henning's statement). * Jesus: Can we delay the sr release 2-3 weeks? (everybody agrees). * Daniel: - I don't want to be involved in it (release), you can do whatever, I cannot be involved. - I won't be promoting sip-router. * Dragos: It is not going to be distributed through standard distributions like Ubuntu yet? * Jan,Andrei: No, we are not there yet. * Jan as scribe: (licensing discussion, I got lost in it) * Henning: So we will have k3.0 and a developer release of sip-router * Jiri: So we will have a release marked as development 1.3.2 Short Name ----------------- * Jiri: - How do we select short name for the application? - Have 1 week for proposals? - How do we select who is going to vote? * Andrei: Everybody who who has at least one commit in all the projects. * Ramona: For active modules * Jan: Since the beginning of the project. * Jiri: past 3 years might be better. * Andrei: At least 1 commit in 3 years and non-compete provisions. * Daniels: Let's have registered voters. * Jiri: Use doodle * Jan: There will be a deadline, voting is right, not obligation (in response to Daniels concern). * Ancuta: Both projects prepare list of voters * scribe: there is a consensus that we will approach those who had at least one commit in past three years. * Stefan: Make it clear that users and other people are not included. * Daniel - Community only via anonymous proposals. - Don't discuss, just vote. * Andrei: requirements: no conflicts, shorter version of sip router, less or equal than sip-router, shouldn't be an existing application in debian or clear trademark. not overlapping with debian package names. 1.3.3 Resolution Procedures ---------------------------- * Jiri: - We have rough consensus that we want to have them. - Tt has to be clearly defined (which implies some infairness) - Important is that we choose something that is fair and easy to understand. 1.3.4 Resolving Technical Conflicts ------------------------------------ * Jan: Do we need it for the project? * Daniel: Yes, we had the problem before. * Daniel: With Kamailio fork it started with a very late commit of local route. * Andrei: Let's have a board. * Andrei: It is a hard problem, the technical part is not simple. * Daniel: We end up in political discussions anyway. * Jiri: Not sure if we need to have a general consensus on that. * Daniel: I am concerned mainly about the core and tm. 1.3.5 SIP-Router in Three Years -------------------------------- * Daniel: bigger project, bigger community, trying to build a bigger open source project with bigger community. * Jiri: For Tekelec there is little motivation for promotion. * Daniel: Why are we having two versions of some modules that depend on database, such as rr or sl modules? * Daniel: We mark features that we obsolete and keep them one release * Daniel: that does not apply to features that can be done in another way 1.3.6 OpenSSL License Issue ---------------------------- * Jan: Giving an overview of the problem and possible solutions, this is based on a description sent out earlier by email. * Jan: suggests that we attempt to solve this by approaching as many people as we can and we see how far we can get and if we can add an exception to the license. * scribe: The discussion is about whether the exception is needed in the whole application or only the TLS module. * Ramona: is concerned about (c) owning companies. * Daniel: Lots of contributors on kamailio side dissappeared. * scribe: resolution seems to be: let's try approach them and see what happens. 1.3.7 Database Schema Merge ---------------------------- * Jan: presenting the document sent out earlier: http://iptel.org/jan/db_merge * Daniel: concerned about some presence table where we cannot use UID. * scribe: most of discussion revolving around some low-level technical details. * scribe: resolution: Let's merge the easy tables, and then we will see how to go futher, Jan and Henning will figure out how to to merge the easy tables and store their definition in the repository. 1.3.8 SEMS ----------- * Stefan: Giving a presentation about SEMS and its features, Stefan will send a link to the presentation to the mailing list. 1.3.9 Project Infrastructure ----------------------------- * Daniel: What is current status? * Jan: The domain and server owned and paid by Jan. In long term we should have a foundation-like status so that the domain is not owned by a single person. We should also have a transparent bank account.