[asterisk-dev] Re: [asterisk-commits] oej: trunk r47194 - /trunk/channels/chan_sip.c

[Kevin P. Fleming]

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.