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: <87tvld77xh.fsf@notabene.neil.brown.name>
Date:   Tue, 23 Oct 2018 12:44:58 +1100
From:   NeilBrown <neil@...wn.name>
To:     "Theodore Y. Ts'o" <tytso@....edu>,
        Josh Triplett <josh@...htriplett.org>
Cc:     Mishi Choudhary <mishi@...ux.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        ksummit-discuss@...ts.linuxfoundation.org
Subject: Re: [Ksummit-discuss] Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document

On Sun, Oct 21 2018, Theodore Y. Ts'o wrote:

> On Sun, Oct 21, 2018 at 11:26:08PM +0100, Josh Triplett wrote:
>> On Mon, Oct 22, 2018 at 08:20:11AM +1100, NeilBrown wrote:
>> > I call on you, Greg:
>> >  - to abandon this divisive attempt to impose a "Code of Conduct"
>> >  - to revert 8a104f8b5867c68
>> >  - to return to your core competence of building a great team around
>> >    a great kernel
>
> I would point out that Greg did not chose to "impose" a Code of
> Conduct.  That directive came from Linus; the change was signed off by
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Linus, and the choice of the timing came from Linus.  That's why the
> initial commit went in with very minimal review.  This series of
> patches, especially the first two, have a very large number of
> Acked-by sign-offs.  That's because there was a *huge* amount of
> consultation with the top contributors to the kernel (using git
> statistics) before the patch set was posted.
>
> This level of consultation did not take place before Linus took his
> break during -rc4, precisely because he didn't want people to think
> that Greg did this "behind his back" and so there was no time to do
> the sort of consultations which we did with this patch set.
>
> (And when I say we, although the TAB was obviously involved, Greg did
> most of the heavy lifting; and this is something that I can say
> definitively Greg did out of a sense of duty, and because he was asked
                               ^^^^^^^^^^^^^^^
> to take on this role.  It obviously has *not* been a fun job, and Greg
> has taken a lot of flak.  I, for one, thank Greg for taking on this
> thankless task!)


"I was told to do it" and "it was my duty" are not excuses for doing
something wrong.
I'm genuinely surprised that you would suggest it is at all relevant.
What am I missing?

NeilBrown

>
>> (I personally *do* want to see most of the patch series that started
>> this particular thread dropped, because half of it undermines the point
>> of the document. The original commit, however, is a matter of
>> celebration.)
>
> Josh, here I think it's clear a very large number of kernel developers
> disagree with you.  Part of the concerns that led to creation of the
> interpretation document was precisely because there was a lot of fear
> mongering from people outside of the kernel development community,
> some of them apparently from the Gamergate brigade.
>
> And so while it is certainly true that a huge number of open source
> projects use the Contributor's Convenant, and you don't see large
> number of people getting "impeached" for stupid stuff from, say, the
> GoLang project, there were a lot of people who *were* afraid that
> perhaps, some of the insane/silly interpretations that had been flying
> around might have actually been true.  Perhaps that's what Neil is so
> worried about.
>
> For example, it should have been obvious that if code is rejected for
> technical reasons, some shadowy, unacountable group would ***not***
> second guess the reasons for a maintainer's decision and magically
> eject said maintainer from kernel development.  Maintainers still can
> reject code for any technical reason, and in some cases, for good
> non-technical reasons, such as the Netfilter team and code
> contributions from someone who had been deemed, by his deeds, to be a
> copyright troll.  And as always, people who disagree with a
> maintainer's decision to reject a patch can always appeal directly to
> Linus by sending the change to him.
>
> The Linux kernel adopting the Contributor's Convenant was not going to
> change this.  And certainly people haven't been using the
> Contributor's Convenant to try to force crap ideas or crap code into
> the Go language.  Unfortunately, because the Code of Conduct was
> suddenly dropped in with minimal chance for consultations, that fear
> was out there.  And that's why IMHO, the interpretation document
> became necessary.
>
> Ultimately, what we're after is a cultural change that will hopefully
> strengthen the kernel community and make it a better place.  Neil is
> correct that ultimately what's important is not words in a document,
> but how people behave.  And so, if the words were causing a lot of
> anxiety because were afraid that even accidental microagressions would
> cause them to be permanently "impeached", and that failing to nit-pick
> every possible microagression might be grounds for "impeaching" a
> maintainer --- then making it clear that this is not what anyone had
> in mind is a very important thing, since anxiety can lead to people
> actively resist the cultural change which most of us are want and are
> working towards.
>
> Regards,
> 						- Ted

Download attachment "signature.asc" of type "application/pgp-signature" (833 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ