On Wed, Mar 14, 2012 at 5:18 PM, Russ Allbery wrote: > Michael Gilbert writes: >> On Wed, Mar 14, 2012 at 1:43 AM, Russ Allbery wrote: > >>> I think you're in the "rough" of "rough consensus." > >> It takes some moxie to put a dent into the status quo. If that's rough, >> so be it. I try my best to be kind and constructive though. Really >> I've tried to avoid anything potentially confrontational for a long long >> time now. > > Ack, sorry. That's a term from the IETF that I think is too easy to > misinterpret out of context. I didn't mean to say that you were being > rough or confrontational to anyone. > > The intent of the phrase is to capture the fact that consensus-based > decision-making doesn't mean that everyone agrees. Consensus isn't > unanimity, particularly "rough consensus," which is the metric that the > IETF uses formally and that Debian uses in practice. When someone > disagrees with the consensus but still seems clearly outnumbered and > doesn't succeed in persauding others that there is not consensus, they're > said to be in the "rough" of the "rough consensus." > > Think the "rough" of a golf course, not "rough" as in confrontational or > aggressive.
OK, thanks for the explainaton. >> Well, there was the recent -devel thread on essentially the same >> topic: something like "holes in our software fortress". > > Which was about yet a third separate topic, namely cryptographic > verification of executable code retrieved from the network, and is > unrelated to whether or not that code is non-free. Well like I've been trying to say, the issue is quite multi-faceted. I went to great lengths to break it down from all perspectives including crypto/security in one of my messages to the foo2zjs bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=449497#212 The important consequence of a potential policy change/clarification here, is that pushing these oddballs out of main solves all of the problems: security authenticity/integrity, non-freeness, brokenness, trustworthiness, etc. They're all good qualities that would be achieved via modest policy clarification, and would clearly (in my opinion) make main better. That's why I still think this concept is worth pursuing and contemplating a bit more, even if it does have the downside that it will cause a bit of pain in a few packages. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
