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: <CAHk-=wiDeCY_ENy9S-6DjPgzzF=1UucJGrKo_K98jYA-yR1jJg@mail.gmail.com>
Date:   Mon, 3 Dec 2018 08:49:39 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     pavel@....cz
Cc:     Greg KH <gregkh@...uxfoundation.org>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        Jonathan Corbet <corbet@....net>,
        Frank Rowand <frowand.list@...il.com>, acme@...nel.org,
        tomi.valkeinen@....fi, bvanassche@....org,
        linux-doc@...r.kernel.org,
        Linux List Kernel Mailing <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3] code-of-conduct: Remove explicit list of
 discrimination factors

On Mon, Dec 3, 2018 at 4:15 AM Pavel Machek <pavel@....cz> wrote:
>
> Linus, I don't think Greg is doing good job maintaining this. Can you
> take the patch? (Or explain what is going on here, because I don't
> think public has full story).

I think Greg is doing a fine job, and I personally will not take
patches to the CoC without *much* stronger reasons than just some
random opinion.

This is an area where everybody has opinions, and there is no inherent
technical agreement (ie no "look, numbers: this makes code 5%
faster"), so my policy wrt the CoC is that changes to it have to have
very concrete reasons for them. IOW, actual problems caused by real
issues, not "in my opinion".

Honestly, the list of discrimination factors looks fine to me, and if
it is shown to be insufficient or problematic, there's the documented
link to the Code of Conduct Committee. That sounds to me like the
right way to bring up problematic behavior - and if the review then
shows that "yes, the CoC should cover this too", then at that point we
have a real and present example and reason to modify the CoC.

             Linus

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ