Re: default softphone in Debian stretch
On 14/01/16 20:00, Michael Banck wrote:
> On Thu, Jan 14, 2016 at 07:29:48PM +0100, Daniel Pocock wrote:
>> On 14/01/16 17:10, Iain R. Learmonth wrote:
>>> It would make sense that if upstreams for desktop environments do not
>>> recommend a softphone, that Debian includes a softphone with the desktop
>>> environment's task package that is suitable for each desktop environment.
>>>
>>
>> That is the current situation
>>
>> The problem with this approach is that because it is just a component of
>> something larger (like Empathy is part of GNOME), it is not getting
>> dedicated support, it is more like they ship it as part of GNOME to tick
>> the "has a softphone" checkbox.
>>
>> Furthermore, if each desktop supplied a different softphone and they
>> didn't all work with each other, their usefulness is dramatically
>> reduced (think Metcalfe's law in reverse). Debian can make a bigger
>> impact in this area by ensuring that users can freely talk to each
>> other, whether using GNOME, KDE or whatever else.
>
> Well I think it would be the Debian SIP maintainer's task to ensure that
> the default softphone apps are interoperating between different Debian
> desktops.
>
Should that come with some specific rules though, for example, any
packaging claiming to support SIP should work with the rtc.debian.org
service or it deserves and RC bug?
I'm not writing off Empathy - I've actually been working on the
telepathy-resiprocate module to make Empathy work through NAT - but I
want to make sure other upstreams have a fair chance to get exposure if
their product is the "best", by whatever metric we choose, when the next
freeze happens.
> It might make sense to have a meta-package the depends on a generic
> softphone deemed most compatible and useful so users can install it if
> they wish. Then again, it might dilute the above effort, if that
> happend.
>
If we did that, should the desktop teams stop installing their own
softphones? Having multiple softphones on a single system is likely to
be a source of confusion, especially if the pre-installed one is weaker
than the one referred to by the meta-package.
Regards,
Daniel
Reply to: