Luigi Rizzo wrote: > i asked this specific change on the list, we discussed a bit on how > i thought it was useful. i did not see any explaination from you > (or others, if it matters) on why you consider this code harmful.
We don't reject things ONLY because they might be harmful. We also have to keep in mind documentation, support, interoperability, future code maintenance, and just generally 'why would someone want this', among other things. > if your point is that you (or anyone else) have the authority to > veto changes to chan_sip.c (or anything else), fine, but then > understand that it has obvious consequences. I think you misunderstand. There are some people who have 'primary maintainership' over particular areas of Asterisk, and they are given the privilege of managing the direction and goals of that part of the code base. In general, that means you need to convince them of the value of your changes, and that your changes must take into account the collected experience of the other people who have been maintainers of that code. In the specific case of chan_sip, we spend an inordinate amount of time dealing with the ambiguities of SIP/SDP/RTP/etc., and dealing with interoperability issues caused by broken/non-compliant SIP implementations in the wild. When someone proposes changes because the RFC says they are 'right', we frequently reject them because our experience shows that the change would actually make us _incompatible_ with other endpoints. So, to summarize: in most cases, Olle is the maintainer of chan_sip, and has the authority to request that he be shown (convinced) why a change is the right thing to do. If in any given case his opinion is not something you agree with and you wish to enlist support from the other members of the community to change his mind, you are welcome to do so :-) I would disagree with him on one point, though: the bug tracker is an awful place for design/architecture/code discussions. I would much rather see those discussions happen here, because this list is far more accessible to people who want to participate. _______________________________________________ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
