asterisk into unstable

[Faidon Liambotis]

Tzafrir Cohen wrote:
> As it has to spend time in the new queue anyway, I wonder if it won't be
> best to go for Asterisk 1.6.1 and experiment with the alternative timing
> sources. I guess that even if they don't really work well on 1.6.1, they
> will work well by the time 1.6.2 is released, and hence it may be useful
> to add the following two subpackages:
> 
>   asterisk-dahdi:
>     chan_dahdi.so
>     res_timing_dahdi.so
>     codec_dahdi.so
>     app_dahdibarge.so
>     app_dahdiras.so
>     app_dahdiscan.so
> 
>   asterisk-timing-pthread:
>     res_timing_pthread.so
> 
> Both packages will provide "asterisk-timing" and the main asterisk
> package will depend on:
> 
>   asterisk-dahdi | asterisk-timing
> 
> As for the moment we'll still default to the DAHDI timing source, until
> a new one proves useful.
> 
> The over-engeneering here is because 1.6.2 has a third timing source:
> res_timing_timerfd .
I don't see the point.

I think we should just enable timerfd and disable all others.

timerfd will be supported in squeeze (and iirc is already supported in
lenny -- not that it matters much) and it should be mature enough in
Asterisk by the time squeeze will get released.

As far as I understand it (and correct me if I'm wrong), the only reason
there are three different res_timing sources is backwards compatibility,
which of course doesn't apply for us.

As for 1.6.1, we could do either of
a) Backport res_timing_timerfd from 1.6.2,
b) Package a pre-release of 1.6.2/trunk,
c) Use timing_pthread until 1.6.2 gets released.

Thanks,
Faidon