asterisk into unstable

[Faidon Liambotis]

Tzafrir Cohen wrote:
>> I think we should just enable timerfd and disable all others.
> 
> On an Asterisk system with DAHDI hardware, dahdi timing would actually
> be better. Though not on a system with dahdi_dummy.
Are you sure?

The mail from Russell that you pointed us to, has timerfd on a higher
priority than DAHDI. From that mail I understand that timerfd is the
best timing source that one can get, with the only disadvantage of not
working on an older kernel & glibc.

>> 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.
> 
> Should be supported in Lenny. It is important, as I'm going to stick
> with Lenny for a while :-)
I did a second check and realized that it's probably not going to work
on lenny due to an older glibc.

So yes, we should probably try to find a backwards-compatible way.
We could enable this workaround only for backports with the obvious
downside of limiting our testing systems.

In any case, my view is:
  - We should make mid/long-term plans;
  - Our goal is the a squeeze release;
  - In the end, we are not going to release with DAHDI as the timing
    source.

 => therefore we should make the switch and all relevant changes early
    in our release cycle.

I understand that DAHDI is the "beast that we know" but this is unstable
that we're talking about. We *need* to test this "new beast" now, not
create unnecessary packages.

>> 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.
> 
> Considering 1.6.1 is not yet released, we're far from that. Squeeze is
> far from release as well. Which is why I think that if backporting
> res_timing_timerfd is not simple enough, we should just use 1.6.1 for
> now. 
Err, what? :-)

I didn't quite get what you said but in any case I see no reason for not
trying to package trunk, if that suits us better at this point.

Thanks,
Faidon