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]
Date:   Mon, 22 Oct 2018 22:10:25 +0100
From:   Greg Kroah-Hartman <greg@...ah.com>
To:     James Bottomley <James.Bottomley@...senpartnership.com>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        ksummit-discuss@...ts.linuxfoundation.org
Subject: Re: [GIT PULL] code of conduct fixes for 4.19-rc8

On Sat, Oct 20, 2018 at 01:15:14PM -0700, James Bottomley wrote:
> This is the series of patches which has been discussed on both ksummit-
> discuss and linux-kernel for the past few weeks.  As Shuah said when
> kicking off the process, it's designed as a starting point for the next
> phase of the discussion, not as the end point, so it's only really a
> set of minor updates to further that goal.
> 
> The merger of the three patches to show the combined effect is attached
> below.  However, Greg recently posted the next phase of the discussion,
> so people will be asking what the merger of the series looks like. 
> Ignoring the non-CoC documents, I think it looks like this

Sorry for not responding sooner for this, travel and the meeting today
took up my time.

Anyway, as we discussed today in the Maintainers summit, let's leave the
Code of Conduct text alone for now.  It matches what "upstream" has with
the exception of removing that one paragraph.  If you have issues with
the wording in it, please work with upstream to fix the issues there as
hundreds of other projects will benefit with your changes if they are
really needed.

For now, let's let things settle down and not worry about hypothetical
situations that might possibly happen in some way or another as we can
debate that type of thing endlessly (it's a good skill we have which
makes us great kernel developers, but it not always transferrable to
other environments).

If real issues do come up in the future, we will address them then, as
we always have the option to change and revisit things as needed.

thanks,

greg k-h

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ