Re: Bug#681834: network-manager, gnome, Recommends vs Depends
]] Ian Jackson Hi, It seems to me that our objectives must include: [...] 3. Users who deliberately removed network-manager in squeeze (which they will generally have done by deliberately violating the Recommends from the gnome metapackage) should not have to do anything special to avoid it coming back in wheezy. A somewhat tangential question here – is this a general requirement? Doesn't that prevent maintainers from (worst case) ever upgrading Recommends to Depends? I'm worried about what precedent this would be setting. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87txwwcq60@xoog.err.no
Re: Bug#681834: network-manager, gnome, Recommends vs Depends
Tollef Fog Heen tfh...@err.no writes: ]] Ian Jackson 3. Users who deliberately removed network-manager in squeeze (which they will generally have done by deliberately violating the Recommends from the gnome metapackage) should not have to do anything special to avoid it coming back in wheezy. A somewhat tangential question here – is this a general requirement? Doesn't that prevent maintainers from (worst case) ever upgrading Recommends to Depends? I'm worried about what precedent this would be setting. Yeah, I have the same concern. I'm not fond of just stating this as a simple requirement. As I understand it, the timeline here looks something like: 1. network-manager was a Recommends in squeeze. 2. GNOME maintainers get a bunch of bugs from confused users who don't install Recommends for some reason and then don't get network-manager and perceive a crippled system. 3. GNOME maintainers upgrade Recommends to Depends to solve, from their perspective, those bugs. 4. Other users who understood the Recommends vs. Depends distinction and used it to remove network-manager from their systems intentionally now find it harder to do so and perceive the dependency as introducing a bug. Ian's argument goes on to essentially state that it's more important to cater to the people who understand how the dependency system works and are using it to make intentional choices about a package that they don't want to use than it is to cater to the people who don't understand how it works and end up confusing themselves and creating installations that don't, from their perspective, work. I think this argument has substantial validity. It seems reasonable to apply, as a general principle, the idea that we should cater to people who are using the system as documented over people who are using it incorrectly, and that if there are a lot of people using it incorrectly, that's probably a bug in our education or documentation rather than in how we use the system. But I do think that it's possible to disagree with this argument, and to some extent it's situational. In other contexts in Debian, when we do something that is technically correct but nonetheless confusing, that is frequently considered a bug and we will sometimes address that bug by changing what we do to more closely follow the expectations of users, even if it's less elegant or less aesthetically appealing. It's of course easy to make that decision when the drawbacks of doing so are just loss of a sense of order or elegance, as opposed to making harder something that we know people want to do. This strikes me as a classic example of one of the harder types of bugs to solve: one where there is a vocal community on both sides of somewhat mutually exclusive alternatives. One of the problems with trying to address this sort of bug is that one always runs the risk of underestimating the number people who are happy with whatever the current situation is, since those people will not, at the current time, be actively complaining. (And this applies both ways: it is easy for the GNOME maintainers to underestimate the number of people who were grateful for the Recommends rather than Depends and focus on the confused people filing bugs, and now currently it's easy to focus on the people who don't want network-manager and want to make it easier to remove and miss the people whose systems now work the way that they expect because of the upgraded dependency.) That's why, with changes like this, one often sees an unstable fluctuation between the two alternatives because, at any given time, responding to the squeaky wheel (the users who are actively complaining) means flipping the state back to the other alternative. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87629cgvoy@windlord.stanford.edu
Bug#682010: [mumble] Communication failures due to CELT codec library removal
Hi, On Wednesday 25 July 2012 03:50:23 Chris Knadle wrote: The way you've described this, /if/ the trick with Speex does work, and the Debian version of Mumble ships without CELT, it would mean that if any Debian user shows up on a public server then all users would switch to using Speex. If that's the case, then the audio quality of Speex vs Celt and the latency each has matters to an extent. If the trick with speex works and is actually deemed necessary, then we're talking about a package providing the absolute minimum of interoperability without any ambition to providing quality. And yes, for it to work, it would need to switch all clients within hearing range to using speex with all the penalties in quality and latency that brings. However, as suggested earlier, statistics also show that users on Linux platforms make up not quite 2% of the overall userbase, and users affected by the hack would be well below that (my guess would put them under one per mil). With that in mind, it would be easy for users to just kick the offending handful of clients worldwide off their servers if the need arises, since it would be a very rare occurrence. That makes the impact on the overall userbase absolutely negligible. Regards, Nicos -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201207250940.52462.gt...@spearhead.de
Re: Bug#682010: [mumble] Communication failures due to CELT codec library removal
On Wednesday, July 25, 2012 03:40:52, Nicos Gollan wrote: Hi, On Wednesday 25 July 2012 03:50:23 Chris Knadle wrote: The way you've described this, /if/ the trick with Speex does work, and the Debian version of Mumble ships without CELT, it would mean that if any Debian user shows up on a public server then all users would switch to using Speex. If that's the case, then the audio quality of Speex vs Celt and the latency each has matters to an extent. If the trick with speex works and is actually deemed necessary, then we're talking about a package providing the absolute minimum of interoperability without any ambition to providing quality. And yes, for it to work, it would need to switch all clients within hearing range to using speex with all the penalties in quality and latency that brings. Yeah... I'm not liking the sound of that. For instance one of the things that are common on public Mumble/Murmur servers are one or more music channels among the many other channels for teams of gamers. Forcing all of that through a low-quality codec meant only for voice communication sounds very undesirable from the user perspective. However, as suggested earlier, statistics also show that users on Linux platforms make up not quite 2% of the overall userbase, and users affected by the hack would be well below that (my guess would put them under one per mil). With that in mind, it would be easy for users to just kick the offending handful of clients worldwide off their servers if the need arises, since it would be a very rare occurrence. That makes the impact on the overall userbase absolutely negligible. [I'm sure you know the following, but I'm explaining this in more detail for those that may not be familiar with it.] Normally users cannot kick nor ban another user off the server. To kick an offending client off the server would require SuperUser priviliges in the Mumble/Murmur server, or for kick/ban priviliges to be delegated to specific users via Groups or ACL rules in the server. After that, this would involve right-clicking on the suspected offending client and getting Information on the client version, *somehow* figuring out that that version of Mumble was causing the problem (i.e. the Debian version of Mumble is a problem from a web search), and then finding someone with kick/ban priviliges to get the offending client off. Then presumably someone has to leave the server and return in order to get the server to renegotiate the codec used. I wouldn't characterize the above as easy -- although it is easy in the sense that it doesn't require reconfiguring the host machine to do it. It would be easier for users to text the offending client and ask that the user leave, but this would also involve understanding and explaining the situation. -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201207250702.02620.chris.kna...@coredump.us
Re: Bug#682010: [mumble] Communication failures due to CELT codec library removal
On Wed, Jul 25, 2012 at 09:40:52AM +0200, Nicos Gollan wrote: If the trick with speex works and is actually deemed necessary, then we're talking about a package providing the absolute minimum of interoperability without any ambition to providing quality. And yes, for it to work, it would need to switch all clients within hearing range to using speex with all the penalties in quality and latency that brings. No, it will provide OPUS and the official client will as well, at which point Windows users just need to upgrade. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: Bug#682010: [mumble] Communication failures due to CELT codec library removal
On Wednesday, July 25, 2012 09:17:10, Philipp Kern wrote: On Wed, Jul 25, 2012 at 09:40:52AM +0200, Nicos Gollan wrote: If the trick with speex works and is actually deemed necessary, then we're talking about a package providing the absolute minimum of interoperability without any ambition to providing quality. And yes, for it to work, it would need to switch all clients within hearing range to using speex with all the penalties in quality and latency that brings. No, it will provide OPUS and the official client will as well, at which point Windows users just need to upgrade. In principle that's possible -- assuming the Windows developer snapshot is updated (which right now doesn't support Opus), that's what users would have to upgrade to in order to not have their communications degrade when a Debian user joins their server. I'd be a lot more comfortable with this idea if Opus was about to make it to the *stable* version of Mumble -- it doesn't seem right to me to force the stable version of the software into planned obsolescence. And of course if we count Linux users in this [who have admittedly been shown to be a tiny fraction of the population], then we have a different problem, because it's going to take time for Opus support to make its way into the various distribution releases and it's not as easy to say just upgrade for that case. Just food for thought. -- Chris -- Chris Knadle chris.kna...@coredump.us GPG Key: 4096R/0x1E759A726A9FDD74 signature.asc Description: This is a digitally signed message part.
CTTE IRC Meeting reminder: date -d 'July 26 2012 17:00 UTC'
Just a reminder that the next CTTE IRC meeting is at: date -d 'July 26 2012 17:00 UTC' on #debian-ctte on irc.debian.org. I've also taken the liberty of shoving a stab at the agenda in the git repository, feel free to add/modify items. git://git.debian.org/git/collab-maint/debian-ctte.git Don Armstrong -- THERE IS NO GRAVITY THE WORLD SUCKS -- Vietnam War Penquin Lighter http://gallery.donarmstrong.com/clippings/vietnam_there_is_no_gravity.jpg http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120725180140.gx32...@rzlab.ucr.edu
Bug#681687: Collaborative maintenance of mime-support (was Re: Using FreeDesktop MIME entries directly in mime-support).
Le Tue, Jul 17, 2012 at 03:51:55PM +, Laszlo Boszormenyi (GCS) a écrit : It is now visible: http://anonscm.debian.org/gitweb/?p=collab-maint/mime-support.git;a=summary Dear all, I have uploaded to mime-support version 3.53_experimental1 to experimental. As discussed earlier, me and Laszlo strictly limited the changes to the adoption of the package, the transfer of its source in collab-maint, and the addition of a triggered parsing of Desktop entries to populate /etc/mailcap. Many thanks to Brian M. Carlson for the patch ! We did not have that much time to make extensive tests. On my computer, I did not suffer from the lack of a mailcap entry for evince, so please, people concerned with #658139, test the package and let us know what you think. If there is a consensus for uploading to Unstable and ask for a freeze exception, we will. Here is a link to the diff with the previous version: http://anonscm.debian.org/gitweb/?p=collab-maint/mime-support.git;a=commitdiff;hp=3.52-1;h=3.53_experimental1 Here is a link to the build log: http://anonscm.debian.org/gitweb/?p=collab-maint/mime-support.git;a=blob;f=amd64.log;h=9a0dace97c2ddd49a03e7c97428cae945ca5f0b0;hb=uploads (And my apologises for messing with the changelog for my first upload of a high-priority package... in contrary of what is written, it was really uploaded ot experimental...) Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120726002739.ga12...@falafel.plessy.net
