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