[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: default softphone in Debian stretch

Hash: SHA256

On 15/01/16 14:20, Bas Wijnen wrote:
> On Fri, Jan 15, 2016 at 11:08:35AM +0100, Daniel Pocock wrote:
>> On 15/01/16 04:00, Paul Wise wrote:
>>> On Tue, Jan 12, 2016 at 5:42 PM, Daniel Pocock wrote:
>>>> default softphone in Debian[1]
>>> It should be up to the user what communications tools they want
>>> to use and or have installed (if any), that is none of our
>>> business, other than perhaps informing them of the security
>>> properties of what is available and or providing the default
>>> upstream tool choices via metapackages where available.
> I strongly disagree.  Users should be able to choose, and we should
> not force one option on them.  But users should not be forced to
> choose.  A major feature of using a distribution is that you don't
> need to choose individual programs to install, but get a well
> functioning system.
> Don't confuse the freedom to choose with the obligation to choose.
> Freedom is good, and so is having good defaults.

Yes, I wasn't insisting that every user should be forced to install
something or even worse, forcing users to create a SIP or XMPP account
in some designated service provider.

Making it as easy as possible for those who do want such things and
helping them make a good choice on their first attempt are the things
I'm concerned with.

>> If there are meta-packages (e.g. sip-client, xmpp-client), should
>> any softphone be able to assert that it provides sip-client?  Or
>> should there be some quality threshold?
> I think there should be a threshold.  Failing to meet that should
> be ground for an RC bug.  In other words, the package can be in
> unstable, but not in testing (or stable).

Is this approach used in a formal manner with any other sets of
packages, meta-packages or tags in Debian?

>> For example, WebRTC browsers must officially support G.711 and
>> Opus codecs.  Many softphones don't support Opus yet.  Should we
>> say that support for Opus is mandatory for any package that
>> provides sip-client or xmpp-client and any package that falls
>> short has to remove the Provides line from debian/control or be
>> hit with an RC bug?
> Yes, that sounds reasonable.  If a package Depends: sip-client,
> things are expected to work well.

I'll make a wiki with my own ideas about this and maybe the details
can be discussed on the debian-rtc list (it is lower volume than the
pkg-voip[1] list)

>> Using some threshold for quality and interoperability will help
>> the majority of users to choose from the more desirable
>> softphones, but no softphone would be excluded from the
>> distribution.
> Also, an RC bug is not always a problem.  If a maintainer believes
> that it is useful to have a work in progress program in Debian, it
> can be in unstable, with an RC bug to prevent it from entering
> testing.

Yes, that is why I thought this would be a useful approach.
Maintainers could also upload a version of the package without the
metapackage name and then downgrade the RC bug.



1. http://pkg-voip.alioth.debian.org/
Version: GnuPG v2


Reply to: