Bug#587279: debian-policy: section 2.2.1 needs some tweaking
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
Reply to: