On Tue, Jan 28, 2014 at 05:34:53PM -0600, Ciaby wrote:
Hi,
> > ok, here it is.
> So, what's the timeline for these patches to be integrated into the
> master branch? There are some specific things in there (half-rate
> support, AMR support, rtp-bridge) which could be very handy to us
> (Rhizomatica) both in terms of network capacity and also sound quality
> (at the moment we are routing everything to LCR, which means a
> GSM<->PCMA<->GSM codec conversion even on internal calls).
the answer is as time permits. As you see with the responses there
are various things that are not right with them and as a maintainer
it is frustrating to have to start at zero at every new patch.
>From a maintainer point of view:
* When an external protocol changes, the version number needs to
change. I added MNCC protocol versioning as OpenBSC and LCR were
out of sync and then funny things happened. This one line change
of the version number can save you hours in debugging!
* When a new feature is added, ask for a testcase. E.g. specially
the E1 bit fiddling as it is so rarely used that it is likely
to bitrot.
* Check the error paths. Developers tend to only test with a single
phone, not run into error paths, not force them to be taken during
development (faul injection).
* For things like device work-arounds ask if they are really necessary,
e.g. I have my doubts for the RTP timestamp handling.
* General code hygiene. Don't have the action take place four tabs in
in a thousand line code method, don't use magic numbers, don't repeat
yourself etc. Code is read a lot more than it is written. Besides smaller
methods being easier to write unit tests for, they are easier to
understand/review.
I have merged two patches from this patchset but they required multiple
rounds and my spare time is really limited.
cheers
holger
