Re: default softphone in Debian stretch

[Daniel Pocock]

-BEGIN PGP SIGNED MESSAGE-
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)
https://lists.debian.org/debian-rtc/


>> 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.

Regards,

Daniel

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

iQIcBAEBCAAGBQJWmjwuAAoJEGxlgOd711bEptQP/2D3zHREhJ26Cn4xJAqQr0Fi
AL9KJYYYGqWqmbEW9fKnkv257e51mIdqAWmzaewoCraQmXE1UajmxpkkVlwONdPU
f17Dc5YzG7JNJYaLUDuIqa24itxdhZJ3c9ZQPneVOYeS7t5j1gAyALZquzBIF8pD
SZEFv7LUfwy1BG0di4wPZ2mnTOjl59rE6/R6WHnBR1nuqrTw31kbkOR1yToylZWf
gj+top6pL82eC6xvfc7L0ssUgnz1Xwos/4/EnmBMC8Ac/y/fsR5XquT3DRxenJsI
JUerMkbacOeWAQC5Rqj7ILyhSU6UF65ClbWbGB+xJ6IF1Lf7UWJoc13D7qvD+XJs
e5NvFsqU8SCcM2zucW7/75+WBPRci7fe+E3exL6jS5tCujhMP3MgyYyWFcS6hjRD
7wc/wGbUsJcat+rOeojJGkeYBFBcrBIdfPAU6WMGe7gM8qYGgrkcrWMBcUmog8Dk
Iek3ieZF0uMst2Qfrf2yCwjyz2t0YhPjLYeCnC2Q9a0qwuN4QrXr4K2vVAv2Wa/N
n1Wu7ayathBEwZHM+uEZ5uamLOcj+1xbzOYCuoBysgBLyOqWSh+fuy9wEowVF107
mca5iW2Itpp0y2ZPg3rNzGGOkv6vhWY0nAszm+pC0PtdKF0ualXJvN+ACOnH912G
PCN6EXc+yFn8w0y28pL3
=Iuhj
-END PGP SIGNATURE-

Re: default softphone in Debian stretch

[Ansgar Burchardt]

Daniel Pocock  writes:
> On 15/01/16 14:20, Bas Wijnen wrote:
>> On Fri, Jan 15, 2016 at 11:08:35AM +0100, Daniel Pocock wrote:
>>> 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?

No, I don't think we have some sort of "quality" level for providing a
virtual package.  Just take a look at www-browser which is provided by
packages not getting any security updates at all or implementing SSL in
very broken ways (I remember reading about browsers that would just
accept any certificate silently).

Ansgar

Defaults and virtual package rules (was: default softphone in Debian stretch)

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sat, Jan 16, 2016 at 01:48:46PM +0100, Daniel Pocock wrote:
> 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.

I wasn't disagreeing with you, but with Paul.  AIUI, he wants to force users to
choose which softphone they want.  I understand the resistance against forcing
users to install one softphone and not allowing them to use any other.  But
that doesn't mean there shouldn't be a default.  If a user wants a softphone
and doesn't care which, they should be getting a good default.

In short, if a user wants a softphone, Paul says: we give the options and they
_must_ study those options and choose one.  I say: we give them one that works
well, plus a list of options.  They can ignore the list of options if they
don't care about it, or use it to get exactly what they want if they do care.

> 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.

I almost agree.  On their first attempt, I don't want to help them make a good
choice; I want to make the choice for them.  Unless they want to choose
themselves, of course; I'm not saying we should stop that.  But I think most
people just want it to work.  They don't care what the program is called, and
they don't want to spend their time on choosing one.

> >> 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?
> 
> No, I don't think we have some sort of "quality" level for providing a
> virtual package.  Just take a look at www-browser which is provided by
> packages not getting any security updates at all or implementing SSL in
> very broken ways (I remember reading about browsers that would just
> accept any certificate silently).

Perhaps it would be good to allow virtual packages to have a description where
they can specify rules that providers must follow in order to be allowed to
provide it.  And in some cases, it may be possible to run automated tests (if
one of the rules is to implement some protocol).  This could be implemented by
creating a package that is used as a Build-Depends, which adds the virtual
package to the Depends of selected packages through substvars.  Lintian can
check that packages don't have hardcoded Depends on the virtual packages.

Would this be useful for more virtual packages, or not?

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJWmlsEAAoJEJzRfVgHwHE6vH8QAJ1PDeJ6/R5Yoh0S661eDlvP
TwqwLQqABMRnnUKi1+MYHNTUfxT13hbfSVcymEvlQJ9xQvYAE8H6DUKr43eyzOmJ
d0UBNOc9HI/5rx9A2nyY9Pz7u09StLzy1btD1rZUa9LaCzZm2WAj0HtWSpsH27yq
tOAB9nObLj01ZOANotP6VpIX2lUm2G85ROGgivv4pkhDVEAzgzPX1mRTOrYX/y2E
FPtdcdanWrqKgQuIgxhQAkzcOk4ylnU4DOqdSlHgwWlaQ/KJVG95awqI1D83DqbZ
EyKsezbD6rV6k9+FuGgb6xou6/xPxNM8e0ogZwWSOiuz0GdV9ap5P1tTUtO71iqu
jsDndRFFoOKhbGuCHYAqYLEToOxKbgGlc8nKm7b2GzxqefJVkcoP8UdZZFNNqEr3
Y0lNFbSYdwjMGalMbsEt2hpizUQDOZLi6FMC42TRGlqLycPg9fg5GTR4dzdamtj+
ZfYjLu/zw+562fWJqyJZLFEBkIyZIIuAhXcQwLZSh9+1OYfeLwgmZgIx2bjvkKkL
zohrbHLtc3ozQAV1SKCMUSRkzAQQguq2MxGu7+8D4EYShj8uNGA2hoZbTu6iPKLM
XE1Ef+ceg+j9ji9DifRILV6TaIGv2thl1TqAijjTBAgGSWQhv3srejchvCHYwxe0
jxMPCZfwt+Et43WEx8OV
=8mga
-END PGP SIGNATURE-

Re: default softphone in Debian stretch

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

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.

> 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).

> 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.

> 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.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJWmPIrAAoJEJzRfVgHwHE6ZpMP/0/EEjPpfCBTu479xUqDMZFr
g3/7qjPVUhD7DI6SIez55Rav8YC7UiS+khwb4emlmT/olk18nfdpYEVwhkniv4vN
pxDE8YerOUAqs3ZqicbhwsNx1SRw+rHnurJfJFUEldw5+M1hnLTnSZ3NCpoS1IUI
06VLw6yuKa2udwaP+JpXyBVrRceRXWti9gU5xHCO2VgsDol6ug1jHWGZq8tugPqL
QLBeWzswFszAhSp81SIY8Ez9DvIIXBrQrVzUCUly/yaSAzOHUi5hD88KHaMSZrzt
DLx8yAVM6iG4fVYD7f6VzRTCl55YMKJIU2XuH19efI94/5WEZTumPEL19RrRe+8u
Bo+xzlFd346skNp+cT8ytHyGlXHUQCbPp9GxAPMbNeoal/DF7zFgTudDcNPnyPb4
cJOnUfhFbfekr3l3ETfwMyuf0Awv2SGmY2XaS5mqxdMNuRsCWbGp0AJTI7nR4Lil
wAeZW1HWS2cE0r3cd3Te99O7jC6loDgPXAb/BrWLSEBpR2TqXzBEnR6q712JezMK
pkoelAiFaJ3DKtx4ONp/hyC5D6Zr2u1j83dGACZamlzfJ3UFTqVfHsuNu2f/VPjA
Q2Y5vtjBE3IyS2FZX8K2Y3t2FTmuhHKhGiUh44opkgyH5kOh4ATBHEwp2VtOP4eI
2qQfoqbIzezKrYmeYOgx
=iUqi
-END PGP SIGNATURE-

Re: default softphone in Debian stretch

[Daniel Pocock]

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.
> 

That is not the status-quo however.  Are you saying that somebody
installing a default GNOME desktop should not automatically have Empathy
any more?  That is actually what upstream discussed (link in the message
that started this thread), but without any conclusion.

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?

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?

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.

Regards,

Daniel

Re: default softphone in Debian stretch

[Iain R. Learmonth]

Hi,

On Tue, Jan 12, 2016 at 10:42:06AM +0100, Daniel Pocock wrote:
> Nothing really changed, the thread appeared to fizzle out with comments
> from more than one person that Debian would ship whatever was
> recommended by the desktop maintainers / GNOME upstream[2]

I think for the best desktop integration, there shouldn't be a default for
Debian, but rather a default for each desktop environment.

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.

Thanks,
Iain.

-- 

Re: default softphone in Debian stretch

[Paul Wise]

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.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: default softphone in Debian stretch

[Daniel Pocock]

On 14/01/16 17:10, Iain R. Learmonth wrote:
> Hi,
> 
> On Tue, Jan 12, 2016 at 10:42:06AM +0100, Daniel Pocock wrote:
>> Nothing really changed, the thread appeared to fizzle out with comments
>> from more than one person that Debian would ship whatever was
>> recommended by the desktop maintainers / GNOME upstream[2]
> 
> I think for the best desktop integration, there shouldn't be a default for
> Debian, but rather a default for each desktop environment.
> 
> 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.

Regards,

Daniel

Re: default softphone in Debian stretch

[Daniel Pocock]

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

Re: default softphone in Debian stretch

[Michael Banck]

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.

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.


Michael

default softphone in Debian stretch

[Daniel Pocock]

Before the jessie release, I started a thread about the default
softphone in Debian[1]

Nothing really changed, the thread appeared to fizzle out with comments
from more than one person that Debian would ship whatever was
recommended by the desktop maintainers / GNOME upstream[2]

GNOME upstream have subsequently made statements that the default
softphone they provide is not maintained and may even be dropped[3]

That third email also suggests that the GNOME philosophy is not quite
the same as the Debian philosophy: "popular
chat protocols are mostly closed nowadays, meaning that having a
built-in chat client potentially isn't as important as it used to be."

Going forward,

a) is this consistent with Debian's philosophy, or do we value having
the choice of using a free and open softphone?

b) if the answer to that is "yes", then should stretch continue to rely
on Empathy, or should we open it up to competition, giving all the other
softphone developers an opportunity to be installed by default?

There is more than one way forward though, for example, the
telepathy-resiprocate project[4] may make Empathy work better with SIP
and I will ask the developers of Ring, which is a peer-to-peer protocol,
if they would consider making a Telepathy connection manager too, then
it could be used from Empathy.  On the other hand, if Empathy is going
away, then such initiatives may be a waste of time.

Regards,

Daniel


1. https://lists.debian.org/debian-devel/2014/03/msg00595.html
2. https://lists.debian.org/debian-devel/2014/03/msg00638.html
3. https://mail.gnome.org/archives/release-team/2015-April/msg00050.html
4. http://danielpocock.com/enterprise-grade-sip-coming-to-telepathy
5. http://ring.cx