Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision
Previous revision
Next revision Both sides next revision
meetings:berlin_2009 [2009/10/12 17:11]
janakj created
meetings:berlin_2009 [2009/10/12 17:19]
janakj removed
Line 1: Line 1:
 +<code>
 +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.
 +</code>

Navigation

Wiki

Other

QR Code
QR Code meetings:berlin_2009 (generated for current page)