linux-kernel - Re: [Ksummit-discuss] [PATCH v3 1/3] code-of-conduct: Fix the ambiguity about collecting email addresses

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1539874609.2845.5.camel@HansenPartnership.com>
Date:   Thu, 18 Oct 2018 07:56:49 -0700
From:   James Bottomley <James.Bottomley@...senPartnership.com>
To:     Frank Rowand <frowand.list@...il.com>,
        ksummit-discuss@...ts.linuxfoundation.org
Cc:     linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [Ksummit-discuss] [PATCH v3 1/3] code-of-conduct: Fix the
 ambiguity about collecting email addresses

On Wed, 2018-10-17 at 12:53 -0700, Frank Rowand wrote:
> On 10/17/18 12:08, James Bottomley wrote:
[...]
> > > Trying to understand how you are understanding my comment vs what
> > > I intended to communicate, it seems to me that you are focused on
> > > the "where allowed" and I am focused on the "which email
> > > addresses".
> > > 
> > > More clear?  Or am I still not communicating well enough?
> > 
> > I think the crux of the disagreement is that you think the carve
> > out equates to a permission which is not specific enough and I
> > think it
> 
> Nope.  That is a big place where I was not transferring my thoughts
> to clear communication.  I agree that what I wrote should have been
> written in terms of carve out instead of permission.
> 
> 
> > doesn't equate to a permission at all, which is why there's no need
> > to make it more explicit.  Is that a fair characterisation?
> 
> Nope.  My concern is "which email addresses".

The idea here was because it's a carve out that doesn't give permission
and because the permission is ruled by the project contribution
documents, the carve out should be broad enough to cover anything they
might say hence "email addresses not ordinarily collected by the
project" are still included as unacceptable behaviour.

Perhaps if you propose the wording you'd like to see it would help
because there still looks to be some subtlety I'm not getting.

James