* [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document @ 2018-10-20 13:49 Greg Kroah-Hartman 2018-10-20 13:49 ` [PATCH 1/7] Code of conduct: Fix wording around maintainers enforcing the code of conduct Greg Kroah-Hartman ` (8 more replies) 0 siblings, 9 replies; 104+ messages in thread From: Greg Kroah-Hartman @ 2018-10-20 13:49 UTC (permalink / raw) To: linux-kernel Cc: ksummit-discuss, Thomas Gleixner, Olof Johansson, Chris Mason, Mishi Choudhary Hi all, As everyone knows by now, we added a new Code of Conduct to the kernel tree a few weeks ago. When we did this, it raised a number of questions as to how this would affect the kernel community. To help address these issues, I, and a few other kernel developers including the TAB, have come up with the following patch series to be added to the tree to both modify the existing Code of Conduct to remove a confusing paragraph as well as to add a new document to help explain how the Code of Conduct is to be interpreted by our community. I originally sent the first two patches in this series to a lot of kernel developers privately, to get their review and comments and see if they wanted to ack them. This is the traditional way we have always done for policy documents or other "contentious" issues like the GPLv3 statement or the "closed kernel modules are bad" statement. Due to the very unexpected way that the original Code of Conduct file was added to the tree, a number of developers asked if this series could also be posted publicly before they were merged, and so, here they are. This patch series adds this new document to the kernel tree, as well as removes a paragraph from the existing Code of Conduct that was bothersome to many maintainers. It also does a bit of housekeeping around these documents to get the documentation links correct as well as fix up the email address and other links and add a MAINTAINER entry for the files. Also I would like to publicly thank Mishi Choudhary for being willing to serve as a mediator for Code of Conduct issues. She has a long history of working in many open source communities, many much more contentious than ours. For more information about her, please see her wikipedia entry: https://en.wikipedia.org/wiki/Mishi_Choudhary or take the chance to talk with her at the Plumbers conference in a few weeks, as she will be attending that along with almost everyone on the TAB as well as many kernel developers and maintainers, myself included. thanks, greg k-h Chris Mason (1): Code of conduct: Fix wording around maintainers enforcing the code of conduct Greg Kroah-Hartman (6): Code of Conduct Interpretation: Add document explaining how the Code of Conduct is to be interpreted Code of Conduct Interpretation: Properly reference the TAB correctly Code of Conduct: Provide links between the two documents Code of Conduct Interpretation: Put in the proper URL for the committee Code of Conduct: Change the contact email address MAINTAINERS: Add an entry for the code of conduct .../code-of-conduct-interpretation.rst | 156 ++++++++++++++++++ Documentation/process/code-of-conduct.rst | 25 +-- Documentation/process/index.rst | 1 + MAINTAINERS | 6 + 4 files changed, 178 insertions(+), 10 deletions(-) create mode 100644 Documentation/process/code-of-conduct-interpretation.rst -- 2.19.1 ^ permalink raw reply [flat|nested] 104+ messages in thread
* [PATCH 1/7] Code of conduct: Fix wording around maintainers enforcing the code of conduct 2018-10-20 13:49 [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document Greg Kroah-Hartman @ 2018-10-20 13:49 ` Greg Kroah-Hartman 2018-10-20 13:50 ` [PATCH 2/7] Code of Conduct Interpretation: Add document explaining how the Code of Conduct is to be interpreted Greg Kroah-Hartman ` (7 subsequent siblings) 8 siblings, 0 replies; 104+ messages in thread From: Greg Kroah-Hartman @ 2018-10-20 13:49 UTC (permalink / raw) To: linux-kernel Cc: ksummit-discuss, Thomas Gleixner, Olof Johansson, Chris Mason, Mishi Choudhary From: Chris Mason <clm@fb.com> As it was originally worded, this paragraph requires maintainers to enforce the code of conduct, or face potential repercussions. It sends the wrong message, when really we just want maintainers to be part of the solution and not violate the code of conduct themselves. Removing it doesn't limit our ability to enforce the code of conduct, and we can still encourage maintainers to help maintain high standards for the level of discourse in their subsystem. Signed-off-by: Chris Mason <clm@fb.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Acked-by: Amir Goldstein <amir73il@gmail.com> Acked-by: Andrew Morton <akpm@linux-foundation.org> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Acked-by: Boris Brezillon <boris.brezillon@bootlin.com> Acked-by: Borislav Petkov <bp@kernel.org> Acked-by: Christian Lütke-Stetzkamp <christian@lkamp.de> Acked-by: Christoph Hellwig <hch@lst.de> Acked-by: Colin Ian King <colin.king@canonical.com> Acked-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Dan Williams <dan.j.williams@intel.com> Acked-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Dave Airlie <airlied@redhat.com> Acked-by: Dave Hansen <dave.hansen@linux.intel.com> Acked-by: David Ahern <dsa@cumulusnetworks.com> Acked-by: David Sterba <kdave@kernel.org> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Acked-by: Eric Dumazet <eric.dumazet@gmail.com> Acked-by: Felipe Balbi <balbi@kernel.org> Acked-by: Felix Kuehling <Felix.Kuehling@amd.com> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Acked-by: Florian Westphal <fw@strlen.de> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> Acked-by: Gregory CLEMENT <gregory.clement@bootlin.com> Acked-by: Guenter Roeck <linux@roeck-us.net> Acked-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Acked-by: Hans Verkuil <hverkuil@xs4all.nl> Acked-by: Hans de Goede <j.w.r.degoede@gmail.com> Acked-by: Harry Wentland <harry.wentland@amd.com> Acked-by: Heiko Stuebner <heiko@sntech.de> Acked-by: Ingo Molnar <mingo@kernel.org> Acked-by: Jaegeuk Kim <jaegeuk@kernel.org> Acked-by: James Smart <james.smart@broadcom.com> Acked-by: James Smart <jsmart2021@gmail.com> Acked-by: Jan Kara <jack@ucw.cz> Acked-by: Jason A. Donenfeld <Jason@zx2c4.com> Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Acked-by: Jens Axboe <axboe@kernel.dk> Acked-by: Jessica Yu <jeyu@kernel.org> Acked-by: Jia-Ju Bai <baijiaju1990@gmail.com> Acked-by: Jiri Kosina <jikos@kernel.org> Acked-by: Jiri Olsa <jolsa@redhat.com> Acked-by: Joerg Roedel <joro@8bytes.org> Acked-by: Johan Hovold <johan@kernel.org> Acked-by: Johannes Thumshirn <jth@kernel.org> Acked-by: Jonathan Corbet <corbet@lwn.net> Acked-by: Julia Lawall <julia.lawall@lip6.fr> Acked-by: Kees Cook <keescook@chromium.org> Acked-by: Kirill Tkhai <ktkhai@virtuozzo.com> Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Lina Iyer <ilina@codeaurora.org> Acked-by: Linus Torvalds <torvalds@linux-foundation.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Mark Brown <broonie@kernel.org> Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Masami Hiramatsu <mhiramat@kernel.org> Acked-by: Matias Bjørling <mb@lightnvm.io> Acked-by: Maxime Ripard <maxime.ripard@bootlin.com> Acked-by: Michael Ellerman <mpe@ellerman.id.au> Acked-by: Mimi Zohar <zohar@linux.ibm.com> Acked-by: Miquel Raynal <miquel.raynal@bootlin.com> Acked-by: Nikolay Borisov <n.borisov.lkml@gmail.com> Acked-by: Oded Gabbay <oded.gabbay@gmail.com> Acked-by: Olof Johansson <olof@lixom.net> Acked-by: Palmer Dabbelt <palmer@dabbelt.com> Acked-by: Paul E. McKenney <paulmck@linux.ibm.com> Acked-by: Peter Zijlstra <peterz@infradead.org> Acked-by: Rafael J. Wysocki <rafael@kernel.org> Acked-by: Richard Weinberger <richard@nod.at> Acked-by: Rik van Riel <riel@surriel.com> Acked-by: Rob Clark <robdclark@gmail.com> Acked-by: Rob Herring <robh@kernel.org> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Acked-by: Sebastian Reichel <sre@kernel.org> Acked-by: Sergio Paracuellos <sergio.paracuellos@gmail.com> Acked-by: Shawn Guo <shawnguo@kernel.org> Acked-by: Shuah Khan <shuah@kernel.org> Acked-by: Simon Horman <horms@verge.net.au> Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Acked-by: Stephen Hemminger <stephen@networkplumber.org> Acked-by: Takashi Iwai <tiwai@kernel.org> Acked-by: Tejun Heo <tj@kernel.org> Acked-by: Theodore Ts'o <tytso@mit.edu> Acked-by: Thierry Reding <thierry.reding@gmail.com> Acked-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Tim Bird <tim.bird@sony.com> Acked-by: Todd Poynor <toddpoynor@google.com> Acked-by: Wei Yongjun <weiyongjun1@huawei.com> Acked-by: YueHaibing <yuehaibing@huawei.com> Reviewed-by: Mauro Carvalho Chehab <mchehab@kernel.org> Reviewed-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- Documentation/process/code-of-conduct.rst | 4 ---- 1 file changed, 4 deletions(-) diff --git a/Documentation/process/code-of-conduct.rst b/Documentation/process/code-of-conduct.rst index ab7c24b5478c..a2641c19cf26 100644 --- a/Documentation/process/code-of-conduct.rst +++ b/Documentation/process/code-of-conduct.rst @@ -70,10 +70,6 @@ appropriate to the circumstances. The TAB is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately. -Maintainers who do not follow or enforce the Code of Conduct in good faith may -face temporary or permanent repercussions as determined by other members of the -project’s leadership. - Attribution =========== -- 2.19.1 ^ permalink raw reply related [flat|nested] 104+ messages in thread
* [PATCH 2/7] Code of Conduct Interpretation: Add document explaining how the Code of Conduct is to be interpreted 2018-10-20 13:49 [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document Greg Kroah-Hartman 2018-10-20 13:49 ` [PATCH 1/7] Code of conduct: Fix wording around maintainers enforcing the code of conduct Greg Kroah-Hartman @ 2018-10-20 13:50 ` Greg Kroah-Hartman 2018-10-20 13:50 ` [PATCH 3/7] Code of Conduct Interpretation: Properly reference the TAB correctly Greg Kroah-Hartman ` (6 subsequent siblings) 8 siblings, 0 replies; 104+ messages in thread From: Greg Kroah-Hartman @ 2018-10-20 13:50 UTC (permalink / raw) To: linux-kernel Cc: ksummit-discuss, Thomas Gleixner, Olof Johansson, Chris Mason, Mishi Choudhary The Contributor Covenant Code of Conduct is a general document meant to provide a set of rules for almost any open source community. Every open-source community is unique and the Linux kernel is no exception. Because of this, this document describes how we in the Linux kernel community will interpret it. We also do not expect this interpretation to be static over time, and will adjust it as needed. This document was created with the input and feedback of the TAB as well as many current kernel maintainers. Co-Developed-by: Thomas Gleixner <tglx@linutronix.de> Co-Developed-by: Olof Johansson <olof@lixom.net> Acked-by: Alex Deucher <alexander.deucher@amd.com> Acked-by: Alexei Starovoitov <ast@kernel.org> Acked-by: Amir Goldstein <amir73il@gmail.com> Acked-by: Andrew Morton <akpm@linux-foundation.org> Acked-by: Andy Lutomirski <luto@kernel.org> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Acked-by: Boris Brezillon <boris.brezillon@bootlin.com> Acked-by: Borislav Petkov <bp@kernel.org> Acked-by: Chris Mason <clm@fb.com> Acked-by: Christian Lütke-Stetzkamp <christian@lkamp.de> Acked-by: Colin Ian King <colin.king@canonical.com> Acked-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Dan Williams <dan.j.williams@intel.com> Acked-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Dave Airlie <airlied@redhat.com> Acked-by: Dave Hansen <dave.hansen@linux.intel.com> Acked-by: David Ahern <dsa@cumulusnetworks.com> Acked-by: David Sterba <kdave@kernel.org> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Acked-by: Eric Dumazet <eric.dumazet@gmail.com> Acked-by: Felipe Balbi <balbi@kernel.org> Acked-by: Felix Kuehling <Felix.Kuehling@amd.com> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> Acked-by: Gregory CLEMENT <gregory.clement@bootlin.com> Acked-by: Guenter Roeck <linux@roeck-us.net> Acked-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Acked-by: Hans Verkuil <hverkuil@xs4all.nl> Acked-by: Hans de Goede <j.w.r.degoede@gmail.com> Acked-by: Harry Wentland <harry.wentland@amd.com> Acked-by: Heiko Stuebner <heiko@sntech.de> Acked-by: Ingo Molnar <mingo@kernel.org> Acked-by: Jaegeuk Kim <jaegeuk@kernel.org> Acked-by: James Smart <james.smart@broadcom.com> Acked-by: James Smart <jsmart2021@gmail.com> Acked-by: Jan Kara <jack@ucw.cz> Acked-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Jason A. Donenfeld <Jason@zx2c4.com> Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Acked-by: Jens Axboe <axboe@kernel.dk> Acked-by: Jessica Yu <jeyu@kernel.org> Acked-by: Jia-Ju Bai <baijiaju1990@gmail.com> Acked-by: Jiri Kosina <jikos@kernel.org> Acked-by: Jiri Olsa <jolsa@redhat.com> Acked-by: Joerg Roedel <joro@8bytes.org> Acked-by: Johan Hovold <johan@kernel.org> Acked-by: Johannes Thumshirn <jth@kernel.org> Acked-by: Jonathan Corbet <corbet@lwn.net> Acked-by: Julia Lawall <julia.lawall@lip6.fr> Acked-by: Kees Cook <keescook@chromium.org> Acked-by: Kirill Tkhai <ktkhai@virtuozzo.com> Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Lina Iyer <ilina@codeaurora.org> Acked-by: Linus Torvalds <torvalds@linux-foundation.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Mark Brown <broonie@kernel.org> Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Masami Hiramatsu <mhiramat@kernel.org> Acked-by: Matias Bjørling <mb@lightnvm.io> Acked-by: Mauro Carvalho Chehab <mchehab@kernel.org> Acked-by: Maxime Ripard <maxime.ripard@bootlin.com> Acked-by: Michael Ellerman <mpe@ellerman.id.au> Acked-by: Mimi Zohar <zohar@linux.ibm.com> Acked-by: Miquel Raynal <miquel.raynal@bootlin.com> Acked-by: Mishi Choudhary <mishi@linux.com> Acked-by: Nikolay Borisov <n.borisov.lkml@gmail.com> Acked-by: Oded Gabbay <oded.gabbay@gmail.com> Acked-by: Palmer Dabbelt <palmer@dabbelt.com> Acked-by: Paul E. McKenney <paulmck@linux.ibm.com> Acked-by: Peter Zijlstra <peterz@infradead.org> Acked-by: Rafael J. Wysocki <rafael@kernel.org> Acked-by: Richard Weinberger <richard@nod.at> Acked-by: Rik van Riel <riel@surriel.com> Acked-by: Rob Clark <robdclark@gmail.com> Acked-by: Rob Herring <robh@kernel.org> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Sean Paul <sean@poorly.run> Acked-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Acked-by: Sebastian Reichel <sre@kernel.org> Acked-by: Sergio Paracuellos <sergio.paracuellos@gmail.com> Acked-by: Shawn Guo <shawnguo@kernel.org> Acked-by: Shuah Khan <shuah@kernel.org> Acked-by: Simon Horman <horms@verge.net.au> Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Acked-by: Stephen Hemminger <stephen@networkplumber.org> Acked-by: Takashi Iwai <tiwai@kernel.org> Acked-by: Tejun Heo <tj@kernel.org> Acked-by: Theodore Ts'o <tytso@mit.edu> Acked-by: Thierry Reding <thierry.reding@gmail.com> Acked-by: Todd Poynor <toddpoynor@google.com> Acked-by: Wei Yongjun <weiyongjun1@huawei.com> Acked-by: YueHaibing <yuehaibing@huawei.com> Reviewed-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Olof Johansson <olof@lixom.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- .../code-of-conduct-interpretation.rst | 153 ++++++++++++++++++ Documentation/process/index.rst | 1 + 2 files changed, 154 insertions(+) create mode 100644 Documentation/process/code-of-conduct-interpretation.rst diff --git a/Documentation/process/code-of-conduct-interpretation.rst b/Documentation/process/code-of-conduct-interpretation.rst new file mode 100644 index 000000000000..b14441711f7b --- /dev/null +++ b/Documentation/process/code-of-conduct-interpretation.rst @@ -0,0 +1,153 @@ +Linux Kernel Contributor Covenant Code of Conduct Interpretation +================================================================ + +The Contributor Covenant Code of Conduct is a general document meant to +provide a set of rules for almost any open source community. Every +open-source community is unique and the Linux kernel is no exception. +Because of this, this document describes how we in the Linux kernel +community will interpret it. We also do not expect this interpretation +to be static over time, and will adjust it as needed. + +The Linux kernel development effort is a very personal process compared +to "traditional" ways of developing software. Your contributions and +ideas behind them will be carefully reviewed, often resulting in +critique and criticism. The review will almost always require +improvements before the material can be included in the +kernel. Know that this happens because everyone involved wants to see +the best possible solution for the overall success of Linux. This +development process has been proven to create the most robust operating +system kernel ever, and we do not want to do anything to cause the +quality of submission and eventual result to ever decrease. + +Maintainers +----------- + +The Code of Conduct uses the term "maintainers" numerous times. In the +kernel community, a "maintainer" is anyone who is responsible for a +subsystem, driver, or file, and is listed in the MAINTAINERS file in the +kernel source tree. + +Responsibilities +---------------- + +The Code of Conduct mentions rights and responsibilities for +maintainers, and this needs some further clarifications. + +First and foremost, it is a reasonable expectation to have maintainers +lead by example. + +That being said, our community is vast and broad, and there is no new +requirement for maintainers to unilaterally handle how other people +behave in the parts of the community where they are active. That +responsibility is upon all of us, and ultimately the Code of Conduct +documents final escalation paths in case of unresolved concerns +regarding conduct issues. + +Maintainers should be willing to help when problems occur, and work with +others in the community when needed. Do not be afraid to reach out to +the TAB or other maintainers if you're uncertain how to handle +situations that come up. It will not be considered a violation report +unless you want it to be. If you are uncertain about approaching the +TAB or any other maintainers, please reach out to our conflict mediator, +Mishi Choudhary <mishi@linux.com>. + +In the end, "be kind to each other" is really what the end goal is for +everybody. We know everyone is human and we all fail at times, but the +primary goal for all of us should be to work toward amicable resolutions +of problems. Enforcement of the code of conduct will only be a last +resort option. + +Our goal of creating a robust and technically advanced operating system +and the technical complexity involved naturally require expertise and +decision-making. + +The required expertise varies depending on the area of contribution. It +is determined mainly by context and technical complexity and only +secondary by the expectations of contributors and maintainers. + +Both the expertise expectations and decision-making are subject to +discussion, but at the very end there is a basic necessity to be able to +make decisions in order to make progress. This prerogative is in the +hands of maintainers and project's leadership and is expected to be used +in good faith. + +As a consequence, setting expertise expectations, making decisions and +rejecting unsuitable contributions are not viewed as a violation of the +Code of Conduct. + +While maintainers are in general welcoming to newcomers, their capacity +of helping contributors overcome the entry hurdles is limited, so they +have to set priorities. This, also, is not to be seen as a violation of +the Code of Conduct. The kernel community is aware of that and provides +entry level programs in various forms like kernelnewbies.org. + +Scope +----- + +The Linux kernel community primarily interacts on a set of public email +lists distributed around a number of different servers controlled by a +number of different companies or individuals. All of these lists are +defined in the MAINTAINERS file in the kernel source tree. Any emails +sent to those mailing lists are considered covered by the Code of +Conduct. + +Developers who use the kernel.org bugzilla, and other subsystem bugzilla +or bug tracking tools should follow the guidelines of the Code of +Conduct. The Linux kernel community does not have an "official" project +email address, or "official" social media address. Any activity +performed using a kernel.org email account must follow the Code of +Conduct as published for kernel.org, just as any individual using a +corporate email account must follow the specific rules of that +corporation. + +The Code of Conduct does not prohibit continuing to include names, email +addresses, and associated comments in mailing list messages, kernel +change log messages, or code comments. + +Interaction in other forums is covered by whatever rules apply to said +forums and is in general not covered by the Code of Conduct. Exceptions +may be considered for extreme circumstances. + +Contributions submitted for the kernel should use appropriate language. +Content that already exists predating the Code of Conduct will not be +addressed now as a violation. Inappropriate language can be seen as a +bug, though; such bugs will be fixed more quickly if any interested +parties submit patches to that effect. Expressions that are currently +part of the user/kernel API, or reflect terminology used in published +standards or specifications, are not considered bugs. + +Enforcement +----------- + +The address listed in the Code of Conduct goes to the Code of Conduct +Committee. The exact members receiving these emails at any given time +are listed at <URL>. Members can not access reports made before they +joined or after they have left the committee. + +The initial Code of Conduct Committee consists of volunteer members of +the Technical Advisory Board (TAB), as well as a professional mediator +acting as a neutral third party. The first task of the committee is to +establish documented processes, which will be made public. + +Any member of the committee, including the mediator, can be contacted +directly if a reporter does not wish to include the full committee in a +complaint or concern. + +The Code of Conduct Committee reviews the cases according to the +processes (see above) and consults with the TAB as needed and +appropriate, for instance to request and receive information about the +kernel community. + +Any decisions by the committee will be brought to the TAB, for +implementation of enforcement with the relevant maintainers if needed. +A decision by the Code of Conduct Committee can be overturned by the TAB +by a two-thirds vote. + +At quarterly intervals, the Code of Conduct Committee and TAB will +provide a report summarizing the anonymised reports that the Code of +Conduct committee has received and their status, as well details of any +overridden decisions including complete and identifiable voting details. + +We expect to establish a different process for Code of Conduct Committee +staffing beyond the bootstrap period. This document will be updated +with that information when this occurs. diff --git a/Documentation/process/index.rst b/Documentation/process/index.rst index 9ae3e317bddf..42691e2880eb 100644 --- a/Documentation/process/index.rst +++ b/Documentation/process/index.rst @@ -21,6 +21,7 @@ Below are the essential guides that every developer should read. howto code-of-conduct + code-of-conduct-interpretation development-process submitting-patches coding-style -- 2.19.1 ^ permalink raw reply related [flat|nested] 104+ messages in thread
* [PATCH 3/7] Code of Conduct Interpretation: Properly reference the TAB correctly 2018-10-20 13:49 [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document Greg Kroah-Hartman 2018-10-20 13:49 ` [PATCH 1/7] Code of conduct: Fix wording around maintainers enforcing the code of conduct Greg Kroah-Hartman 2018-10-20 13:50 ` [PATCH 2/7] Code of Conduct Interpretation: Add document explaining how the Code of Conduct is to be interpreted Greg Kroah-Hartman @ 2018-10-20 13:50 ` Greg Kroah-Hartman 2018-10-20 13:50 ` [PATCH 4/7] Code of Conduct: Provide links between the two documents Greg Kroah-Hartman ` (5 subsequent siblings) 8 siblings, 0 replies; 104+ messages in thread From: Greg Kroah-Hartman @ 2018-10-20 13:50 UTC (permalink / raw) To: linux-kernel Cc: ksummit-discuss, Thomas Gleixner, Olof Johansson, Chris Mason, Mishi Choudhary We use the term "TAB" before defining it later in the document. Fix that up by defining it at the first location. Reported-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Acked-by: Chris Mason <clm@fb.com> Acked-by: Olof Johansson <olof@lixom.net> Acked-by: Theodore Ts'o <tytso@mit.edu> Acked-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- .../process/code-of-conduct-interpretation.rst | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/Documentation/process/code-of-conduct-interpretation.rst b/Documentation/process/code-of-conduct-interpretation.rst index b14441711f7b..ecf84cd29735 100644 --- a/Documentation/process/code-of-conduct-interpretation.rst +++ b/Documentation/process/code-of-conduct-interpretation.rst @@ -45,11 +45,11 @@ regarding conduct issues. Maintainers should be willing to help when problems occur, and work with others in the community when needed. Do not be afraid to reach out to -the TAB or other maintainers if you're uncertain how to handle -situations that come up. It will not be considered a violation report -unless you want it to be. If you are uncertain about approaching the -TAB or any other maintainers, please reach out to our conflict mediator, -Mishi Choudhary <mishi@linux.com>. +the Technical Advisory Board (TAB) or other maintainers if you're +uncertain how to handle situations that come up. It will not be +considered a violation report unless you want it to be. If you are +uncertain about approaching the TAB or any other maintainers, please +reach out to our conflict mediator, Mishi Choudhary <mishi@linux.com>. In the end, "be kind to each other" is really what the end goal is for everybody. We know everyone is human and we all fail at times, but the @@ -125,9 +125,9 @@ are listed at <URL>. Members can not access reports made before they joined or after they have left the committee. The initial Code of Conduct Committee consists of volunteer members of -the Technical Advisory Board (TAB), as well as a professional mediator -acting as a neutral third party. The first task of the committee is to -establish documented processes, which will be made public. +the TAB, as well as a professional mediator acting as a neutral third +party. The first task of the committee is to establish documented +processes, which will be made public. Any member of the committee, including the mediator, can be contacted directly if a reporter does not wish to include the full committee in a -- 2.19.1 ^ permalink raw reply related [flat|nested] 104+ messages in thread
* [PATCH 4/7] Code of Conduct: Provide links between the two documents 2018-10-20 13:49 [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document Greg Kroah-Hartman ` (2 preceding siblings ...) 2018-10-20 13:50 ` [PATCH 3/7] Code of Conduct Interpretation: Properly reference the TAB correctly Greg Kroah-Hartman @ 2018-10-20 13:50 ` Greg Kroah-Hartman 2018-10-20 13:50 ` [PATCH 5/7] Code of Conduct Interpretation: Put in the proper URL for the committee Greg Kroah-Hartman ` (4 subsequent siblings) 8 siblings, 0 replies; 104+ messages in thread From: Greg Kroah-Hartman @ 2018-10-20 13:50 UTC (permalink / raw) To: linux-kernel Cc: ksummit-discuss, Thomas Gleixner, Olof Johansson, Chris Mason, Mishi Choudhary Create a link between the Code of Conduct and the Code of Conduct Interpretation so that people can see that they are related. Acked-by: Chris Mason <clm@fb.com> Acked-by: Olof Johansson <olof@lixom.net> Acked-by: Theodore Ts'o <tytso@mit.edu> Acked-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- Documentation/process/code-of-conduct-interpretation.rst | 4 +++- Documentation/process/code-of-conduct.rst | 8 ++++++++ 2 files changed, 11 insertions(+), 1 deletion(-) diff --git a/Documentation/process/code-of-conduct-interpretation.rst b/Documentation/process/code-of-conduct-interpretation.rst index ecf84cd29735..4d4e2cc94b5e 100644 --- a/Documentation/process/code-of-conduct-interpretation.rst +++ b/Documentation/process/code-of-conduct-interpretation.rst @@ -1,7 +1,9 @@ +.. _code_of_conduct_interpretation: + Linux Kernel Contributor Covenant Code of Conduct Interpretation ================================================================ -The Contributor Covenant Code of Conduct is a general document meant to +The :ref:`code_of_conduct` is a general document meant to provide a set of rules for almost any open source community. Every open-source community is unique and the Linux kernel is no exception. Because of this, this document describes how we in the Linux kernel diff --git a/Documentation/process/code-of-conduct.rst b/Documentation/process/code-of-conduct.rst index a2641c19cf26..3046664c929e 100644 --- a/Documentation/process/code-of-conduct.rst +++ b/Documentation/process/code-of-conduct.rst @@ -1,3 +1,5 @@ +.. _code_of_conduct: + Contributor Covenant Code of Conduct ++++++++++++++++++++++++++++++++++++ @@ -75,3 +77,9 @@ Attribution This Code of Conduct is adapted from the Contributor Covenant, version 1.4, available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html + +Interpretation +============== + +See the :ref:`code_of_conduct_interpretation` document for how the Linux +kernel community will be interpreting this document. -- 2.19.1 ^ permalink raw reply related [flat|nested] 104+ messages in thread
* [PATCH 5/7] Code of Conduct Interpretation: Put in the proper URL for the committee 2018-10-20 13:49 [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document Greg Kroah-Hartman ` (3 preceding siblings ...) 2018-10-20 13:50 ` [PATCH 4/7] Code of Conduct: Provide links between the two documents Greg Kroah-Hartman @ 2018-10-20 13:50 ` Greg Kroah-Hartman 2018-10-20 19:01 ` Geert Uytterhoeven 2018-10-20 13:51 ` [PATCH 6/7] Code of Conduct: Change the contact email address Greg Kroah-Hartman ` (3 subsequent siblings) 8 siblings, 1 reply; 104+ messages in thread From: Greg Kroah-Hartman @ 2018-10-20 13:50 UTC (permalink / raw) To: linux-kernel Cc: ksummit-discuss, Thomas Gleixner, Olof Johansson, Chris Mason, Mishi Choudhary There was a blank <URL> reference for how to find the Code of Conduct Committee. Fix that up by pointing it to the correct kernel.org website page location. Acked-by: Chris Mason <clm@fb.com> Acked-by: Olof Johansson <olof@lixom.net> Acked-by: Theodore Ts'o <tytso@mit.edu> Acked-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- Documentation/process/code-of-conduct-interpretation.rst | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/Documentation/process/code-of-conduct-interpretation.rst b/Documentation/process/code-of-conduct-interpretation.rst index 4d4e2cc94b5e..e899f14a4ba2 100644 --- a/Documentation/process/code-of-conduct-interpretation.rst +++ b/Documentation/process/code-of-conduct-interpretation.rst @@ -123,8 +123,9 @@ Enforcement The address listed in the Code of Conduct goes to the Code of Conduct Committee. The exact members receiving these emails at any given time -are listed at <URL>. Members can not access reports made before they -joined or after they have left the committee. +are listed at https://kernel.org/code-of-conduct.html. Members can not +access reports made before they joined or after they have left the +committee. The initial Code of Conduct Committee consists of volunteer members of the TAB, as well as a professional mediator acting as a neutral third -- 2.19.1 ^ permalink raw reply related [flat|nested] 104+ messages in thread
* Re: [PATCH 5/7] Code of Conduct Interpretation: Put in the proper URL for the committee 2018-10-20 13:50 ` [PATCH 5/7] Code of Conduct Interpretation: Put in the proper URL for the committee Greg Kroah-Hartman @ 2018-10-20 19:01 ` Geert Uytterhoeven 2018-10-21 7:18 ` [Ksummit-discuss] " Greg KH 0 siblings, 1 reply; 104+ messages in thread From: Geert Uytterhoeven @ 2018-10-20 19:01 UTC (permalink / raw) To: Greg KH Cc: Linux Kernel Mailing List, ksummit-discuss, Thomas Gleixner, Olof Johansson, Chris Mason, mishi Hi Greg, On Sat, Oct 20, 2018 at 3:53 PM Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote: > There was a blank <URL> reference for how to find the Code of Conduct > Committee. Fix that up by pointing it to the correct kernel.org website > page location. > > Acked-by: Chris Mason <clm@fb.com> > Acked-by: Olof Johansson <olof@lixom.net> > Acked-by: Theodore Ts'o <tytso@mit.edu> > Acked-by: Thomas Gleixner <tglx@linutronix.de> > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Thanks for your patch! > --- a/Documentation/process/code-of-conduct-interpretation.rst > +++ b/Documentation/process/code-of-conduct-interpretation.rst > @@ -123,8 +123,9 @@ Enforcement > > The address listed in the Code of Conduct goes to the Code of Conduct > Committee. The exact members receiving these emails at any given time > -are listed at <URL>. Members can not access reports made before they > -joined or after they have left the committee. > +are listed at https://kernel.org/code-of-conduct.html. Members can not > +access reports made before they joined or after they have left the > +committee. This seems to be the wrong URL? It just points to the CoC, not to the TAB members. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Ksummit-discuss] [PATCH 5/7] Code of Conduct Interpretation: Put in the proper URL for the committee 2018-10-20 19:01 ` Geert Uytterhoeven @ 2018-10-21 7:18 ` Greg KH 0 siblings, 0 replies; 104+ messages in thread From: Greg KH @ 2018-10-21 7:18 UTC (permalink / raw) To: Geert Uytterhoeven; +Cc: ksummit-discuss, mishi, Linux Kernel Mailing List On Sat, Oct 20, 2018 at 09:01:57PM +0200, Geert Uytterhoeven wrote: > Hi Greg, > > On Sat, Oct 20, 2018 at 3:53 PM Greg Kroah-Hartman > <gregkh@linuxfoundation.org> wrote: > > There was a blank <URL> reference for how to find the Code of Conduct > > Committee. Fix that up by pointing it to the correct kernel.org website > > page location. > > > > Acked-by: Chris Mason <clm@fb.com> > > Acked-by: Olof Johansson <olof@lixom.net> > > Acked-by: Theodore Ts'o <tytso@mit.edu> > > Acked-by: Thomas Gleixner <tglx@linutronix.de> > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > > Thanks for your patch! > > > --- a/Documentation/process/code-of-conduct-interpretation.rst > > +++ b/Documentation/process/code-of-conduct-interpretation.rst > > @@ -123,8 +123,9 @@ Enforcement > > > > The address listed in the Code of Conduct goes to the Code of Conduct > > Committee. The exact members receiving these emails at any given time > > -are listed at <URL>. Members can not access reports made before they > > -joined or after they have left the committee. > > +are listed at https://kernel.org/code-of-conduct.html. Members can not > > +access reports made before they joined or after they have left the > > +committee. > > This seems to be the wrong URL? It just points to the CoC, not to the TAB > members. The information at that web page will be updatd "soon" with the information about the committee. Please give us a few more days for this, as we are all traveling at the moment... thanks, greg k-h ^ permalink raw reply [flat|nested] 104+ messages in thread
* [PATCH 6/7] Code of Conduct: Change the contact email address 2018-10-20 13:49 [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document Greg Kroah-Hartman ` (4 preceding siblings ...) 2018-10-20 13:50 ` [PATCH 5/7] Code of Conduct Interpretation: Put in the proper URL for the committee Greg Kroah-Hartman @ 2018-10-20 13:51 ` Greg Kroah-Hartman 2018-10-20 18:28 ` Alan Cox 2018-10-20 13:51 ` [PATCH 7/7] MAINTAINERS: Add an entry for the code of conduct Greg Kroah-Hartman ` (2 subsequent siblings) 8 siblings, 1 reply; 104+ messages in thread From: Greg Kroah-Hartman @ 2018-10-20 13:51 UTC (permalink / raw) To: linux-kernel Cc: ksummit-discuss, Thomas Gleixner, Olof Johansson, Chris Mason, Mishi Choudhary The contact point for the kernel's Code of Conduct should now be the Code of Conduct Committee, not the full TAB. Change the email address in the file to properly reflect this. Acked-by: Chris Mason <clm@fb.com> Acked-by: Olof Johansson <olof@lixom.net> Acked-by: Theodore Ts'o <tytso@mit.edu> Acked-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- Documentation/process/code-of-conduct.rst | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/Documentation/process/code-of-conduct.rst b/Documentation/process/code-of-conduct.rst index 3046664c929e..be50294aebd5 100644 --- a/Documentation/process/code-of-conduct.rst +++ b/Documentation/process/code-of-conduct.rst @@ -65,12 +65,13 @@ Enforcement =========== Instances of abusive, harassing, or otherwise unacceptable behavior may be -reported by contacting the Technical Advisory Board (TAB) at -<tab@lists.linux-foundation.org>. All complaints will be reviewed and -investigated and will result in a response that is deemed necessary and -appropriate to the circumstances. The TAB is obligated to maintain -confidentiality with regard to the reporter of an incident. Further details of -specific enforcement policies may be posted separately. +reported by contacting the Code of Conduct Committee at +<conduct@kernel.org>. All complaints will be reviewed and investigated +and will result in a response that is deemed necessary and appropriate +to the circumstances. The Code of Conduct Committee is obligated to +maintain confidentiality with regard to the reporter of an incident. +Further details of specific enforcement policies may be posted +separately. Attribution =========== -- 2.19.1 ^ permalink raw reply related [flat|nested] 104+ messages in thread
* Re: [PATCH 6/7] Code of Conduct: Change the contact email address 2018-10-20 13:51 ` [PATCH 6/7] Code of Conduct: Change the contact email address Greg Kroah-Hartman @ 2018-10-20 18:28 ` Alan Cox 2018-10-20 18:45 ` [Ksummit-discuss] " Trond Myklebust ` (2 more replies) 0 siblings, 3 replies; 104+ messages in thread From: Alan Cox @ 2018-10-20 18:28 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: linux-kernel, ksummit-discuss, Thomas Gleixner, Olof Johansson, Chris Mason, Mishi Choudhary > +to the circumstances. The Code of Conduct Committee is obligated to > +maintain confidentiality with regard to the reporter of an incident. > +Further details of specific enforcement policies may be posted > +separately. Unfortunately by ignoring the other suggestions on this you've left this bit broken. The committee can't keep most stuff confidential so it's misleading and wrong to imply they can. Data protection law, reporting laws in some countries and the like mean that anyone expecting an incident to remain confidential from the person it was reported against is living in dreamland and are going to get a nasty shock. At the very least it should say '(except where required by law)'. There is a separate issue that serious things should always go to law enforcement - you are setting up a policy akin to the one that got the catholic church and many others in trouble. You should also reserving the right to report serious incidents directly to law enforcement. Unless of course you want to be forced to sit on multiple reports of physical abuse from different people about someone - unable to tell them about each others report, unable to prove anything, and in twenty years time having to explain to the media why nothing was done. Alan ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Ksummit-discuss] [PATCH 6/7] Code of Conduct: Change the contact email address 2018-10-20 18:28 ` Alan Cox @ 2018-10-20 18:45 ` Trond Myklebust 2018-10-20 19:14 ` jonsmirl 2018-10-20 19:24 ` Tim.Bird 2018-10-20 20:13 ` James Bottomley 2 siblings, 1 reply; 104+ messages in thread From: Trond Myklebust @ 2018-10-20 18:45 UTC (permalink / raw) To: gnomes, gregkh; +Cc: mishi, ksummit-discuss, linux-kernel On Sat, 2018-10-20 at 19:28 +0100, Alan Cox wrote: > > +to the circumstances. The Code of Conduct Committee is obligated > > to > > +maintain confidentiality with regard to the reporter of an > > incident. > > +Further details of specific enforcement policies may be posted > > +separately. > > Unfortunately by ignoring the other suggestions on this you've left > this > bit broken. > > The committee can't keep most stuff confidential so it's misleading > and > wrong to imply they can. Data protection law, reporting laws in some > countries and the like mean that anyone expecting an incident to > remain > confidential from the person it was reported against is living in > dreamland and are going to get a nasty shock. > > At the very least it should say '(except where required by law)'. > > There is a separate issue that serious things should always go to law > enforcement - you are setting up a policy akin to the one that got > the > catholic church and many others in trouble. > > You should also reserving the right to report serious incidents > directly > to law enforcement. Unless of course you want to be forced to sit on > multiple reports of physical abuse from different people about > someone - unable to tell them about each others report, unable to > prove > anything, and in twenty years time having to explain to the media why > nothing was done. > ...and then you get into questions about how this committee will respond to queries from said law enforcement, and indeed to which legal systems the committee will or will not report incidents. Why would we want to be going down the path of trying to handle reports about "serious incidents" in the first place? That seems way out of scope for a code of conduct arbitration scheme. Even attempting to counsel people as to whether or not they should report incidents can get you in trouble in many parts of the world. -- Trond Myklebust Linux NFS client maintainer, Hammerspace trond.myklebust@hammerspace.com ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Ksummit-discuss] [PATCH 6/7] Code of Conduct: Change the contact email address 2018-10-20 18:45 ` [Ksummit-discuss] " Trond Myklebust @ 2018-10-20 19:14 ` jonsmirl 2018-10-21 8:27 ` Theodore Y. Ts'o 0 siblings, 1 reply; 104+ messages in thread From: jonsmirl @ 2018-10-20 19:14 UTC (permalink / raw) To: trondmy; +Cc: gnomes, Greg KH, mishi, ksummit-discuss, lkml On Sat, Oct 20, 2018 at 2:47 PM Trond Myklebust <trondmy@hammerspace.com> wrote: > > On Sat, 2018-10-20 at 19:28 +0100, Alan Cox wrote: > > > +to the circumstances. The Code of Conduct Committee is obligated > > > to > > > +maintain confidentiality with regard to the reporter of an > > > incident. > > > +Further details of specific enforcement policies may be posted > > > +separately. > > > > Unfortunately by ignoring the other suggestions on this you've left > > this > > bit broken. > > > > The committee can't keep most stuff confidential so it's misleading > > and > > wrong to imply they can. Data protection law, reporting laws in some > > countries and the like mean that anyone expecting an incident to > > remain > > confidential from the person it was reported against is living in > > dreamland and are going to get a nasty shock. > > > > At the very least it should say '(except where required by law)'. > > > > There is a separate issue that serious things should always go to law > > enforcement - you are setting up a policy akin to the one that got > > the > > catholic church and many others in trouble. > > > > You should also reserving the right to report serious incidents > > directly > > to law enforcement. Unless of course you want to be forced to sit on > > multiple reports of physical abuse from different people about > > someone - unable to tell them about each others report, unable to > > prove > > anything, and in twenty years time having to explain to the media why > > nothing was done. > > > > ...and then you get into questions about how this committee will > respond to queries from said law enforcement, and indeed to which legal > systems the committee will or will not report incidents. > > Why would we want to be going down the path of trying to handle reports > about "serious incidents" in the first place? That seems way out of > scope for a code of conduct arbitration scheme. Even attempting to > counsel people as to whether or not they should report incidents can > get you in trouble in many parts of the world. > Which is why the lawyers need to go over this document and I haven't seen anything posted from them. In the same vein Mauro is concerned that the way this is code is written it is a binding contract in Brazil. > -- > Trond Myklebust > Linux NFS client maintainer, Hammerspace > trond.myklebust@hammerspace.com > > -- Jon Smirl jonsmirl@gmail.com ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Ksummit-discuss] [PATCH 6/7] Code of Conduct: Change the contact email address 2018-10-20 19:14 ` jonsmirl @ 2018-10-21 8:27 ` Theodore Y. Ts'o 2018-10-21 9:23 ` Greg KH 0 siblings, 1 reply; 104+ messages in thread From: Theodore Y. Ts'o @ 2018-10-21 8:27 UTC (permalink / raw) To: jonsmirl; +Cc: trondmy, gnomes, Greg KH, mishi, ksummit-discuss, lkml On Sat, Oct 20, 2018 at 03:14:20PM -0400, jonsmirl@gmail.com wrote: > > Which is why the lawyers need to go over this document and I haven't > seen anything posted from them. In the same vein Mauro is concerned > that the way this is code is written it is a binding contract in > Brazil. My understanding is that lawyers from the Linux Foundation have gone over both the CoC and as well as the changes in this patchset, and that this happened before they were sent out. - Ted ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Ksummit-discuss] [PATCH 6/7] Code of Conduct: Change the contact email address 2018-10-21 8:27 ` Theodore Y. Ts'o @ 2018-10-21 9:23 ` Greg KH 0 siblings, 0 replies; 104+ messages in thread From: Greg KH @ 2018-10-21 9:23 UTC (permalink / raw) To: Theodore Y. Ts'o Cc: jonsmirl, trondmy, gnomes, mishi, ksummit-discuss, lkml On Sun, Oct 21, 2018 at 04:27:57AM -0400, Theodore Y. Ts'o wrote: > On Sat, Oct 20, 2018 at 03:14:20PM -0400, jonsmirl@gmail.com wrote: > > > > Which is why the lawyers need to go over this document and I haven't > > seen anything posted from them. In the same vein Mauro is concerned > > that the way this is code is written it is a binding contract in > > Brazil. > > My understanding is that lawyers from the Linux Foundation have gone > over both the CoC and as well as the changes in this patchset, and > that this happened before they were sent out. That is correct. ^ permalink raw reply [flat|nested] 104+ messages in thread
* RE: [Ksummit-discuss] [PATCH 6/7] Code of Conduct: Change the contact email address 2018-10-20 18:28 ` Alan Cox 2018-10-20 18:45 ` [Ksummit-discuss] " Trond Myklebust @ 2018-10-20 19:24 ` Tim.Bird 2018-10-20 20:07 ` Trond Myklebust 2018-10-21 0:13 ` Alan Cox 2018-10-20 20:13 ` James Bottomley 2 siblings, 2 replies; 104+ messages in thread From: Tim.Bird @ 2018-10-20 19:24 UTC (permalink / raw) To: gnomes, gregkh; +Cc: ksummit-discuss, mishi, linux-kernel > -----Original Message----- > From: Alan Cox > > > +to the circumstances. The Code of Conduct Committee is obligated to > > +maintain confidentiality with regard to the reporter of an incident. > > +Further details of specific enforcement policies may be posted > > +separately. > > Unfortunately by ignoring the other suggestions on this you've left this > bit broken. > > The committee can't keep most stuff confidential so it's misleading and > wrong to imply they can. I disagree with this assessment. We have managed to keep most stuff confidential to the general public in the past, to the point where it has been argued that the TAB have not been transparent enough. We're trying to address that issue with the section about quarterly anonymized reports. > Data protection law, reporting laws in some > countries and the like mean that anyone expecting an incident to remain > confidential from the person it was reported against is living in > dreamland and are going to get a nasty shock. OK - you seem to be talking about keeping the incident and reporter confidential from the person reported against. Certainly the person reported against has to have the incident identified to them, so that part is not confidential. Many legal jurisdictions require that the accused can know their accuser. But these things come into play mostly when items have veered into legal territory. Most violation reports are not in the territory. There's no legal requirement that the Code of Conduct committee tell someone who it was that said they were rude on the mailing list. > At the very least it should say '(except where required by law)'. That might be a good to add. It would be helpful, IMHO, to re-visit the patch that's been floating around and see if it can be added on top of this. > There is a separate issue that serious things should always go to law > enforcement - you are setting up a policy akin to the one that got the > catholic church and many others in trouble. > > You should also reserving the right to report serious incidents directly > to law enforcement. Unless of course you want to be forced to sit on > multiple reports of physical abuse from different people about > someone - unable to tell them about each others report, unable to prove > anything, and in twenty years time having to explain to the media why > nothing was done. The scope of the code of conduct basically means that it covers online interactions (communication via mailing list, git commits and Bugzilla). Not to be flippant, but those are hardly mediums that are susceptible to executing physical abuse. Also, they are all mediums that leave a persistent, public trail. So I don't think the comparison is very apt here. -- Tim ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Ksummit-discuss] [PATCH 6/7] Code of Conduct: Change the contact email address 2018-10-20 19:24 ` Tim.Bird @ 2018-10-20 20:07 ` Trond Myklebust 2018-10-21 0:13 ` Alan Cox 1 sibling, 0 replies; 104+ messages in thread From: Trond Myklebust @ 2018-10-20 20:07 UTC (permalink / raw) To: gnomes, gregkh, Tim.Bird; +Cc: mishi, linux-kernel, ksummit-discuss On Sat, 2018-10-20 at 19:24 +0000, Tim.Bird@sony.com wrote: > The scope of the code of conduct basically means that it covers > online interactions (communication via mailing list, git commits > and Bugzilla). Not to be flippant, but those are hardly mediums > that are susceptible to executing physical abuse. Also, they are > all mediums that leave a persistent, public trail. So I don't think > the > comparison is very apt here. > -- Tim If that is the case, then why does this need to go into the Linux kernel in the first place? The mailing lists, the kernel.org git repository, and bugzilla presumably all have "terms of use" pages that could specify the expected behaviour very explicitly, and could specify how arbitration works as part of those terms of use (and if enforcement is required, then it could specify legal venues etc). IOW: if the scope is just communication online, then I would think there are better tools for that. Putting a code of conduct into the kernel code itself wants to be justified by more than just regulating online behaviour. -- Trond Myklebust Linux NFS client maintainer, Hammerspace trond.myklebust@hammerspace.com ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Ksummit-discuss] [PATCH 6/7] Code of Conduct: Change the contact email address 2018-10-20 19:24 ` Tim.Bird 2018-10-20 20:07 ` Trond Myklebust @ 2018-10-21 0:13 ` Alan Cox 2018-10-21 6:19 ` Thomas Gleixner 1 sibling, 1 reply; 104+ messages in thread From: Alan Cox @ 2018-10-21 0:13 UTC (permalink / raw) To: Tim.Bird; +Cc: gregkh, ksummit-discuss, mishi, linux-kernel > > Data protection law, reporting laws in some > > countries and the like mean that anyone expecting an incident to remain > > confidential from the person it was reported against is living in > > dreamland and are going to get a nasty shock. > > OK - you seem to be talking about keeping the incident and reporter > confidential from the person reported against. > Certainly the person reported against has to have the incident > identified to them, so that part is not confidential. Many legal > jurisdictions require that the accused can know their accuser. > But these things come into play mostly when items have veered > into legal territory. Most violation reports are not in the territory. > There's no legal requirement that the Code of Conduct committee > tell someone who it was that said they were rude on the mailing list. The 'who said' is generally safe (except from the it's in court case - which is fine when that happens the legal process deals with it). The other details are not so while someone accused of something might not know who said it they can ask for what personal data (which would include that email with names etc scrubbed). You can possibly fight that in court of course, if you've got lots of money and nothing better to do for six weeks. > > You should also reserving the right to report serious incidents directly > > to law enforcement. Unless of course you want to be forced to sit on > > multiple reports of physical abuse from different people about > > someone - unable to tell them about each others report, unable to prove > > anything, and in twenty years time having to explain to the media why > > nothing was done. > > The scope of the code of conduct basically means that it covers > online interactions (communication via mailing list, git commits > and Bugzilla). I don't see it specifically stating that 'If someone is offensive at a kernel summit we are going to refuse to listen' Seriously ? Alan ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Ksummit-discuss] [PATCH 6/7] Code of Conduct: Change the contact email address 2018-10-21 0:13 ` Alan Cox @ 2018-10-21 6:19 ` Thomas Gleixner 0 siblings, 0 replies; 104+ messages in thread From: Thomas Gleixner @ 2018-10-21 6:19 UTC (permalink / raw) To: Alan Cox; +Cc: Tim.Bird, gregkh, ksummit-discuss, mishi, linux-kernel On Sun, 21 Oct 2018, Alan Cox wrote: > > I don't see it specifically stating that 'If someone is offensive at a > kernel summit we are going to refuse to listen' Kernel summit or Maintainer summit is covered by the CoC of the conference it is attached to. Thanks, tglx ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Ksummit-discuss] [PATCH 6/7] Code of Conduct: Change the contact email address 2018-10-20 18:28 ` Alan Cox 2018-10-20 18:45 ` [Ksummit-discuss] " Trond Myklebust 2018-10-20 19:24 ` Tim.Bird @ 2018-10-20 20:13 ` James Bottomley 2 siblings, 0 replies; 104+ messages in thread From: James Bottomley @ 2018-10-20 20:13 UTC (permalink / raw) To: Alan Cox, Greg Kroah-Hartman Cc: ksummit-discuss, Mishi Choudhary, linux-kernel On Sat, 2018-10-20 at 19:28 +0100, Alan Cox wrote: > > +to the circumstances. The Code of Conduct Committee is obligated > > to > > +maintain confidentiality with regard to the reporter of an > > incident. > > +Further details of specific enforcement policies may be posted > > +separately. > > Unfortunately by ignoring the other suggestions on this you've left > this bit broken. > > The committee can't keep most stuff confidential so it's misleading > and wrong to imply they can. Data protection law, reporting laws in > some countries and the like mean that anyone expecting an incident to > remain confidential from the person it was reported against is living > in dreamland and are going to get a nasty shock. > > At the very least it should say '(except where required by law)'. I've got a solution for this: the patches I've been curating also modify the section so the merger will look like what I have below. The intent of the series I'm curating was only the beginning to show desire to change in 4.19 but to correct the obvious defect before we started the debate, so after suitable discussion, this one can be the final set. > There is a separate issue that serious things should always go to law > enforcement - you are setting up a policy akin to the one that got > the catholic church and many others in trouble. > > You should also reserving the right to report serious incidents > directly to law enforcement. Unless of course you want to be forced > to sit on multiple reports of physical abuse from different people > about someone - unable to tell them about each others report, unable > to prove anything, and in twenty years time having to explain to the > media why nothing was done. I think we should debate that. Most legal systems provide significant deference to victims wishing for confidentiality and we should both respect that and remember that an automatic crime report is a significant deterrent to vulnerable people in a lot of places. James --- diff --git a/Documentation/process/code-of-conduct.rst b/Documentation/process/code-of-conduct.rst index eec768471a4d..8913851dab89 100644 --- a/Documentation/process/code-of-conduct.rst +++ b/Documentation/process/code-of-conduct.rst @@ -59,19 +59,27 @@ address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers. -Reporting -========= +Enforcement +=========== Instances of abusive, harassing, or otherwise unacceptable behavior may be -reported by contacting the Technical Advisory Board (TAB) at -<tab@lists.linux-foundation.org>. All complaints will be reviewed and -investigated and will result in a response that is deemed necessary and -appropriate to the circumstances. The TAB is obligated to maintain -confidentiality with regard to the reporter of an incident (except where -required by law). +reported by contacting the Code of Conduct Committee at +<conduct@kernel.org>. All complaints will be reviewed and investigated +and will result in a response that is deemed necessary and appropriate +to the circumstances. The Code of Conduct Committee is obligated to +maintain confidentiality with regard to the reporter of an incident +(except where required by law). Further details of specific enforcement +policies may be posted separately. + Attribution =========== This Code of Conduct is adapted from the Contributor Covenant, version 1.4, available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html + +Interpretation +============== + +See the :ref:`code_of_conduct_interpretation` document for how the Linux +kernel community will be interpreting this document. ^ permalink raw reply related [flat|nested] 104+ messages in thread
* [PATCH 7/7] MAINTAINERS: Add an entry for the code of conduct 2018-10-20 13:49 [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document Greg Kroah-Hartman ` (5 preceding siblings ...) 2018-10-20 13:51 ` [PATCH 6/7] Code of Conduct: Change the contact email address Greg Kroah-Hartman @ 2018-10-20 13:51 ` Greg Kroah-Hartman 2018-10-21 21:20 ` Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document NeilBrown 2018-10-21 23:36 ` Eric S. Raymond 8 siblings, 0 replies; 104+ messages in thread From: Greg Kroah-Hartman @ 2018-10-20 13:51 UTC (permalink / raw) To: linux-kernel Cc: ksummit-discuss, Thomas Gleixner, Olof Johansson, Chris Mason, Mishi Choudhary As I introduced these files, I'm willing to be the maintainer of them as well. Acked-by: Chris Mason <clm@fb.com> Acked-by: Olof Johansson <olof@lixom.net> Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org> Acked-by: Theodore Ts'o <tytso@mit.edu> Acked-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- MAINTAINERS | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 7f371d372bdd..21faaf4c6161 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3673,6 +3673,12 @@ S: Maintained F: Documentation/devicetree/bindings/media/coda.txt F: drivers/media/platform/coda/ +CODE OF CONDUCT +M: Greg Kroah-Hartman <gregkh@linuxfoundation.org> +S: Supported +F: Documentation/process/code-of-conduct.rst +F: Documentation/process/code-of-conduct-interpretation.rst + COMMON CLK FRAMEWORK M: Michael Turquette <mturquette@baylibre.com> M: Stephen Boyd <sboyd@kernel.org> -- 2.19.1 ^ permalink raw reply related [flat|nested] 104+ messages in thread
* Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document 2018-10-20 13:49 [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document Greg Kroah-Hartman ` (6 preceding siblings ...) 2018-10-20 13:51 ` [PATCH 7/7] MAINTAINERS: Add an entry for the code of conduct Greg Kroah-Hartman @ 2018-10-21 21:20 ` NeilBrown 2018-10-21 22:26 ` [Ksummit-discuss] " Josh Triplett ` (6 more replies) 2018-10-21 23:36 ` Eric S. Raymond 8 siblings, 7 replies; 104+ messages in thread From: NeilBrown @ 2018-10-21 21:20 UTC (permalink / raw) To: Greg Kroah-Hartman, linux-kernel, Linus Torvalds Cc: ksummit-discuss, Thomas Gleixner, Olof Johansson, Chris Mason, Mishi Choudhary [-- Attachment #1: Type: text/plain, Size: 2996 bytes --] On Sat, Oct 20 2018, Greg Kroah-Hartman wrote: > Hi all, > > As everyone knows by now, we added a new Code of Conduct to the kernel > tree a few weeks ago. I wanted to stay detached from all this, but as remaining (publicly) silent might be seen (publicly) as acquiescing, I hereby declare that: I reject, as illegitimate, this Code and the process by which it is being "developed". It is clear from the surrounding discussions that this is well outside our core competencies. It will be flawed, it isn't what we need. I call on any other community members who reject this process to say so, not to remain silent. #Iobject We don't need a "Code of Conduct" nearly as much as we need "Leadership in conduct". Without the leadership, any code looks like a joke. I call on Linus Torvalds to follow up on his confession (which I think is momentous and worth celebrating - Hurray!!!) with repentance - a clear demonstration of change of mind. Linus: I know your intentions are good and am confident that, now that you see the problem, you will be able to effect a solution. If you are not so confident, please be aware that there are many in the community who can see clearly where you were blind, and are willing to help guide and coach. Please reach out to someone you trust, and ask. I call on the community to respond to this confession and repentance from Linus with forgiveness and restoration. I have no direct hurts to report and little to forgive, so my forgiveness can only be worth little. However, for what it is worth: I offer to Linus, and to any who are seeking to improve their behaviour, my forgiveness for any past hurts, whether direct or indirect. I hold no grudge, and wish to continue working together as the need and opportunity arises. #Iforgive I call on the community to effect whatever reparation is possible to those who have been hurt. Sometimes an apology is all that is possible, sometimes it is all that is needed. If you are ever in a position to do more, please consider doing so. On behalf of my community, I apologise to all those who have been hurt by us, for the lack of respect and care which should have been shown. Where I have hurt you, whether through action or inaction, I unreservedly apologise. #Iapologise (or #Iapologize :-) 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 #Isupportreversion I call on the community to consider what *does* need to be said, about conduct, to people outside the community and who have recently joined. What is the document that you would have liked to have read as you were starting out? It is all too long ago for me to remember clearly, and so much has changed. Thanks, NeilBrown #Iobject #Iforgive #Iapologise #Isupportreversion [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 832 bytes --] ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Ksummit-discuss] Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document 2018-10-21 21:20 ` Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document NeilBrown @ 2018-10-21 22:26 ` Josh Triplett 2018-10-21 23:37 ` Theodore Y. Ts'o 2018-10-22 20:26 ` NeilBrown 2018-10-21 22:33 ` Joe Perches ` (5 subsequent siblings) 6 siblings, 2 replies; 104+ messages in thread From: Josh Triplett @ 2018-10-21 22:26 UTC (permalink / raw) To: NeilBrown Cc: Greg Kroah-Hartman, linux-kernel, Linus Torvalds, ksummit-discuss, Mishi Choudhary 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 > > #Isupportreversion > > I call on the community to consider what *does* need to be said, about > conduct, to people outside the community and who have recently joined. > What is the document that you would have liked to have read as you were > starting out? It is all too long ago for me to remember clearly, and so > much has changed. The document I would have liked to have read when starting out is currently checked into the source tree in Documentation/process/code-of-conduct.rst . What is your actual concern? Why does it matter so much to you to push back against this code of conduct? What does it say that you so fundamentally object to? (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.) ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Ksummit-discuss] Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document 2018-10-21 22:26 ` [Ksummit-discuss] " Josh Triplett @ 2018-10-21 23:37 ` Theodore Y. Ts'o 2018-10-23 1:44 ` NeilBrown 2018-10-22 20:26 ` NeilBrown 1 sibling, 1 reply; 104+ messages in thread From: Theodore Y. Ts'o @ 2018-10-21 23:37 UTC (permalink / raw) To: Josh Triplett Cc: NeilBrown, Mishi Choudhary, Greg Kroah-Hartman, linux-kernel, ksummit-discuss 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 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 ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Ksummit-discuss] Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document 2018-10-21 23:37 ` Theodore Y. Ts'o @ 2018-10-23 1:44 ` NeilBrown 0 siblings, 0 replies; 104+ messages in thread From: NeilBrown @ 2018-10-23 1:44 UTC (permalink / raw) To: Theodore Y. Ts'o, Josh Triplett Cc: Mishi Choudhary, Greg Kroah-Hartman, linux-kernel, ksummit-discuss [-- Attachment #1: Type: text/plain, Size: 4713 bytes --] 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 [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 832 bytes --] ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Ksummit-discuss] Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document 2018-10-21 22:26 ` [Ksummit-discuss] " Josh Triplett 2018-10-21 23:37 ` Theodore Y. Ts'o @ 2018-10-22 20:26 ` NeilBrown 2018-10-22 22:46 ` Theodore Y. Ts'o ` (2 more replies) 1 sibling, 3 replies; 104+ messages in thread From: NeilBrown @ 2018-10-22 20:26 UTC (permalink / raw) To: Josh Triplett Cc: Greg Kroah-Hartman, linux-kernel, Linus Torvalds, ksummit-discuss, Mishi Choudhary [-- Attachment #1: Type: text/plain, Size: 6345 bytes --] On Sun, Oct 21 2018, 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 >> >> #Isupportreversion >> >> I call on the community to consider what *does* need to be said, about >> conduct, to people outside the community and who have recently joined. >> What is the document that you would have liked to have read as you were >> starting out? It is all too long ago for me to remember clearly, and so >> much has changed. > > The document I would have liked to have read when starting out is > currently checked into the source tree in > Documentation/process/code-of-conduct.rst . I'm curious - what would you have gained by reading that document? > > What is your actual concern? Why does it matter so much to you to push > back against this code of conduct? What does it say that you so > fundamentally object to? Thank you for asking. The discipline of focusing on an answer to this question (rather than being distracted by all the different things that are wrong here) has helped me to clarify my thoughts very nicely. The current document is upside down. The whole point of any document like this is to curtail, bypass, or redirect the power of the powerful (and thanks to Dave[1] for the "power" frame). We already have plenty of process documents which attempt to give power to the weak by explaining how they can be heard. While those documents might have room for improvement in this process, this document is quite different - it aims to take power away. The power that the current document describes is the power of having a platform on which to speak - through a wiki, through comments, through code etc. It talks about maintainers curtailing that power when it is misused. I argue that regular "participants" in the kernel community have virtually no power. The only "platforms" for speech are lkml (and other lists) and bugzilla. lkml is a cacophony (even Mozart would sound terrible if we played all his works at once!) and bugzilla is a ghost town. Neither provide a platform where any central control is needed. Every subscriber already filters content themselves, whether by unsubscribing, just skimming subject lines, or with more automated assistance (and that is not something the community can control, whether it wants to or not). The only strength that participants have is the value of their contribution, and this is only turned into power when they are listened to. On the other end of the spectrum, Linus has all the power. Patches are the currency of the realm and all power (popularity, voice, voting rights) flow from them. Linus ultimately controls patches and has ultimate power (almost - see below) In between are maintainers - they received power from Linus through lines of trust, and sometimes pass it on through other lines of trust - to sub-maintainers and valued contributors. They also (noblesse oblige) give some power to the poor who they don't know - accepting bug reports, giving advice, reviewing patches. Given the power structure, the document we should be modeling our thoughts on is the Magna Carte, where the British barons demanded that the King's power be curtailed. We don't need a document where the maintainers tell the participants how they must behave, but we might need one where the maintainers tell Linus how to behave. As I said, the current document is upside down. I would hope that Linus would provide Magna Carte himself, but maybe he isn't up to it. In which case, our job is to draft a document for Linus to agree to abide by. He might want to then make changes, and that is *perfect* *fine*. It is *his* statement to the community on how *he* will use the power he has - after all, it is ultimately the whole community (well beyond developers) who give Linus the power he has by valuing the product he produces (just as farmers ultimately give power to the king by putting food on his table to feed him and his soldiers). Once Linus has adopted such a document, we can look to other maintainers to follow suite. They might choose to use the same document, or to write something completely different. In either case, it puts their stance clearly on the table. People who find the need to work with them can have clear expectations, and can decide on the best approach, and whether it is worth the effort at all. In parallel with these promises (willingly adopted, not imposed), we need clear processes for people to follow if they cannot work with a maintainer, either because the promise doesn't make them feel safe enough, or because the maintainer violates their own promise. This isn't about enforcement and repercussions and punishment exactly. This is about economics - keeping the patches moving. If, for example, Linus or Andrew said "if you cannot work with any given maintainer, I will consider your patch directly, but you need to point to where you tried, and why you failed - or to where the promise is inadequate". Currently if a maintainer is rude to you, there is no where else that you can go and *that* is why it hurts. It isn't the abuse so much as the powerlessness associated with it. If you can (metaphorically) say to that maintainer "I don't care about your toilet mouth, you've just given me the right to take my petition to caesar" - then the emotional response will be quite different to pain. If Linus is not true to his new-found sensitivity, we might need someone (Greg?) to be a co-maintainer, able to accept patches when Linus has a relapse. It might be good form to create this channel anyway, but I doubt it would be needed in practice. So there you have it. The "Code" is upside down. We need documents which: - curtail the power of the strong, starting with Linus - are adopted willingly by individuals, not imposed on the community. - provide alternate routes for patch-flow, so that no-one has ultimate power. Thanks, NeilBrown #Iobject #Iforgive #Iapologize #Isupportreversion [1] just a random "Dave" [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 832 bytes --] ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Ksummit-discuss] Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document 2018-10-22 20:26 ` NeilBrown @ 2018-10-22 22:46 ` Theodore Y. Ts'o 2018-10-23 1:31 ` NeilBrown 2018-10-23 6:26 ` Dan Carpenter 2018-10-23 3:31 ` Al Viro 2018-10-24 12:16 ` Josh Triplett 2 siblings, 2 replies; 104+ messages in thread From: Theodore Y. Ts'o @ 2018-10-22 22:46 UTC (permalink / raw) To: NeilBrown Cc: Josh Triplett, Mishi Choudhary, Greg Kroah-Hartman, linux-kernel, ksummit-discuss Neil, I disagree with your framing, and thus your analysis, and thus your proposed solution. On Tue, Oct 23, 2018 at 07:26:06AM +1100, NeilBrown wrote: > If, for example, Linus or Andrew said "if you cannot work with any given > maintainer, I will consider your patch directly, but you need to point > to where you tried, and why you failed - or to where the promise is > inadequate". > > Currently if a maintainer is rude to you, there is no where else that > you can go and *that* is why it hurts. It isn't the abuse so much as > the powerlessness associated with it. If you can (metaphorically) say > to that maintainer "I don't care about your toilet mouth, you've just > given me the right to take my petition to caesar" - then the emotional > response will be quite different to pain. No. That's just not how things work. Patches don't get rejected because maintainers are being rude. Patches don't get accepted because they are not of a sufficiently high technical quality. And if you spam a maintainer with bad quality patches, and they tell you what you should do to make them better, and you actively ignore requests about how to write better code[1], it is perfectly acceptable for maintainers to decide to ignore said bad patch committer. Putting bad patch commiters on a blacklist is not a CoC violation. [1] And no, this is not a hypothetical example. This particular kernel newcomer continually spammed maintainers with patches that wouldn't even compile, and were clearly never tested. And when the newcomer started giving bad advice to users reporting bugs, he ultimately got banned from LKML... After all, we all want to make the kernel to be better. So if someone submits good quality code, Maintainers are going to want that code to improve their subsystem. Thinking that people want to go off on power trips by rejecting perfectly sound code is a complete misdiagnosis of the problem. - Ted ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Ksummit-discuss] Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document 2018-10-22 22:46 ` Theodore Y. Ts'o @ 2018-10-23 1:31 ` NeilBrown 2018-10-23 6:26 ` Dan Carpenter 1 sibling, 0 replies; 104+ messages in thread From: NeilBrown @ 2018-10-23 1:31 UTC (permalink / raw) To: Theodore Y. Ts'o Cc: Josh Triplett, Mishi Choudhary, Greg Kroah-Hartman, linux-kernel, ksummit-discuss [-- Attachment #1: Type: text/plain, Size: 1277 bytes --] On Mon, Oct 22 2018, Theodore Y. Ts'o wrote: > Neil, > > I disagree with your framing, and thus your analysis, and thus your > proposed solution. > > On Tue, Oct 23, 2018 at 07:26:06AM +1100, NeilBrown wrote: >> If, for example, Linus or Andrew said "if you cannot work with any given >> maintainer, I will consider your patch directly, but you need to point >> to where you tried, and why you failed - or to where the promise is >> inadequate". >> >> Currently if a maintainer is rude to you, there is no where else that >> you can go and *that* is why it hurts. It isn't the abuse so much as >> the powerlessness associated with it. If you can (metaphorically) say >> to that maintainer "I don't care about your toilet mouth, you've just >> given me the right to take my petition to caesar" - then the emotional >> response will be quite different to pain. > > No. That's just not how things work. Patches don't get rejected > because maintainers are being rude. Correct. Patches don't get *posted* because maintainers are rude. They don't get accepted because they weren't posted. Do you disagree with my claim that the main cause of hurt is powerlessness? Without that, we may as well be on different planets. Thanks, NeilBrown [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 832 bytes --] ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Ksummit-discuss] Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document 2018-10-22 22:46 ` Theodore Y. Ts'o 2018-10-23 1:31 ` NeilBrown @ 2018-10-23 6:26 ` Dan Carpenter 2018-10-23 6:40 ` Al Viro 1 sibling, 1 reply; 104+ messages in thread From: Dan Carpenter @ 2018-10-23 6:26 UTC (permalink / raw) To: Theodore Y. Ts'o, NeilBrown, Josh Triplett, Mishi Choudhary, Greg Kroah-Hartman, linux-kernel, ksummit-discuss On Mon, Oct 22, 2018 at 06:46:04PM -0400, Theodore Y. Ts'o wrote: > Neil, > > I disagree with your framing, and thus your analysis, and thus your > proposed solution. > > On Tue, Oct 23, 2018 at 07:26:06AM +1100, NeilBrown wrote: > > If, for example, Linus or Andrew said "if you cannot work with any given > > maintainer, I will consider your patch directly, but you need to point > > to where you tried, and why you failed - or to where the promise is > > inadequate". > > > > Currently if a maintainer is rude to you, there is no where else that > > you can go and *that* is why it hurts. It isn't the abuse so much as > > the powerlessness associated with it. If you can (metaphorically) say > > to that maintainer "I don't care about your toilet mouth, you've just > > given me the right to take my petition to caesar" - then the emotional > > response will be quite different to pain. > > No. That's just not how things work. Patches don't get rejected > because maintainers are being rude. Patches don't get accepted > because they are not of a sufficiently high technical quality. I once sent a bugfix and instead of applying it, the maintainer insulted me and rejected it because the subject wasn't in imperative tense and because I said "NULL dereference" instead of "NULL pointer dereference." Ten years back there was a patch rejected because "F*** you, what do women know about programming?" I can't imagine it happening now, but I was so shocked by it at the time also... regards, dan carpenter ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Ksummit-discuss] Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document 2018-10-23 6:26 ` Dan Carpenter @ 2018-10-23 6:40 ` Al Viro 2018-10-23 6:46 ` Dan Carpenter 0 siblings, 1 reply; 104+ messages in thread From: Al Viro @ 2018-10-23 6:40 UTC (permalink / raw) To: Dan Carpenter Cc: Theodore Y. Ts'o, NeilBrown, Josh Triplett, Mishi Choudhary, Greg Kroah-Hartman, linux-kernel, ksummit-discuss On Tue, Oct 23, 2018 at 09:26:52AM +0300, Dan Carpenter wrote: > Ten years back there was a patch rejected because "F*** you, what do > women know about programming?" I can't imagine it happening now, but I > was so shocked by it at the time also... URL? I would really, honestly, no kidding, like to know who had that been (and where had that been, while we are at it). I would expect a massive (and absolutely deserved) shitstorm if that was on any public kernel-related lists 10 years ago, but I'm not reading all of them, obviously... ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Ksummit-discuss] Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document 2018-10-23 6:40 ` Al Viro @ 2018-10-23 6:46 ` Dan Carpenter 0 siblings, 0 replies; 104+ messages in thread From: Dan Carpenter @ 2018-10-23 6:46 UTC (permalink / raw) To: Al Viro Cc: ksummit-discuss, Mishi Choudhary, Greg Kroah-Hartman, linux-kernel, NeilBrown On Tue, Oct 23, 2018 at 07:40:51AM +0100, Al Viro wrote: > On Tue, Oct 23, 2018 at 09:26:52AM +0300, Dan Carpenter wrote: > > > Ten years back there was a patch rejected because "F*** you, what do > > women know about programming?" I can't imagine it happening now, but I > > was so shocked by it at the time also... > > URL? I would really, honestly, no kidding, like to know who had that > been (and where had that been, while we are at it). I would expect > a massive (and absolutely deserved) shitstorm if that was on any > public kernel-related lists 10 years ago, but I'm not reading all > of them, obviously... It was a private email and I don't know who the maintainer was. But I heard about it from the woman at a Linux conference and she was a competent programmer and the bug was still there at the time. regards, dan carpenter ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Ksummit-discuss] Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document 2018-10-22 20:26 ` NeilBrown 2018-10-22 22:46 ` Theodore Y. Ts'o @ 2018-10-23 3:31 ` Al Viro 2018-10-23 4:25 ` NeilBrown 2018-10-24 12:16 ` Josh Triplett 2 siblings, 1 reply; 104+ messages in thread From: Al Viro @ 2018-10-23 3:31 UTC (permalink / raw) To: NeilBrown Cc: Josh Triplett, Greg Kroah-Hartman, linux-kernel, Linus Torvalds, ksummit-discuss, Mishi Choudhary On Tue, Oct 23, 2018 at 07:26:06AM +1100, NeilBrown wrote: > Currently if a maintainer is rude to you, there is no where else that > you can go and *that* is why it hurts. It isn't the abuse so much as > the powerlessness associated with it. If you can (metaphorically) say > to that maintainer "I don't care about your toilet mouth, you've just > given me the right to take my petition to caesar" - then the emotional > response will be quite different to pain. Bollocks. First of all, you *always* can take patches to Linus, even if maintainer is being the sodding Miss Manners. Always could. What you can't (and shouldn't be able to) is to _force_ a piece of shit patch (pardon the toilet mouth) into the tree on the grounds of maintainer having been "rude" to your patch. Again, you can and always could appeal to Linus if your patches are wrongly rejected, in your opinion. You'd better have good evidence supporting the "wrongly" bit in that case, but the "right to petition" model implies that anyway. If you are talking about the situations when "rude" maintainer makes insufferable requests to one's precious patches (e.g. demonstrates his or her mental inferiority by admitting that they are unable to follow contributor's 0.5KLoC of spaghetty in a single function and has an unspeakable gall to demand to clean it up - instead of passing that task upon the interns, as they ought to[1])... sure, that would be something new. Would you care to be the person charged with dealing with such... valuable contributors? And how good is the coverage of psychiatric treatments offered by your medical insurance? [1] no, I'm not making it up > If Linus is not true to his new-found sensitivity, we might need someone > (Greg?) to be a co-maintainer, able to accept patches when Linus has a > relapse. It might be good form to create this channel anyway, but I > doubt it would be needed in practice. > > So there you have it. The "Code" is upside down. > We need documents which: > - curtail the power of the strong, starting with Linus > - are adopted willingly by individuals, not imposed on the community. > - provide alternate routes for patch-flow, so that no-one has ultimate > power. Really? The ultimate power being to say "No" to a patch, and nobody should have such? Are you fucking serious? PS: All together, now - Every Patch is Sacred, Every Patch is Great, If a Patch Is Wasted, Neil Gets Quite Irate may the filking begin... ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Ksummit-discuss] Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document 2018-10-23 3:31 ` Al Viro @ 2018-10-23 4:25 ` NeilBrown 2018-10-23 4:52 ` Al Viro 2018-10-23 8:11 ` Theodore Y. Ts'o 0 siblings, 2 replies; 104+ messages in thread From: NeilBrown @ 2018-10-23 4:25 UTC (permalink / raw) To: Al Viro Cc: Josh Triplett, Greg Kroah-Hartman, linux-kernel, Linus Torvalds, ksummit-discuss, Mishi Choudhary [-- Attachment #1: Type: text/plain, Size: 3815 bytes --] On Tue, Oct 23 2018, Al Viro wrote: > On Tue, Oct 23, 2018 at 07:26:06AM +1100, NeilBrown wrote: > >> Currently if a maintainer is rude to you, there is no where else that >> you can go and *that* is why it hurts. It isn't the abuse so much as >> the powerlessness associated with it. If you can (metaphorically) say >> to that maintainer "I don't care about your toilet mouth, you've just >> given me the right to take my petition to caesar" - then the emotional >> response will be quite different to pain. > > Bollocks. First of all, you *always* can take patches to Linus, even if > maintainer is being the sodding Miss Manners. Always could. What you > can't (and shouldn't be able to) is to _force_ a piece of shit patch > (pardon the toilet mouth) into the tree on the grounds of maintainer having > been "rude" to your patch. Yes, you could, and you can. But if it was Linus who was behaving inappropriately, where did you go then? This is why I think whatever "code" we have should be overtly a statement Linus makes about his behaviour, in the first instance. And of course a bad patch should be rejected. In many cases a bad patch can then be improved. If the maintainer responds badly to your first (bad) patch, it can be very hard to try again - once bitten twice shy, as they say. The point of being able to circumvent a maintainer is to be able to get relevant rational review, instead of emotional attacks. > > Again, you can and always could appeal to Linus if your patches are wrongly > rejected, in your opinion. You'd better have good evidence supporting the > "wrongly" bit in that case, but the "right to petition" model implies that > anyway. I wonder how many people know about this right-to-petition, or use it. Maybe it should be stated in the "Code of conduct". > > If you are talking about the situations when "rude" maintainer makes insufferable > requests to one's precious patches (e.g. demonstrates his or her mental inferiority > by admitting that they are unable to follow contributor's 0.5KLoC of spaghetty in a > single function and has an unspeakable gall to demand to clean it up - instead of > passing that task upon the interns, as they ought to[1])... sure, that would be > something new. Would you care to be the person charged with dealing with such... > valuable contributors? And how good is the coverage of psychiatric treatments > offered by your medical insurance? > > [1] no, I'm not making it up > >> If Linus is not true to his new-found sensitivity, we might need someone >> (Greg?) to be a co-maintainer, able to accept patches when Linus has a >> relapse. It might be good form to create this channel anyway, but I >> doubt it would be needed in practice. >> >> So there you have it. The "Code" is upside down. >> We need documents which: >> - curtail the power of the strong, starting with Linus >> - are adopted willingly by individuals, not imposed on the community. >> - provide alternate routes for patch-flow, so that no-one has ultimate >> power. > > Really? The ultimate power being to say "No" to a patch, and nobody should > have such? Are you fucking serious? I have noticed of late a tendency in all sorts of different people to hear/read a statement from someone they know, interpret it a particular way, be surprised about that interpretation, and persist with believing that interpretation anyway, rather than realizing that the most likely explanation is a communication failure, and asking for clarification. The "ultimate power" is the ability to say "no" to a patch, *with no opportunity for review*. Two people together having that ultimate power is a totally different thing to one person having it alone. Thanks NeilBrown [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 832 bytes --] ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Ksummit-discuss] Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document 2018-10-23 4:25 ` NeilBrown @ 2018-10-23 4:52 ` Al Viro 2018-10-23 5:28 ` NeilBrown 2018-10-23 8:11 ` Theodore Y. Ts'o 1 sibling, 1 reply; 104+ messages in thread From: Al Viro @ 2018-10-23 4:52 UTC (permalink / raw) To: NeilBrown Cc: Josh Triplett, Greg Kroah-Hartman, linux-kernel, Linus Torvalds, ksummit-discuss, Mishi Choudhary On Tue, Oct 23, 2018 at 03:25:08PM +1100, NeilBrown wrote: > >> If Linus is not true to his new-found sensitivity, we might need someone > >> (Greg?) to be a co-maintainer, able to accept patches when Linus has a > >> relapse. It might be good form to create this channel anyway, but I > >> doubt it would be needed in practice. > >> > >> So there you have it. The "Code" is upside down. > >> We need documents which: > >> - curtail the power of the strong, starting with Linus > >> - are adopted willingly by individuals, not imposed on the community. > >> - provide alternate routes for patch-flow, so that no-one has ultimate > >> power. > > > > Really? The ultimate power being to say "No" to a patch, and nobody should > > have such? Are you fucking serious? > > I have noticed of late a tendency in all sorts of different people to > hear/read a statement from someone they know, interpret it a particular > way, be surprised about that interpretation, and persist with believing > that interpretation anyway, rather than realizing that the most likely > explanation is a communication failure, and asking for clarification. > > The "ultimate power" is the ability to say "no" to a patch, *with no > opportunity for review*. Two people together having that ultimate power > is a totally different thing to one person having it alone. If that's a clarification, I'm sorry to say that I understand you even less now. What are you proposing? Duopoly? How do you deal with disagreements? Fork? Revert wars? Frankly, CoC as-is is a bloody awful idea wide-open to abuses, but what you are proposing feels even more incoherent... ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Ksummit-discuss] Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document 2018-10-23 4:52 ` Al Viro @ 2018-10-23 5:28 ` NeilBrown 2018-10-23 6:00 ` Al Viro 0 siblings, 1 reply; 104+ messages in thread From: NeilBrown @ 2018-10-23 5:28 UTC (permalink / raw) To: Al Viro Cc: Josh Triplett, Greg Kroah-Hartman, linux-kernel, Linus Torvalds, ksummit-discuss, Mishi Choudhary [-- Attachment #1: Type: text/plain, Size: 2676 bytes --] On Tue, Oct 23 2018, Al Viro wrote: > On Tue, Oct 23, 2018 at 03:25:08PM +1100, NeilBrown wrote: > >> >> If Linus is not true to his new-found sensitivity, we might need someone >> >> (Greg?) to be a co-maintainer, able to accept patches when Linus has a >> >> relapse. It might be good form to create this channel anyway, but I >> >> doubt it would be needed in practice. >> >> >> >> So there you have it. The "Code" is upside down. >> >> We need documents which: >> >> - curtail the power of the strong, starting with Linus >> >> - are adopted willingly by individuals, not imposed on the community. >> >> - provide alternate routes for patch-flow, so that no-one has ultimate >> >> power. >> > >> > Really? The ultimate power being to say "No" to a patch, and nobody should >> > have such? Are you fucking serious? >> >> I have noticed of late a tendency in all sorts of different people to >> hear/read a statement from someone they know, interpret it a particular >> way, be surprised about that interpretation, and persist with believing >> that interpretation anyway, rather than realizing that the most likely >> explanation is a communication failure, and asking for clarification. >> >> The "ultimate power" is the ability to say "no" to a patch, *with no >> opportunity for review*. Two people together having that ultimate power >> is a totally different thing to one person having it alone. > > If that's a clarification, I'm sorry to say that I understand you even less now. > What are you proposing? Duopoly? How do you deal with disagreements? Fork? > Revert wars? We already have team-maintainership arrangements - doing the same thing at the top level should not be that hard to imagine. It really about "saying" no. I suspect all members of a team would come to much the same decision about any given patch, but they might "say" it differently. One might say "anyone who wrote this should be lobotomised", and the other might say "I see what you are trying to do, but the approach won't work - go look at how we handle XXXX, they have a similar problem". Neither will accept the patch, and they will probably both accept it after certain changes. But when one of them is having a bad day, I would like people to have the explicit opportunity to ignore them and talk to the other. Yes, they'll still get "no" twice, but they'll also get something approaching sane review least once. Just knowing that the person you are ranting at can by-pass you would, I suspect, encourage a lot of people to reconsider their behavior (though maybe I'm optomistic there). Thanks, NeilBrown [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 832 bytes --] ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Ksummit-discuss] Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document 2018-10-23 5:28 ` NeilBrown @ 2018-10-23 6:00 ` Al Viro 2018-10-23 20:45 ` NeilBrown 0 siblings, 1 reply; 104+ messages in thread From: Al Viro @ 2018-10-23 6:00 UTC (permalink / raw) To: NeilBrown Cc: Josh Triplett, Greg Kroah-Hartman, linux-kernel, Linus Torvalds, ksummit-discuss, Mishi Choudhary On Tue, Oct 23, 2018 at 04:28:03PM +1100, NeilBrown wrote: > > If that's a clarification, I'm sorry to say that I understand you even less now. > > What are you proposing? Duopoly? How do you deal with disagreements? Fork? > > Revert wars? > > We already have team-maintainership arrangements - doing the same thing > at the top level should not be that hard to imagine. > > It really about "saying" no. I suspect all members of a team would come > to much the same decision about any given patch, but they might "say" it > differently. One might say "anyone who wrote this should be > lobotomised", and the other might say "I see what you are trying to do, > but the approach won't work - go look at how we handle XXXX, they have a > similar problem". Neither will accept the patch, and they will probably > both accept it after certain changes. But when one of them is having a > bad day, I would like people to have the explicit opportunity to ignore > them and talk to the other. Yes, they'll still get "no" twice, but they'll > also get something approaching sane review least once. You still have not answered the question I've asked - what to do in case of real disagreements, seeing that "pass it to Linus for final decision" obviously doesn't work here. And while we are at it, what to do in case when "they" _agree_ that patch is unsalvagable? I'm quite sure that you can think of examples of such... BTW, out of curiosity - when has anyone suggested lobotomies[1]? I'd like to see details - got to be interesting... [1] on kernel development lists, that is - I can think of examples in e.g. NANAE circa '98 or so regarding the SGI employees responsible for sendmail setup they used to ship in IRIX, but that was more of a possible explanation of the reasons rather than suggested remedy... ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Ksummit-discuss] Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document 2018-10-23 6:00 ` Al Viro @ 2018-10-23 20:45 ` NeilBrown 0 siblings, 0 replies; 104+ messages in thread From: NeilBrown @ 2018-10-23 20:45 UTC (permalink / raw) To: Al Viro Cc: Josh Triplett, Greg Kroah-Hartman, linux-kernel, Linus Torvalds, ksummit-discuss, Mishi Choudhary [-- Attachment #1: Type: text/plain, Size: 3179 bytes --] On Tue, Oct 23 2018, Al Viro wrote: > On Tue, Oct 23, 2018 at 04:28:03PM +1100, NeilBrown wrote: > >> > If that's a clarification, I'm sorry to say that I understand you even less now. >> > What are you proposing? Duopoly? How do you deal with disagreements? Fork? >> > Revert wars? >> >> We already have team-maintainership arrangements - doing the same thing >> at the top level should not be that hard to imagine. >> >> It really about "saying" no. I suspect all members of a team would come >> to much the same decision about any given patch, but they might "say" it >> differently. One might say "anyone who wrote this should be >> lobotomised", and the other might say "I see what you are trying to do, >> but the approach won't work - go look at how we handle XXXX, they have a >> similar problem". Neither will accept the patch, and they will probably >> both accept it after certain changes. But when one of them is having a >> bad day, I would like people to have the explicit opportunity to ignore >> them and talk to the other. Yes, they'll still get "no" twice, but they'll >> also get something approaching sane review least once. > > You still have not answered the question I've asked - what to do in case of > real disagreements, seeing that "pass it to Linus for final decision" obviously > doesn't work here. And while we are at it, what to do in case when "they" > _agree_ that patch is unsalvagable? I'm quite sure that you can think of > examples of such... Sorry, things easily get lost in such a wide ranging conversation. Handling of real disagreements is not my problem, unless I am a member of the maintainership team. We have maintainership teams which appear to work, so they provide an existence-proof that something can be achieved. Were I to have an opportunity to be part of a maintainership team, I would probably base any internal agreement necessary on two principles. 1/ People on the team are reasonably competent, and aren't going to commit anything that all controversial without being quite confident. I would choose to trust. 2/ We commit bad patches often, and when we realize, we fix them. You and I have both been on both sides of that. We (the community) even commit quite large mistakes (devfs, control-groups) and the world doesn't end. Accepting imperfection is a key part of Linus' pragmatic approach, and a key part of the success of Linux. If they agree that the patch is unsalvagable, then they say so - politely and with reasons. It is a right-of-review, not a right-of-success. > > BTW, out of curiosity - when has anyone suggested lobotomies[1]? I'd like to see > details - got to be interesting... Sorry, it was a deliberately ficticious example. Thanks for showing an interest, it is more than a lot of people are doing. NeilBrown > > [1] on kernel development lists, that is - I can think of examples in e.g. > NANAE circa '98 or so regarding the SGI employees responsible for sendmail > setup they used to ship in IRIX, but that was more of a possible explanation > of the reasons rather than suggested remedy... [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 832 bytes --] ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Ksummit-discuss] Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document 2018-10-23 4:25 ` NeilBrown 2018-10-23 4:52 ` Al Viro @ 2018-10-23 8:11 ` Theodore Y. Ts'o 2018-10-23 14:22 ` Rainer Fiebig 2018-10-23 21:14 ` NeilBrown 1 sibling, 2 replies; 104+ messages in thread From: Theodore Y. Ts'o @ 2018-10-23 8:11 UTC (permalink / raw) To: NeilBrown Cc: Al Viro, Josh Triplett, Greg Kroah-Hartman, linux-kernel, Linus Torvalds, ksummit-discuss, Mishi Choudhary On Tue, Oct 23, 2018 at 03:25:08PM +1100, NeilBrown wrote: > > Yes, you could, and you can. But if it was Linus who was behaving > inappropriately, where did you go then? This is why I think whatever > "code" we have should be overtly a statement Linus makes about his > behaviour, in the first instance. You're still missing the point, and the problem. The concern was not *that* a patch was rejected, it was in *how* the patch was rejected. The "problem" has never been about how Linus was treating anyone other than core maintainers; i.e., most of the rants that I can think of (a) happened years of ago, and (b) were directed at the sort of people who were in the room at the Maintainer's Summit yesterday. Who which, by the way, didn't have a complaint about Linus's recent behavior; in fact, there was general agreement that Linus's behavior has been getting *better* over the last few years. One of the more important effects of the CoC is that newcomers have a fear about Linux's reputation of having extremely toxic community. There is a narrative that has been constructed that because Linus behaves badly to everyone; and this gives everyone "permission" to behave badly. Regardless of how true it may have been in the past, I believe that it is largely obsolete today. And so, the mere existence of a CoC has caused some newcomers to say that they have "already noticed a difference" --- which is IMO mostly the effect of CoC easing fears, as opposed to any real change in Linux community in the past four weeks. I think how it will work out in practice is that the CoC will be more a commitment about what we are holding up as community norms. Unfortunately, for some poeple the term "CoC" apparently acts as trigger language and it brings to mind legal proceedings, unaccountable court-like entities, and hammering people with punishments for petty issues with no appeal or recourse. Perhaps this is why other communities have elected to use terms such as "How to do Samba: Nicely" and "GNU Kind Communication Guidelines". All of these are trying to solve the same issue, and so my suggestion is let's just wait and see how things go. If people continue to see that the community has "changed" for the better, and other people see that we're not hammering people with sanctions, but rather reminding each other about the kind of community we aspire to be, it'll all be good. - Ted ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Ksummit-discuss] Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document 2018-10-23 8:11 ` Theodore Y. Ts'o @ 2018-10-23 14:22 ` Rainer Fiebig 2018-10-23 15:43 ` Theodore Y. Ts'o 2018-10-23 21:14 ` NeilBrown 1 sibling, 1 reply; 104+ messages in thread From: Rainer Fiebig @ 2018-10-23 14:22 UTC (permalink / raw) To: linux-kernel, t Cc: NeilBrown, Al Viro, Josh Triplett, Greg Kroah-Hartman, Linus Torvalds, ksummit-discuss, Mishi Choudhary Am Dienstag, 23. Oktober 2018, 04:11:44 schrieb Theodore Y. Ts'o: > On Tue, Oct 23, 2018 at 03:25:08PM +1100, NeilBrown wrote: > > Yes, you could, and you can. But if it was Linus who was behaving > > inappropriately, where did you go then? This is why I think whatever > > "code" we have should be overtly a statement Linus makes about his > > behaviour, in the first instance. > > You're still missing the point, and the problem. The concern was not > *that* a patch was rejected, it was in *how* the patch was rejected. And to solve *this* problem a highly controversial and politically charged CoC had to be introduced that has already begun to divide the wider community? Seems like a bit of an overkill to me. And whether that CoC does come with a political agenda or is just being *perceived* so, is irrelevant: the perception *is* the reality. And by embracing this CoC, Linux is now being perceived as also supporting the agenda that comes with it. But perhaps that was intended? In my view you now have a new, probably even bigger problem: namely that by adopting *this* CoC and by unyieldingly clinging to it, you have alienated many, if not the majority of loyal Linux-users/supporters. Bad choice and bad timing, now that Linux seemed ready to also take off in the desktop-area. > The "problem" has never been about how Linus was treating anyone other > than core maintainers; i.e., most of the rants that I can think of (a) > happened years of ago, and (b) were directed at the sort of people who > were in the room at the Maintainer's Summit yesterday. Who which, by > the way, didn't have a complaint about Linus's recent behavior; in > fact, there was general agreement that Linus's behavior has been > getting *better* over the last few years. > > One of the more important effects of the CoC is that newcomers have a > fear about Linux's reputation of having extremely toxic community. > There is a narrative that has been constructed that because Linus > behaves badly to everyone; and this gives everyone "permission" to > behave badly. Regardless of how true it may have been in the past, I > believe that it is largely obsolete today. And so, the mere existence > of a CoC has caused some newcomers to say that they have "already > noticed a difference" --- which is IMO mostly the effect of CoC easing > fears, as opposed to any real change in Linux community in the past > four weeks. > > I think how it will work out in practice is that the CoC will be more > a commitment about what we are holding up as community norms. > Unfortunately, for some poeple the term "CoC" apparently acts as > trigger language and it brings to mind legal proceedings, > unaccountable court-like entities, and hammering people with > punishments for petty issues with no appeal or recourse. > I think you're wrong here. It's not the term "CoC" as such that brings up the negative associations. It is the specific choice of the CoC and its wording that does. And quite a few people have pointed this out already. Mitigations and alternatives had been offered but were ignored. > Perhaps this is why other communities have elected to use terms such > as "How to do Samba: Nicely" and "GNU Kind Communication Guidelines". > All of these are trying to solve the same issue, and so my suggestion > is let's just wait and see how things go. If people continue to see > that the community has "changed" for the better, and other people see > that we're not hammering people with sanctions, but rather reminding > each other about the kind of community we aspire to be, it'll all be > good. > > - Ted Those other communities have not just chosen other terms but also chosen other approaches and wordings. In my view, the Linux-CoC stands for exactly that sort of extreme "Political Correctness" that is infesting our societies and has proven its destructive nature in more than enough instances. For some examples see [1][2][3][4][5]. To me it feels more and more like the dark times of witch-hunts are back or when it was politically in-correct to say that the earth revolves around the sun. In those days offenders like Galilei were at least offered the choice between recanting and the funeral-pile. Today you may recant but you get publicly burnt anyway. To see Linux falling for this is a sorry sight. Rainer Fiebig *** [1] https://www.ibtimes.co.uk/sacked-nobel-prize-winning-scientist-sir-tim-hunt-gets-backing-eight-fellow-laureates-1507096 [2] https://www.telegraph.co.uk/news/science/science-news/12057365/Sir-Tim-Hunt-to-leave-Britain-for-Japan-after-sexism-row.html [3] https://en.wikipedia.org/wiki/Tim_Hunt#The_toast [4] https://www.bbc.com/news/world-europe-45703700 [5] https://www.bbc.com/news/world-us-canada-45789819 -- The truth always turns out to be simpler than you thought. Richard Feynman ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Ksummit-discuss] Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document 2018-10-23 14:22 ` Rainer Fiebig @ 2018-10-23 15:43 ` Theodore Y. Ts'o 2018-10-23 17:51 ` Rainer Fiebig 0 siblings, 1 reply; 104+ messages in thread From: Theodore Y. Ts'o @ 2018-10-23 15:43 UTC (permalink / raw) To: Rainer Fiebig Cc: linux-kernel, t, NeilBrown, Al Viro, Josh Triplett, Greg Kroah-Hartman, Linus Torvalds, ksummit-discuss, Mishi Choudhary On Tue, Oct 23, 2018 at 04:22:54PM +0200, Rainer Fiebig wrote: > > And whether that CoC does come with a political agenda or is just being > *perceived* so, is irrelevant: the perception *is* the reality. And by > embracing this CoC, Linux is now being perceived as also supporting the agenda > that comes with it. But perhaps that was intended? > > In my view you now have a new, probably even bigger problem: namely that by > adopting *this* CoC and by unyieldingly clinging to it, you have alienated > many, if not the majority of loyal Linux-users/supporters. Citation Needed: What's your *proof* the majority of Linux users/supports have been alienated? Many people have actually been quite supportive of the CoC. And perception is a funny thing. I have no doubt that there are people who will claim that some CoC's that might more be acceptable to you would be "useless" or "means nothing". (Note how simply removing three lines that troubled ***many*** Maintainers caused Josh to complain that it ruined the CoC). And there are others for whom the Contributor's Convenant automatically seems to mean kangaroo courts and harsh punishments with no accountability for minor issues. I suspect that both you *and* Josh are unhappy, in opposite directions, might be a hint that we've mostly gotten things right. Another example of this is that zero-day testing bot changed its message in order to be more welcoming to newcomers. ("Thank you for the patch! Yet something to improve...".) At the Maintainer's Summit, someone from Germany pointed out that in European and especially German cultures, being ultra polite is often a signal that the person is considered stupid/incompetent, and he actually viewed it the change in the testing bot as making it be *less* welcoming, not *more*. Not that he cared, because he has a thick skin and after all, it's only a 'bot --- but in his view he thought it was quite funny that the change was welcomed by some as being an improvement when he viewed it completely the other way 'round. Ultimately, we are a world-wide effort, and it's really hard to predict or control how people from different cultures will perceive an e-mail or some document. That doesn't mean we shouldn't *try*, and there may very well be times when someone will file a complaint for what is perceived to be a Code of Conduct which is really a misunderstanding due to a cultural mismatch. (And *obviously* that's not a CoC violation either, despite some people trying to spread FUD by making the case that it would be.) > In my view, the Linux-CoC stands for exactly that sort of extreme "Political > Correctness" that is infesting our societies and has proven its destructive > nature in more than enough instances. For some examples see [1][2][3][4][5]. > > To me it feels more and more like the dark times of witch-hunts are back or > when it was politically in-correct to say that the earth revolves around the > sun. In those days offenders like Galilei were at least offered the choice > between recanting and the funeral-pile. Today you may recant but you get > publicly burnt anyway. Yeah, and that's precisely the FUD that I'm talking about. I understand that is your view. Let's see if it's actually true. I haven't seen any witch trials or burnings in the GoLang community, which also uses the Contributor hConvenant as their CoC. Can you be open-minded enough to accept the fact that you might be wrong? And are you prepared to change your views if we don't see Maintainers getting "impeached" or otherwise burned at the stake in the next year or so? And on the flip side, if we continue to have newcomers saying that they are feeling more welcomed, I'm hoping that Josh is also open minded to understand that the changes the we made didn't completely destroy the whole point of the CoC. Best regards, - Ted ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Ksummit-discuss] Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document 2018-10-23 15:43 ` Theodore Y. Ts'o @ 2018-10-23 17:51 ` Rainer Fiebig 0 siblings, 0 replies; 104+ messages in thread From: Rainer Fiebig @ 2018-10-23 17:51 UTC (permalink / raw) To: Theodore Y. Ts'o, linux-kernel, t, NeilBrown, Al Viro, Josh Triplett, Greg Kroah-Hartman, Linus Torvalds, ksummit-discuss, Mishi Choudhary Theodore Y. Ts'o schrieb: > On Tue, Oct 23, 2018 at 04:22:54PM +0200, Rainer Fiebig wrote: >> >> And whether that CoC does come with a political agenda or is just being >> *perceived* so, is irrelevant: the perception *is* the reality. And by >> embracing this CoC, Linux is now being perceived as also supporting the agenda >> that comes with it. But perhaps that was intended? >> >> In my view you now have a new, probably even bigger problem: namely that by >> adopting *this* CoC and by unyieldingly clinging to it, you have alienated >> many, if not the majority of loyal Linux-users/supporters. > > Citation Needed: What's your *proof* the majority of Linux > users/supports have been alienated? Many people have actually been > quite supportive of the CoC. > Ah, come on. Proof? Do you have any hard data to underpin your assertion of "many"? That it *may* be the majority is the impression I got from the many discussions that I have seen, I haven't counted the pro- and con-comments. But I've found a little poll at "Pro-Linux", small sample, no way representative but accessible only for registered users.[1] The question was: "The new Code of Conduct: Good or bad for Linux?" - Brings Linux sympathies and support: 11% - Costs linux sympathies and support: 57% - Will have no impact: 32% - Nothing of this, but: 0% I wouldn't call this "proof" but a worrisome indication nevertheless, especially if you consider the name of the site. > And perception is a funny thing. I have no doubt that there are > people who will claim that some CoC's that might more be acceptable to > you would be "useless" or "means nothing". (Note how simply removing > three lines that troubled ***many*** Maintainers caused Josh to > complain that it ruined the CoC). And there are others for whom the > Contributor's Convenant automatically seems to mean kangaroo courts > and harsh punishments with no accountability for minor issues. I > suspect that both you *and* Josh are unhappy, in opposite directions, > might be a hint that we've mostly gotten things right. > I find Josh's position rather extreme - for him it seems to be "All or nothing". On the other hand, I've already made a proposal that is not too far from what you have now - without the political sting. Doesn't mean you should use it. So personally, I would be content already if you modified the first sentence in the way that has been suggested by others here several times. Less would be more. > Another example of this is that zero-day testing bot changed its > message in order to be more welcoming to newcomers. ("Thank you for > the patch! Yet something to improve...".) At the Maintainer's Summit, > someone from Germany pointed out that in European and especially > German cultures, being ultra polite is often a signal that the person > is considered stupid/incompetent, and he actually viewed it the change > in the testing bot as making it be *less* welcoming, not *more*. Not > that he cared, because he has a thick skin and after all, it's only a > 'bot --- but in his view he thought it was quite funny that the change > was welcomed by some as being an improvement when he viewed it > completely the other way 'round. > Perhaps not *less* welcoming but yes, you might get the impression that this bot wants to take you on a ride. :) > Ultimately, we are a world-wide effort, and it's really hard to > predict or control how people from different cultures will perceive an > e-mail or some document. That doesn't mean we shouldn't *try*, and > there may very well be times when someone will file a complaint for > what is perceived to be a Code of Conduct which is really a > misunderstanding due to a cultural mismatch. (And *obviously* that's > not a CoC violation either, despite some people trying to spread FUD > by making the case that it would be.) > >> In my view, the Linux-CoC stands for exactly that sort of extreme "Political >> Correctness" that is infesting our societies and has proven its destructive >> nature in more than enough instances. For some examples see [1][2][3][4][5]. >> >> To me it feels more and more like the dark times of witch-hunts are back or >> when it was politically in-correct to say that the earth revolves around the >> sun. In those days offenders like Galilei were at least offered the choice >> between recanting and the funeral-pile. Today you may recant but you get >> publicly burnt anyway. > > Yeah, and that's precisely the FUD that I'm talking about. I > understand that is your view. Let's see if it's actually true. I FUD? What happened to those guys and other people is not fiction but reality. And if a Nobel-laureate can lose his job and even leaves his country because of a harmless joke which was quoted completely out of context, it's time to be concerned and alarmed. There's something getting out of hand, imo. I would have expected Linux to resist this and not invite it. > haven't seen any witch trials or burnings in the GoLang community, > which also uses the Contributor hConvenant as their CoC. Can you be > open-minded enough to accept the fact that you might be wrong? And > are you prepared to change your views if we don't see Maintainers > getting "impeached" or otherwise burned at the stake in the next year > or so? I think I am. But are you open-minded enough to entertain the idea that introducing *this* CoC *this* way might have been a ghastly mistake? > And on the flip side, if we continue to have newcomers saying that > they are feeling more welcomed, I'm hoping that Josh is also open > minded to understand that the changes the we made didn't completely > destroy the whole point of the CoC. > Not so long ago I was a newcomer myself. And submitting the patch, discussing and improving it was a constructive and motivating experience - *no* CoC needed. What happened in the last few weeks was just the opposite. We'll see how this pans out. Thanks and regards! Rainer Fiebig --- [1] https://www.pro-linux.de/umfragen/2/454/der-neue-code-of-conduct-gut-oder-schlecht-f%C3%BCr-linux.html ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Ksummit-discuss] Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document 2018-10-23 8:11 ` Theodore Y. Ts'o 2018-10-23 14:22 ` Rainer Fiebig @ 2018-10-23 21:14 ` NeilBrown 1 sibling, 0 replies; 104+ messages in thread From: NeilBrown @ 2018-10-23 21:14 UTC (permalink / raw) To: t Cc: Al Viro, Josh Triplett, Greg Kroah-Hartman, linux-kernel, Linus Torvalds, ksummit-discuss, Mishi Choudhary [-- Attachment #1: Type: text/plain, Size: 4155 bytes --] On Tue, Oct 23 2018, Theodore Y. Ts'o wrote: > On Tue, Oct 23, 2018 at 03:25:08PM +1100, NeilBrown wrote: >> >> Yes, you could, and you can. But if it was Linus who was behaving >> inappropriately, where did you go then? This is why I think whatever >> "code" we have should be overtly a statement Linus makes about his >> behaviour, in the first instance. > > You're still missing the point, and the problem. The concern was not > *that* a patch was rejected, it was in *how* the patch was rejected. That is not a point I am missing. Of course it is about *how*. One form of rejection shows you a path forward, which might be revising the patch, and it might be solving your problem in a completely different way. The other form or rejection leaves you hurting and confused and not knowing which way to turn - so you leave. One way gives you power to move forward, the other denies it to you. > The "problem" has never been about how Linus was treating anyone other > than core maintainers; i.e., most of the rants that I can think of (a) > happened years of ago, and (b) were directed at the sort of people who > were in the room at the Maintainer's Summit yesterday. Who which, by > the way, didn't have a complaint about Linus's recent behavior; in > fact, there was general agreement that Linus's behavior has been > getting *better* over the last few years. The fact that Linus' behaviour has improved (with which I agree) is only part of the story. There is also Linus' reputation which is, I think, worse than his behaviour has ever been - partly because he has never (until recently) done anything to correct that reputation. Also, it is *not* just about how Linus treats core maintainers, as you seem to agree with below (despite your statements above). To take the liberty of quoting from an email on a non-public list that you will have seen: The unresolved bug was that Linus' conduct, and more importantly the conduct of people that less artfully and less productively emulated his blow ups, were getting further and further away from Linus' own stated ideals on how to treat people. Linus' example is (apparently) being copied. That makes it important, I think, for him to set an explicit counter-example. > > One of the more important effects of the CoC is that newcomers have a > fear about Linux's reputation of having extremely toxic community. > There is a narrative that has been constructed that because Linus > behaves badly to everyone; and this gives everyone "permission" to > behave badly. Regardless of how true it may have been in the past, I > believe that it is largely obsolete today. And so, the mere existence > of a CoC has caused some newcomers to say that they have "already > noticed a difference" --- which is IMO mostly the effect of CoC easing > fears, as opposed to any real change in Linux community in the past > four weeks. If the CoC has really eased fears, then that is clearly good news. I must admit to being a little surprised. > > I think how it will work out in practice is that the CoC will be more > a commitment about what we are holding up as community norms. > Unfortunately, for some poeple the term "CoC" apparently acts as > trigger language and it brings to mind legal proceedings, > unaccountable court-like entities, and hammering people with > punishments for petty issues with no appeal or recourse. > > Perhaps this is why other communities have elected to use terms such > as "How to do Samba: Nicely" and "GNU Kind Communication Guidelines". And doesn't our "code", with an "interpretation" two and a half times as long, look clumsy beside these documents?? > All of these are trying to solve the same issue, and so my suggestion > is let's just wait and see how things go. If people continue to see > that the community has "changed" for the better, and other people see > that we're not hammering people with sanctions, but rather reminding > each other about the kind of community we aspire to be, it'll all be > good. > Thanks for your time, NeilBrown [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 832 bytes --] ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Ksummit-discuss] Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document 2018-10-22 20:26 ` NeilBrown 2018-10-22 22:46 ` Theodore Y. Ts'o 2018-10-23 3:31 ` Al Viro @ 2018-10-24 12:16 ` Josh Triplett 2018-10-25 21:14 ` NeilBrown 2018-11-04 10:35 ` Geert Uytterhoeven 2 siblings, 2 replies; 104+ messages in thread From: Josh Triplett @ 2018-10-24 12:16 UTC (permalink / raw) To: NeilBrown Cc: Greg Kroah-Hartman, linux-kernel, Linus Torvalds, ksummit-discuss, Mishi Choudhary On Tue, Oct 23, 2018 at 07:26:06AM +1100, NeilBrown wrote: > On Sun, Oct 21 2018, 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 > >> > >> #Isupportreversion > >> > >> I call on the community to consider what *does* need to be said, about > >> conduct, to people outside the community and who have recently joined. > >> What is the document that you would have liked to have read as you were > >> starting out? It is all too long ago for me to remember clearly, and so > >> much has changed. > > > > The document I would have liked to have read when starting out is > > currently checked into the source tree in > > Documentation/process/code-of-conduct.rst . > > I'm curious - what would you have gained by reading that document? I would have then had rather less of a pervasive feeling of "if I make even a single mistake I get made an example of in ways that will feed people's quotes files for years to come". See https://hbr.org/2017/08/high-performing-teams-need-psychological-safety-heres-how-to-create-it for more on the benefits of that. ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Ksummit-discuss] Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document 2018-10-24 12:16 ` Josh Triplett @ 2018-10-25 21:14 ` NeilBrown 2018-10-27 1:10 ` Josh Triplett 2018-11-04 10:35 ` Geert Uytterhoeven 1 sibling, 1 reply; 104+ messages in thread From: NeilBrown @ 2018-10-25 21:14 UTC (permalink / raw) To: Josh Triplett Cc: Greg Kroah-Hartman, linux-kernel, Linus Torvalds, ksummit-discuss, Mishi Choudhary [-- Attachment #1: Type: text/plain, Size: 2056 bytes --] On Wed, Oct 24 2018, Josh Triplett wrote: > On Tue, Oct 23, 2018 at 07:26:06AM +1100, NeilBrown wrote: >> On Sun, Oct 21 2018, 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 >> >> >> >> #Isupportreversion >> >> >> >> I call on the community to consider what *does* need to be said, about >> >> conduct, to people outside the community and who have recently joined. >> >> What is the document that you would have liked to have read as you were >> >> starting out? It is all too long ago for me to remember clearly, and so >> >> much has changed. >> > >> > The document I would have liked to have read when starting out is >> > currently checked into the source tree in >> > Documentation/process/code-of-conduct.rst . >> >> I'm curious - what would you have gained by reading that document? > > I would have then had rather less of a pervasive feeling of "if I make > even a single mistake I get made an example of in ways that will feed > people's quotes files for years to come". Thanks for your reply. Certainly feeling safe is important, and having clear statements that the community values and promotes psychological safety is valuable. The old "code of conflict" said If however, anyone feels personally abused, threatened, or otherwise uncomfortable due to this process, that is not acceptable. would you have not found this a strong enough statement to ward off that pervasive feeling? In the current code, would The "Our Pledge" section have been sufficient, or do you think the other sections would have actually helped you? > > See > https://hbr.org/2017/08/high-performing-teams-need-psychological-safety-heres-how-to-create-it > for more on the benefits of that. Thanks for the link. NeilBrown [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 832 bytes --] ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Ksummit-discuss] Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document 2018-10-25 21:14 ` NeilBrown @ 2018-10-27 1:10 ` Josh Triplett 2018-10-28 21:48 ` NeilBrown 2018-11-01 16:45 ` Paul E. McKenney 0 siblings, 2 replies; 104+ messages in thread From: Josh Triplett @ 2018-10-27 1:10 UTC (permalink / raw) To: NeilBrown Cc: Greg Kroah-Hartman, linux-kernel, Linus Torvalds, ksummit-discuss, Mishi Choudhary On Fri, Oct 26, 2018 at 08:14:51AM +1100, NeilBrown wrote: > On Wed, Oct 24 2018, Josh Triplett wrote: > > > On Tue, Oct 23, 2018 at 07:26:06AM +1100, NeilBrown wrote: > >> On Sun, Oct 21 2018, 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 > >> >> > >> >> #Isupportreversion > >> >> > >> >> I call on the community to consider what *does* need to be said, about > >> >> conduct, to people outside the community and who have recently joined. > >> >> What is the document that you would have liked to have read as you were > >> >> starting out? It is all too long ago for me to remember clearly, and so > >> >> much has changed. > >> > > >> > The document I would have liked to have read when starting out is > >> > currently checked into the source tree in > >> > Documentation/process/code-of-conduct.rst . > >> > >> I'm curious - what would you have gained by reading that document? > > > > I would have then had rather less of a pervasive feeling of "if I make > > even a single mistake I get made an example of in ways that will feed > > people's quotes files for years to come". > > Thanks for your reply. Certainly feeling safe is important, and having > clear statements that the community values and promotes psychological > safety is valuable. > > The old "code of conflict" said > If however, anyone feels personally abused, threatened, or otherwise > uncomfortable due to this process, that is not acceptable. > > would you have not found this a strong enough statement to ward off that > pervasive feeling? Not when that document started out effectively saying, in an elaborate way, "code > people". (Leaving aside that the more important detail would be the community actually acting consistently with the code of conduct it espoused.) > In the current code, would The "Our Pledge" section have been > sufficient, or do you think the other sections would have actually > helped you? "Our Standards" would have been at least as important to me personally, as would "Enforcement" (and more importantly, examples of that applying in practice and not just as empty words). ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Ksummit-discuss] Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document 2018-10-27 1:10 ` Josh Triplett @ 2018-10-28 21:48 ` NeilBrown 2018-11-01 16:45 ` Paul E. McKenney 1 sibling, 0 replies; 104+ messages in thread From: NeilBrown @ 2018-10-28 21:48 UTC (permalink / raw) To: Josh Triplett Cc: Greg Kroah-Hartman, linux-kernel, Linus Torvalds, ksummit-discuss, Mishi Choudhary [-- Attachment #1: Type: text/plain, Size: 5821 bytes --] On Sat, Oct 27 2018, Josh Triplett wrote: > On Fri, Oct 26, 2018 at 08:14:51AM +1100, NeilBrown wrote: >> On Wed, Oct 24 2018, Josh Triplett wrote: >> >> > On Tue, Oct 23, 2018 at 07:26:06AM +1100, NeilBrown wrote: >> >> On Sun, Oct 21 2018, 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 >> >> >> >> >> >> #Isupportreversion >> >> >> >> >> >> I call on the community to consider what *does* need to be said, about >> >> >> conduct, to people outside the community and who have recently joined. >> >> >> What is the document that you would have liked to have read as you were >> >> >> starting out? It is all too long ago for me to remember clearly, and so >> >> >> much has changed. >> >> > >> >> > The document I would have liked to have read when starting out is >> >> > currently checked into the source tree in >> >> > Documentation/process/code-of-conduct.rst . >> >> >> >> I'm curious - what would you have gained by reading that document? >> > >> > I would have then had rather less of a pervasive feeling of "if I make >> > even a single mistake I get made an example of in ways that will feed >> > people's quotes files for years to come". >> >> Thanks for your reply. Certainly feeling safe is important, and having >> clear statements that the community values and promotes psychological >> safety is valuable. >> >> The old "code of conflict" said >> If however, anyone feels personally abused, threatened, or otherwise >> uncomfortable due to this process, that is not acceptable. >> >> would you have not found this a strong enough statement to ward off that >> pervasive feeling? > > Not when that document started out effectively saying, in an elaborate > way, "code > people". (Leaving aside that the more important detail > would be the community actually acting consistently with the code of > conduct it espoused.) I certainly cannot argue with that. .... that those starting words have been preserved in the code-of-conduct-interpretation.rst, so we still have them. > >> In the current code, would The "Our Pledge" section have been >> sufficient, or do you think the other sections would have actually >> helped you? > > "Our Standards" would have been at least as important to me personally, > as would "Enforcement" (and more importantly, examples of that applying > in practice and not just as empty words). I find it interesting that you appear to particularly value the Enforcement section, I particularly dislike it. It is also interesting that you seem to fear that it might be "empty words", and elsewhere in this thread Laura Abbott wondered Will those problems actually be handled appropriately when the time comes? I can't actually say for sure She goes on to opine that trust is needed, but if we really had trust, we might not need the code. None of us, to my knowledge, has credible expertise or demonstrated experience in this area, so we might easily become the blind misleading the blind. However I would like to make one more attempt to give context and meaning to my dislike for that section. The approach described seem to be combative rather than conciliatory. The first action-step described is to mark a report - to complain. This isn't quite as bad as being litigious, but it seems headed in that direction. I would rather we gave people the power to resolve their own issues, rather than an avenue to magnify them but involving others. Think for a moment about how we resolve technical differences. I acknowledge that we don't always resolve them very well, but when we do - what techniques seem to work? We don't have any court to which we can apply to resolve our differences, we need to present our case and garner support from like-minded people. To help with that, we do have some standards like "no regressions" and "maintainable" and various coding-style guidelines. They don't necessarily answer everything but they help. Over all this, there is a general principle that the person who writes the code makes the decisions - "code talks". The person who puts in the effort gets heard more than the person who complains from the side lines. This isn't all perfect, but it largely works, and we are familiar with it. Can we translate any of that experience to the social/harm side of things? 1/ We can have some standards. We will never all agree on the level of detail needed (but then, we don't all agree on checkpatch.pl either), but anything generally in the right direction would help (I like "Be helpful. Don't be harmful". "Be kind to each other" is in the interpretation). 2/ We can voice our support when we see a cause the we agree with, whether it is a revised API, or discomfort with a particular word-choice. 3/ We can make sure that people who have done valuable work (written a patch, found a bug, etc) have a place where they can be heard, even if they find the need to filter all messages from an unrepentant abuser. I think our practice, in the technical sphere, has generally been towards conciliation, not combat. I think that is the experience that we should try to leverage in the more social sphere. A useful side-node is that "hurting people hurt people". If someone does hurt you, there is a good chance that they are hurting themselves. Do you want to increase that hurt by fighting back? Would it not be better to simply side-step. Thanks, NeilBrown [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 832 bytes --] ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Ksummit-discuss] Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document 2018-10-27 1:10 ` Josh Triplett 2018-10-28 21:48 ` NeilBrown @ 2018-11-01 16:45 ` Paul E. McKenney 2018-11-01 21:11 ` Josh Triplett 2018-11-01 21:50 ` NeilBrown 1 sibling, 2 replies; 104+ messages in thread From: Paul E. McKenney @ 2018-11-01 16:45 UTC (permalink / raw) To: Josh Triplett Cc: NeilBrown, Mishi Choudhary, Greg Kroah-Hartman, linux-kernel, ksummit-discuss On Sat, Oct 27, 2018 at 02:10:10AM +0100, Josh Triplett wrote: > On Fri, Oct 26, 2018 at 08:14:51AM +1100, NeilBrown wrote: > > On Wed, Oct 24 2018, Josh Triplett wrote: > > > > > On Tue, Oct 23, 2018 at 07:26:06AM +1100, NeilBrown wrote: > > >> On Sun, Oct 21 2018, 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 > > >> >> > > >> >> #Isupportreversion > > >> >> > > >> >> I call on the community to consider what *does* need to be said, about > > >> >> conduct, to people outside the community and who have recently joined. > > >> >> What is the document that you would have liked to have read as you were > > >> >> starting out? It is all too long ago for me to remember clearly, and so > > >> >> much has changed. > > >> > > > >> > The document I would have liked to have read when starting out is > > >> > currently checked into the source tree in > > >> > Documentation/process/code-of-conduct.rst . > > >> > > >> I'm curious - what would you have gained by reading that document? > > > > > > I would have then had rather less of a pervasive feeling of "if I make > > > even a single mistake I get made an example of in ways that will feed > > > people's quotes files for years to come". > > > > Thanks for your reply. Certainly feeling safe is important, and having > > clear statements that the community values and promotes psychological > > safety is valuable. > > > > The old "code of conflict" said > > If however, anyone feels personally abused, threatened, or otherwise > > uncomfortable due to this process, that is not acceptable. > > > > would you have not found this a strong enough statement to ward off that > > pervasive feeling? > > Not when that document started out effectively saying, in an elaborate > way, "code > people". Interesting. I am curious what leads you to your "code > people" statement. Of course, one could argue that this does not really matter given that the code of conflict is no longer. However, I would like to understand for future reference, if for no other reason. One possibility is that you are restricting the "people" to only those people directly contributing in one way or another. But those using the kernel (both directly and indirectly) are important as well, and it is exactly this group that is served by "the most robust operating system kernel ever", the chest-beating sentiment notwithstanding. Which is in fact why I must reject (or rework or whatever) any patch that might result in too-short RCU grace periods: The needs of the patch's submitter are quite emphatically outweighed by the needs of the kernel's many users, and many of the various technical requirements and restrictions are in fact proxies for the needs of these users. But you knew that already. Similarly for the Linux kernel's various code-style strictures, which serve the surprisingly large group of people reading the kernel's code. Including the stricture that I most love to hate, which is the one stating that single-line do/for/if/while statements must not be enclosed in braces, which sometimes causes me trouble when inserting debug code, but which also makes more code fit into a window of a given size. ;-) But you knew that already, too. The maintainability requirements can be argued to mostly serve the maintainers, but if the code becomes unmaintainable, future users will be inconvenienced, to say the least. So even the maintainability requirements serve the kernel's many users. But you also knew that already. So what am I missing here? Thanx, Paul > (Leaving aside that the more important detail > would be the community actually acting consistently with the code of > conduct it espoused.) > > > In the current code, would The "Our Pledge" section have been > > sufficient, or do you think the other sections would have actually > > helped you? > > "Our Standards" would have been at least as important to me personally, > as would "Enforcement" (and more importantly, examples of that applying > in practice and not just as empty words). > _______________________________________________ > Ksummit-discuss mailing list > Ksummit-discuss@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss > ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Ksummit-discuss] Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document 2018-11-01 16:45 ` Paul E. McKenney @ 2018-11-01 21:11 ` Josh Triplett 2018-11-02 13:13 ` Paul E. McKenney 2018-11-01 21:50 ` NeilBrown 1 sibling, 1 reply; 104+ messages in thread From: Josh Triplett @ 2018-11-01 21:11 UTC (permalink / raw) To: Paul E. McKenney Cc: NeilBrown, Mishi Choudhary, Greg Kroah-Hartman, linux-kernel, ksummit-discuss On Thu, Nov 01, 2018 at 09:45:44AM -0700, Paul E. McKenney wrote: > On Sat, Oct 27, 2018 at 02:10:10AM +0100, Josh Triplett wrote: > > Not when that document started out effectively saying, in an elaborate > > way, "code > people". > > Interesting. > > I am curious what leads you to your "code > people" statement. Of course, > one could argue that this does not really matter given that the code of > conflict is no longer. However, I would like to understand for future > reference, if for no other reason. > > One possibility is that you are restricting the "people" to only those > people directly contributing in one way or another. But those using the > kernel (both directly and indirectly) are important as well, and it is > exactly this group that is served by "the most robust operating system > kernel ever", the chest-beating sentiment notwithstanding. Which is in > fact why I must reject (or rework or whatever) any patch that might result > in too-short RCU grace periods: The needs of the patch's submitter are > quite emphatically outweighed by the needs of the kernel's many users, > and many of the various technical requirements and restrictions are in > fact proxies for the needs of these users. As discussed in many other places as well, nobody is suggesting at all that the standards for accepting code should change. Reject the patches you would have rejected, accept the patches you would have accepted. All of this affects *communication*. - Josh Triplett ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Ksummit-discuss] Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document 2018-11-01 21:11 ` Josh Triplett @ 2018-11-02 13:13 ` Paul E. McKenney 0 siblings, 0 replies; 104+ messages in thread From: Paul E. McKenney @ 2018-11-02 13:13 UTC (permalink / raw) To: Josh Triplett Cc: NeilBrown, Mishi Choudhary, Greg Kroah-Hartman, linux-kernel, ksummit-discuss On Thu, Nov 01, 2018 at 02:11:53PM -0700, Josh Triplett wrote: > On Thu, Nov 01, 2018 at 09:45:44AM -0700, Paul E. McKenney wrote: > > On Sat, Oct 27, 2018 at 02:10:10AM +0100, Josh Triplett wrote: > > > Not when that document started out effectively saying, in an elaborate > > > way, "code > people". > > > > Interesting. > > > > I am curious what leads you to your "code > people" statement. Of course, > > one could argue that this does not really matter given that the code of > > conflict is no longer. However, I would like to understand for future > > reference, if for no other reason. > > > > One possibility is that you are restricting the "people" to only those > > people directly contributing in one way or another. But those using the > > kernel (both directly and indirectly) are important as well, and it is > > exactly this group that is served by "the most robust operating system > > kernel ever", the chest-beating sentiment notwithstanding. Which is in > > fact why I must reject (or rework or whatever) any patch that might result > > in too-short RCU grace periods: The needs of the patch's submitter are > > quite emphatically outweighed by the needs of the kernel's many users, > > and many of the various technical requirements and restrictions are in > > fact proxies for the needs of these users. > > As discussed in many other places as well, nobody is suggesting at all > that the standards for accepting code should change. Reject the patches > you would have rejected, accept the patches you would have accepted. There have been a great many discussions in a great many places expressing a great many views, but it is good to hear your view on this particular point. It should come as no surprise that I advise you in the strongest possible terms to continue with the view that standards for accepting code into the Linux kernel should not decrease. > All > of this affects *communication*. Communication is inherently difficult. As I suspect the two of us just demonstrated. ;-) Thanx, Paul ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Ksummit-discuss] Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document 2018-11-01 16:45 ` Paul E. McKenney 2018-11-01 21:11 ` Josh Triplett @ 2018-11-01 21:50 ` NeilBrown 2018-11-02 13:33 ` Paul E. McKenney 2018-11-02 13:52 ` James Bottomley 1 sibling, 2 replies; 104+ messages in thread From: NeilBrown @ 2018-11-01 21:50 UTC (permalink / raw) To: paulmck, Josh Triplett Cc: Mishi Choudhary, Greg Kroah-Hartman, linux-kernel, ksummit-discuss [-- Attachment #1: Type: text/plain, Size: 7665 bytes --] On Thu, Nov 01 2018, Paul E. McKenney wrote: > On Sat, Oct 27, 2018 at 02:10:10AM +0100, Josh Triplett wrote: >> On Fri, Oct 26, 2018 at 08:14:51AM +1100, NeilBrown wrote: >> > On Wed, Oct 24 2018, Josh Triplett wrote: >> > >> > > On Tue, Oct 23, 2018 at 07:26:06AM +1100, NeilBrown wrote: >> > >> On Sun, Oct 21 2018, 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 >> > >> >> >> > >> >> #Isupportreversion >> > >> >> >> > >> >> I call on the community to consider what *does* need to be said, about >> > >> >> conduct, to people outside the community and who have recently joined. >> > >> >> What is the document that you would have liked to have read as you were >> > >> >> starting out? It is all too long ago for me to remember clearly, and so >> > >> >> much has changed. >> > >> > >> > >> > The document I would have liked to have read when starting out is >> > >> > currently checked into the source tree in >> > >> > Documentation/process/code-of-conduct.rst . >> > >> >> > >> I'm curious - what would you have gained by reading that document? >> > > >> > > I would have then had rather less of a pervasive feeling of "if I make >> > > even a single mistake I get made an example of in ways that will feed >> > > people's quotes files for years to come". >> > >> > Thanks for your reply. Certainly feeling safe is important, and having >> > clear statements that the community values and promotes psychological >> > safety is valuable. >> > >> > The old "code of conflict" said >> > If however, anyone feels personally abused, threatened, or otherwise >> > uncomfortable due to this process, that is not acceptable. >> > >> > would you have not found this a strong enough statement to ward off that >> > pervasive feeling? >> >> Not when that document started out effectively saying, in an elaborate >> way, "code > people". > > Interesting. > > I am curious what leads you to your "code > people" statement. Of course, > one could argue that this does not really matter given that the code of > conflict is no longer. However, I would like to understand for future > reference, if for no other reason. > > One possibility is that you are restricting the "people" to only those > people directly contributing in one way or another. But those using the > kernel (both directly and indirectly) are important as well, and it is > exactly this group that is served by "the most robust operating system > kernel ever", the chest-beating sentiment notwithstanding. Which is in > fact why I must reject (or rework or whatever) any patch that might result > in too-short RCU grace periods: The needs of the patch's submitter are > quite emphatically outweighed by the needs of the kernel's many users, > and many of the various technical requirements and restrictions are in > fact proxies for the needs of these users. > > But you knew that already. > > Similarly for the Linux kernel's various code-style strictures, which > serve the surprisingly large group of people reading the kernel's code. > Including the stricture that I most love to hate, which is the one > stating that single-line do/for/if/while statements must not be enclosed > in braces, which sometimes causes me trouble when inserting debug code, > but which also makes more code fit into a window of a given size. ;-) > > But you knew that already, too. > > The maintainability requirements can be argued to mostly serve the > maintainers, but if the code becomes unmaintainable, future users > will be inconvenienced, to say the least. So even the maintainability > requirements serve the kernel's many users. > > But you also knew that already. > > So what am I missing here? > Hi Paul, thanks for contributing your thoughts. It is nice to have a new voice in the conversation, it helps me to maintain my illusion that this issue is relevant to the whole community. I cannot, of course, speak to why Josh wrote what he did, but I can give some insight into why I had no disagreement with that part of his statement. A key insight, worth your time to consider and unpack I think, is People won't care what you know, until they know that you care. I won't dwell on that here, but will make some more obviously relevant observations. Firstly, you gave an analytical response to what was, in my view, an emotional observation. While I agree with your analysis, it is largely irrelevant. It is not how people *feel* about kernel development. You say that the code of conflict is gone, but in fact much of it is preserved in the code-of-conduct-interpretation. If you reflect on the focus of the second para of that document (which I think was directly lifted from the code-of-conflict) you will see that value is placed squarely on the code (kernel code, not code of conduct). The code is put forward as the thing of primary importance. People (you, me) are only mentioned in the context of being the authors of code that will be criticised - because (it almost says this) we care about the code, but not about you. So I think it is beyond argument that the value system presented by this paragraph is code > people I think this is particularly unfortunate as it is not really how the community works, and not really how Linus works, except in those occasional outbursts that are publicised so much. I recall two specific events (there were probably others) from early in my Linux experience where Linus said/did things which said to me that he valued me, not just the code that I wrote. I think he did that a lot (and probably still does). As I knew that he "cared", I was much more interested in what he knew/thought. I think that the fact that Linus is now acknowledging every "pull" request is brilliant. It doesn't really help the process much (we all have plenty of visibility into what Linus has pulled) and doesn't help the code (directly) at all. But it tells people that Linus can see them, and has seen them. It also allows people to see that they have an email from Linus without expecting it to be a criticism. Certainly he still criticises and is right to do so, and he doesn't say "Pulled, thanks", which would be my preference, but the fact that he responds at least says "me responding to you matters" and by implication "you matter". (The code-of-conflict only acknowledged that you matter once you feel personally abused). Thanks, NeilBrown > Thanx, Paul > >> (Leaving aside that the more important detail >> would be the community actually acting consistently with the code of >> conduct it espoused.) >> >> > In the current code, would The "Our Pledge" section have been >> > sufficient, or do you think the other sections would have actually >> > helped you? >> >> "Our Standards" would have been at least as important to me personally, >> as would "Enforcement" (and more importantly, examples of that applying >> in practice and not just as empty words). >> _______________________________________________ >> Ksummit-discuss mailing list >> Ksummit-discuss@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss >> [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 832 bytes --] ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Ksummit-discuss] Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document 2018-11-01 21:50 ` NeilBrown @ 2018-11-02 13:33 ` Paul E. McKenney 2018-11-03 8:36 ` NeilBrown 2018-11-02 13:52 ` James Bottomley 1 sibling, 1 reply; 104+ messages in thread From: Paul E. McKenney @ 2018-11-02 13:33 UTC (permalink / raw) To: NeilBrown Cc: Josh Triplett, Mishi Choudhary, Greg Kroah-Hartman, linux-kernel, ksummit-discuss On Fri, Nov 02, 2018 at 08:50:11AM +1100, NeilBrown wrote: > On Thu, Nov 01 2018, Paul E. McKenney wrote: > > > On Sat, Oct 27, 2018 at 02:10:10AM +0100, Josh Triplett wrote: > >> On Fri, Oct 26, 2018 at 08:14:51AM +1100, NeilBrown wrote: > >> > On Wed, Oct 24 2018, Josh Triplett wrote: > >> > > >> > > On Tue, Oct 23, 2018 at 07:26:06AM +1100, NeilBrown wrote: > >> > >> On Sun, Oct 21 2018, 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 > >> > >> >> > >> > >> >> #Isupportreversion > >> > >> >> > >> > >> >> I call on the community to consider what *does* need to be said, about > >> > >> >> conduct, to people outside the community and who have recently joined. > >> > >> >> What is the document that you would have liked to have read as you were > >> > >> >> starting out? It is all too long ago for me to remember clearly, and so > >> > >> >> much has changed. > >> > >> > > >> > >> > The document I would have liked to have read when starting out is > >> > >> > currently checked into the source tree in > >> > >> > Documentation/process/code-of-conduct.rst . > >> > >> > >> > >> I'm curious - what would you have gained by reading that document? > >> > > > >> > > I would have then had rather less of a pervasive feeling of "if I make > >> > > even a single mistake I get made an example of in ways that will feed > >> > > people's quotes files for years to come". > >> > > >> > Thanks for your reply. Certainly feeling safe is important, and having > >> > clear statements that the community values and promotes psychological > >> > safety is valuable. > >> > > >> > The old "code of conflict" said > >> > If however, anyone feels personally abused, threatened, or otherwise > >> > uncomfortable due to this process, that is not acceptable. > >> > > >> > would you have not found this a strong enough statement to ward off that > >> > pervasive feeling? > >> > >> Not when that document started out effectively saying, in an elaborate > >> way, "code > people". > > > > Interesting. > > > > I am curious what leads you to your "code > people" statement. Of course, > > one could argue that this does not really matter given that the code of > > conflict is no longer. However, I would like to understand for future > > reference, if for no other reason. > > > > One possibility is that you are restricting the "people" to only those > > people directly contributing in one way or another. But those using the > > kernel (both directly and indirectly) are important as well, and it is > > exactly this group that is served by "the most robust operating system > > kernel ever", the chest-beating sentiment notwithstanding. Which is in > > fact why I must reject (or rework or whatever) any patch that might result > > in too-short RCU grace periods: The needs of the patch's submitter are > > quite emphatically outweighed by the needs of the kernel's many users, > > and many of the various technical requirements and restrictions are in > > fact proxies for the needs of these users. > > > > But you knew that already. > > > > Similarly for the Linux kernel's various code-style strictures, which > > serve the surprisingly large group of people reading the kernel's code. > > Including the stricture that I most love to hate, which is the one > > stating that single-line do/for/if/while statements must not be enclosed > > in braces, which sometimes causes me trouble when inserting debug code, > > but which also makes more code fit into a window of a given size. ;-) > > > > But you knew that already, too. > > > > The maintainability requirements can be argued to mostly serve the > > maintainers, but if the code becomes unmaintainable, future users > > will be inconvenienced, to say the least. So even the maintainability > > requirements serve the kernel's many users. > > > > But you also knew that already. > > > > So what am I missing here? > > > > Hi Paul, > thanks for contributing your thoughts. It is nice to have a new voice > in the conversation, it helps me to maintain my illusion that this > issue is relevant to the whole community. I am not sure whether I should feel Australia-style chastened, American-style encouraged, or what, but either way, good show on that paragraph. ;-) > I cannot, of course, speak to why Josh wrote what he did, but I can > give some insight into why I had no disagreement with that part of his > statement. > A key insight, worth your time to consider and unpack I think, is > > People won't care what you know, until they know that you care. > > I won't dwell on that here, but will make some more obviously relevant > observations. > > Firstly, you gave an analytical response to what was, in my view, an > emotional observation. While I agree with your analysis, it is largely > irrelevant. It is not how people *feel* about kernel development. > > You say that the code of conflict is gone, but in fact much of it is > preserved in the code-of-conduct-interpretation. If you reflect on the > focus of the second para of that document (which I think was directly > lifted from the code-of-conflict) you will see that value is placed > squarely on the code (kernel code, not code of conduct). The code is > put forward as the thing of primary importance. People (you, me) are > only mentioned in the context of being the authors of code that will be > criticised - because (it almost says this) we care about the code, but > not about you. > > So I think it is beyond argument that the value system presented by > this paragraph is > code > people > > I think this is particularly unfortunate as it is not really how the > community works, and not really how Linus works, except in those > occasional outbursts that are publicised so much. > > I recall two specific events (there were probably others) from early in > my Linux experience where Linus said/did things which said to me that > he valued me, not just the code that I wrote. I think he did that a > lot (and probably still does). As I knew that he "cared", I was much > more interested in what he knew/thought. > > I think that the fact that Linus is now acknowledging every "pull" > request is brilliant. It doesn't really help the process much (we all > have plenty of visibility into what Linus has pulled) and doesn't help > the code (directly) at all. But it tells people that Linus can see > them, and has seen them. It also allows people to see that they have > an email from Linus without expecting it to be a criticism. Certainly > he still criticises and is right to do so, and he doesn't say "Pulled, > thanks", which would be my preference, but the fact that he responds at > least says "me responding to you matters" and by implication "you > matter". > > (The code-of-conflict only acknowledged that you matter once you feel > personally abused). I agree that Linus's acknowledging pull requests is a good thing. I have long appreciated my upstream maintainer doing the same, and I do try to acknowledge patch submissions myself. And yes, motivating people is an underappreciated art, and an art made more difficult by the wide variety of mindsets, even within a relatively like-minded community such as the Linux kernel community. So I agree that improvements are welcome, and further believe that there always will be room for improvement. But I am still not seeing "code > people" in the interpretation document. For me, it is all about people. Back to "People won't care what you know, until they know that you care." Fortunately for me, it is not necessary for all that many people to care what I know, given that I have the usual human limitations on the number of individuals that I can directly relate to, and this number is way less than the billions that have some relationship to the Linux kernel, unwitting though that relationship is in the common case. In contrast, back in the late 70s, my software had two users, and I frequently chatted with both of them. This is clearly not possible in the case of the Linux kernel. Nor would it be all that helpful, given that all they really need from me is to keep RCU working properly. So I instead create an abstraction of those users' needs in the form of requirements. These requirements might seem dull and uninspiring, but they are in fact a proxy for the needs of the users. In short, instead of "code > people", I am seeing "our users need us". Thanx, Paul > Thanks, > NeilBrown > > > > Thanx, Paul > > > >> (Leaving aside that the more important detail > >> would be the community actually acting consistently with the code of > >> conduct it espoused.) > >> > >> > In the current code, would The "Our Pledge" section have been > >> > sufficient, or do you think the other sections would have actually > >> > helped you? > >> > >> "Our Standards" would have been at least as important to me personally, > >> as would "Enforcement" (and more importantly, examples of that applying > >> in practice and not just as empty words). > >> _______________________________________________ > >> Ksummit-discuss mailing list > >> Ksummit-discuss@lists.linuxfoundation.org > >> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss > >> ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Ksummit-discuss] Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document 2018-11-02 13:33 ` Paul E. McKenney @ 2018-11-03 8:36 ` NeilBrown 2018-11-03 17:37 ` Paul E. McKenney 0 siblings, 1 reply; 104+ messages in thread From: NeilBrown @ 2018-11-03 8:36 UTC (permalink / raw) To: paulmck Cc: Josh Triplett, Mishi Choudhary, Greg Kroah-Hartman, linux-kernel, ksummit-discuss [-- Attachment #1: Type: text/plain, Size: 11967 bytes --] On Fri, Nov 02 2018, Paul E. McKenney wrote: > On Fri, Nov 02, 2018 at 08:50:11AM +1100, NeilBrown wrote: >> On Thu, Nov 01 2018, Paul E. McKenney wrote: >> >> > On Sat, Oct 27, 2018 at 02:10:10AM +0100, Josh Triplett wrote: >> >> On Fri, Oct 26, 2018 at 08:14:51AM +1100, NeilBrown wrote: >> >> > On Wed, Oct 24 2018, Josh Triplett wrote: >> >> > >> >> > > On Tue, Oct 23, 2018 at 07:26:06AM +1100, NeilBrown wrote: >> >> > >> On Sun, Oct 21 2018, 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 >> >> > >> >> >> >> > >> >> #Isupportreversion >> >> > >> >> >> >> > >> >> I call on the community to consider what *does* need to be said, about >> >> > >> >> conduct, to people outside the community and who have recently joined. >> >> > >> >> What is the document that you would have liked to have read as you were >> >> > >> >> starting out? It is all too long ago for me to remember clearly, and so >> >> > >> >> much has changed. >> >> > >> > >> >> > >> > The document I would have liked to have read when starting out is >> >> > >> > currently checked into the source tree in >> >> > >> > Documentation/process/code-of-conduct.rst . >> >> > >> >> >> > >> I'm curious - what would you have gained by reading that document? >> >> > > >> >> > > I would have then had rather less of a pervasive feeling of "if I make >> >> > > even a single mistake I get made an example of in ways that will feed >> >> > > people's quotes files for years to come". >> >> > >> >> > Thanks for your reply. Certainly feeling safe is important, and having >> >> > clear statements that the community values and promotes psychological >> >> > safety is valuable. >> >> > >> >> > The old "code of conflict" said >> >> > If however, anyone feels personally abused, threatened, or otherwise >> >> > uncomfortable due to this process, that is not acceptable. >> >> > >> >> > would you have not found this a strong enough statement to ward off that >> >> > pervasive feeling? >> >> >> >> Not when that document started out effectively saying, in an elaborate >> >> way, "code > people". >> > >> > Interesting. >> > >> > I am curious what leads you to your "code > people" statement. Of course, >> > one could argue that this does not really matter given that the code of >> > conflict is no longer. However, I would like to understand for future >> > reference, if for no other reason. >> > >> > One possibility is that you are restricting the "people" to only those >> > people directly contributing in one way or another. But those using the >> > kernel (both directly and indirectly) are important as well, and it is >> > exactly this group that is served by "the most robust operating system >> > kernel ever", the chest-beating sentiment notwithstanding. Which is in >> > fact why I must reject (or rework or whatever) any patch that might result >> > in too-short RCU grace periods: The needs of the patch's submitter are >> > quite emphatically outweighed by the needs of the kernel's many users, >> > and many of the various technical requirements and restrictions are in >> > fact proxies for the needs of these users. >> > >> > But you knew that already. >> > >> > Similarly for the Linux kernel's various code-style strictures, which >> > serve the surprisingly large group of people reading the kernel's code. >> > Including the stricture that I most love to hate, which is the one >> > stating that single-line do/for/if/while statements must not be enclosed >> > in braces, which sometimes causes me trouble when inserting debug code, >> > but which also makes more code fit into a window of a given size. ;-) >> > >> > But you knew that already, too. >> > >> > The maintainability requirements can be argued to mostly serve the >> > maintainers, but if the code becomes unmaintainable, future users >> > will be inconvenienced, to say the least. So even the maintainability >> > requirements serve the kernel's many users. >> > >> > But you also knew that already. >> > >> > So what am I missing here? >> > >> >> Hi Paul, >> thanks for contributing your thoughts. It is nice to have a new voice >> in the conversation, it helps me to maintain my illusion that this >> issue is relevant to the whole community. > > I am not sure whether I should feel Australia-style chastened, > American-style encouraged, or what, but either way, good show on that > paragraph. ;-) > >> I cannot, of course, speak to why Josh wrote what he did, but I can >> give some insight into why I had no disagreement with that part of his >> statement. >> A key insight, worth your time to consider and unpack I think, is >> >> People won't care what you know, until they know that you care. >> >> I won't dwell on that here, but will make some more obviously relevant >> observations. >> >> Firstly, you gave an analytical response to what was, in my view, an >> emotional observation. While I agree with your analysis, it is largely >> irrelevant. It is not how people *feel* about kernel development. >> >> You say that the code of conflict is gone, but in fact much of it is >> preserved in the code-of-conduct-interpretation. If you reflect on the >> focus of the second para of that document (which I think was directly >> lifted from the code-of-conflict) you will see that value is placed >> squarely on the code (kernel code, not code of conduct). The code is >> put forward as the thing of primary importance. People (you, me) are >> only mentioned in the context of being the authors of code that will be >> criticised - because (it almost says this) we care about the code, but >> not about you. >> >> So I think it is beyond argument that the value system presented by >> this paragraph is >> code > people >> >> I think this is particularly unfortunate as it is not really how the >> community works, and not really how Linus works, except in those >> occasional outbursts that are publicised so much. >> >> I recall two specific events (there were probably others) from early in >> my Linux experience where Linus said/did things which said to me that >> he valued me, not just the code that I wrote. I think he did that a >> lot (and probably still does). As I knew that he "cared", I was much >> more interested in what he knew/thought. >> >> I think that the fact that Linus is now acknowledging every "pull" >> request is brilliant. It doesn't really help the process much (we all >> have plenty of visibility into what Linus has pulled) and doesn't help >> the code (directly) at all. But it tells people that Linus can see >> them, and has seen them. It also allows people to see that they have >> an email from Linus without expecting it to be a criticism. Certainly >> he still criticises and is right to do so, and he doesn't say "Pulled, >> thanks", which would be my preference, but the fact that he responds at >> least says "me responding to you matters" and by implication "you >> matter". >> >> (The code-of-conflict only acknowledged that you matter once you feel >> personally abused). > > I agree that Linus's acknowledging pull requests is a good thing. I have > long appreciated my upstream maintainer doing the same, and I do try to > acknowledge patch submissions myself. And yes, motivating people is an > underappreciated art, and an art made more difficult by the wide variety > of mindsets, even within a relatively like-minded community such as the > Linux kernel community. So I agree that improvements are welcome, and > further believe that there always will be room for improvement. > > But I am still not seeing "code > people" in the interpretation document. > For me, it is all about people. > > Back to "People won't care what you know, until they know that you care." > > Fortunately for me, it is not necessary for all that many people to care > what I know, given that I have the usual human limitations on the number > of individuals that I can directly relate to, and this number is way > less than the billions that have some relationship to the Linux kernel, > unwitting though that relationship is in the common case. > > In contrast, back in the late 70s, my software had two users, and I > frequently chatted with both of them. This is clearly not possible in > the case of the Linux kernel. Nor would it be all that helpful, given > that all they really need from me is to keep RCU working properly. > So I instead create an abstraction of those users' needs in the form > of requirements. These requirements might seem dull and uninspiring, > but they are in fact a proxy for the needs of the users. > > In short, instead of "code > people", I am seeing "our users need us". > Ok, maybe we need to introduce a distinction here. - our users are affected by our product - our developers are affected by our process The para in question talks a lot about meeting the needs of our users, and says almost nothing about meeting the needs of our developers. In fact, our developers need to submit their needs to the needs for the users. So maybe the inequality is "users > developers". Now you and I and most of the community know that this isn't true, the developers are actually valued: patches are reviewed, bug reports are attended to, questions are answered. On re-reading the text in question, I see that it says: Your contributions and ideas behind them will be carefully reviewed, ... and while that is a good thing, it really doesn't come across as welcoming to me. ( .... will be *welcomed* and carefully reviewed....) And I guess this highlights the wisdom of your response to Josh: Communication is inherently difficult. This is, in part, why I suggest that we shouldn't have a code of conduct at all. Whatever we write, different people will understand it differently. And history suggests that some of us will treat it like a legal document and try to be lawyers, but without all the training real lawyers have. Instead of a code of conduct, we just need good conduct, and to encourage that conduct when we see it. This builds on our core competencies as a community: our usual mode of working is to each work independently on our own areas, and to combine our skills intermittently as need and opportunity arises. The "Linux kernel" emerges organically from the work of multiple developers, and likewise, the only meaningful statement of the conduct of the community is that conduct with emerges organically from the conduct of the members. Thanks, NeilBrown > Thanx, Paul > >> Thanks, >> NeilBrown >> >> >> > Thanx, Paul >> > >> >> (Leaving aside that the more important detail >> >> would be the community actually acting consistently with the code of >> >> conduct it espoused.) >> >> >> >> > In the current code, would The "Our Pledge" section have been >> >> > sufficient, or do you think the other sections would have actually >> >> > helped you? >> >> >> >> "Our Standards" would have been at least as important to me personally, >> >> as would "Enforcement" (and more importantly, examples of that applying >> >> in practice and not just as empty words). >> >> _______________________________________________ >> >> Ksummit-discuss mailing list >> >> Ksummit-discuss@lists.linuxfoundation.org >> >> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss >> >> [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 832 bytes --] ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Ksummit-discuss] Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document 2018-11-03 8:36 ` NeilBrown @ 2018-11-03 17:37 ` Paul E. McKenney 2018-11-03 21:06 ` NeilBrown 0 siblings, 1 reply; 104+ messages in thread From: Paul E. McKenney @ 2018-11-03 17:37 UTC (permalink / raw) To: NeilBrown Cc: Josh Triplett, Mishi Choudhary, Greg Kroah-Hartman, linux-kernel, ksummit-discuss On Sat, Nov 03, 2018 at 07:36:19PM +1100, NeilBrown wrote: > On Fri, Nov 02 2018, Paul E. McKenney wrote: > > > On Fri, Nov 02, 2018 at 08:50:11AM +1100, NeilBrown wrote: > >> On Thu, Nov 01 2018, Paul E. McKenney wrote: > >> > >> > On Sat, Oct 27, 2018 at 02:10:10AM +0100, Josh Triplett wrote: > >> >> On Fri, Oct 26, 2018 at 08:14:51AM +1100, NeilBrown wrote: > >> >> > On Wed, Oct 24 2018, Josh Triplett wrote: > >> >> > > >> >> > > On Tue, Oct 23, 2018 at 07:26:06AM +1100, NeilBrown wrote: > >> >> > >> On Sun, Oct 21 2018, 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 > >> >> > >> >> > >> >> > >> >> #Isupportreversion > >> >> > >> >> > >> >> > >> >> I call on the community to consider what *does* need to be said, about > >> >> > >> >> conduct, to people outside the community and who have recently joined. > >> >> > >> >> What is the document that you would have liked to have read as you were > >> >> > >> >> starting out? It is all too long ago for me to remember clearly, and so > >> >> > >> >> much has changed. > >> >> > >> > > >> >> > >> > The document I would have liked to have read when starting out is > >> >> > >> > currently checked into the source tree in > >> >> > >> > Documentation/process/code-of-conduct.rst . > >> >> > >> > >> >> > >> I'm curious - what would you have gained by reading that document? > >> >> > > > >> >> > > I would have then had rather less of a pervasive feeling of "if I make > >> >> > > even a single mistake I get made an example of in ways that will feed > >> >> > > people's quotes files for years to come". > >> >> > > >> >> > Thanks for your reply. Certainly feeling safe is important, and having > >> >> > clear statements that the community values and promotes psychological > >> >> > safety is valuable. > >> >> > > >> >> > The old "code of conflict" said > >> >> > If however, anyone feels personally abused, threatened, or otherwise > >> >> > uncomfortable due to this process, that is not acceptable. > >> >> > > >> >> > would you have not found this a strong enough statement to ward off that > >> >> > pervasive feeling? > >> >> > >> >> Not when that document started out effectively saying, in an elaborate > >> >> way, "code > people". > >> > > >> > Interesting. > >> > > >> > I am curious what leads you to your "code > people" statement. Of course, > >> > one could argue that this does not really matter given that the code of > >> > conflict is no longer. However, I would like to understand for future > >> > reference, if for no other reason. > >> > > >> > One possibility is that you are restricting the "people" to only those > >> > people directly contributing in one way or another. But those using the > >> > kernel (both directly and indirectly) are important as well, and it is > >> > exactly this group that is served by "the most robust operating system > >> > kernel ever", the chest-beating sentiment notwithstanding. Which is in > >> > fact why I must reject (or rework or whatever) any patch that might result > >> > in too-short RCU grace periods: The needs of the patch's submitter are > >> > quite emphatically outweighed by the needs of the kernel's many users, > >> > and many of the various technical requirements and restrictions are in > >> > fact proxies for the needs of these users. > >> > > >> > But you knew that already. > >> > > >> > Similarly for the Linux kernel's various code-style strictures, which > >> > serve the surprisingly large group of people reading the kernel's code. > >> > Including the stricture that I most love to hate, which is the one > >> > stating that single-line do/for/if/while statements must not be enclosed > >> > in braces, which sometimes causes me trouble when inserting debug code, > >> > but which also makes more code fit into a window of a given size. ;-) > >> > > >> > But you knew that already, too. > >> > > >> > The maintainability requirements can be argued to mostly serve the > >> > maintainers, but if the code becomes unmaintainable, future users > >> > will be inconvenienced, to say the least. So even the maintainability > >> > requirements serve the kernel's many users. > >> > > >> > But you also knew that already. > >> > > >> > So what am I missing here? > >> > > >> > >> Hi Paul, > >> thanks for contributing your thoughts. It is nice to have a new voice > >> in the conversation, it helps me to maintain my illusion that this > >> issue is relevant to the whole community. > > > > I am not sure whether I should feel Australia-style chastened, > > American-style encouraged, or what, but either way, good show on that > > paragraph. ;-) > > > >> I cannot, of course, speak to why Josh wrote what he did, but I can > >> give some insight into why I had no disagreement with that part of his > >> statement. > >> A key insight, worth your time to consider and unpack I think, is > >> > >> People won't care what you know, until they know that you care. > >> > >> I won't dwell on that here, but will make some more obviously relevant > >> observations. > >> > >> Firstly, you gave an analytical response to what was, in my view, an > >> emotional observation. While I agree with your analysis, it is largely > >> irrelevant. It is not how people *feel* about kernel development. > >> > >> You say that the code of conflict is gone, but in fact much of it is > >> preserved in the code-of-conduct-interpretation. If you reflect on the > >> focus of the second para of that document (which I think was directly > >> lifted from the code-of-conflict) you will see that value is placed > >> squarely on the code (kernel code, not code of conduct). The code is > >> put forward as the thing of primary importance. People (you, me) are > >> only mentioned in the context of being the authors of code that will be > >> criticised - because (it almost says this) we care about the code, but > >> not about you. > >> > >> So I think it is beyond argument that the value system presented by > >> this paragraph is > >> code > people > >> > >> I think this is particularly unfortunate as it is not really how the > >> community works, and not really how Linus works, except in those > >> occasional outbursts that are publicised so much. > >> > >> I recall two specific events (there were probably others) from early in > >> my Linux experience where Linus said/did things which said to me that > >> he valued me, not just the code that I wrote. I think he did that a > >> lot (and probably still does). As I knew that he "cared", I was much > >> more interested in what he knew/thought. > >> > >> I think that the fact that Linus is now acknowledging every "pull" > >> request is brilliant. It doesn't really help the process much (we all > >> have plenty of visibility into what Linus has pulled) and doesn't help > >> the code (directly) at all. But it tells people that Linus can see > >> them, and has seen them. It also allows people to see that they have > >> an email from Linus without expecting it to be a criticism. Certainly > >> he still criticises and is right to do so, and he doesn't say "Pulled, > >> thanks", which would be my preference, but the fact that he responds at > >> least says "me responding to you matters" and by implication "you > >> matter". > >> > >> (The code-of-conflict only acknowledged that you matter once you feel > >> personally abused). > > > > I agree that Linus's acknowledging pull requests is a good thing. I have > > long appreciated my upstream maintainer doing the same, and I do try to > > acknowledge patch submissions myself. And yes, motivating people is an > > underappreciated art, and an art made more difficult by the wide variety > > of mindsets, even within a relatively like-minded community such as the > > Linux kernel community. So I agree that improvements are welcome, and > > further believe that there always will be room for improvement. > > > > But I am still not seeing "code > people" in the interpretation document. > > For me, it is all about people. > > > > Back to "People won't care what you know, until they know that you care." > > > > Fortunately for me, it is not necessary for all that many people to care > > what I know, given that I have the usual human limitations on the number > > of individuals that I can directly relate to, and this number is way > > less than the billions that have some relationship to the Linux kernel, > > unwitting though that relationship is in the common case. > > > > In contrast, back in the late 70s, my software had two users, and I > > frequently chatted with both of them. This is clearly not possible in > > the case of the Linux kernel. Nor would it be all that helpful, given > > that all they really need from me is to keep RCU working properly. > > So I instead create an abstraction of those users' needs in the form > > of requirements. These requirements might seem dull and uninspiring, > > but they are in fact a proxy for the needs of the users. > > > > In short, instead of "code > people", I am seeing "our users need us". > > Ok, maybe we need to introduce a distinction here. > - our users are affected by our product > - our developers are affected by our process > > The para in question talks a lot about meeting the needs of our users, > and says almost nothing about meeting the needs of our developers. In > fact, our developers need to submit their needs to the needs for the > users. So maybe the inequality is "users > developers". > > Now you and I and most of the community know that this isn't true, the > developers are actually valued: patches are reviewed, bug reports are > attended to, questions are answered. I completely and emphatically agree that the reality is quite a bit more complicated and nuanced than can be captured by sound bites, whether inequalities or otherwise. For example, one sense in which "users > developers" might be said to be true is that things usually don't go at all well for developers when users vote with their feet, abandoning the project. And one sense in which "developers > users" might be said to be true is in terms of direct influence over the project itself. I am quite confident that you could easily come up with a very large number of additional examples supporting any number of inequalities between any number of pairs of subgroups within the greater Linux-kernel community. ;-) > On re-reading the text in question, I see that it says: > > Your contributions and ideas behind them will be > carefully reviewed, ... > > and while that is a good thing, it really doesn't come across as > welcoming to me. ( .... will be *welcomed* and carefully reviewed....) Heh! Like many people in my country, there is a mat labeled "Welcome" in front of my door. And, again like many people in my country, that door is almost always locked, which is admittedly strange and ironic enough. But given where the code of conduct is located, it would be more like a "Welcome" mat hidden in the shrubbery behind my house, now wouldn't it? Which would be even more strange, though perhaps no more ironic. Yet putting the code of conduct (say) in all caps in the Linux kernel's home directory might not be sending all that positive a message, so it makes no sense to move it from its current location. We therefore cannot really rely on the code of conduct to serve as the Linux kernel's "Welcome" mat. Nor should that be its purpose. > And I guess this highlights the wisdom of your response to Josh: > Communication is inherently difficult. Thank you, much though I wish I was wrong on this point. > This is, in part, why I suggest that we shouldn't have a code of conduct > at all. Whatever we write, different people will understand it > differently. And history suggests that some of us will treat it like a > legal document and try to be lawyers, but without all the training real > lawyers have. > > Instead of a code of conduct, we just need good conduct, and to > encourage that conduct when we see it. > This builds on our core competencies as a community: our usual mode of > working is to each work independently on our own areas, and to combine > our skills intermittently as need and opportunity arises. The "Linux > kernel" emerges organically from the work of multiple developers, and > likewise, the only meaningful statement of the conduct of the community is > that conduct with emerges organically from the conduct of the members. If the was a perfect world, we might well not need a code of conduct. On the other hand, in a perfect world we also just might not need locks (with or without the ironic "Welcome" mat), passwords, urgent security patches, fences topped with concertina wire, weapons, and much more besides. So rather than randomly mutate the code of conduct further, let alone remove it completely, let's instead leave it alone for a few years. We then might have enough experience with it to make any needed adjustments. Of course, the optimal outcome would be zero experience with it at all ever due to overwhelming best behavior on the part of all concerned, but again, this world is sometimes less than perfect. Thanx, Paul ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Ksummit-discuss] Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document 2018-11-03 17:37 ` Paul E. McKenney @ 2018-11-03 21:06 ` NeilBrown 2018-11-03 22:23 ` Paul E. McKenney 0 siblings, 1 reply; 104+ messages in thread From: NeilBrown @ 2018-11-03 21:06 UTC (permalink / raw) To: paulmck Cc: Josh Triplett, Mishi Choudhary, Greg Kroah-Hartman, linux-kernel, ksummit-discuss [-- Attachment #1: Type: text/plain, Size: 15410 bytes --] On Sat, Nov 03 2018, Paul E. McKenney wrote: > On Sat, Nov 03, 2018 at 07:36:19PM +1100, NeilBrown wrote: >> On Fri, Nov 02 2018, Paul E. McKenney wrote: >> >> > On Fri, Nov 02, 2018 at 08:50:11AM +1100, NeilBrown wrote: >> >> On Thu, Nov 01 2018, Paul E. McKenney wrote: >> >> >> >> > On Sat, Oct 27, 2018 at 02:10:10AM +0100, Josh Triplett wrote: >> >> >> On Fri, Oct 26, 2018 at 08:14:51AM +1100, NeilBrown wrote: >> >> >> > On Wed, Oct 24 2018, Josh Triplett wrote: >> >> >> > >> >> >> > > On Tue, Oct 23, 2018 at 07:26:06AM +1100, NeilBrown wrote: >> >> >> > >> On Sun, Oct 21 2018, 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 >> >> >> > >> >> >> >> >> > >> >> #Isupportreversion >> >> >> > >> >> >> >> >> > >> >> I call on the community to consider what *does* need to be said, about >> >> >> > >> >> conduct, to people outside the community and who have recently joined. >> >> >> > >> >> What is the document that you would have liked to have read as you were >> >> >> > >> >> starting out? It is all too long ago for me to remember clearly, and so >> >> >> > >> >> much has changed. >> >> >> > >> > >> >> >> > >> > The document I would have liked to have read when starting out is >> >> >> > >> > currently checked into the source tree in >> >> >> > >> > Documentation/process/code-of-conduct.rst . >> >> >> > >> >> >> >> > >> I'm curious - what would you have gained by reading that document? >> >> >> > > >> >> >> > > I would have then had rather less of a pervasive feeling of "if I make >> >> >> > > even a single mistake I get made an example of in ways that will feed >> >> >> > > people's quotes files for years to come". >> >> >> > >> >> >> > Thanks for your reply. Certainly feeling safe is important, and having >> >> >> > clear statements that the community values and promotes psychological >> >> >> > safety is valuable. >> >> >> > >> >> >> > The old "code of conflict" said >> >> >> > If however, anyone feels personally abused, threatened, or otherwise >> >> >> > uncomfortable due to this process, that is not acceptable. >> >> >> > >> >> >> > would you have not found this a strong enough statement to ward off that >> >> >> > pervasive feeling? >> >> >> >> >> >> Not when that document started out effectively saying, in an elaborate >> >> >> way, "code > people". >> >> > >> >> > Interesting. >> >> > >> >> > I am curious what leads you to your "code > people" statement. Of course, >> >> > one could argue that this does not really matter given that the code of >> >> > conflict is no longer. However, I would like to understand for future >> >> > reference, if for no other reason. >> >> > >> >> > One possibility is that you are restricting the "people" to only those >> >> > people directly contributing in one way or another. But those using the >> >> > kernel (both directly and indirectly) are important as well, and it is >> >> > exactly this group that is served by "the most robust operating system >> >> > kernel ever", the chest-beating sentiment notwithstanding. Which is in >> >> > fact why I must reject (or rework or whatever) any patch that might result >> >> > in too-short RCU grace periods: The needs of the patch's submitter are >> >> > quite emphatically outweighed by the needs of the kernel's many users, >> >> > and many of the various technical requirements and restrictions are in >> >> > fact proxies for the needs of these users. >> >> > >> >> > But you knew that already. >> >> > >> >> > Similarly for the Linux kernel's various code-style strictures, which >> >> > serve the surprisingly large group of people reading the kernel's code. >> >> > Including the stricture that I most love to hate, which is the one >> >> > stating that single-line do/for/if/while statements must not be enclosed >> >> > in braces, which sometimes causes me trouble when inserting debug code, >> >> > but which also makes more code fit into a window of a given size. ;-) >> >> > >> >> > But you knew that already, too. >> >> > >> >> > The maintainability requirements can be argued to mostly serve the >> >> > maintainers, but if the code becomes unmaintainable, future users >> >> > will be inconvenienced, to say the least. So even the maintainability >> >> > requirements serve the kernel's many users. >> >> > >> >> > But you also knew that already. >> >> > >> >> > So what am I missing here? >> >> > >> >> >> >> Hi Paul, >> >> thanks for contributing your thoughts. It is nice to have a new voice >> >> in the conversation, it helps me to maintain my illusion that this >> >> issue is relevant to the whole community. >> > >> > I am not sure whether I should feel Australia-style chastened, >> > American-style encouraged, or what, but either way, good show on that >> > paragraph. ;-) >> > >> >> I cannot, of course, speak to why Josh wrote what he did, but I can >> >> give some insight into why I had no disagreement with that part of his >> >> statement. >> >> A key insight, worth your time to consider and unpack I think, is >> >> >> >> People won't care what you know, until they know that you care. >> >> >> >> I won't dwell on that here, but will make some more obviously relevant >> >> observations. >> >> >> >> Firstly, you gave an analytical response to what was, in my view, an >> >> emotional observation. While I agree with your analysis, it is largely >> >> irrelevant. It is not how people *feel* about kernel development. >> >> >> >> You say that the code of conflict is gone, but in fact much of it is >> >> preserved in the code-of-conduct-interpretation. If you reflect on the >> >> focus of the second para of that document (which I think was directly >> >> lifted from the code-of-conflict) you will see that value is placed >> >> squarely on the code (kernel code, not code of conduct). The code is >> >> put forward as the thing of primary importance. People (you, me) are >> >> only mentioned in the context of being the authors of code that will be >> >> criticised - because (it almost says this) we care about the code, but >> >> not about you. >> >> >> >> So I think it is beyond argument that the value system presented by >> >> this paragraph is >> >> code > people >> >> >> >> I think this is particularly unfortunate as it is not really how the >> >> community works, and not really how Linus works, except in those >> >> occasional outbursts that are publicised so much. >> >> >> >> I recall two specific events (there were probably others) from early in >> >> my Linux experience where Linus said/did things which said to me that >> >> he valued me, not just the code that I wrote. I think he did that a >> >> lot (and probably still does). As I knew that he "cared", I was much >> >> more interested in what he knew/thought. >> >> >> >> I think that the fact that Linus is now acknowledging every "pull" >> >> request is brilliant. It doesn't really help the process much (we all >> >> have plenty of visibility into what Linus has pulled) and doesn't help >> >> the code (directly) at all. But it tells people that Linus can see >> >> them, and has seen them. It also allows people to see that they have >> >> an email from Linus without expecting it to be a criticism. Certainly >> >> he still criticises and is right to do so, and he doesn't say "Pulled, >> >> thanks", which would be my preference, but the fact that he responds at >> >> least says "me responding to you matters" and by implication "you >> >> matter". >> >> >> >> (The code-of-conflict only acknowledged that you matter once you feel >> >> personally abused). >> > >> > I agree that Linus's acknowledging pull requests is a good thing. I have >> > long appreciated my upstream maintainer doing the same, and I do try to >> > acknowledge patch submissions myself. And yes, motivating people is an >> > underappreciated art, and an art made more difficult by the wide variety >> > of mindsets, even within a relatively like-minded community such as the >> > Linux kernel community. So I agree that improvements are welcome, and >> > further believe that there always will be room for improvement. >> > >> > But I am still not seeing "code > people" in the interpretation document. >> > For me, it is all about people. >> > >> > Back to "People won't care what you know, until they know that you care." >> > >> > Fortunately for me, it is not necessary for all that many people to care >> > what I know, given that I have the usual human limitations on the number >> > of individuals that I can directly relate to, and this number is way >> > less than the billions that have some relationship to the Linux kernel, >> > unwitting though that relationship is in the common case. >> > >> > In contrast, back in the late 70s, my software had two users, and I >> > frequently chatted with both of them. This is clearly not possible in >> > the case of the Linux kernel. Nor would it be all that helpful, given >> > that all they really need from me is to keep RCU working properly. >> > So I instead create an abstraction of those users' needs in the form >> > of requirements. These requirements might seem dull and uninspiring, >> > but they are in fact a proxy for the needs of the users. >> > >> > In short, instead of "code > people", I am seeing "our users need us". >> >> Ok, maybe we need to introduce a distinction here. >> - our users are affected by our product >> - our developers are affected by our process >> >> The para in question talks a lot about meeting the needs of our users, >> and says almost nothing about meeting the needs of our developers. In >> fact, our developers need to submit their needs to the needs for the >> users. So maybe the inequality is "users > developers". >> >> Now you and I and most of the community know that this isn't true, the >> developers are actually valued: patches are reviewed, bug reports are >> attended to, questions are answered. > > I completely and emphatically agree that the reality is quite a bit more > complicated and nuanced than can be captured by sound bites, whether > inequalities or otherwise. For example, one sense in which "users > > developers" might be said to be true is that things usually don't go > at all well for developers when users vote with their feet, abandoning > the project. And one sense in which "developers > users" might be said > to be true is in terms of direct influence over the project itself. > > I am quite confident that you could easily come up with a very large > number of additional examples supporting any number of inequalities > between any number of pairs of subgroups within the greater Linux-kernel > community. ;-) > >> On re-reading the text in question, I see that it says: >> >> Your contributions and ideas behind them will be >> carefully reviewed, ... >> >> and while that is a good thing, it really doesn't come across as >> welcoming to me. ( .... will be *welcomed* and carefully reviewed....) > > Heh! Like many people in my country, there is a mat labeled "Welcome" in > front of my door. And, again like many people in my country, that door > is almost always locked, which is admittedly strange and ironic enough. > But given where the code of conduct is located, it would be more like a > "Welcome" mat hidden in the shrubbery behind my house, now wouldn't it? > Which would be even more strange, though perhaps no more ironic. > > Yet putting the code of conduct (say) in all caps in the Linux kernel's > home directory might not be sending all that positive a message, so > it makes no sense to move it from its current location. We therefore > cannot really rely on the code of conduct to serve as the Linux kernel's > "Welcome" mat. Nor should that be its purpose. > >> And I guess this highlights the wisdom of your response to Josh: >> Communication is inherently difficult. > > Thank you, much though I wish I was wrong on this point. > >> This is, in part, why I suggest that we shouldn't have a code of conduct >> at all. Whatever we write, different people will understand it >> differently. And history suggests that some of us will treat it like a >> legal document and try to be lawyers, but without all the training real >> lawyers have. >> >> Instead of a code of conduct, we just need good conduct, and to >> encourage that conduct when we see it. >> This builds on our core competencies as a community: our usual mode of >> working is to each work independently on our own areas, and to combine >> our skills intermittently as need and opportunity arises. The "Linux >> kernel" emerges organically from the work of multiple developers, and >> likewise, the only meaningful statement of the conduct of the community is >> that conduct with emerges organically from the conduct of the members. > > If the was a perfect world, we might well not need a code of conduct. > On the other hand, in a perfect world we also just might not need locks > (with or without the ironic "Welcome" mat), passwords, urgent security > patches, fences topped with concertina wire, weapons, and much more > besides. > > So rather than randomly mutate the code of conduct further, let alone > remove it completely, let's instead leave it alone for a few years. > We then might have enough experience with it to make any needed > adjustments. Hi Paul, thanks for your thoughts, and particularly for the door-mat analogy. It is a thing of beauty. I agree that the window of opportunity appears to be closed. Indeed, it appears now that it was closed before I wrote my "Call to action" despite the apparent offer of an open discussion. Maybe I was the only one too blind to see that for what it was. > > Of course, the optimal outcome would be zero experience with it at all > ever due to overwhelming best behavior on the part of all concerned, > but again, this world is sometimes less than perfect. I have two concerns (fears??) going forward. One is that the CoC might be weaponized as has already happened to the GNU Kind Communication Guidelines - see the thread leading to the recent LWN QoTD by RMS. In essence, it is being used to attack rather than to protect (you could argue in this case it is also being used to defend in a different sense, but the attack is, I think, not healthy). Maybe I can now say "I told you so" - while that is cold comfort, it is still better than no comfort. The second is that people might perceive behavioural improvements in the community from this time, see the CoC added at this time, and incorrectly assume causality - the most likely actual cause is improvement in leadership. I hope that I have made enough noise that such people will think twice about copying our mistakes. Thanks, NeilBrown [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 832 bytes --] ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Ksummit-discuss] Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document 2018-11-03 21:06 ` NeilBrown @ 2018-11-03 22:23 ` Paul E. McKenney 0 siblings, 0 replies; 104+ messages in thread From: Paul E. McKenney @ 2018-11-03 22:23 UTC (permalink / raw) To: NeilBrown Cc: Josh Triplett, Mishi Choudhary, Greg Kroah-Hartman, linux-kernel, ksummit-discuss On Sun, Nov 04, 2018 at 08:06:41AM +1100, NeilBrown wrote: > On Sat, Nov 03 2018, Paul E. McKenney wrote: > > > On Sat, Nov 03, 2018 at 07:36:19PM +1100, NeilBrown wrote: > >> On Fri, Nov 02 2018, Paul E. McKenney wrote: > >> > >> > On Fri, Nov 02, 2018 at 08:50:11AM +1100, NeilBrown wrote: > >> >> On Thu, Nov 01 2018, Paul E. McKenney wrote: > >> >> > >> >> > On Sat, Oct 27, 2018 at 02:10:10AM +0100, Josh Triplett wrote: > >> >> >> On Fri, Oct 26, 2018 at 08:14:51AM +1100, NeilBrown wrote: > >> >> >> > On Wed, Oct 24 2018, Josh Triplett wrote: > >> >> >> > > >> >> >> > > On Tue, Oct 23, 2018 at 07:26:06AM +1100, NeilBrown wrote: > >> >> >> > >> On Sun, Oct 21 2018, 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 > >> >> >> > >> >> > >> >> >> > >> >> #Isupportreversion > >> >> >> > >> >> > >> >> >> > >> >> I call on the community to consider what *does* need to be said, about > >> >> >> > >> >> conduct, to people outside the community and who have recently joined. > >> >> >> > >> >> What is the document that you would have liked to have read as you were > >> >> >> > >> >> starting out? It is all too long ago for me to remember clearly, and so > >> >> >> > >> >> much has changed. > >> >> >> > >> > > >> >> >> > >> > The document I would have liked to have read when starting out is > >> >> >> > >> > currently checked into the source tree in > >> >> >> > >> > Documentation/process/code-of-conduct.rst . > >> >> >> > >> > >> >> >> > >> I'm curious - what would you have gained by reading that document? > >> >> >> > > > >> >> >> > > I would have then had rather less of a pervasive feeling of "if I make > >> >> >> > > even a single mistake I get made an example of in ways that will feed > >> >> >> > > people's quotes files for years to come". > >> >> >> > > >> >> >> > Thanks for your reply. Certainly feeling safe is important, and having > >> >> >> > clear statements that the community values and promotes psychological > >> >> >> > safety is valuable. > >> >> >> > > >> >> >> > The old "code of conflict" said > >> >> >> > If however, anyone feels personally abused, threatened, or otherwise > >> >> >> > uncomfortable due to this process, that is not acceptable. > >> >> >> > > >> >> >> > would you have not found this a strong enough statement to ward off that > >> >> >> > pervasive feeling? > >> >> >> > >> >> >> Not when that document started out effectively saying, in an elaborate > >> >> >> way, "code > people". > >> >> > > >> >> > Interesting. > >> >> > > >> >> > I am curious what leads you to your "code > people" statement. Of course, > >> >> > one could argue that this does not really matter given that the code of > >> >> > conflict is no longer. However, I would like to understand for future > >> >> > reference, if for no other reason. > >> >> > > >> >> > One possibility is that you are restricting the "people" to only those > >> >> > people directly contributing in one way or another. But those using the > >> >> > kernel (both directly and indirectly) are important as well, and it is > >> >> > exactly this group that is served by "the most robust operating system > >> >> > kernel ever", the chest-beating sentiment notwithstanding. Which is in > >> >> > fact why I must reject (or rework or whatever) any patch that might result > >> >> > in too-short RCU grace periods: The needs of the patch's submitter are > >> >> > quite emphatically outweighed by the needs of the kernel's many users, > >> >> > and many of the various technical requirements and restrictions are in > >> >> > fact proxies for the needs of these users. > >> >> > > >> >> > But you knew that already. > >> >> > > >> >> > Similarly for the Linux kernel's various code-style strictures, which > >> >> > serve the surprisingly large group of people reading the kernel's code. > >> >> > Including the stricture that I most love to hate, which is the one > >> >> > stating that single-line do/for/if/while statements must not be enclosed > >> >> > in braces, which sometimes causes me trouble when inserting debug code, > >> >> > but which also makes more code fit into a window of a given size. ;-) > >> >> > > >> >> > But you knew that already, too. > >> >> > > >> >> > The maintainability requirements can be argued to mostly serve the > >> >> > maintainers, but if the code becomes unmaintainable, future users > >> >> > will be inconvenienced, to say the least. So even the maintainability > >> >> > requirements serve the kernel's many users. > >> >> > > >> >> > But you also knew that already. > >> >> > > >> >> > So what am I missing here? > >> >> > > >> >> > >> >> Hi Paul, > >> >> thanks for contributing your thoughts. It is nice to have a new voice > >> >> in the conversation, it helps me to maintain my illusion that this > >> >> issue is relevant to the whole community. > >> > > >> > I am not sure whether I should feel Australia-style chastened, > >> > American-style encouraged, or what, but either way, good show on that > >> > paragraph. ;-) > >> > > >> >> I cannot, of course, speak to why Josh wrote what he did, but I can > >> >> give some insight into why I had no disagreement with that part of his > >> >> statement. > >> >> A key insight, worth your time to consider and unpack I think, is > >> >> > >> >> People won't care what you know, until they know that you care. > >> >> > >> >> I won't dwell on that here, but will make some more obviously relevant > >> >> observations. > >> >> > >> >> Firstly, you gave an analytical response to what was, in my view, an > >> >> emotional observation. While I agree with your analysis, it is largely > >> >> irrelevant. It is not how people *feel* about kernel development. > >> >> > >> >> You say that the code of conflict is gone, but in fact much of it is > >> >> preserved in the code-of-conduct-interpretation. If you reflect on the > >> >> focus of the second para of that document (which I think was directly > >> >> lifted from the code-of-conflict) you will see that value is placed > >> >> squarely on the code (kernel code, not code of conduct). The code is > >> >> put forward as the thing of primary importance. People (you, me) are > >> >> only mentioned in the context of being the authors of code that will be > >> >> criticised - because (it almost says this) we care about the code, but > >> >> not about you. > >> >> > >> >> So I think it is beyond argument that the value system presented by > >> >> this paragraph is > >> >> code > people > >> >> > >> >> I think this is particularly unfortunate as it is not really how the > >> >> community works, and not really how Linus works, except in those > >> >> occasional outbursts that are publicised so much. > >> >> > >> >> I recall two specific events (there were probably others) from early in > >> >> my Linux experience where Linus said/did things which said to me that > >> >> he valued me, not just the code that I wrote. I think he did that a > >> >> lot (and probably still does). As I knew that he "cared", I was much > >> >> more interested in what he knew/thought. > >> >> > >> >> I think that the fact that Linus is now acknowledging every "pull" > >> >> request is brilliant. It doesn't really help the process much (we all > >> >> have plenty of visibility into what Linus has pulled) and doesn't help > >> >> the code (directly) at all. But it tells people that Linus can see > >> >> them, and has seen them. It also allows people to see that they have > >> >> an email from Linus without expecting it to be a criticism. Certainly > >> >> he still criticises and is right to do so, and he doesn't say "Pulled, > >> >> thanks", which would be my preference, but the fact that he responds at > >> >> least says "me responding to you matters" and by implication "you > >> >> matter". > >> >> > >> >> (The code-of-conflict only acknowledged that you matter once you feel > >> >> personally abused). > >> > > >> > I agree that Linus's acknowledging pull requests is a good thing. I have > >> > long appreciated my upstream maintainer doing the same, and I do try to > >> > acknowledge patch submissions myself. And yes, motivating people is an > >> > underappreciated art, and an art made more difficult by the wide variety > >> > of mindsets, even within a relatively like-minded community such as the > >> > Linux kernel community. So I agree that improvements are welcome, and > >> > further believe that there always will be room for improvement. > >> > > >> > But I am still not seeing "code > people" in the interpretation document. > >> > For me, it is all about people. > >> > > >> > Back to "People won't care what you know, until they know that you care." > >> > > >> > Fortunately for me, it is not necessary for all that many people to care > >> > what I know, given that I have the usual human limitations on the number > >> > of individuals that I can directly relate to, and this number is way > >> > less than the billions that have some relationship to the Linux kernel, > >> > unwitting though that relationship is in the common case. > >> > > >> > In contrast, back in the late 70s, my software had two users, and I > >> > frequently chatted with both of them. This is clearly not possible in > >> > the case of the Linux kernel. Nor would it be all that helpful, given > >> > that all they really need from me is to keep RCU working properly. > >> > So I instead create an abstraction of those users' needs in the form > >> > of requirements. These requirements might seem dull and uninspiring, > >> > but they are in fact a proxy for the needs of the users. > >> > > >> > In short, instead of "code > people", I am seeing "our users need us". > >> > >> Ok, maybe we need to introduce a distinction here. > >> - our users are affected by our product > >> - our developers are affected by our process > >> > >> The para in question talks a lot about meeting the needs of our users, > >> and says almost nothing about meeting the needs of our developers. In > >> fact, our developers need to submit their needs to the needs for the > >> users. So maybe the inequality is "users > developers". > >> > >> Now you and I and most of the community know that this isn't true, the > >> developers are actually valued: patches are reviewed, bug reports are > >> attended to, questions are answered. > > > > I completely and emphatically agree that the reality is quite a bit more > > complicated and nuanced than can be captured by sound bites, whether > > inequalities or otherwise. For example, one sense in which "users > > > developers" might be said to be true is that things usually don't go > > at all well for developers when users vote with their feet, abandoning > > the project. And one sense in which "developers > users" might be said > > to be true is in terms of direct influence over the project itself. > > > > I am quite confident that you could easily come up with a very large > > number of additional examples supporting any number of inequalities > > between any number of pairs of subgroups within the greater Linux-kernel > > community. ;-) > > > >> On re-reading the text in question, I see that it says: > >> > >> Your contributions and ideas behind them will be > >> carefully reviewed, ... > >> > >> and while that is a good thing, it really doesn't come across as > >> welcoming to me. ( .... will be *welcomed* and carefully reviewed....) > > > > Heh! Like many people in my country, there is a mat labeled "Welcome" in > > front of my door. And, again like many people in my country, that door > > is almost always locked, which is admittedly strange and ironic enough. > > But given where the code of conduct is located, it would be more like a > > "Welcome" mat hidden in the shrubbery behind my house, now wouldn't it? > > Which would be even more strange, though perhaps no more ironic. > > > > Yet putting the code of conduct (say) in all caps in the Linux kernel's > > home directory might not be sending all that positive a message, so > > it makes no sense to move it from its current location. We therefore > > cannot really rely on the code of conduct to serve as the Linux kernel's > > "Welcome" mat. Nor should that be its purpose. > > > >> And I guess this highlights the wisdom of your response to Josh: > >> Communication is inherently difficult. > > > > Thank you, much though I wish I was wrong on this point. > > > >> This is, in part, why I suggest that we shouldn't have a code of conduct > >> at all. Whatever we write, different people will understand it > >> differently. And history suggests that some of us will treat it like a > >> legal document and try to be lawyers, but without all the training real > >> lawyers have. > >> > >> Instead of a code of conduct, we just need good conduct, and to > >> encourage that conduct when we see it. > >> This builds on our core competencies as a community: our usual mode of > >> working is to each work independently on our own areas, and to combine > >> our skills intermittently as need and opportunity arises. The "Linux > >> kernel" emerges organically from the work of multiple developers, and > >> likewise, the only meaningful statement of the conduct of the community is > >> that conduct with emerges organically from the conduct of the members. > > > > If the was a perfect world, we might well not need a code of conduct. > > On the other hand, in a perfect world we also just might not need locks > > (with or without the ironic "Welcome" mat), passwords, urgent security > > patches, fences topped with concertina wire, weapons, and much more > > besides. > > > > So rather than randomly mutate the code of conduct further, let alone > > remove it completely, let's instead leave it alone for a few years. > > We then might have enough experience with it to make any needed > > adjustments. > > Hi Paul, > thanks for your thoughts, and particularly for the door-mat analogy. > It is a thing of beauty. Glad you liked it. ;-) > I agree that the window of opportunity appears to be closed. Indeed, > it appears now that it was closed before I wrote my "Call to action" > despite the apparent offer of an open discussion. Maybe I was the only > one too blind to see that for what it was. If you were to assert that the move to the CoC has not been handled all that well, I would have a hard time arguing against you. On the other hand, I would also have a hard time arguing that I would have done any better. Life is like that sometimes... > > Of course, the optimal outcome would be zero experience with it at all > > ever due to overwhelming best behavior on the part of all concerned, > > but again, this world is sometimes less than perfect. > > I have two concerns (fears??) going forward. > One is that the CoC might be weaponized as has already happened to the > GNU Kind Communication Guidelines - see the thread leading to the recent > LWN QoTD by RMS. In essence, it is being used to attack rather than to > protect (you could argue in this case it is also being used to defend > in a different sense, but the attack is, I think, not healthy). > Maybe I can now say "I told you so" - while that is cold comfort, it is > still better than no comfort. I would like to believe that all the various players have good intentions as well as the intelligence, persistence, and strength of character required to have a fighting chance of producing good outcomes. If that turns out not to be the case, for example, if hordes of toxic characters descend on the Linux kernel community leveraging the CoC to disrupt and to do disservice to its various members, then this community most certainly has a good and sufficient number of people skilled in the art of blacklisting email addresses and, if need be, of "git rm". Nevertheless, to your point about the GNU Kind Communication Guidelines, given that RMS reportedly said of the CoC "I myself did not like the punitive spirit of that approach, and decided against it" [1], significant vigilance and caution might be warranted. Perhaps deletion of a certain paragraph from the Linux kernel's version of that CoC has made the spirit a bit less punitive. > The second is that people might perceive behavioural improvements in the > community from this time, see the CoC added at this time, and > incorrectly assume causality - the most likely actual cause is > improvement in leadership. I hope that I have made enough noise that > such people will think twice about copying our mistakes. My perception is that these behavioral improvements have been accumulating steadily since I joined almost twenty years ago. But if people claim that adopting the CoC magically made the Linux kernel community way better, well, that wouldn't be the strangest statement I have heard this year. A very low bar, to be sure, but a bar that would be cleared. ;-) Thanx, Paul [1] https://lwn.net/Articles/769167/ ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Ksummit-discuss] Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document 2018-11-01 21:50 ` NeilBrown 2018-11-02 13:33 ` Paul E. McKenney @ 2018-11-02 13:52 ` James Bottomley 2018-11-03 9:19 ` Eric S. Raymond 1 sibling, 1 reply; 104+ messages in thread From: James Bottomley @ 2018-11-02 13:52 UTC (permalink / raw) To: NeilBrown, paulmck, Josh Triplett Cc: Mishi Choudhary, Greg Kroah-Hartman, linux-kernel, ksummit-discuss [-- Attachment #1: Type: text/plain, Size: 1864 bytes --] On Fri, 2018-11-02 at 08:50 +1100, NeilBrown wrote: > Firstly, you gave an analytical response to what was, in my view, an > emotional observation. While I agree with your analysis, it is > largely irrelevant. It is not how people *feel* about kernel > development. > > You say that the code of conflict is gone, but in fact much of it is > preserved in the code-of-conduct-interpretation. If you reflect on > the focus of the second para of that document (which I think was > directly lifted from the code-of-conflict) you will see that value > is placed squarely on the code (kernel code, not code of > conduct). The code is put forward as the thing of primary > importance. People (you, me) are only mentioned in the context of > being the authors of code that will be criticised - because (it > almost says this) we care about the code, but not about you. > > So I think it is beyond argument that the value system presented by > this paragraph is > code > people Actually, I think this whole code vs people debate is a straw man and inherently inimical to the discussion. In neither code of conduct (old or new) is there any statement that allows one to make a value judgment of people relative to code, so the very premise you're all arguing on doesn't exist. The two separate, but related statements present in both systems are that the technical quality of the code going into the kernel is paramount and that we should try to be respectful of others in email or other interactions including code reviews. Code and people aren't opposites: you can give purely technical reviews with a laser like focus on quality and still do it respectfully. Or to put it another way: respecting code doesn't automatically mean you disrespect people, which seems to be what the '>' was implying. James [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 228 bytes --] ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Ksummit-discuss] Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document 2018-11-02 13:52 ` James Bottomley @ 2018-11-03 9:19 ` Eric S. Raymond 0 siblings, 0 replies; 104+ messages in thread From: Eric S. Raymond @ 2018-11-03 9:19 UTC (permalink / raw) To: James Bottomley Cc: NeilBrown, paulmck, Josh Triplett, Mishi Choudhary, Greg Kroah-Hartman, linux-kernel, ksummit-discuss [-- Attachment #1: Type: text/plain, Size: 854 bytes --] James Bottomley <James.Bottomley@HansenPartnership.com>: > Actually, I think this whole code vs people debate is a straw man and > inherently inimical to the discussion. In neither code of conduct (old > or new) is there any statement that allows one to make a value judgment > of people relative to code, so the very premise you're all arguing on > doesn't exist. The author's original version of the new CoC is, however, associated with (and intended by its author to implement) "The Post-Meritocracy Manifesto". https://postmeritocracy.org/ Do you think it's a stretch to see "people > code" in that? -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Ksummit-discuss] Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document 2018-10-24 12:16 ` Josh Triplett 2018-10-25 21:14 ` NeilBrown @ 2018-11-04 10:35 ` Geert Uytterhoeven 1 sibling, 0 replies; 104+ messages in thread From: Geert Uytterhoeven @ 2018-11-04 10:35 UTC (permalink / raw) To: Josh Triplett Cc: neil, mishi, Greg KH, Linux Kernel Mailing List, ksummit-discuss Hi Josh, On Wed, Oct 24, 2018 at 2:16 PM Josh Triplett <josh@joshtriplett.org> wrote: > On Tue, Oct 23, 2018 at 07:26:06AM +1100, NeilBrown wrote: > > On Sun, Oct 21 2018, 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 > > >> > > >> #Isupportreversion > > >> > > >> I call on the community to consider what *does* need to be said, about > > >> conduct, to people outside the community and who have recently joined. > > >> What is the document that you would have liked to have read as you were > > >> starting out? It is all too long ago for me to remember clearly, and so > > >> much has changed. > > > > > > The document I would have liked to have read when starting out is > > > currently checked into the source tree in > > > Documentation/process/code-of-conduct.rst . > > > > I'm curious - what would you have gained by reading that document? > > I would have then had rather less of a pervasive feeling of "if I make > even a single mistake I get made an example of in ways that will feed > people's quotes files for years to come". > > See > https://hbr.org/2017/08/high-performing-teams-need-psychological-safety-heres-how-to-create-it > for more on the benefits of that. Funny how you post a link to that article ;-) Because the psychological safety of the Linux kernel developers and maintainers is exactly what is being affected, due to the atmosphere surrounding this particular CoC. While the addition of the CoC Clarification did improve the general understanding, the addition of the CoC itself has already caused a chilling effect. From chatting at the conferences in Edinburgh, people do have concerns and comments, but many just do not want to express their thoughts and feelings in public... Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Ksummit-discuss] Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document 2018-10-21 21:20 ` Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document NeilBrown 2018-10-21 22:26 ` [Ksummit-discuss] " Josh Triplett @ 2018-10-21 22:33 ` Joe Perches 2018-10-21 22:37 ` Randy Dunlap 2018-10-22 9:09 ` Rainer Fiebig ` (4 subsequent siblings) 6 siblings, 1 reply; 104+ messages in thread From: Joe Perches @ 2018-10-21 22:33 UTC (permalink / raw) To: NeilBrown, Greg Kroah-Hartman, linux-kernel, Linus Torvalds Cc: ksummit-discuss, Mishi Choudhary On Mon, 2018-10-22 at 08:20 +1100, NeilBrown wrote: > On Sat, Oct 20 2018, Greg Kroah-Hartman wrote: > > As everyone knows by now, we added a new Code of Conduct to the kernel > > tree a few weeks ago. > > I wanted to stay detached from all this, but as remaining (publicly) > silent might be seen (publicly) as acquiescing, I hereby declare that: > I reject, as illegitimate, this Code and the process by > which it is being "developed". [] > I call on any other community members who reject this process to say so, > not to remain silent. The concept of describing a desire for pleasant interactions while developing the linux kernel is legitimate and useful. I do reject this process as well and I think the attempt to reform it via a private, non-public method is, at best, poor form. Joe Perches ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Ksummit-discuss] Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document 2018-10-21 22:33 ` Joe Perches @ 2018-10-21 22:37 ` Randy Dunlap 0 siblings, 0 replies; 104+ messages in thread From: Randy Dunlap @ 2018-10-21 22:37 UTC (permalink / raw) To: Joe Perches, NeilBrown, Greg Kroah-Hartman, linux-kernel, Linus Torvalds Cc: ksummit-discuss, Mishi Choudhary On 10/21/18 3:33 PM, Joe Perches wrote: > On Mon, 2018-10-22 at 08:20 +1100, NeilBrown wrote: >> On Sat, Oct 20 2018, Greg Kroah-Hartman wrote: >>> As everyone knows by now, we added a new Code of Conduct to the kernel >>> tree a few weeks ago. >> >> I wanted to stay detached from all this, but as remaining (publicly) >> silent might be seen (publicly) as acquiescing, I hereby declare that: >> I reject, as illegitimate, this Code and the process by >> which it is being "developed". > [] >> I call on any other community members who reject this process to say so, >> not to remain silent. > > The concept of describing a desire for pleasant interactions > while > developing the linux kernel is legitimate and useful. Agree. > I do reject this process as well and I think the attempt to > reform it via a private, non-public method is, at best, > poor form. and Agree. > Joe Perches Thanks. -- ~Randy ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document 2018-10-21 21:20 ` Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document NeilBrown 2018-10-21 22:26 ` [Ksummit-discuss] " Josh Triplett 2018-10-21 22:33 ` Joe Perches @ 2018-10-22 9:09 ` Rainer Fiebig 2018-10-22 11:02 ` [Ksummit-discuss] " James Bottomley ` (3 subsequent siblings) 6 siblings, 0 replies; 104+ messages in thread From: Rainer Fiebig @ 2018-10-22 9:09 UTC (permalink / raw) To: NeilBrown Cc: linux-kernel, Greg Kroah-Hartman, ksummit-discuss, Thomas Gleixner, Olof Johansson, Chris Mason, Mishi Choudhary Am Montag, 22. Oktober 2018, 08:20:11 schrieb NeilBrown: > On Sat, Oct 20 2018, Greg Kroah-Hartman wrote: > > Hi all, > > > > As everyone knows by now, we added a new Code of Conduct to the kernel > > tree a few weeks ago. > > I wanted to stay detached from all this, but as remaining (publicly) And I didn't expect myself to ever post in this matter again, as I had already given up and relegated it to the "waste of precious lifetime" category. But your initiative and courage deserve support and so: +1. > I call on the community to consider what *does* need to be said, about > conduct, to people outside the community and who have recently joined. > What is the document that you would have liked to have read as you were > starting out? It is all too long ago for me to remember clearly, and so > much has changed. On the day the patch came out, I started working on a modified version, a CoC that I could have lived with. I guess this was my way of dealing with this unfortunate affair. So please find below what I would have submitted for discussion. Thanks and regards! Rainer Fiebig Disclosure ========== My contribution to the Linux kernel is admittedly negligible: I run rc- kernels, have reported a few problems, helped to fix them and fixed one myself. To the extent of the time and effort this took me, I dare to give my opinion in this matter. --- Code of Conduct +++++++++++++++ The goal of the Linux kernel development process is to maintain and advance the most robust operating system kernel ever. Needless to say, views on how to achieve this will differ at times. In order to keep arguments civilized and to ensure an open, positive and constructive environment, we have setup guidelines that participants are expected to comply with: No bias ======= Nobody must be discriminated or favored due to personal traits like - for example - age, gender or ethnicity. They are irrelevant. What counts is whether the contribution is in line with a/m goal. Any such contribution will be carefully reviewed. Be excellent to each other ========================== Don't do to others what you don't want others to do to you. Straightforward talk is fine. But dissent can be communicated in a non-destructive manner. And keep in mind that at times it may be *you* who is dead wrong. Examples of encouraged behavior: * Being respectful of differing viewpoints * Criticizing constructively, i. e. showing ways for improvement * Accepting constructive criticism * Focusing on what is best for our goal and the community Examples of unacceptable behavior: * Comments intended to insult, depreciate or defame a person * Public or private harassment * Unwelcome sexual attention or advances * Fabricating incriminations by quoting out of context * Publishing others’ private information, such as a physical or electronic address, without explicit permission * Promoting political agendas * Trolling Responsibilities ================ All participants are responsible for complying with this Code of Conduct. Maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of obviously unacceptable behavior. Maintainers have the right to ban temporarily or permanently any contributor who's behavior is not aligned to this Code of Conduct. Arbitration =========== Anyone who feels abused, harassed or affected by otherwise unacceptable behavior may report this to the Technical Advisory Board (TAB) at <tab@lists.linux-foundation.org>. All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The TAB is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific arbitration policies may be posted separately. Attribution =========== Some elements of this Code of Conduct are derived from the Contributor Covenant, version 1.4, available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Ksummit-discuss] Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document 2018-10-21 21:20 ` Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document NeilBrown ` (2 preceding siblings ...) 2018-10-22 9:09 ` Rainer Fiebig @ 2018-10-22 11:02 ` James Bottomley 2018-10-24 8:49 ` Laura Abbott ` (2 subsequent siblings) 6 siblings, 0 replies; 104+ messages in thread From: James Bottomley @ 2018-10-22 11:02 UTC (permalink / raw) To: NeilBrown, Greg Kroah-Hartman, linux-kernel, Linus Torvalds Cc: ksummit-discuss, Mishi Choudhary [-- Attachment #1: Type: text/plain, Size: 2457 bytes --] On Mon, 2018-10-22 at 08:20 +1100, NeilBrown wrote: > On Sat, Oct 20 2018, Greg Kroah-Hartman wrote: > > > Hi all, > > > > As everyone knows by now, we added a new Code of Conduct to the > > kernel tree a few weeks ago. > > I wanted to stay detached from all this, but as remaining (publicly) > silent might be seen (publicly) as acquiescing, I hereby declare > that: > I reject, as illegitimate, this Code and the process by > which it is being "developed". > > It is clear from the surrounding discussions that this is well > outside our core competencies. It will be flawed, it isn't what we > need. > > I call on any other community members who reject this process to say > so, not to remain silent. > #Iobject Well, I've got to say we really know how to screw up the process by ramming this in at the last minute (again): https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8e630c31a3dfc7f4ab1007f95dd507cb2fe1dda5 So yes, I'll certainly object to our inability to follow an open process. > We don't need a "Code of Conduct" nearly as much as we need > "Leadership in conduct". Without the leadership, any code looks like > a joke. I do think we need something in document form, though. Not least because we do have a perception problem which having a document helps allay, mostly for external not internal perceptions. As I've said several times, we have been steadily getting better thanks mostly to internal people helping drive more civilised discussions and being more helpful to new patch submitters. I've also previously pointed out that I really like the debian code of conduct: https://www.debian.org/code_of_conduct But now that I'm in Edinburgh, I had a conversation with Jeremy Allison. Apparently the Samba community went through almost exactly the same thing as were going through now: attempt initially to impose the contributor covenant followed by an acrimonious argument (done mostly in private). However, one interesting thing for us might be their final endpoint: https://wiki.samba.org/index.php/How_to_do_Samba:_Nicely Which, like the debian document is a nicely engineered statement of values which is specifically tailored to their community and needs. The interesting thing is that eventually everyone in Samba agreed to this, including the people who initially tried to impose the contributor covenant. James [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 228 bytes --] ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document 2018-10-21 21:20 ` Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document NeilBrown ` (3 preceding siblings ...) 2018-10-22 11:02 ` [Ksummit-discuss] " James Bottomley @ 2018-10-24 8:49 ` Laura Abbott 2018-10-25 7:56 ` The linux devs can rescind their license grant visionsofalice 2018-10-25 22:02 ` Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document NeilBrown 2018-10-25 8:06 ` Pavel Machek 2018-10-25 11:20 ` Rainer Fiebig 6 siblings, 2 replies; 104+ messages in thread From: Laura Abbott @ 2018-10-24 8:49 UTC (permalink / raw) To: NeilBrown, Greg Kroah-Hartman, linux-kernel, Linus Torvalds Cc: ksummit-discuss, Thomas Gleixner, Olof Johansson, Chris Mason, Mishi Choudhary On 10/21/2018 02:20 PM, NeilBrown wrote: <snip> > I call on the community to consider what *does* need to be said, about > conduct, to people outside the community and who have recently joined. > What is the document that you would have liked to have read as you were > starting out? It is all too long ago for me to remember clearly, and so > much has changed. > I joined much more recently than many and what I would have wanted then is an interesting question. I probably would _not_ have wanted a code of conduct when I first started working in open source. I also said things in my younger years I regret and probably wouldn't have said if I was held to a higher standard of conduct. Younger me frequently put up with behavior I wouldn't tolerate today. Younger me also greatly benefited from the experience of other kernel developers giving me firm feedback in a helpful way and saying no to bad approaches. I don't believe I would have continued if I hadn't been given that feedback in a useful way. Today, I think the code of conduct is a very important addition to the community. It's a stronger assertion that the kernel community is committed to raising the bar for behavior. I have no concern about patch review or quality dropping because most maintainers demonstrate every day that they can give effective feedback. We're all going to screw that up sometimes and the Code of Conduct reminds us to do our best. Most issues that arise can be resolved with a private e-mail going "you might want to rethink your wording there." What the Code of Conduct also provides is confidence that more serious community issues such as harassment not related to patch review can be handled. It spells out certain behaviors that won't be tolerated and explains how those problems will be dealt with. Will those problems actually be handled appropriately when the time comes? I can't actually say for sure, but the kernel community works on trust so I guess I have to trust that it will. I really hope I never have to report harassment but I'm glad there's a process in place. Thanks, Laura ^ permalink raw reply [flat|nested] 104+ messages in thread
* The linux devs can rescind their license grant. 2018-10-24 8:49 ` Laura Abbott @ 2018-10-25 7:56 ` visionsofalice 2018-10-25 8:19 ` Greg Kroah-Hartman ` (4 more replies) 2018-10-25 22:02 ` Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document NeilBrown 1 sibling, 5 replies; 104+ messages in thread From: visionsofalice @ 2018-10-25 7:56 UTC (permalink / raw) To: linux-kernel Cc: rms, bruce, moglen, bkuhn, editor, NeilBrown, Greg Kroah-Hartman, Laura Abbott, Linus Torvalds, ksummit-discuss, Thomas Gleixner, Olof Johansson, Chris Mason, Mishi Choudhary, linux-kernel-owner The linux devs can rescind their license grant. Why don't they if they don't like the CoC. They did NOT give their code away. They merely licensed it to people for nothing. Licenses can be rescinded. The License text itself doesn't even disclaim the possibility of rescission. All it says is that those who are down stream of a violator won't have their license automatically revoked if the violator's is. (No this was NOT "debunked", it's a complete lie to say that the owner of the copyright cannot rescind his freely licensed (no consideration paid) property: yes the free software people ARE LYING - but EVERYONE now believes their lie even though their debunking was immediately debunked itself. - Since none of you woman worshiping anti-marry-little-girls** faggots are lawyers you believe whatever you're told by "SFConservancy"*) *(Who even had to bring in outside council themselves, inorder to conflate clause 4, having so little expertise on the subject in-house) **(YHWH explicitly allows men to have female children as brides (Devarim chapter 22, verse 28 (na'ar) (same expressed in the Septuagint (padia)) (including in cases of a forceful taking (taphas)) (Yes, white men (americans, anglos) are the enemy of YHWH's law, worldwide championing a system that condemns all men to slavery at women's feet - the position they themselves naturally gravitate to) ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: The linux devs can rescind their license grant. 2018-10-25 7:56 ` The linux devs can rescind their license grant visionsofalice @ 2018-10-25 8:19 ` Greg Kroah-Hartman 2018-10-25 19:39 ` Eric S. Raymond ` (2 more replies) 2018-10-27 5:04 ` The linux devs can rescind their license grant. - Additional restrictive terms visionsofalice ` (3 subsequent siblings) 4 siblings, 3 replies; 104+ messages in thread From: Greg Kroah-Hartman @ 2018-10-25 8:19 UTC (permalink / raw) To: visionsofalice Cc: linux-kernel, rms, bruce, moglen, bkuhn, editor, NeilBrown, Laura Abbott, Linus Torvalds, ksummit-discuss, Thomas Gleixner, Olof Johansson, Chris Mason, Mishi Choudhary, linux-kernel-owner On Thu, Oct 25, 2018 at 07:56:26AM +0000, visionsofalice@redchan.it wrote: > The linux devs can rescind their license grant. No they can not, please do not keep spreading false information. greg k-h ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: The linux devs can rescind their license grant. 2018-10-25 8:19 ` Greg Kroah-Hartman @ 2018-10-25 19:39 ` Eric S. Raymond 2018-10-25 20:47 ` Theodore Y. Ts'o 2018-10-26 13:15 ` Eben Moglen 2018-10-26 10:34 ` The linux devs can rescind their license grant visionsofalice 2018-10-29 22:31 ` Bradley M. Kuhn 2 siblings, 2 replies; 104+ messages in thread From: Eric S. Raymond @ 2018-10-25 19:39 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: visionsofalice, linux-kernel, rms, bruce, moglen, bkuhn, editor, NeilBrown, Laura Abbott, Linus Torvalds, ksummit-discuss, Thomas Gleixner, Olof Johansson, Chris Mason, Mishi Choudhary, linux-kernel-owner Greg Kroah-Hartman <gregkh@linuxfoundation.org>: > On Thu, Oct 25, 2018 at 07:56:26AM +0000, visionsofalice@redchan.it wrote: > > The linux devs can rescind their license grant. > > No they can not, please do not keep spreading false information. I think the confusion about whether applying GPL can be rescinded has obscured the most serious actual threat vector. Under Jacobsen vs. Katzer (535 f 3d 1373 fed cir 2008) authors of GPLed software have a specific right to relief (including injunctive relief) against misappropriation of their software. That ruling (which was the case of first impression on the binding status of the GPL) reputational damage is *specifically* recognized as grounds for relief. The anti-CoC dissidents don't have to rescind their license grant to cause a great deal of trouble. Instead they can invoke the doctrine established in Jacobsen vs. Katzer, seeking restraining orders. The line of argument is so simple that I could probably brief it myself, and I'm not a lawyer - just somebody who had to become a topic expert in this area to do my job as the founding president of OSI. For that matter, I don't think the question of whether the GPL can be rescinded is settled - nor does my wife Cathy Raymond, Esq., a practicing attorney who has also studied the relevant law. Be very skeptical about what the FSF or SFC tells you about this; they have a very strong institutional/ideological incentive to affirm irrevocability regardless of what the law actually says. I, on the other hand, don't have an ideological stake to defend in that argument; I'm telling you that the doctrine forbidding perpetual grants may very well have teeth here. There is, at any rate, significant risk that a court will see it that way. Between Jacobsen vs. Katzer and the prohibition against perpetual grants I think you are incurring a grave risk by assuming the dissidents have no ammunition. Better for both sides to climb down from a confrontational position before real damage gets done. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own. ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: The linux devs can rescind their license grant. 2018-10-25 19:39 ` Eric S. Raymond @ 2018-10-25 20:47 ` Theodore Y. Ts'o 2018-10-25 21:41 ` Eric S. Raymond 2018-10-25 23:32 ` Iván Chavero 2018-10-26 13:15 ` Eben Moglen 1 sibling, 2 replies; 104+ messages in thread From: Theodore Y. Ts'o @ 2018-10-25 20:47 UTC (permalink / raw) To: esr, Greg Kroah-Hartman, visionsofalice, linux-kernel, rms, bruce, moglen, bkuhn, editor, NeilBrown, Laura Abbott, Linus Torvalds, ksummit-discuss, Thomas Gleixner, Olof Johansson, Chris Mason, Mishi Choudhary, linux-kernel-owner On Thu, Oct 25, 2018 at 03:39:01PM -0400, Eric S. Raymond wrote: > > Under Jacobsen vs. Katzer (535 f 3d 1373 fed cir 2008) authors of > GPLed software have a specific right to relief (including injunctive > relief) against misappropriation of their software. That ruling (which > was the case of first impression on the binding status of the GPL) > reputational damage is *specifically* recognized as grounds for relief. I've read the legal briefs, and I'm pretty sure they don't say what you are claiming they say. Yes, I'm not a lawyer --- but that's OK --- neither are you. > The anti-CoC dissidents don't have to rescind their license grant to > cause a great deal of trouble. The *vast* majority of the "anti-CoC dissidents" who have been advancing this argument, have, as near as I can tell, little or no copyright ownership in the kernel. They are external trolls who are not members of the kernel development community, to the best of my belief and knowledge. In short; they are adding noise to the conversation, and have been presuming that in fact people are going to be regularly and summarily ejected from the community. In short, they are adding FUD, probably because they have their own agenda. I would recommend that before people respond such provocation messages, that they do a quick "git log" and find out whether they have in fact contributed code to the kernel at all, and if so, how long ago it was. Regards, - Ted ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: The linux devs can rescind their license grant. 2018-10-25 20:47 ` Theodore Y. Ts'o @ 2018-10-25 21:41 ` Eric S. Raymond 2018-10-25 22:12 ` NeilBrown 2018-10-25 23:06 ` Al Viro 2018-10-25 23:32 ` Iván Chavero 1 sibling, 2 replies; 104+ messages in thread From: Eric S. Raymond @ 2018-10-25 21:41 UTC (permalink / raw) To: Theodore Y. Ts'o, Greg Kroah-Hartman, visionsofalice, linux-kernel, rms, bruce, moglen, bkuhn, editor, NeilBrown, Laura Abbott, Linus Torvalds, ksummit-discuss, Thomas Gleixner, Olof Johansson, Chris Mason, Mishi Choudhary, linux-kernel-owner Theodore Y. Ts'o <tytso@mit.edu>: > On Thu, Oct 25, 2018 at 03:39:01PM -0400, Eric S. Raymond wrote: > > Under Jacobsen vs. Katzer (535 f 3d 1373 fed cir 2008) authors of > > GPLed software have a specific right to relief (including injunctive > > relief) against misappropriation of their software. That ruling (which > > was the case of first impression on the binding status of the GPL) > > reputational damage is *specifically* recognized as grounds for relief. > > I've read the legal briefs, and I'm pretty sure they don't say what > you are claiming they say. Yes, I'm not a lawyer --- but that's OK > --- neither are you. How much are you willing to gamble on not being wrong? > The *vast* majority of the "anti-CoC dissidents" who have been > advancing this argument, have, as near as I can tell, little or no > copyright ownership in the kernel. I do not have any facts with which to dispute this specific claim. However, I do notice that a significant number of long-time contributors have put themselves in the anti-CoC camp. I note Al Viro as a recent example. Even supposing you are right about most of the anti-Coc people being outsiders, a tiny minority of people with a genuine IP stake could do a lot of damage. I ask again: how much are you willing to gamble on not being wrong? I definitely do not want to see the kind of explosion we could witness. I think you are making it more likely rather than less by appearing high-handed and dismissive. Because, whatever the merits of the CoC itself, there has been a process failure here. It doesn't look good to be defending that failure. A change like the CoC adoption was not a good thing to do without proper public notice, discussion, and consensus-building *beforehand*. This was an unforced error on the part of the leadership group; please, *please* don't compound it by digging in around the error. Do you really think you're going to win hearts and minds among insider dissidents - people with a genuine stake - by dismissing the opposition as a troll job? Instead of declaiming about "trolls", how about we fix the process failure instead? -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own. ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: The linux devs can rescind their license grant. 2018-10-25 21:41 ` Eric S. Raymond @ 2018-10-25 22:12 ` NeilBrown 2018-10-25 22:38 ` Eric S. Raymond 2018-11-04 10:47 ` [Ksummit-discuss] " Geert Uytterhoeven 2018-10-25 23:06 ` Al Viro 1 sibling, 2 replies; 104+ messages in thread From: NeilBrown @ 2018-10-25 22:12 UTC (permalink / raw) To: esr, Theodore Y. Ts'o, Greg Kroah-Hartman, visionsofalice, linux-kernel, rms, bruce, moglen, bkuhn, editor, Laura Abbott, Linus Torvalds, ksummit-discuss, Thomas Gleixner, Olof Johansson, Chris Mason, Mishi Choudhary, linux-kernel-owner [-- Attachment #1: Type: text/plain, Size: 2999 bytes --] On Thu, Oct 25 2018, Eric S. Raymond wrote: > Theodore Y. Ts'o <tytso@mit.edu>: >> On Thu, Oct 25, 2018 at 03:39:01PM -0400, Eric S. Raymond wrote: >> > Under Jacobsen vs. Katzer (535 f 3d 1373 fed cir 2008) authors of >> > GPLed software have a specific right to relief (including injunctive >> > relief) against misappropriation of their software. That ruling (which >> > was the case of first impression on the binding status of the GPL) >> > reputational damage is *specifically* recognized as grounds for relief. >> >> I've read the legal briefs, and I'm pretty sure they don't say what >> you are claiming they say. Yes, I'm not a lawyer --- but that's OK >> --- neither are you. > > How much are you willing to gamble on not being wrong? > >> The *vast* majority of the "anti-CoC dissidents" who have been >> advancing this argument, have, as near as I can tell, little or no >> copyright ownership in the kernel. > > I do not have any facts with which to dispute this specific claim. > However, I do notice that a significant number of long-time > contributors have put themselves in the anti-CoC camp. I note Al Viro > as a recent example. I think you are blurring two groups here. Ted describes "anti-CoC dissidents" as people who are advancing an argument about rescinding their license. This is a smaller groups than the "ant-CoC camp" who don't really like the CoC. I suspect is it is a much smaller group when restricting to actual copyright holders. I am against the CoC as it stands, but rescinding any license is such an enormous over-reaction, I find the concept laughable. NeilBrown > > Even supposing you are right about most of the anti-Coc people being > outsiders, a tiny minority of people with a genuine IP stake could do a > lot of damage. I ask again: how much are you willing to gamble on not > being wrong? > > I definitely do not want to see the kind of explosion we could witness. > I think you are making it more likely rather than less by appearing > high-handed and dismissive. Because, whatever the merits of the > CoC itself, there has been a process failure here. It doesn't look > good to be defending that failure. > > A change like the CoC adoption was not a good thing to do without > proper public notice, discussion, and consensus-building *beforehand*. > This was an unforced error on the part of the leadership group; > please, *please* don't compound it by digging in around the error. Do > you really think you're going to win hearts and minds among insider > dissidents - people with a genuine stake - by dismissing the > opposition as a troll job? > > Instead of declaiming about "trolls", how about we fix the process > failure instead? > -- > <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> > > My work is funded by the Internet Civil Engineering Institute: https://icei.org > Please visit their site and donate: the civilization you save might be your own. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 832 bytes --] ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: The linux devs can rescind their license grant. 2018-10-25 22:12 ` NeilBrown @ 2018-10-25 22:38 ` Eric S. Raymond 2018-10-25 22:52 ` NeilBrown 2018-11-04 10:47 ` [Ksummit-discuss] " Geert Uytterhoeven 1 sibling, 1 reply; 104+ messages in thread From: Eric S. Raymond @ 2018-10-25 22:38 UTC (permalink / raw) To: NeilBrown Cc: Theodore Y. Ts'o, Greg Kroah-Hartman, visionsofalice, linux-kernel, rms, bruce, moglen, bkuhn, editor, Laura Abbott, Linus Torvalds, ksummit-discuss, Thomas Gleixner, Olof Johansson, Chris Mason, Mishi Choudhary, linux-kernel-owner [-- Attachment #1: Type: text/plain, Size: 1596 bytes --] NeilBrown <neil@brown.name>: > I think you are blurring two groups here. > Ted describes "anti-CoC dissidents" as people who are advancing an > argument about rescinding their license. This is a smaller groups than > the "ant-CoC camp" who don't really like the CoC. I suspect is it is a > much smaller group when restricting to actual copyright holders. You may be right that these are semi-distinct groups. I don't think the distinction makes a lot of difference to my argument, though. Either way, (a) there's been a process failure by the leadership, and (b) the threat of a massive legal disruption is real. > I am against the CoC as it stands, but rescinding any license is such an > enormous over-reaction, I find the concept laughable. I'm...not sure I do. I was going to agree with you that it's a massive overreaction, but then a simple question occurred to me: what else could *I* do if I thought I had a significant stake (I don't; my kernel contributions are minor and old) and felt my interests were damaged? All this could have been avoided so easily. A felt need for a new Code should not have been followed by the immediate imposition of one, but by a public RFC process and consensus-building - a process in which even those who lost arguments about the construction of the code could know they had been heard. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: The linux devs can rescind their license grant. 2018-10-25 22:38 ` Eric S. Raymond @ 2018-10-25 22:52 ` NeilBrown 0 siblings, 0 replies; 104+ messages in thread From: NeilBrown @ 2018-10-25 22:52 UTC (permalink / raw) To: esr Cc: Theodore Y. Ts'o, Greg Kroah-Hartman, visionsofalice, linux-kernel, rms, bruce, moglen, bkuhn, editor, Laura Abbott, Linus Torvalds, ksummit-discuss, Thomas Gleixner, Olof Johansson, Chris Mason, Mishi Choudhary, linux-kernel-owner [-- Attachment #1: Type: text/plain, Size: 2211 bytes --] On Thu, Oct 25 2018, Eric S. Raymond wrote: > NeilBrown <neil@brown.name>: >> I think you are blurring two groups here. >> Ted describes "anti-CoC dissidents" as people who are advancing an >> argument about rescinding their license. This is a smaller groups than >> the "ant-CoC camp" who don't really like the CoC. I suspect is it is a >> much smaller group when restricting to actual copyright holders. > > You may be right that these are semi-distinct groups. I don't think > the distinction makes a lot of difference to my argument, though. > Either way, (a) there's been a process failure by the leadership, and > (b) the threat of a massive legal disruption is real. > >> I am against the CoC as it stands, but rescinding any license is such an >> enormous over-reaction, I find the concept laughable. > > I'm...not sure I do. I was going to agree with you that it's a > massive overreaction, but then a simple question occurred to me: what > else could *I* do if I thought I had a significant stake (I don't; my > kernel contributions are minor and old) and felt my interests were > damaged? Reasonable people can certainly see this issue differently. My perspective is that I have already gained so much benefit in return for my investment that this is little more than a rounding error. If something happened that really did threaten the value of my investment, I'm sure there would be so many others who thought so too, that we would be able to fork the community. > > All this could have been avoided so easily. A felt need for a new Code > should not have been followed by the immediate imposition of one, > but by a public RFC process and consensus-building - a process in which > even those who lost arguments about the construction of the code could > know they had been heard. I do agree about the process failure. The "immediate imposition" was unnecessary and (I think) harmful. Thanks, NeilBrown > -- > <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> > > My work is funded by the Internet Civil Engineering Institute: https://icei.org > Please visit their site and donate: the civilization you save might be your own. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 832 bytes --] ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Ksummit-discuss] The linux devs can rescind their license grant. 2018-10-25 22:12 ` NeilBrown 2018-10-25 22:38 ` Eric S. Raymond @ 2018-11-04 10:47 ` Geert Uytterhoeven 1 sibling, 0 replies; 104+ messages in thread From: Geert Uytterhoeven @ 2018-11-04 10:47 UTC (permalink / raw) To: neil Cc: esr, Theodore Tso, Greg KH, visionsofalice, Linux Kernel Mailing List, rms, bruce, moglen, Bradley M. Kuhn, editor, Laura Abbott, torvalds, ksummit-discuss, Thomas Gleixner, Olof Johansson, Chris Mason, mishi, linux-kernel-owner On Fri, Oct 26, 2018 at 12:12 AM NeilBrown <neil@brown.name> wrote: > On Thu, Oct 25 2018, Eric S. Raymond wrote: > > Theodore Y. Ts'o <tytso@mit.edu>: > >> On Thu, Oct 25, 2018 at 03:39:01PM -0400, Eric S. Raymond wrote: > >> > Under Jacobsen vs. Katzer (535 f 3d 1373 fed cir 2008) authors of > >> > GPLed software have a specific right to relief (including injunctive > >> > relief) against misappropriation of their software. That ruling (which > >> > was the case of first impression on the binding status of the GPL) > >> > reputational damage is *specifically* recognized as grounds for relief. > >> > >> I've read the legal briefs, and I'm pretty sure they don't say what > >> you are claiming they say. Yes, I'm not a lawyer --- but that's OK > >> --- neither are you. > > > > How much are you willing to gamble on not being wrong? > > > >> The *vast* majority of the "anti-CoC dissidents" who have been > >> advancing this argument, have, as near as I can tell, little or no > >> copyright ownership in the kernel. > > > > I do not have any facts with which to dispute this specific claim. > > However, I do notice that a significant number of long-time > > contributors have put themselves in the anti-CoC camp. I note Al Viro > > as a recent example. > > I think you are blurring two groups here. > Ted describes "anti-CoC dissidents" as people who are advancing an > argument about rescinding their license. This is a smaller groups than > the "ant-CoC camp" who don't really like the CoC. I suspect is it is a > much smaller group when restricting to actual copyright holders. > > I am against the CoC as it stands, but rescinding any license is such an > enormous over-reaction, I find the concept laughable. Indeed. While I cannot comment on the legality of the rescinding, this rescinding is definitely not compatible with "be nice to each other", which is what all kernel developers who do not like the CoC as it stands, and who I'm aware of, do like as a general principle. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: The linux devs can rescind their license grant. 2018-10-25 21:41 ` Eric S. Raymond 2018-10-25 22:12 ` NeilBrown @ 2018-10-25 23:06 ` Al Viro 2018-10-26 2:28 ` Eric S. Raymond 2018-10-27 6:52 ` visionsofalice 1 sibling, 2 replies; 104+ messages in thread From: Al Viro @ 2018-10-25 23:06 UTC (permalink / raw) To: esr, Theodore Y. Ts'o, Greg Kroah-Hartman, visionsofalice, linux-kernel, rms, bruce, moglen, bkuhn, editor, NeilBrown, Laura Abbott, Linus Torvalds, ksummit-discuss, Thomas Gleixner, Olof Johansson, Chris Mason, Mishi Choudhary, linux-kernel-owner On Thu, Oct 25, 2018 at 05:41:23PM -0400, Eric S. Raymond wrote: > I do not have any facts with which to dispute this specific claim. > However, I do notice that a significant number of long-time > contributors have put themselves in the anti-CoC camp. I note Al Viro > as a recent example. *snort* For the record: * CoC is a piss-poor match for the structure of community * Linus had essentially tossed a live grenade into an outhouse on his way to vacation, with quite predictable results - all kinds of interesting coprophagous fauna dropping by to feed, including cartooneys of the sort I hadn't seen since NANAE days. * As idiotic gambits go, "try and revoke the license on my contributions, so that they'll have to revoke CoC" is... impressive. Sadly, my command of English has turned out to be woefully inadequate, and I can't even blame that on not being a native speaker; I'm just as incapable of producing a coherent (let alone printable) description of that cunning plan in any language, Russian included. I've tried. Really. * in case it needs to be spelled out: I am not at all interested in that kind of stunts. One of the reasons I thoroughly despise RMS and his bunch is the leverage game they tried to play with GPLv3; damned if I'm going to lower myself to their level. ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: The linux devs can rescind their license grant. 2018-10-25 23:06 ` Al Viro @ 2018-10-26 2:28 ` Eric S. Raymond 2018-10-26 5:49 ` Al Viro 2018-10-27 6:52 ` visionsofalice 1 sibling, 1 reply; 104+ messages in thread From: Eric S. Raymond @ 2018-10-26 2:28 UTC (permalink / raw) To: Al Viro Cc: Theodore Y. Ts'o, Greg Kroah-Hartman, visionsofalice, linux-kernel, rms, bruce, moglen, bkuhn, editor, NeilBrown, Laura Abbott, Linus Torvalds, ksummit-discuss, Thomas Gleixner, Olof Johansson, Chris Mason, Mishi Choudhary, linux-kernel-owner Al Viro <viro@ZenIV.linux.org.uk>: > * in case it needs to be spelled out: I am not at all interested > in that kind of stunts. One of the reasons I thoroughly despise RMS > and his bunch is the leverage game they tried to play with GPLv3; > damned if I'm going to lower myself to their level. Sorry, I did not mean to imply that you are one with the license-revokers. More like "if even Al Viro thinks you fucked up your process, it would be unwise to dismiss the opposition to the CoC as mere trolls". *I* can't dismiss it, because I read my mail. Apparently lots of people think that it is *my* job to fix this mess, or at least to give it a good hard try. I doubt they're trolling; what would be the point? -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own. ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: The linux devs can rescind their license grant. 2018-10-26 2:28 ` Eric S. Raymond @ 2018-10-26 5:49 ` Al Viro 0 siblings, 0 replies; 104+ messages in thread From: Al Viro @ 2018-10-26 5:49 UTC (permalink / raw) To: esr, Theodore Y. Ts'o, Greg Kroah-Hartman, visionsofalice, linux-kernel, rms, bruce, moglen, bkuhn, editor, NeilBrown, Laura Abbott, Linus Torvalds, ksummit-discuss, Thomas Gleixner, Olof Johansson, Chris Mason, Mishi Choudhary, linux-kernel-owner On Thu, Oct 25, 2018 at 10:28:36PM -0400, Eric S. Raymond wrote: > Al Viro <viro@ZenIV.linux.org.uk>: > > * in case it needs to be spelled out: I am not at all interested > > in that kind of stunts. One of the reasons I thoroughly despise RMS > > and his bunch is the leverage game they tried to play with GPLv3; > > damned if I'm going to lower myself to their level. > > Sorry, I did not mean to imply that you are one with the license-revokers. > More like "if even Al Viro thinks you fucked up your process, it would be > unwise to dismiss the opposition to the CoC as mere trolls". Kindly stop conflating opposition to CoC with that kind of idiocy. ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: The linux devs can rescind their license grant. 2018-10-25 23:06 ` Al Viro 2018-10-26 2:28 ` Eric S. Raymond @ 2018-10-27 6:52 ` visionsofalice 2018-10-27 7:32 ` Al Viro 1 sibling, 1 reply; 104+ messages in thread From: visionsofalice @ 2018-10-27 6:52 UTC (permalink / raw) To: linux-kernel Cc: esr, Theodore Y. Ts'o, Greg Kroah-Hartman, Al Viro, rms, bruce, moglen, bkuhn, editor, NeilBrown, Laura Abbott, Linus Torvalds, ksummit-discuss, Thomas Gleixner, Olof Johansson, Chris Mason, Mishi Choudhary, linux-kernel-owner Al: the FSF was so insistent on the adoption of the GPL version 3 because the GPL version 2 is not operative against the grantor. This deficiency was, in their eyes, so fatal to the purposes that they envisioned that they, as you have pointed out, elected to employ enhanced means of converting projects to version 3. Eben Moglen's contention that the GPL 3 exists to internationalize the GPL is a lie of omission. It is true that that is a partial reason-to-be for the GPL version 3 but it is not the main nor most important reason for the insistence on version 3 or "v2 or any later version". The very heart of the GPLv3 is the addition of the "irrevocable by grantor" clause and the "term of years" clause. Additionally the contention by the FSF and, as I recall, Eben Moglen that the reason the FSF only accepts code where the copyright is transferred to the FSF - is so they may have standing to sue - is another lie by omission. Yes, standing to sue is vital, if you are going to sue. But the real beating heart of the copyright assignment policy is to prevent a programmer from rescinding license-to-use regarding his freely given code. Without copyright assignment, any contributor to the GNU project could elect to rescind the gratis license grant at his pleasure, at any time, as of right. Without an "irrevocable by grantor" clause (as seen in the GPL version 3, but omitted in GPL version 2 due to a mis-assumption on the part of the drafter) there is not even an affirmative defense of promissory estoppel. We come to lie number three. (Neccecitated by:) The incorrect assumption made by the drafter of version 2 of the GPL and memorandized by Eben Moglen in this very thread in an attempt to protect the error in drafting. Lie number three: If terms regarding termination are proffered in a copyright license they are the only means of termination. This is true... If those terms are supported by bargained-for consideration. That is: the words Eben Moglen wrote were true; as regards to commercial software, where the licensee has paid valuable consideration for the terms offered. The drafter of version 2 of the GPL was familiar with such commercial licensing agreements. He failed in his due-diligence if RMS did indeed request an irrevocable-by-grantor license. The drafter stopped his research at the typical copyright license stage, and did not research further into what underlays the construction there-of. And thus we have the lie of omission number 3. (All, naturally, to protect Eben Moglen's former client and to discourage litigation where there is, indeed, good and sufficient cause for such litigation) (Which is all part of an attorney's duties, I can assure you) On 2018-10-25 23:06, Al Viro wrote: > On Thu, Oct 25, 2018 at 05:41:23PM -0400, Eric S. Raymond wrote: > >> I do not have any facts with which to dispute this specific claim. >> However, I do notice that a significant number of long-time >> contributors have put themselves in the anti-CoC camp. I note Al Viro >> as a recent example. > > *snort* > > For the record: > * CoC is a piss-poor match for the structure of community > * Linus had essentially tossed a live grenade into an outhouse on > his way to vacation, with quite predictable results - all kinds of > interesting coprophagous fauna dropping by to feed, including > cartooneys > of the sort I hadn't seen since NANAE days. > * As idiotic gambits go, "try and revoke the license on my > contributions, so that they'll have to revoke CoC" is... impressive. > Sadly, my command of English has turned out to be woefully inadequate, > and I can't even blame that on not being a native speaker; I'm just as > incapable of producing a coherent (let alone printable) description of > that cunning plan in any language, Russian included. I've tried. > Really. > * in case it needs to be spelled out: I am not at all interested > in that kind of stunts. One of the reasons I thoroughly despise RMS > and his bunch is the leverage game they tried to play with GPLv3; > damned if I'm going to lower myself to their level. ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: The linux devs can rescind their license grant. 2018-10-27 6:52 ` visionsofalice @ 2018-10-27 7:32 ` Al Viro 2018-10-27 16:18 ` [Ksummit-discuss] " Tim.Bird 0 siblings, 1 reply; 104+ messages in thread From: Al Viro @ 2018-10-27 7:32 UTC (permalink / raw) To: visionsofalice Cc: linux-kernel, esr, Theodore Y. Ts'o, Greg Kroah-Hartman, rms, bruce, moglen, bkuhn, editor, NeilBrown, Laura Abbott, Linus Torvalds, ksummit-discuss, Thomas Gleixner, Olof Johansson, Chris Mason, Mishi Choudhary, linux-kernel-owner On Sat, Oct 27, 2018 at 06:52:44AM +0000, visionsofalice@redchan.it wrote: > Al: the FSF was so insistent on the adoption of the GPL version 3 > because the GPL version 2 is not operative against the grantor. Anonymous wankstain: sod off and learn to troll properly. It *is* an art form, and the one you are clearly not up to. D-. For the effort and successful use of spellchecker. The style and contents are about F to E-, unfortunately, so take that in the spirit in which it is offered. As a participation award, that is. *plonk* ^ permalink raw reply [flat|nested] 104+ messages in thread
* RE: [Ksummit-discuss] The linux devs can rescind their license grant. 2018-10-27 7:32 ` Al Viro @ 2018-10-27 16:18 ` Tim.Bird 2018-10-27 22:09 ` Jiri Kosina 0 siblings, 1 reply; 104+ messages in thread From: Tim.Bird @ 2018-10-27 16:18 UTC (permalink / raw) To: viro, visionsofalice Cc: linux-kernel-owner, rms, ksummit-discuss, mishi, gregkh, bruce, linux-kernel, esr, bkuhn, editor, neil, moglen > -----Original Message----- > From: Al Viro > > On Sat, Oct 27, 2018 at 06:52:44AM +0000, visionsofalice@redchan.it wrote: > > Al: the FSF was so insistent on the adoption of the GPL version 3 > > because the GPL version 2 is not operative against the grantor. > > Anonymous wankstain: sod off and learn to troll properly. It *is* an art > form, and the one you are clearly not up to. > > D-. For the effort and successful use of spellchecker. The style and > contents are about F to E-, unfortunately, so take that in the spirit > in which it is offered. As a participation award, that is. Al, Can you please, even in the face of comments you find irritating, keep your responses more civil? Calling someone a "wankstain" is unprofessional, and we're trying to raise the level of discourse here. > > *plonk* I think this part of the response was sufficient to communicate that you do not take the suggestions of the other party seriously. And it communicates to others the right approach. If someone thinks that another person is acting in bad faith, I think it's better to just stop listening to that person, and let that person know it, and to let other community members know it. De-escalation is preferable to engagement when working with someone who is acting in bad faith. Although I disagree with the approach used in the top portion of this message, I am grateful that you are committed to protecting Linux and our development community. Regards, -- Tim ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Ksummit-discuss] The linux devs can rescind their license grant. 2018-10-27 16:18 ` [Ksummit-discuss] " Tim.Bird @ 2018-10-27 22:09 ` Jiri Kosina [not found] ` <CAK2MWOtNUTjWy5pTcGco5DNurqNCc=9CfDJ-Ko-K+6HDC55ikg@mail.gmail.com> 2018-10-28 21:13 ` NeilBrown 0 siblings, 2 replies; 104+ messages in thread From: Jiri Kosina @ 2018-10-27 22:09 UTC (permalink / raw) To: Tim.Bird Cc: viro, visionsofalice, linux-kernel-owner, rms, ksummit-discuss, mishi, gregkh, bruce, linux-kernel, esr, moglen, bkuhn, neil, editor On Sat, 27 Oct 2018, Tim.Bird@sony.com wrote: > Al, > > Can you please, even in the face of comments you find irritating, keep > your responses more civil? Calling someone a "wankstain" is > unprofessional Tim, to be completely honest, communicating anonymously doesn't really match my "this is highly professional" standards either, so I don't think we should be losing too much sleep over this particular e-mail exchange. CoC explicitly requires us to be reasonably nice to the human being on the other end of the wire, which I whole-heartedly believe is a very noble and nice goal. But you really have to know at least a little bit who's there on the other end. Otherwise failure to communicate might be sort of inevitable. -- Jiri Kosina SUSE Labs ^ permalink raw reply [flat|nested] 104+ messages in thread
[parent not found: <CAK2MWOtNUTjWy5pTcGco5DNurqNCc=9CfDJ-Ko-K+6HDC55ikg@mail.gmail.com>]
* Re: [Ksummit-discuss] The linux devs can rescind their license grant. [not found] ` <CAK2MWOtNUTjWy5pTcGco5DNurqNCc=9CfDJ-Ko-K+6HDC55ikg@mail.gmail.com> @ 2018-10-27 23:07 ` Eric S. Raymond 2018-10-27 23:40 ` Al Viro 1 sibling, 0 replies; 104+ messages in thread From: Eric S. Raymond @ 2018-10-27 23:07 UTC (permalink / raw) To: Bruce Perens Cc: Jiri Kosina, Tim.Bird, Al Viro, linux-kernel-owner, rms, ksummit-discuss, Mishi Choudhary, Greg Kroah-Hartman, linux-kernel, moglen, Bradley M. Kuhn, Neil Brown, editor Bruce Perens <bruce@perens.com>: > The anonymous person is generally thought to have appeared on the net > previously as MikeeUSA. That entity has a well-recorded history of misogyny > and other anti-social behaviour. He's also complained to me recently that > because of "people like me", the law prohibits him from marrying very young > women. I mean single-digit young. Although he is not at all meritorious of > your civil behavior, you may not wish to lower yourself to his level. I strongly doubt it. I've had my own run-in with MikeeUSA; I remember it vividly and unpleasantly. The prose style doesn't match. MikeeUSA could barely maintain coherent communication; this guy is using language that indicates he's at least several degrees brighter. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own. ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Ksummit-discuss] The linux devs can rescind their license grant. [not found] ` <CAK2MWOtNUTjWy5pTcGco5DNurqNCc=9CfDJ-Ko-K+6HDC55ikg@mail.gmail.com> 2018-10-27 23:07 ` Eric S. Raymond @ 2018-10-27 23:40 ` Al Viro 1 sibling, 0 replies; 104+ messages in thread From: Al Viro @ 2018-10-27 23:40 UTC (permalink / raw) To: Bruce Perens Cc: Jiri Kosina, Tim.Bird, linux-kernel-owner, rms, ksummit-discuss, Mishi Choudhary, Greg Kroah-Hartman, linux-kernel, Eric Raymond, moglen, Bradley M. Kuhn, Neil Brown, editor On Sat, Oct 27, 2018 at 03:46:02PM -0700, Bruce Perens wrote: > The anonymous person is generally thought to have appeared on the net > previously as MikeeUSA. That entity has a well-recorded history of misogyny > and other anti-social behaviour. You are misreading it - behaviour of that... member of our biological species is entirely controlled by its desperate need to be noticed, no matter what. Pathetic, but that's the social shmedia generation for you... I wouldn't be surprised if s/h/it maintains a sock puppet or two in the other bunch of PETA-level wankers^W^W^W^Wculture warriors, BTW. ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Ksummit-discuss] The linux devs can rescind their license grant. 2018-10-27 22:09 ` Jiri Kosina [not found] ` <CAK2MWOtNUTjWy5pTcGco5DNurqNCc=9CfDJ-Ko-K+6HDC55ikg@mail.gmail.com> @ 2018-10-28 21:13 ` NeilBrown 1 sibling, 0 replies; 104+ messages in thread From: NeilBrown @ 2018-10-28 21:13 UTC (permalink / raw) To: Jiri Kosina, Tim.Bird Cc: viro, visionsofalice, linux-kernel-owner, rms, ksummit-discuss, mishi, gregkh, bruce, linux-kernel, esr, moglen, bkuhn, editor [-- Attachment #1: Type: text/plain, Size: 1602 bytes --] On Sun, Oct 28 2018, Jiri Kosina wrote: > On Sat, 27 Oct 2018, Tim.Bird@sony.com wrote: > >> Al, >> >> Can you please, even in the face of comments you find irritating, keep >> your responses more civil? Calling someone a "wankstain" is >> unprofessional > > Tim, > > to be completely honest, communicating anonymously doesn't really match my > "this is highly professional" standards either, so I don't think we should > be losing too much sleep over this particular e-mail exchange. I agree with Tim here. It doesn't really matter who (or what) you are talking to, what matters is the context in which you are talking. We seem to be trying to raise the standard of communication within the kernel community. That means all communication. > > CoC explicitly requires us to be reasonably nice to the human being on the > other end of the wire, which I whole-heartedly believe is a very noble and > nice goal. But you really have to know at least a little bit who's there > on the other end. Otherwise failure to communicate might be sort of > inevitable. As you know, I think the CoC is a mistake and should be removed. But seeing you to play that game: 1/ code-of-conduct.rst doesn't contain the word "human" at all 2/ code-of-conduect-interpretation.rst explicitly says We know everyone is human which could be read as implying that you need to treat the other person as human, even if they don't act that way. Do you *really* want to use the CoC to support your position? Thanks, NeilBrown > > -- > Jiri Kosina > SUSE Labs [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 832 bytes --] ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: The linux devs can rescind their license grant. 2018-10-25 20:47 ` Theodore Y. Ts'o 2018-10-25 21:41 ` Eric S. Raymond @ 2018-10-25 23:32 ` Iván Chavero 1 sibling, 0 replies; 104+ messages in thread From: Iván Chavero @ 2018-10-25 23:32 UTC (permalink / raw) To: Theodore Y. Ts'o, esr, Greg Kroah-Hartman, visionsofalice, linux-kernel, rms, bruce, moglen, bkuhn, editor, NeilBrown, Laura Abbott, Linus Torvalds, ksummit-discuss, Thomas Gleixner, Olof Johansson, Chris Mason, Mishi Choudhary, linux-kernel-owner El jue, 25-10-2018 a las 16:47 -0400, Theodore Y. Ts'o escribió: > On Thu, Oct 25, 2018 at 03:39:01PM -0400, Eric S. Raymond wrote: > > > > Under Jacobsen vs. Katzer (535 f 3d 1373 fed cir 2008) authors of > > GPLed software have a specific right to relief (including > > injunctive > > relief) against misappropriation of their software. That ruling > > (which > > was the case of first impression on the binding status of the GPL) > > reputational damage is *specifically* recognized as grounds for > > relief. > > I've read the legal briefs, and I'm pretty sure they don't say what > you are claiming they say. Yes, I'm not a lawyer --- but that's OK > --- neither are you. > > > The anti-CoC dissidents don't have to rescind their license grant > > to > > cause a great deal of trouble. > > The *vast* majority of the "anti-CoC dissidents" who have been > advancing this argument, have, as near as I can tell, little or no > copyright ownership in the kernel. They are external trolls who are > not members of the kernel development community, to the best of my > belief and knowledge. I understand the point, but being an outsider from the kernel development community, does not mean i should not care about Linux development and this particular community. I have been promoting, using, installing, testing and loving Linux for more than 20 years now. One of the things that got me into it and still appreciate a lot is the meritocracy: the norm of technical excellence, the: "it does not matter who you are as long as you contribute good code". This CoC "movement" is part of an anti meritocracy "movement" that should not be influencing a project that thanks to this meritocracy has become the most important in the world. I'll take one of the arguments of the CoC promoters and use it on my favor: The Linux community has grown more than just a bunch of developers it has: promoters, users, testers, enthusiast, companies, foundations, etc... I wouldn't like that a negative code of conduct (yes its languaje is aggresive and charged with negativity, politics and victimization) compromise the technical aspects of a critical system like the Linux kernel. When it comes to coding, Engineers should be above that stuff. > > In short; they are adding noise to the conversation, and have been > presuming that in fact people are going to be regularly and summarily > ejected from the community. In short, they are adding FUD, probably > because they have their own agenda. I have one agenda: World Domination :P > I would recommend that before people respond such provocation > messages, that they do a quick "git log" and find out whether they > have in fact contributed code to the kernel at all, and if so, how > long ago it was. Just want to clarify that this is not a provocation, just got tired of being a passive member of this discussion. You're right the people with more merit in this list should have a more important voice since it shows the commitment to the development. BTW Thanks for the comment, i will start contributing to the extent of my capacities. As i say, the reach of Linux is broader than just the development community. Too bad you can't git log all the servers that people has installed and maintaining during the years. > Regards, > > - Ted Cheers, Ivan ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: The linux devs can rescind their license grant. 2018-10-25 19:39 ` Eric S. Raymond 2018-10-25 20:47 ` Theodore Y. Ts'o @ 2018-10-26 13:15 ` Eben Moglen 2018-10-26 15:50 ` Eric S. Raymond 2018-10-26 17:32 ` visionsofalice 1 sibling, 2 replies; 104+ messages in thread From: Eben Moglen @ 2018-10-26 13:15 UTC (permalink / raw) To: esr Cc: gregkh, visionsofalice, linux-kernel, rms, bruce, bkuhn, editor, neil, labbott, torvalds, ksummit-discuss, tglx, olof, clm, mishi, linux-kernel-owner On Thursday, 25 October 2018, Eric S. Raymond wrote: Under Jacobsen vs. Katzer (535 f 3d 1373 fed cir 2008) authors of GPLed software have a specific right to relief (including injunctive relief) against misappropriation of their software. That ruling (which was the case of first impression on the binding status of the GPL) No, Eric, _Jacobsen_ v. _Katzer_ has nothing to do with GPL. The license terms on the software at issue were Artistic 1.0. The GPL is mentioned in an informational footnote only. The case has little legal weight, for procedural reasons, and is most certainly not "the case of first impression on the binding status of the GPL." reputational damage is *specifically* recognized as grounds for relief. No. Reputational damage is not mentioned at all, let alone specifically recognized. The District Court opinion that was overturned in the Court of Appeals had held that licenses that don't require payment of royalties are unenforceable, which was not copyright law of any kind. The CAFC, guessing about the content of Ninth Circuit law under the jurisdictional rules of the appeal (a state of affairs which leaves no real precedential weight at all behind the opinion) rightly discovered that there are "economic interests" furthered by free licensing. Reputational interests are not among those mentioned. This is a <a href="https://caselaw.findlaw.com/us-federal-circuit/1189790.html">public document</a> anyone can read. I'm a little surprised you didn't check before asserting. The anti-CoC dissidents don't have to rescind their license grant to cause a great deal of trouble. Instead they can invoke the doctrine established in Jacobsen vs. Katzer, seeking restraining orders. They can do neither. There is no "doctrine established in Jacobsen." The license terms of the GPLv2, GPLv3, and all related licenses provide a mode of termination---for imposition of additional restrictions or violation of other terms. This termination provision, being explicit, is therefore the sole form of termination recognized under the terms of the Copyright Act. The line of argument is so simple that I could probably brief it myself, and I'm not a lawyer Law school exists to give people who are not yet lawyers a healthy respect for what they cannot do. This discussion has been a riot of amateur opining, but practicing law without a license is always a bad idea. For that matter, I don't think the question of whether the GPL can be rescinded is settled - nor does my wife Cathy Raymond, Esq., a practicing attorney who has also studied the relevant law. It is settled. Indeed, it was never in doubt. When Jerry Cohen made GPLv2 he was of course asked by Richard to make an irrevocable license. He did so. The US law provides that this license cannot be terminated except on its stated terms. But the basis of that rule, which is statutory, was not reliable under non-US law, so in GPLv3 I "codified" the US result in the license terms, as we did with various other features in which GPLv2 assumed the US law background. What the discussion set off by the present CoC controversy showed me was that there was no accessible, legally-accurate description of US copyright license termination law as it affects the various FOSS licenses in particular. I wrote such an article and began preparing it for publication, but was interrupted in that work by my mother's last illness and death. In the meantime everything said on all sides, for and against, has been wrong. The correct legal analysis has been offered nowhere. As I am beginning to return to work, I will publish the article soon. For now, the headline is that Greg is correct. There is nothing in the repeated assertions that some form of withdrawal of licensed rights or attacks on the copyright status of the kernel are a possible response to disagreement over changes in internal project governance. It's a small point---and like all the other supposed points raised so far, irrelevant---but I should say in passing, after years of teaching the basic Property course at Columbia and Harvard law schools, that Bruce Perens gave as succinct a description of the "rule against perpetuities" as I ever hear from a beginner in the classroom. In the English legal history course that I also teach (almost the only place in a modern law school in which the law of future interests is seriously considered), more is said. But the key point is that the "rule against perpetuities" is not a rule against perpetuities. The confusion on this point is one of the clearest signs that the writer or writers using various pseudonyms is/are not, whatever s/he claims, a US or UK lawyer at all. Eben -- Eben Moglen v: 212-461-1901 Professor of Law, Columbia Law School f: 212-854-7946 moglen@ 435 West 116th Street, New York City, NY 10027 columbia.edu Founding Director, Software Freedom Law Center softwarefreedom.org ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: The linux devs can rescind their license grant. 2018-10-26 13:15 ` Eben Moglen @ 2018-10-26 15:50 ` Eric S. Raymond 2018-10-26 15:53 ` Eben Moglen 2018-10-26 17:32 ` visionsofalice 1 sibling, 1 reply; 104+ messages in thread From: Eric S. Raymond @ 2018-10-26 15:50 UTC (permalink / raw) To: Eben Moglen Cc: gregkh, visionsofalice, linux-kernel, rms, bruce, bkuhn, editor, neil, labbott, torvalds, ksummit-discuss, tglx, olof, clm, mishi, linux-kernel-owner Eben Moglen <moglen@columbia.edu>: > reputational damage is *specifically* recognized as grounds for relief. > > No. Reputational damage is not mentioned at all, let alone > specifically recognized. I have no difficulty in finding the word "reputation" in the brief in in proximity with the phrase "increasing [the programmer's] recognition in his profession". In fact the brief notes " The Eleventh Circuit has recognized the economic motives inherent in public licenses, *even where profit is not immediate*" (Emphasis mine.) And "The attribution and modification transparency requirements directly serve to drive traffic to the open source incubation page and to inform downstream users of the project, which is a significant economic goal of the copyright holder *that the law will enforce.*" (Emphasis mine.) You seem to be denying that the brief says what it actually says. It not only qualifies reputational gain as a kind of economic gain - and thus losses as damage - but cites the Eleventh Circuit as a previous authority for the proposition, and affirms that these gains and losses can be a matter for the law. This disinclines me to trust the rest of your analysis or assertions. I think you are advocating for your interest in the perceived irrevocability of the GPL, and where this implies being less than fully forthcoming about the actual risks in *this* situation you are committing something perilously close to suppressio veri. This is not helpful. I've lived with a practising attorney since about the time she was one of the first-line legal reviewers for the original GPL back in the 1980s - we probably still have the draft printout with her scribbled annotations on it somewhere. "Only lawyers can interpret this voodoo" is not a good line to pull on me when it comes to open-source licensing; I don't buy it and she wouldn't either. Here's another sentence from the brief that I had forgotten: "Copyright holders who engage in open source licensing have the right to control the modification and distribution of copyrighted material." - a particularly telling sentence in regard to the current controversy, and one I had forgotten. That there could be enough to win the day for the license revokers - they don't actually have to revoke, just assert that control. Pretty much equivalent to what the the Berne Convention's moral-rights provision does in Europe - they could claim that the CoC is a defacement of their work to which they refuse assent and have a case. I am not at all doubtful that the dissidents know these things; some of the language in the broadsides to lkml so indicates. Which is why I'm trying to get the kernel leadership to repair its unnecessarily high-handed behavior before somebody gets pissed off enough to actually drop a bomb. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own. ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: The linux devs can rescind their license grant. 2018-10-26 15:50 ` Eric S. Raymond @ 2018-10-26 15:53 ` Eben Moglen 0 siblings, 0 replies; 104+ messages in thread From: Eben Moglen @ 2018-10-26 15:53 UTC (permalink / raw) To: esr Cc: gregkh, visionsofalice, linux-kernel, rms, bruce, bkuhn, editor, neil, labbott, torvalds, ksummit-discuss, tglx, olof, clm, mishi, linux-kernel-owner On Friday, 26 October 2018, Eric S. Raymond wrote: Eben Moglen <moglen@columbia.edu>: > reputational damage is *specifically* recognized as grounds for relief. > > No. Reputational damage is not mentioned at all, let alone > specifically recognized. I have no difficulty in finding the word "reputation" in the brief in in proximity with the phrase "increasing [the programmer's] recognition i The parties' briefs are not the court opinion, and don't represent what was decided. Wrong document. I linked to the opinion in my message. Eben ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: The linux devs can rescind their license grant. 2018-10-26 13:15 ` Eben Moglen 2018-10-26 15:50 ` Eric S. Raymond @ 2018-10-26 17:32 ` visionsofalice 2018-10-26 18:31 ` Eben Moglen 1 sibling, 1 reply; 104+ messages in thread From: visionsofalice @ 2018-10-26 17:32 UTC (permalink / raw) To: linux-kernel Cc: esr, gregkh, Eben Moglen, rms, bruce, bkuhn, editor, neil, labbott, torvalds, ksummit-discuss, tglx, olof, clm, mishi, linux-kernel-owner On 2018-10-26 13:15, Eben Moglen wrote: > They can do neither. There is no "doctrine established in Jacobsen." > The license terms of the GPLv2, GPLv3, and all related licenses > provide a mode of termination---for imposition of additional > restrictions or violation of other terms. This termination provision, > being explicit, is therefore the sole form of termination recognized > under the terms of the Copyright Act. Incorrect. This rule is only valid for bargained-for copyright licenses supported by consideration. The GPLv2 is not such a situation for most licensees. You are conflating case law dealing with commercial software and non-gratuitous licenses with the present situation, which would likely be a case of first-impression in nearly any jurisdiction. The rule for gratuitous licenses is that they are revocable at the will of the grantor. Raymond Nimmer (God rest his soul) was in agreement on this point, vis-a-vis the GPL and similar licenses. ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: The linux devs can rescind their license grant. 2018-10-26 17:32 ` visionsofalice @ 2018-10-26 18:31 ` Eben Moglen 2018-10-27 7:12 ` visionsofalice 2018-12-18 18:53 ` The linux devs can rescind their license grant. - Analysis published? visionsofalice 0 siblings, 2 replies; 104+ messages in thread From: Eben Moglen @ 2018-10-26 18:31 UTC (permalink / raw) To: visionsofalice Cc: linux-kernel, esr, gregkh, rms, bruce, bkuhn, editor, neil, labbott, torvalds, ksummit-discuss, tglx, olof, clm, mishi, linux-kernel-owner On Friday, 26 October 2018, visionsofalice@redchan.it wrote: You are conflating case law dealing with commercial software and non-gratuitous licenses with the present situation, which would likely be a case of first-impression in nearly any jurisdiction. I think the best procedure would be for me to publish my analysis and for you then to tell me what is wrong with it. What you say here sounds like what a lawyer might say, but isn't. I have been teaching this stuff for about thirty years, so if I am conflating or confusing anything I will be grateful for help in seeing my mistake. The rule for gratuitous licenses is that they are revocable at the will of the grantor. That's not actually "the rule." It sounds like it might be the rule, but it so happens that it's not. When I have given the explanation as I have learned, taught and depended on it, you will be able to show me what I am wrong about. Raymond Nimmer (God rest his soul) was in agreement on this point, vis-a-vis the GPL and similar licenses. You have your Nimmers confused. The primary author of the treatise Nimmer on Copyright (a book about the law, not in itself an authority) was Melville Nimmer. The treatise is continued by his son, David, a fine lawyer with whom I do from time to time politely disagree about something. Ray Nimmer is quite another person. Eben -- Eben Moglen v: 212-461-1901 Professor of Law, Columbia Law School f: 212-854-7946 moglen@ 435 West 116th Street, New York City, NY 10027 columbia.edu Founding Director, Software Freedom Law Center softwarefreedom.org ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: The linux devs can rescind their license grant. 2018-10-26 18:31 ` Eben Moglen @ 2018-10-27 7:12 ` visionsofalice 2018-12-18 18:53 ` The linux devs can rescind their license grant. - Analysis published? visionsofalice 1 sibling, 0 replies; 104+ messages in thread From: visionsofalice @ 2018-10-27 7:12 UTC (permalink / raw) To: linux-kernel; +Cc: Eben Moglen, esr, gregkh, rms, bruce Lawrence Rosen is also in agreement on this point (regarding the GPL v2 specifically). It is revocable at the will of the grantor, at any time. (He writes that if a licensee-contributor was to sue a grantor, then would be a good time to unilaterally rescind: disposing of the matter entirely) The contention that a copyright license is only terminable is traditionally usually true in practice; but not because such is declared by the Copyright Statute (such is not). It is because, in practice, those terms are supported by consideration. Thus the licensee has payed the grantor for those very terms to be in effect. In the case of most users and most developers of the linux-kernel this is not the case. In-fact The very principal that, in the real world, precipitated the widespread adoption of linux: that no consideration is paid for receipt of the program. The GPL v2 is not supported by consideration. This is its strength. And it is not something that can be disclaimed after the fact. The drafter of version 2 of the GPL did, indeed, make an error in drafting. He was, perhaps, familiar mostly with commercial copyright licenses. The foundation of the GPL does not rest on any contemplation of quid-pro-quo or contract theories however; it is on the simple declaration in the Copyright Statute that copyright is alienable in all ways property is. The GPL v2 is similar to a property license, and not a traditional commercial copyright license. On 2018-10-26 18:31, Eben Moglen wrote: > On Friday, 26 October 2018, visionsofalice@redchan.it wrote: > > You are conflating case law dealing with commercial software and > non-gratuitous licenses with the present situation, which would > likely > be a case of first-impression in nearly any jurisdiction. > > I think the best procedure would be for me to publish my analysis and > for you then to tell me what is wrong with it. What you say here > sounds like what a lawyer might say, but isn't. I have been teaching > this stuff for about thirty years, so if I am conflating or confusing > anything I will be grateful for help in seeing my mistake. > > The rule for gratuitous licenses is that they are revocable at the > will > of the grantor. > > That's not actually "the rule." It sounds like it might be the rule, > but it so happens that it's not. When I have given the explanation as > I have learned, taught and depended on it, you will be able to show me > what I am wrong about. > > Raymond Nimmer (God rest his soul) was in agreement on this point, > vis-a-vis the GPL and similar licenses. > > You have your Nimmers confused. The primary author of the treatise > Nimmer on Copyright (a book about the law, not in itself an authority) > was Melville Nimmer. The treatise is continued by his son, David, a > fine lawyer with whom I do from time to time politely disagree about > something. Ray Nimmer is quite another person. > > Eben ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: The linux devs can rescind their license grant. - Analysis published? 2018-10-26 18:31 ` Eben Moglen 2018-10-27 7:12 ` visionsofalice @ 2018-12-18 18:53 ` visionsofalice 1 sibling, 0 replies; 104+ messages in thread From: visionsofalice @ 2018-12-18 18:53 UTC (permalink / raw) To: Eben Moglen Cc: linux-kernel, esr, gregkh, rms, bruce, bkuhn, editor, neil, labbott, torvalds, ksummit-discuss, tglx, olof, clm, mishi, linux-kernel-owner Has the analysis been published yet? I have been away on an artistic sabbatical, but I don't see it in the inbox using searches, this was the last mail I received on the subject. On 2018-10-26 18:31, Eben Moglen wrote: > On Friday, 26 October 2018, visionsofalice@redchan.it wrote: > > You are conflating case law dealing with commercial software and > non-gratuitous licenses with the present situation, which would > likely > be a case of first-impression in nearly any jurisdiction. > > I think the best procedure would be for me to publish my analysis and > for you then to tell me what is wrong with it. What you say here > sounds like what a lawyer might say, but isn't. I have been teaching > this stuff for about thirty years, so if I am conflating or confusing > anything I will be grateful for help in seeing my mistake. > > The rule for gratuitous licenses is that they are revocable at the > will > of the grantor. > > That's not actually "the rule." It sounds like it might be the rule, > but it so happens that it's not. When I have given the explanation as > I have learned, taught and depended on it, you will be able to show me > what I am wrong about. > > Raymond Nimmer (God rest his soul) was in agreement on this point, > vis-a-vis the GPL and similar licenses. > > You have your Nimmers confused. The primary author of the treatise > Nimmer on Copyright (a book about the law, not in itself an authority) > was Melville Nimmer. The treatise is continued by his son, David, a > fine lawyer with whom I do from time to time politely disagree about > something. Ray Nimmer is quite another person. > > Eben ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: The linux devs can rescind their license grant. 2018-10-25 8:19 ` Greg Kroah-Hartman 2018-10-25 19:39 ` Eric S. Raymond @ 2018-10-26 10:34 ` visionsofalice 2018-10-29 22:31 ` Bradley M. Kuhn 2 siblings, 0 replies; 104+ messages in thread From: visionsofalice @ 2018-10-26 10:34 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: linux-kernel, rms, bruce, moglen, bkuhn, editor, NeilBrown, Laura Abbott, Linus Torvalds, ksummit-discuss, Thomas Gleixner, Olof Johansson, Chris Mason, Mishi Choudhary, linux-kernel-owner Yes they can, greg. The GPL v2, is a bare license. It is not a contract. It lacks consideration between the licensee and the grantor. (IE: They didn't pay you, Greg, a thing. YOU, Greg, simply have chosen to bestow a benefit upon them where they suffer no detriment and you, in fact, gain no bargained-for benefit) As a bare license, (read: property license), the standard rules regarding the alienation of property apply. Therein: a gratuitous license is revocable at the will of the grantor. The licensee then may ATTEMPT, as an affirmative defense against your as-of-right action to claim promissory estoppel in state court, and "keep you to your word". However you made no such promise disclaiming your right to rescind the license. Remeber: There is no utterance disclaiming this right within the GPL version 2. Linus, furthermore, has chosen both to exclude the "or any later version" codicil, to reject the GPL version 3, AND to publicly savage GPL version 3 (he surely has his reasons, perhaps this is one of them, left unstated). (GPLv3 which has such promises listed (not to say that they would be effective against the grantor, but it is an attempt at the least)). The Software Freedom Conservancy has attempted to mis-construe clause 4 of the GPL version 2 as a "no-revocation by grantor" clause. However, reading said clause, using plain construction, leads a reasonable person to understand that said clause is speaking specifically about the situation where an upstream licensee loses their permission under the terms due to a violation of the terms; in that case the down-stream licensee does not in-turn also lose their permission under the terms. Additionally, clause 0 makes it crystal clear that "You" is defined as the licensee, not the grantor. Another issue the SFConservancy's public service announcement chooses to ignore. Thirdly, the SFConservancy banks on the ignorance of both the public and the developers regarding property alienation. A license does not impinge the rights of the party granting the license in a quid-pro-quo manner vis a vis the licensee's taking. A license merely grants permission, extended from the grantor, to the licensee, regarding the article of property that is being impinged. A license is NOT a full nor is it a permanent alienation of the article(property) in question. The impinged property, being under a non bargained-for temporary grant, can be taken back into the sole dominion of the owner - at his election to do so. Now as to the 9th circuit appellate court's decision in Jacobsen v. Katzer . While the court waxes eloquently about opensource licenses, even mentioning the word "consideration" in it's long dicta, when it comes time to make the binding decision the court found that the lower (district) court was in _ERROR_ regarding the application of contract-law principals to the Artistic License, regarding the case, and instructed the lower court to instead construe said license as a Copyright License. The SFConservancy, and Bruce Perens have chosen to: 1) Rely on the dicta. (non-binding - "some things could be contracts - opensource is great") 2) Ignore the actual ruling. (Binding - Copyright License - Not Contract) 3) Ignore that this case was about the AL, not the GPLv2 4) Ignore the existence of different jurisdictions. (Why file in the roll-the-dice 9th district if you can file in a district that has personal-juristicion over the defendant and is much more consistent in it's rulings?) 5) Ignore all established law regard property licensing, contract formation, meeting of the minds, what consideration is etc. Which is not surprising considering the desire of people like Bruce Perens is to rob MEN of EVERY benefit of their Labour and every speck of happiness in life and to transfer those benefits to WOMEN and those who support women. (This is why people who are like Bruce Perens, the SFConservancy menbers, and the CoC supporters, banned men from taking female children as brides: in contrivance to the law of YHWH (Devarim chapter 22 - - verse 28 (na'ar (LXX: padia)), and continue to uphold that ban world-wide, and seek to destroy ALL cultures that do no bend to their will.... who are not idolators of Women) Look, you may love your users, you may love the people who edit your code in their home or office; but the fact of the matter is... They have done nothing for you, they have promised nothing to you. They CANNOT hold YOU. You have the right to rescind at any time, and remove your work from any future versions of Linux. And you might consider doing so if YOU are done harm. Don't let the insatiable, never-satisfied, public fool you into thinking otherwise. And, yes, I am a lawyer. And, no, unlike the SFConservancy, I did not have to call upon outside counsel to analyze the fact pattern. (And even then all they could come up with was statements using weasel words "may" etc: not even wanting to commit to their clearly-disingenuous publication) (Note: If you would like to read a nice discussion on the topic, here is one http://illinoisjltp.com/journal/wp-content/uploads/2013/10/kumar.pdf ) On 2018-10-25 08:19, Greg Kroah-Hartman wrote: > On Thu, Oct 25, 2018 at 07:56:26AM +0000, visionsofalice@redchan.it > wrote: >> The linux devs can rescind their license grant. > > No they can not, please do not keep spreading false information. > > greg k-h ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: The linux devs can rescind their license grant. 2018-10-25 8:19 ` Greg Kroah-Hartman 2018-10-25 19:39 ` Eric S. Raymond 2018-10-26 10:34 ` The linux devs can rescind their license grant visionsofalice @ 2018-10-29 22:31 ` Bradley M. Kuhn 2018-12-18 19:17 ` visionsofalice 2 siblings, 1 reply; 104+ messages in thread From: Bradley M. Kuhn @ 2018-10-29 22:31 UTC (permalink / raw) To: ksummit-discuss, linux-kernel Cc: Greg Kroah-Hartman, Thomas Gleixner, Laura Abbott, editor, Linus Torvalds, Thomas Gleixner, Chris Mason, bruce On Thu, Oct 25, 2018 at 07:56:26AM +0000, visionsofalice@redchan.it wrote: > The linux devs can rescind their license grant. Greg KH responded on Thu, 25 Oct 2018 09:19:11 +0100: >> No they can not, please do not keep spreading false information. I was explicitly cc'ed on this thread by visionsofalice. I've read the whole thread, and the only useful thing I can contribute here is to agree with Greg and additionally provide some backup research on the point: https://sfconservancy.org/news/2018/sep/26/GPLv2-irrevocability/ Software Freedom Conservancy engaged our legal counsel to write a new section for the Copyleft Guide that further explains the irrevocability of GPLv2. We published this when others raised these specious claims back in September. Direct link to new section: https://copyleft.org/guide/comprehensive-gpl-guidech8.html#x11-540007.4 HTH, -- Bradley M. Kuhn Distinguished Technologist of Software Freedom Conservancy ======================================================================== Become a Conservancy Supporter today: https://sfconservancy.org/supporter ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: The linux devs can rescind their license grant. 2018-10-29 22:31 ` Bradley M. Kuhn @ 2018-12-18 19:17 ` visionsofalice 0 siblings, 0 replies; 104+ messages in thread From: visionsofalice @ 2018-12-18 19:17 UTC (permalink / raw) To: Bradley M. Kuhn Cc: ksummit-discuss, linux-kernel, Greg Kroah-Hartman, Thomas Gleixner, Laura Abbott, editor, Linus Torvalds, Chris Mason, bruce, linux-kernel-owner Your new explanation was refuted 5 hours after it was published. --- Yes they can, greg. The GPL v2, is a bare license. It is not a contract. It lacks consideration between the licensee and the grantor. (IE: They didn't pay you, Greg, a thing. YOU, Greg, simply have chosen to bestow a benefit upon them where they suffer no detriment and you, in fact, gain no bargained-for benefit) As a bare license, (read: property license), the standard rules regarding the alienation of property apply. Therein: a gratuitous license is revocable at the will of the grantor. The licensee then may ATTEMPT, as an affirmative defense against your as-of-right action to claim promissory estoppel in state court, and "keep you to your word". However you made no such promise disclaiming your right to rescind the license. Remeber: There is no utterance disclaiming this right within the GPL version 2. Linus, furthermore, has chosen both to exclude the "or any later version" codicil, to reject the GPL version 3, AND to publicly savage GPL version 3 (he surely has his reasons, perhaps this is one of them, left unstated). (GPLv3 which has such promises listed (not to say that they would be effective against the grantor, but it is an attempt at the least)). The Software Freedom Conservancy has attempted to mis-construe clause 4 of the GPL version 2 as a "no-revocation by grantor" clause. However, reading said clause, using plain construction, leads a reasonable person to understand that said clause is speaking specifically about the situation where an upstream licensee loses their permission under the terms due to a violation of the terms; in that case the down-stream licensee does not in-turn also lose their permission under the terms. Additionally, clause 0 makes it crystal clear that "You" is defined as the licensee, not the grantor. Another issue the SFConservancy's public service announcement chooses to ignore. Thirdly, the SFConservancy banks on the ignorance of both the public and the developers regarding property alienation. A license does not impinge the rights of the party granting the license in a quid-pro-quo manner vis a vis the licensee's taking. A license merely grants permission, extended from the grantor, to the licensee, regarding the article of property that is being impinged. A license is NOT a full nor is it a permanent alienation of the article(property) in question. The impinged property, being under a non bargained-for temporary grant, can be taken back into the sole dominion of the owner - at his election to do so. Now as to the 9th circuit appellate court's decision in Jacobsen v. Katzer . While the court waxes eloquently about opensource licenses, even mentioning the word "consideration" in it's long dicta, when it comes time to make the binding decision the court found that the lower (district) court was in _ERROR_ regarding the application of contract-law principals to the Artistic License, regarding the case, and instructed the lower court to instead construe said license as a Copyright License. The SFConservancy, and Bruce Perens have chosen to: 1) Rely on the dicta. (non-binding - "some things could be contracts - opensource is great") 2) Ignore the actual ruling. (Binding - Copyright License - Not Contract) 3) Ignore that this case was about the AL, not the GPLv2 4) Ignore the existence of different jurisdictions. (Why file in the roll-the-dice 9th district if you can file in a district that has personal-juristicion over the defendant and is much more consistent in it's rulings?) 5) Ignore all established law regard property licensing, contract formation, meeting of the minds, what consideration is etc. Which is not surprising considering the desire of people like Bruce Perens is to rob MEN of EVERY benefit of their Labour and every speck of happiness in life and to transfer those benefits to WOMEN and those who support women. (This is why people who are like Bruce Perens, the SFConservancy menbers, and the CoC supporters, banned men from taking female children as brides: in contrivance to the law of YHWH (Devarim chapter 22 - - verse 28 (na'ar (LXX: padia)), and continue to uphold that ban world-wide, and seek to destroy ALL cultures that do no bend to their will.... who are not idolators of Women) Look, you may love your users, you may love the people who edit your code in their home or office; but the fact of the matter is... They have done nothing for you, they have promised nothing to you. They CANNOT hold YOU. You have the right to rescind at any time, and remove your work from any future versions of Linux. And you might consider doing so if YOU are done harm. Don't let the insatiable, never-satisfied, public fool you into thinking otherwise. And, yes, I am a lawyer. And, no, unlike the SFConservancy, I did not have to call upon outside counsel to analyze the fact pattern. (And even then all they could come up with was statements using weasel words "may" etc: not even wanting to commit to their clearly-disingenuous publication) (Note: If you would like to read a nice discussion on the topic, here is one http://illinoisjltp.com/journal/wp-content/uploads/2013/10/kumar.pdf ) On 2018-10-25 08:19, Greg Kroah-Hartman wrote: > On Thu, Oct 25, 2018 at 07:56:26AM +0000, visionsofalice@redchan.it > wrote: >> The linux devs can rescind their license grant. > > No they can not, please do not keep spreading false information. > > greg k-h On 2018-10-29 22:31, Bradley M. Kuhn wrote: > On Thu, Oct 25, 2018 at 07:56:26AM +0000, visionsofalice@redchan.it > wrote: >> The linux devs can rescind their license grant. > Greg KH responded on Thu, 25 Oct 2018 09:19:11 +0100: >>> No they can not, please do not keep spreading false information. > > I was explicitly cc'ed on this thread by visionsofalice. I've read the > whole thread, and the only useful thing I can contribute here is to > agree > with Greg and additionally provide some backup research on the point: > https://sfconservancy.org/news/2018/sep/26/GPLv2-irrevocability/ > > Software Freedom Conservancy engaged our legal counsel to write a new > section for the Copyleft Guide that further explains the irrevocability > of > GPLv2. We published this when others raised these specious claims back > in > September. Direct link to new section: > https://copyleft.org/guide/comprehensive-gpl-guidech8.html#x11-540007.4 > > > HTH, ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: The linux devs can rescind their license grant. - Additional restrictive terms 2018-10-25 7:56 ` The linux devs can rescind their license grant visionsofalice 2018-10-25 8:19 ` Greg Kroah-Hartman @ 2018-10-27 5:04 ` visionsofalice 2018-12-18 20:55 ` The CoC regime is a License violation " visionsofalice ` (2 subsequent siblings) 4 siblings, 0 replies; 104+ messages in thread From: visionsofalice @ 2018-10-27 5:04 UTC (permalink / raw) To: linux-kernel Cc: rms, bruce, moglen, bkuhn, editor, NeilBrown, Greg Kroah-Hartman, Laura Abbott, Linus Torvalds, ksummit-discuss, Thomas Gleixner, Olof Johansson, Chris Mason, Mishi Choudhary, linux-kernel-owner Version 2 of the GPL forbids the incorporation of additional restrictive terms, relating to the distribution, modification, etc of the article licensed under the terms. Those that violate this section are declared, by operation of the terms, to have their grant automatically revoked. An additional term need-not be present in the same writing. Such terms simply need to be present to or made known to the taker(sub-licensee) by the distributor. They may be proffered in writing, orally, or implied in the course of doing business dealings. They simply must relate back or involve the article in question (the licensed code or product.) The proffering of additional restrictive terms is a violation of the text of the license grant in and of itself. Here we have a situation where an additional writing has been proffered. The additional writing promises both in it's own text and by implication consequences against those who violate the terms of this additional writing. The additional writing restricts those subject to it from expressing certain views publicly - promising retribution against those who do. No consideration is paid to those subject to the additional writing for their assent; it is simply imposed unilaterally against the subjects. The violators of the additional writing are promised: Additional, unwanted, public scrutiny (to which they were not subject to prior) Public ridicule. Loss of public standing. as-well as an implied loss of future income. These are the enforcement mechanisms of the additional writing to enforce its restrictions against those who publish derivative works of the kernel. The additional writing is activated when (with the prerequisite of being a derivative work of the linux kernel) the work of a rights-holder is incorporated into the kernel, when such a work is made known to the kernel-team to exist where any one person on this earth has seen fit to present it for inclusion, or by simple prior-inclusion into the kernel. Thus all current and past rights-holders who have code in, or have published for distribution, derivative works of the kernel are subject to the retributive promises made to them in the additional writing, drafted to restrict their actions and utterances. This is tantamount to an additional restrictive term regarding the modification and distribution of works under the linux kernel license grant. It is a violation of the license terms of the rights-holders past incorporated works in much the same way that GRSecurity's Contributor Access Agreement was and is. ^ permalink raw reply [flat|nested] 104+ messages in thread
* The CoC regime is a License violation - Additional restrictive terms 2018-10-25 7:56 ` The linux devs can rescind their license grant visionsofalice 2018-10-25 8:19 ` Greg Kroah-Hartman 2018-10-27 5:04 ` The linux devs can rescind their license grant. - Additional restrictive terms visionsofalice @ 2018-12-18 20:55 ` visionsofalice 2018-12-19 1:17 ` visionsofalice 2018-12-23 16:05 ` visionsofalice 4 siblings, 0 replies; 104+ messages in thread From: visionsofalice @ 2018-12-18 20:55 UTC (permalink / raw) To: linux-kernel Cc: rms, bruce, moglen, bkuhn, editor, NeilBrown, Greg Kroah-Hartman, Laura Abbott, Linus Torvalds, ksummit-discuss, Thomas Gleixner, Olof Johansson, Chris Mason, Mishi Choudhary, linux-kernel-owner Version 2 of the GPL forbids the incorporation of additional restrictive terms, relating to the distribution, modification, etc of the article licensed under the terms. Those that violate this section are declared, by operation of the terms, to have their grant automatically revoked. An additional term need-not be present in the same writing. Such terms simply need to be present to or made known to the taker(sub-licensee) by the distributor. They may be proffered in writing, orally, or implied in the course of doing business dealings. They simply must relate back or involve the article in question (the licensed code or product.) The proffering of additional restrictive terms is a violation of the text of the license grant in and of itself. Here we have a situation where an additional writing has been proffered. The additional writing promises both in it's own text and by implication consequences against those who violate the terms of this additional writing. The additional writing restricts those subject to it from expressing certain views publicly - promising retribution against those who do. No consideration is paid to those subject to the additional writing for their assent; it is simply imposed unilaterally against the subjects. The violators of the additional writing are promised: Additional, unwanted, public scrutiny (to which they were not subject to prior) Public ridicule. Loss of public standing. as-well as an implied loss of future income. These are the enforcement mechanisms of the additional writing to enforce its restrictions against those who publish derivative works of the kernel. The additional writing is activated when (with the prerequisite of being a derivative work of the linux kernel) the work of a rights-holder is incorporated into the kernel, when such a work is made known to the kernel-team to exist where any one person on this earth has seen fit to present it for inclusion, or by simple prior-inclusion into the kernel. Thus all current and past rights-holders who have code in, or have published for distribution, derivative works of the kernel are subject to the retributive promises made to them in the additional writing, drafted to restrict their actions and utterances. This is tantamount to an additional restrictive term regarding the modification and distribution of works under the linux kernel license grant. It is a violation of the license terms of the rights-holders past incorporated works in much the same way that GRSecurity's Contributor Access Agreement was and is. ^ permalink raw reply [flat|nested] 104+ messages in thread
* The CoC regime is a License violation - Additional restrictive terms 2018-10-25 7:56 ` The linux devs can rescind their license grant visionsofalice ` (2 preceding siblings ...) 2018-12-18 20:55 ` The CoC regime is a License violation " visionsofalice @ 2018-12-19 1:17 ` visionsofalice 2018-12-23 16:05 ` visionsofalice 4 siblings, 0 replies; 104+ messages in thread From: visionsofalice @ 2018-12-19 1:17 UTC (permalink / raw) To: linux-kernel Version 2 of the GPL forbids the incorporation of additional restrictive terms, relating to the distribution, modification, etc of the article licensed under the terms. Those that violate this section are declared, by operation of the terms, to have their grant automatically revoked. An additional term need-not be present in the same writing. Such terms simply need to be present to or made known to the taker(sub-licensee) by the distributor. They may be proffered in writing, orally, or implied in the course of doing business dealings. They simply must relate back or involve the article in question (the licensed code or product.) The proffering of additional restrictive terms is a violation of the text of the license grant in and of itself. Here we have a situation where an additional writing has been proffered. The additional writing promises both in it's own text and by implication consequences against those who violate the terms of this additional writing. The additional writing restricts those subject to it from expressing certain views publicly - promising retribution against those who do. No consideration is paid to those subject to the additional writing for their assent; it is simply imposed unilaterally against the subjects. The violators of the additional writing are promised: Additional, unwanted, public scrutiny (to which they were not subject to prior) Public ridicule. Loss of public standing. as-well as an implied loss of future income. These are the enforcement mechanisms of the additional writing to enforce its restrictions against those who publish derivative works of the kernel. The additional writing is activated when (with the prerequisite of being a derivative work of the linux kernel) the work of a rights-holder is incorporated into the kernel, when such a work is made known to the kernel-team to exist where any one person on this earth has seen fit to present it for inclusion, or by simple prior-inclusion into the kernel. Thus all current and past rights-holders who have code in, or have published for distribution, derivative works of the kernel are subject to the retributive promises made to them in the additional writing, drafted to restrict their actions and utterances. This is tantamount to an additional restrictive term regarding the modification and distribution of works under the linux kernel license grant. It is a violation of the license terms of the rights-holders past incorporated works in much the same way that GRSecurity's Contributor Access Agreement was and is. ^ permalink raw reply [flat|nested] 104+ messages in thread
* The CoC regime is a License violation - Additional restrictive terms 2018-10-25 7:56 ` The linux devs can rescind their license grant visionsofalice ` (3 preceding siblings ...) 2018-12-19 1:17 ` visionsofalice @ 2018-12-23 16:05 ` visionsofalice 4 siblings, 0 replies; 104+ messages in thread From: visionsofalice @ 2018-12-23 16:05 UTC (permalink / raw) To: linux-kernel Version 2 of the GPL forbids the incorporation of additional restrictive terms, relating to the distribution, modification, etc of the article licensed under the terms. Those that violate this section are declared, by operation of the terms, to have their grant automatically revoked. An additional term need-not be present in the same writing. Such terms simply need to be present to or made known to the taker(sub-licensee) by the distributor. They may be proffered in writing, orally, or implied in the course of doing business dealings. They simply must relate back or involve the article in question (the licensed code or product.) The proffering of additional restrictive terms is a violation of the text of the license grant in and of itself. Here we have a situation where an additional writing has been proffered. The additional writing promises both in it's own text and by implication consequences against those who violate the terms of this additional writing. The additional writing restricts those subject to it from expressing certain views publicly - promising retribution against those who do. No consideration is paid to those subject to the additional writing for their assent; it is simply imposed unilaterally against the subjects. The violators of the additional writing are promised: Additional, unwanted, public scrutiny (to which they were not subject to prior) Public ridicule. Loss of public standing. as-well as an implied loss of future income. These are the enforcement mechanisms of the additional writing to enforce its restrictions against those who publish derivative works of the kernel. The additional writing is activated when (with the prerequisite of being a derivative work of the linux kernel) the work of a rights-holder is incorporated into the kernel, when such a work is made known to the kernel-team to exist where any one person on this earth has seen fit to present it for inclusion, or by simple prior-inclusion into the kernel. Thus all current and past rights-holders who have code in, or have published for distribution, derivative works of the kernel are subject to the retributive promises made to them in the additional writing, drafted to restrict their actions and utterances. This is tantamount to an additional restrictive term regarding the modification and distribution of works under the linux kernel license grant. It is a violation of the license terms of the rights-holders past incorporated works in much the same way that GRSecurity's Contributor Access Agreement was and is. ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document 2018-10-24 8:49 ` Laura Abbott 2018-10-25 7:56 ` The linux devs can rescind their license grant visionsofalice @ 2018-10-25 22:02 ` NeilBrown 1 sibling, 0 replies; 104+ messages in thread From: NeilBrown @ 2018-10-25 22:02 UTC (permalink / raw) To: Laura Abbott, Greg Kroah-Hartman, linux-kernel, Linus Torvalds Cc: ksummit-discuss, Thomas Gleixner, Olof Johansson, Chris Mason, Mishi Choudhary [-- Attachment #1: Type: text/plain, Size: 5102 bytes --] On Wed, Oct 24 2018, Laura Abbott wrote: > On 10/21/2018 02:20 PM, NeilBrown wrote: > > <snip> > >> I call on the community to consider what *does* need to be said, about >> conduct, to people outside the community and who have recently joined. >> What is the document that you would have liked to have read as you were >> starting out? It is all too long ago for me to remember clearly, and so >> much has changed. >> > > I joined much more recently than many and what I would have wanted > then is an interesting question. I probably would _not_ have wanted > a code of conduct when I first started working in open source. I also > said things in my younger years I regret and probably wouldn't have > said if I was held to a higher standard of conduct. Younger me frequently > put up with behavior I wouldn't tolerate today. Younger me also > greatly benefited from the experience of other kernel developers > giving me firm feedback in a helpful way and saying no to bad approaches. > I don't believe I would have continued if I hadn't been given that > feedback in a useful way. Thanks for this thoughtful reply. You seem to make two key points. Firstly, you repeatedly value feedback - both positive and negative. I agree. One of the worst things that can happen when I post a patch, is that it get ignored (no feedback). This gels with what Linus said recently, as reported in https://lwn.net/Articles/769117/ To that end, he asked the assembled group to watch his emails and let him know if things start to get close to the edge. He explicitly asked for feedback, giving people permission to speak up when they thought he was out of line. I personally think this is a very significant statement. Not for what it tells those maintainers (who probably generally knew that already) so much as for what it tells the broader community who don't know Linus so well: Feedback about behaviour is explicitly welcome. You go on to say, below, that a private e-mail can resolve things. I don't actually think that a private e-mail is such a good idea because even though it might resolve things, it doesn't let the broader community know they are resolved, and doesn't set any example of how resolution works. Giving feedback in public is hard, but if there was a clearly established mechanism, that might make it easier. I wouldn't choose the wording you provided as it focuses on "you" rather than "me", but that sort of gentleness is definitely appropriate. Your second point is about more serious issues and particularly how they will be handled. As I have said elsewhere, and will not belabor here, I think this is upside down: we can and should give power to the weak, rather than trying to curb the power of the strong. Extrapolating from the "feedback" point, I'm imagining having a document which starts: In the Linux kernel community we try to be helpful and not hurtful. The best way to understand how this applies in practice is to give, receive, and observe feedback. If someone says/does/writes something that you think is helpful, consider saying so: "Thank you, I found that to be helpful". - You can your own words if you wish. - You might like to add your voice to others if the situation warrants it. If someone says/does/writes something that you think is hurtful (whether to yourself or someone else), please consider saying something: "This seems hurtful to me" - It is best to use exactly this wording. In particular, don't embellish or explain unless asked. - Normally just one voice is sufficient. If an individual repeats the hurtful behavior, one new voice per instance is sufficient. It might then continue with some specifics, though there seems to be some debate on whether such specifics are a good idea. I don't have a firm opinion. Thanks a lot, NeilBrown > > Today, I think the code of conduct is a very important addition to > the community. It's a stronger assertion that the kernel community > is committed to raising the bar for behavior. I have no concern about > patch review or quality dropping because most maintainers demonstrate > every day that they can give effective feedback. We're all going to > screw that up sometimes and the Code of Conduct reminds us to do our > best. Most issues that arise can be resolved with a private e-mail > going "you might want to rethink your wording there." > > What the Code of Conduct also provides is confidence that more serious > community issues such as harassment not related to patch > review can be handled. It spells out certain behaviors that won't > be tolerated and explains how those problems will be dealt with. > Will those problems actually be handled appropriately when the time > comes? I can't actually say for sure, but the kernel community works > on trust so I guess I have to trust that it will. I really hope I never > have to report harassment but I'm glad there's a process in place. > > Thanks, > Laura [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 832 bytes --] ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document 2018-10-21 21:20 ` Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document NeilBrown ` (4 preceding siblings ...) 2018-10-24 8:49 ` Laura Abbott @ 2018-10-25 8:06 ` Pavel Machek 2018-10-25 11:20 ` Rainer Fiebig 6 siblings, 0 replies; 104+ messages in thread From: Pavel Machek @ 2018-10-25 8:06 UTC (permalink / raw) To: NeilBrown Cc: Greg Kroah-Hartman, linux-kernel, Linus Torvalds, ksummit-discuss, Thomas Gleixner, Olof Johansson, Chris Mason, Mishi Choudhary [-- Attachment #1: Type: text/plain, Size: 1217 bytes --] On Mon 2018-10-22 08:20:11, NeilBrown wrote: > On Sat, Oct 20 2018, Greg Kroah-Hartman wrote: > > > Hi all, > > > > As everyone knows by now, we added a new Code of Conduct to the kernel > > tree a few weeks ago. > > I wanted to stay detached from all this, but as remaining (publicly) > silent might be seen (publicly) as acquiescing, I hereby declare that: > I reject, as illegitimate, this Code and the process by > which it is being "developed". > > It is clear from the surrounding discussions that this is well outside our > core competencies. It will be flawed, it isn't what we need. Agreed. > I call on you, Greg: > - to abandon this divisive attempt to impose a "Code of Conduct" > - to revert 8a104f8b5867c68 Agreed. Plus I actually wish more people would gpg-sign their emails. It is not that hard, and I actually thought original Linus' rc4 announcement was fake. It was not, and it does not look like there are spoofed mails here, either, but hey, there are few I'd like to verify. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 181 bytes --] ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document 2018-10-21 21:20 ` Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document NeilBrown ` (5 preceding siblings ...) 2018-10-25 8:06 ` Pavel Machek @ 2018-10-25 11:20 ` Rainer Fiebig 2018-10-25 22:18 ` NeilBrown 6 siblings, 1 reply; 104+ messages in thread From: Rainer Fiebig @ 2018-10-25 11:20 UTC (permalink / raw) To: linux-kernel Cc: NeilBrown, Greg Kroah-Hartman, ksummit-discuss, Thomas Gleixner, Olof Johansson, Chris Mason, Mishi Choudhary [-- Attachment #1: Type: text/plain, Size: 1858 bytes --] Am Montag, 22. Oktober 2018, 08:20:11 schrieb NeilBrown: > On Sat, Oct 20 2018, Greg Kroah-Hartman wrote: > > Hi all, > > > > As everyone knows by now, we added a new Code of Conduct to the kernel > > tree a few weeks ago. > > I wanted to stay detached from all this, but as remaining (publicly) > silent might be seen (publicly) as acquiescing, I hereby declare that: > I reject, as illegitimate, this Code and the process by > which it is being "developed". > > It is clear from the surrounding discussions that this is well outside our > core competencies. It will be flawed, it isn't what we need. > > I call on any other community members who reject this process to say so, > not to remain silent. > #Iobject > > We don't need a "Code of Conduct" nearly as much as we need "Leadership > in conduct". Without the leadership, any code looks like a joke. > [...] > I call on you, Greg: > - to abandon this divisive attempt to impose a "Code of Conduct" > - to revert 8a104f8b5867c68 Yes but this seems increasingly unlikely now. However, there may be an alternative. Jugding by the release-message for 4.19, some people here are fans of Monty Python's. No wonder - as those guys are famous for being unrelenting supporters of Political Correctness. So one would be on the safe side if one just supplemented "Our Pledge" with this: "Everybody has the right to be offended." I think, John Cleese would also welcome this.[1] What do you think? Regards! Rainer Fiebig [1] https://www.dailymail.co.uk/news/article-3427218/Political-correctness-killing-comedy-says-John-Cleese-Monty-Python-star-believes-fear-offending-certain-groups-lead-1984-style-society-free-expression-not-allowed.html -- The truth always turns out to be simpler than you thought. Richard Feynman [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document 2018-10-25 11:20 ` Rainer Fiebig @ 2018-10-25 22:18 ` NeilBrown 2018-10-26 8:33 ` Rainer Fiebig 0 siblings, 1 reply; 104+ messages in thread From: NeilBrown @ 2018-10-25 22:18 UTC (permalink / raw) To: Rainer Fiebig, linux-kernel Cc: Greg Kroah-Hartman, ksummit-discuss, Thomas Gleixner, Olof Johansson, Chris Mason, Mishi Choudhary [-- Attachment #1: Type: text/plain, Size: 2512 bytes --] On Thu, Oct 25 2018, Rainer Fiebig wrote: > Am Montag, 22. Oktober 2018, 08:20:11 schrieb NeilBrown: >> On Sat, Oct 20 2018, Greg Kroah-Hartman wrote: >> > Hi all, >> > >> > As everyone knows by now, we added a new Code of Conduct to the kernel >> > tree a few weeks ago. >> >> I wanted to stay detached from all this, but as remaining (publicly) >> silent might be seen (publicly) as acquiescing, I hereby declare that: >> I reject, as illegitimate, this Code and the process by >> which it is being "developed". >> >> It is clear from the surrounding discussions that this is well outside our >> core competencies. It will be flawed, it isn't what we need. >> >> I call on any other community members who reject this process to say so, >> not to remain silent. >> #Iobject >> >> We don't need a "Code of Conduct" nearly as much as we need "Leadership >> in conduct". Without the leadership, any code looks like a joke. >> > [...] > >> I call on you, Greg: >> - to abandon this divisive attempt to impose a "Code of Conduct" >> - to revert 8a104f8b5867c68 > > Yes but this seems increasingly unlikely now. However, there may be an > alternative. > > Jugding by the release-message for 4.19, some people here are fans of > Monty Python's. No wonder - as those guys are famous for being unrelenting > supporters of Political Correctness. > > So one would be on the safe side if one just supplemented "Our Pledge" > with this: > > "Everybody has the right to be offended." > > I think, John Cleese would also welcome this.[1] > > What do you think? I do think that giving certain rights to the community is a good thing: - the right to tell anyone that their speech is hurtful - the right to (patch) review by a third party. I don't think the right to be offended really needs to be given. Yes, I know it is a joke and I do like Monty Python. I just don't think it is particular helpful in this context. Maybe I missed something. For myself, I relinquish my right to be offended. I just don't do it. It doesn't seem to be worth the effort. Thanks, NeilBrown > > Regards! > > > Rainer Fiebig > > > > [1] https://www.dailymail.co.uk/news/article-3427218/Political-correctness-killing-comedy-says-John-Cleese-Monty-Python-star-believes-fear-offending-certain-groups-lead-1984-style-society-free-expression-not-allowed.html > > > -- > The truth always turns out to be simpler than you thought. > Richard Feynman [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 832 bytes --] ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document 2018-10-25 22:18 ` NeilBrown @ 2018-10-26 8:33 ` Rainer Fiebig 2018-10-26 22:40 ` NeilBrown 0 siblings, 1 reply; 104+ messages in thread From: Rainer Fiebig @ 2018-10-26 8:33 UTC (permalink / raw) To: NeilBrown, linux-kernel Cc: Greg Kroah-Hartman, ksummit-discuss, Thomas Gleixner, Olof Johansson, Chris Mason, Mishi Choudhary [-- Attachment #1.1: Type: text/plain, Size: 3719 bytes --] NeilBrown schrieb: > On Thu, Oct 25 2018, Rainer Fiebig wrote: > >> Am Montag, 22. Oktober 2018, 08:20:11 schrieb NeilBrown: >>> On Sat, Oct 20 2018, Greg Kroah-Hartman wrote: >>>> Hi all, >>>> >>>> As everyone knows by now, we added a new Code of Conduct to the kernel >>>> tree a few weeks ago. >>> >>> I wanted to stay detached from all this, but as remaining (publicly) >>> silent might be seen (publicly) as acquiescing, I hereby declare that: >>> I reject, as illegitimate, this Code and the process by >>> which it is being "developed". >>> >>> It is clear from the surrounding discussions that this is well outside our >>> core competencies. It will be flawed, it isn't what we need. >>> >>> I call on any other community members who reject this process to say so, >>> not to remain silent. >>> #Iobject >>> >>> We don't need a "Code of Conduct" nearly as much as we need "Leadership >>> in conduct". Without the leadership, any code looks like a joke. >>> >> [...] >> >>> I call on you, Greg: >>> - to abandon this divisive attempt to impose a "Code of Conduct" >>> - to revert 8a104f8b5867c68 >> >> Yes but this seems increasingly unlikely now. However, there may be an >> alternative. >> >> Jugding by the release-message for 4.19, some people here are fans of >> Monty Python's. No wonder - as those guys are famous for being unrelenting >> supporters of Political Correctness. >> >> So one would be on the safe side if one just supplemented "Our Pledge" >> with this: >> >> "Everybody has the right to be offended." >> >> I think, John Cleese would also welcome this.[1] >> >> What do you think? > > I do think that giving certain rights to the community is a good thing: > - the right to tell anyone that their speech is hurtful > - the right to (patch) review by a third party. > > I don't think the right to be offended really needs to be given. > Yes, I know it is a joke and I do like Monty Python. I just don't think > it is particular helpful in this context. Maybe I missed something. Of course it's a joke and iirc it was indeed John Cleese who made it. But he made it for a reason, out of concern. It has a serious core. The question is: what *is* helpful in this matter? Just saying "this is not helpful" isn't helpful either. It's a well-known killer-phrase that has been used ad nauseam in this discussion. But an alternative is never given. And thus it's just an other way of saying "Eat it. And shut tf up!" Not even *constructive* criticism is helpful. AFAIK I'm the only one here who came up with a *complete* alternative - ignored. Others provided patches for certain sections - ignored. Data that indicate that this may be detrimental to Linux - ignored. Almost anything that was provided by me or others - ignored. What kind of community or attitude is this? This feels more like "The Wall" or North Korea than an Open-Source-project. And what beat everything was to misuse famously politically *in*correct Monty Python to malign criticism of this Political-Correctness-monster. The "People's Front" - message will forever be a prominent exhibit in "Monty Python's Hall of Shame". And the author should be banned from laughing about MP-sketches until he recants. Perhaps one should also report this incident to the "Ministry of Silly CoCs". ;) > For myself, I relinquish my right to be offended. I just don't do it. > It doesn't seem to be worth the effort. I don't. John Cleese is a smart guy. And he has a point. OK, thanks for your reply! But I think it's time for me to move on. "Cut your losses", as they say. Good luck and regards! Rainer Fiebig [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document 2018-10-26 8:33 ` Rainer Fiebig @ 2018-10-26 22:40 ` NeilBrown 2018-10-27 11:49 ` Rainer Fiebig 0 siblings, 1 reply; 104+ messages in thread From: NeilBrown @ 2018-10-26 22:40 UTC (permalink / raw) To: Rainer Fiebig, linux-kernel Cc: Greg Kroah-Hartman, ksummit-discuss, Thomas Gleixner, Olof Johansson, Chris Mason, Mishi Choudhary [-- Attachment #1: Type: text/plain, Size: 4377 bytes --] On Fri, Oct 26 2018, Rainer Fiebig wrote: > NeilBrown schrieb: >> On Thu, Oct 25 2018, Rainer Fiebig wrote: >> >>> Am Montag, 22. Oktober 2018, 08:20:11 schrieb NeilBrown: >>>> On Sat, Oct 20 2018, Greg Kroah-Hartman wrote: >>>>> Hi all, >>>>> >>>>> As everyone knows by now, we added a new Code of Conduct to the kernel >>>>> tree a few weeks ago. >>>> >>>> I wanted to stay detached from all this, but as remaining (publicly) >>>> silent might be seen (publicly) as acquiescing, I hereby declare that: >>>> I reject, as illegitimate, this Code and the process by >>>> which it is being "developed". >>>> >>>> It is clear from the surrounding discussions that this is well outside our >>>> core competencies. It will be flawed, it isn't what we need. >>>> >>>> I call on any other community members who reject this process to say so, >>>> not to remain silent. >>>> #Iobject >>>> >>>> We don't need a "Code of Conduct" nearly as much as we need "Leadership >>>> in conduct". Without the leadership, any code looks like a joke. >>>> >>> [...] >>> >>>> I call on you, Greg: >>>> - to abandon this divisive attempt to impose a "Code of Conduct" >>>> - to revert 8a104f8b5867c68 >>> >>> Yes but this seems increasingly unlikely now. However, there may be an >>> alternative. >>> >>> Jugding by the release-message for 4.19, some people here are fans of >>> Monty Python's. No wonder - as those guys are famous for being unrelenting >>> supporters of Political Correctness. >>> >>> So one would be on the safe side if one just supplemented "Our Pledge" >>> with this: >>> >>> "Everybody has the right to be offended." >>> >>> I think, John Cleese would also welcome this.[1] >>> >>> What do you think? >> >> I do think that giving certain rights to the community is a good thing: >> - the right to tell anyone that their speech is hurtful >> - the right to (patch) review by a third party. >> >> I don't think the right to be offended really needs to be given. >> Yes, I know it is a joke and I do like Monty Python. I just don't think >> it is particular helpful in this context. Maybe I missed something. > > Of course it's a joke and iirc it was indeed John Cleese who made it. But he > made it for a reason, out of concern. It has a serious core. > > The question is: what *is* helpful in this matter? > > Just saying "this is not helpful" isn't helpful either. It's a well-known > killer-phrase that has been used ad nauseam in this discussion. But an > alternative is never given. And thus it's just an other way of saying > "Eat it. And shut tf up!" You asked me what I thought, and I told you what I thought. If you think differently, you are quite welcome tell us - to explain the way in which you think the addition would be helpful. > > Not even *constructive* criticism is helpful. AFAIK I'm the only one here who > came up with a *complete* alternative - ignored. Others provided patches for > certain sections - ignored. Data that indicate that this may be detrimental to > Linux - ignored. Almost anything that was provided by me or others - ignored. From my perspective, providing a complete alternative is no better than what Greg did - provided a "complete" "code of conduct". Engage in discussion, present your case, make me *want* to read your document because you've shown me how it relates to me. > > What kind of community or attitude is this? This feels more like "The Wall" or > North Korea than an Open-Source-project. > > And what beat everything was to misuse famously politically *in*correct Monty > Python to malign criticism of this Political-Correctness-monster. The > "People's Front" - message will forever be a prominent exhibit in "Monty > Python's Hall of Shame". And the author should be banned from laughing about > MP-sketches until he recants. Perhaps one should also report this incident to > the "Ministry of Silly CoCs". ;) > >> For myself, I relinquish my right to be offended. I just don't do it. >> It doesn't seem to be worth the effort. > > I don't. John Cleese is a smart guy. And he has a point. > > > OK, thanks for your reply! But I think it's time for me to move on. "Cut your > losses", as they say. > Thanks for participating! NeilBrown > > Good luck and regards! > > Rainer Fiebig [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 832 bytes --] ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document 2018-10-26 22:40 ` NeilBrown @ 2018-10-27 11:49 ` Rainer Fiebig 0 siblings, 0 replies; 104+ messages in thread From: Rainer Fiebig @ 2018-10-27 11:49 UTC (permalink / raw) To: NeilBrown, linux-kernel Cc: Greg Kroah-Hartman, ksummit-discuss, Thomas Gleixner, Olof Johansson, Chris Mason, Mishi Choudhary [-- Attachment #1.1: Type: text/plain, Size: 6872 bytes --] NeilBrown schrieb: > On Fri, Oct 26 2018, Rainer Fiebig wrote: > >> NeilBrown schrieb: >>> On Thu, Oct 25 2018, Rainer Fiebig wrote: >>> >>>> Am Montag, 22. Oktober 2018, 08:20:11 schrieb NeilBrown: >>>>> On Sat, Oct 20 2018, Greg Kroah-Hartman wrote: >>>>>> Hi all, >>>>>> >>>>>> As everyone knows by now, we added a new Code of Conduct to the kernel >>>>>> tree a few weeks ago. >>>>> >>>>> I wanted to stay detached from all this, but as remaining (publicly) >>>>> silent might be seen (publicly) as acquiescing, I hereby declare that: >>>>> I reject, as illegitimate, this Code and the process by >>>>> which it is being "developed". >>>>> >>>>> It is clear from the surrounding discussions that this is well outside our >>>>> core competencies. It will be flawed, it isn't what we need. >>>>> >>>>> I call on any other community members who reject this process to say so, >>>>> not to remain silent. >>>>> #Iobject >>>>> >>>>> We don't need a "Code of Conduct" nearly as much as we need "Leadership >>>>> in conduct". Without the leadership, any code looks like a joke. >>>>> >>>> [...] >>>> >>>>> I call on you, Greg: >>>>> - to abandon this divisive attempt to impose a "Code of Conduct" >>>>> - to revert 8a104f8b5867c68 >>>> >>>> Yes but this seems increasingly unlikely now. However, there may be an >>>> alternative. >>>> >>>> Jugding by the release-message for 4.19, some people here are fans of >>>> Monty Python's. No wonder - as those guys are famous for being unrelenting >>>> supporters of Political Correctness. >>>> >>>> So one would be on the safe side if one just supplemented "Our Pledge" >>>> with this: >>>> >>>> "Everybody has the right to be offended." >>>> >>>> I think, John Cleese would also welcome this.[1] >>>> >>>> What do you think? >>> >>> I do think that giving certain rights to the community is a good thing: >>> - the right to tell anyone that their speech is hurtful >>> - the right to (patch) review by a third party. >>> >>> I don't think the right to be offended really needs to be given. >>> Yes, I know it is a joke and I do like Monty Python. I just don't think >>> it is particular helpful in this context. Maybe I missed something. >> >> Of course it's a joke and iirc it was indeed John Cleese who made it. But he >> made it for a reason, out of concern. It has a serious core. >> >> The question is: what *is* helpful in this matter? >> >> Just saying "this is not helpful" isn't helpful either. It's a well-known >> killer-phrase that has been used ad nauseam in this discussion. But an >> alternative is never given. And thus it's just an other way of saying >> "Eat it. And shut tf up!" > > You asked me what I thought, and I told you what I thought. > If you think differently, you are quite welcome tell us - to explain the > way in which you think the addition would be helpful. > Neil, this is probably a misunderstanding. I really value your initiative and dedication in this matter. My suggestion of adding the "right to be offended" was of course just a sarcastic joke. I thought this was obvious, especially since I provided the link to the interview with John Cleese. But it wasn't obvious to you and I'm sorry for that. BTW - it just strikes me: perhaps this endless enumeration of protected/privileged classes was also just a joke and *I* didn't see it? ;) OK. "Not helpful": This is indeed a killer-phrase used to suppress critique and to silence people. I just wanted to expose this. It was not directed at *you*. That's why I began my critique with >> "The question is: what *is* helpful in this matter?" >> >> Not even *constructive* criticism is helpful. AFAIK I'm the only one here who >> came up with a *complete* alternative - ignored. Others provided patches for >> certain sections - ignored. Data that indicate that this may be detrimental to >> Linux - ignored. Almost anything that was provided by me or others - ignored. > > From my perspective, providing a complete alternative is no better than > what Greg did - provided a "complete" "code of conduct". > I think in your message of 10/21/18 you asked for it: "What is the document that you would have liked to have read as you were starting out? [...]" In my reply I also made it clear that my suggestion was just intended as an example that *of course* would have to be discussed: "On the day the patch came out, I started working on a modified version, a CoC that I could have lived with. [...]. So please find below what I would have submitted for discussion." And if that's not *constructive* criticism, I don't know what is. > Engage in discussion, present your case, make me *want* to read your > document because you've shown me how it relates to me. > I think, I engaged in this discussion earlier than you did. My first post was on 10/09/18. And I have already presented my case several times, including examples for why I'm opposed to this CoC, concrete proposals for modification and some data that show that it may be detrimental to Linux. I also suggested to revert the patch, set up a task-force to come up with an alternate CoC, discuss it etc. And all of this early enough. There's no point in repeating it. So - what else could I do? And why should you *want* to read my document? I don't know. Perhaps because you asked for it? Or to get some ideas how the same can be achieved without a political sting? Up to you. But I will definitely no longer participate in this discussion unless there are clear indications by those who introduced this stuff that a discussion is appreciated and its outcome may lead to changes in the CoC. Because else I know of better ways to waste my time. ;) Kind regards - and have a good weekend! Rainer Fiebig >> >> What kind of community or attitude is this? This feels more like "The Wall" or >> North Korea than an Open-Source-project. >> >> And what beat everything was to misuse famously politically *in*correct Monty >> Python to malign criticism of this Political-Correctness-monster. The >> "People's Front" - message will forever be a prominent exhibit in "Monty >> Python's Hall of Shame". And the author should be banned from laughing about >> MP-sketches until he recants. Perhaps one should also report this incident to >> the "Ministry of Silly CoCs". ;) >> >>> For myself, I relinquish my right to be offended. I just don't do it. >>> It doesn't seem to be worth the effort. >> >> I don't. John Cleese is a smart guy. And he has a point. >> >> >> OK, thanks for your reply! But I think it's time for me to move on. "Cut your >> losses", as they say. >> > > Thanks for participating! > > NeilBrown > >> >> Good luck and regards! >> >> Rainer Fiebig [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document 2018-10-20 13:49 [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document Greg Kroah-Hartman ` (7 preceding siblings ...) 2018-10-21 21:20 ` Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document NeilBrown @ 2018-10-21 23:36 ` Eric S. Raymond 8 siblings, 0 replies; 104+ messages in thread From: Eric S. Raymond @ 2018-10-21 23:36 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: linux-kernel, ksummit-discuss, Thomas Gleixner, Olof Johansson, Chris Mason, Mishi Choudhary Greg Kroah-Hartman <gregkh@linuxfoundation.org>: > This patch series adds this new document to the kernel tree, as well as > removes a paragraph from the existing Code of Conduct that was > bothersome to many maintainers. I think the changes have improved it. There is still a process issue with how this code was promulgated that is clearly bothering a lot of people, but I hope that problem is well enough understood that we don't need to rehash it. More transparency, more consultation, and more notice of intent to revise would help head off future problems. I do have one content recommendation. In the version at https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/code-of-conduct.rst which I presume is current, I see a paragraph that reads as follows: >In the interest of fostering an open and welcoming environment, we as >contributors and maintainers pledge to making participation in our project and >our community a harassment-free experience for everyone, regardless of age, body >size, disability, ethnicity, sex characteristics, gender identity and >expression, level of experience, education, socio-economic status, nationality, >personal appearance, race, religion, or sexual identity and orientation. I recommend that all the text from "everyone" on be struck as (a) unnecessary, and (b) tending to embroil the project in politico-cultural wars that can do it no good - and replaced by "every individual". That is, the result would read: >In the interest of fostering an open and welcoming environment, we as >contributors and maintainers pledge to making participation in our project and >our community a harassment-free experience for every individual. That is all that needs to be said. Listing all those specific categories of "regardless of" implicitly privileges certain kinds of identity (those listed) and disfavors others (those not listed). Further, some of the phrases used fo categories are political shibboleths that unavoidably drag in American presumptions not appropriate for an international project. Best to leave the whole mess out and just pledge to treat individuals well. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own. ^ permalink raw reply [flat|nested] 104+ messages in thread
end of thread, other threads:[~2018-12-23 16:05 UTC | newest] Thread overview: 104+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-10-20 13:49 [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document Greg Kroah-Hartman 2018-10-20 13:49 ` [PATCH 1/7] Code of conduct: Fix wording around maintainers enforcing the code of conduct Greg Kroah-Hartman 2018-10-20 13:50 ` [PATCH 2/7] Code of Conduct Interpretation: Add document explaining how the Code of Conduct is to be interpreted Greg Kroah-Hartman 2018-10-20 13:50 ` [PATCH 3/7] Code of Conduct Interpretation: Properly reference the TAB correctly Greg Kroah-Hartman 2018-10-20 13:50 ` [PATCH 4/7] Code of Conduct: Provide links between the two documents Greg Kroah-Hartman 2018-10-20 13:50 ` [PATCH 5/7] Code of Conduct Interpretation: Put in the proper URL for the committee Greg Kroah-Hartman 2018-10-20 19:01 ` Geert Uytterhoeven 2018-10-21 7:18 ` [Ksummit-discuss] " Greg KH 2018-10-20 13:51 ` [PATCH 6/7] Code of Conduct: Change the contact email address Greg Kroah-Hartman 2018-10-20 18:28 ` Alan Cox 2018-10-20 18:45 ` [Ksummit-discuss] " Trond Myklebust 2018-10-20 19:14 ` jonsmirl 2018-10-21 8:27 ` Theodore Y. Ts'o 2018-10-21 9:23 ` Greg KH 2018-10-20 19:24 ` Tim.Bird 2018-10-20 20:07 ` Trond Myklebust 2018-10-21 0:13 ` Alan Cox 2018-10-21 6:19 ` Thomas Gleixner 2018-10-20 20:13 ` James Bottomley 2018-10-20 13:51 ` [PATCH 7/7] MAINTAINERS: Add an entry for the code of conduct Greg Kroah-Hartman 2018-10-21 21:20 ` Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document NeilBrown 2018-10-21 22:26 ` [Ksummit-discuss] " Josh Triplett 2018-10-21 23:37 ` Theodore Y. Ts'o 2018-10-23 1:44 ` NeilBrown 2018-10-22 20:26 ` NeilBrown 2018-10-22 22:46 ` Theodore Y. Ts'o 2018-10-23 1:31 ` NeilBrown 2018-10-23 6:26 ` Dan Carpenter 2018-10-23 6:40 ` Al Viro 2018-10-23 6:46 ` Dan Carpenter 2018-10-23 3:31 ` Al Viro 2018-10-23 4:25 ` NeilBrown 2018-10-23 4:52 ` Al Viro 2018-10-23 5:28 ` NeilBrown 2018-10-23 6:00 ` Al Viro 2018-10-23 20:45 ` NeilBrown 2018-10-23 8:11 ` Theodore Y. Ts'o 2018-10-23 14:22 ` Rainer Fiebig 2018-10-23 15:43 ` Theodore Y. Ts'o 2018-10-23 17:51 ` Rainer Fiebig 2018-10-23 21:14 ` NeilBrown 2018-10-24 12:16 ` Josh Triplett 2018-10-25 21:14 ` NeilBrown 2018-10-27 1:10 ` Josh Triplett 2018-10-28 21:48 ` NeilBrown 2018-11-01 16:45 ` Paul E. McKenney 2018-11-01 21:11 ` Josh Triplett 2018-11-02 13:13 ` Paul E. McKenney 2018-11-01 21:50 ` NeilBrown 2018-11-02 13:33 ` Paul E. McKenney 2018-11-03 8:36 ` NeilBrown 2018-11-03 17:37 ` Paul E. McKenney 2018-11-03 21:06 ` NeilBrown 2018-11-03 22:23 ` Paul E. McKenney 2018-11-02 13:52 ` James Bottomley 2018-11-03 9:19 ` Eric S. Raymond 2018-11-04 10:35 ` Geert Uytterhoeven 2018-10-21 22:33 ` Joe Perches 2018-10-21 22:37 ` Randy Dunlap 2018-10-22 9:09 ` Rainer Fiebig 2018-10-22 11:02 ` [Ksummit-discuss] " James Bottomley 2018-10-24 8:49 ` Laura Abbott 2018-10-25 7:56 ` The linux devs can rescind their license grant visionsofalice 2018-10-25 8:19 ` Greg Kroah-Hartman 2018-10-25 19:39 ` Eric S. Raymond 2018-10-25 20:47 ` Theodore Y. Ts'o 2018-10-25 21:41 ` Eric S. Raymond 2018-10-25 22:12 ` NeilBrown 2018-10-25 22:38 ` Eric S. Raymond 2018-10-25 22:52 ` NeilBrown 2018-11-04 10:47 ` [Ksummit-discuss] " Geert Uytterhoeven 2018-10-25 23:06 ` Al Viro 2018-10-26 2:28 ` Eric S. Raymond 2018-10-26 5:49 ` Al Viro 2018-10-27 6:52 ` visionsofalice 2018-10-27 7:32 ` Al Viro 2018-10-27 16:18 ` [Ksummit-discuss] " Tim.Bird 2018-10-27 22:09 ` Jiri Kosina [not found] ` <CAK2MWOtNUTjWy5pTcGco5DNurqNCc=9CfDJ-Ko-K+6HDC55ikg@mail.gmail.com> 2018-10-27 23:07 ` Eric S. Raymond 2018-10-27 23:40 ` Al Viro 2018-10-28 21:13 ` NeilBrown 2018-10-25 23:32 ` Iván Chavero 2018-10-26 13:15 ` Eben Moglen 2018-10-26 15:50 ` Eric S. Raymond 2018-10-26 15:53 ` Eben Moglen 2018-10-26 17:32 ` visionsofalice 2018-10-26 18:31 ` Eben Moglen 2018-10-27 7:12 ` visionsofalice 2018-12-18 18:53 ` The linux devs can rescind their license grant. - Analysis published? visionsofalice 2018-10-26 10:34 ` The linux devs can rescind their license grant visionsofalice 2018-10-29 22:31 ` Bradley M. Kuhn 2018-12-18 19:17 ` visionsofalice 2018-10-27 5:04 ` The linux devs can rescind their license grant. - Additional restrictive terms visionsofalice 2018-12-18 20:55 ` The CoC regime is a License violation " visionsofalice 2018-12-19 1:17 ` visionsofalice 2018-12-23 16:05 ` visionsofalice 2018-10-25 22:02 ` Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document NeilBrown 2018-10-25 8:06 ` Pavel Machek 2018-10-25 11:20 ` Rainer Fiebig 2018-10-25 22:18 ` NeilBrown 2018-10-26 8:33 ` Rainer Fiebig 2018-10-26 22:40 ` NeilBrown 2018-10-27 11:49 ` Rainer Fiebig 2018-10-21 23:36 ` Eric S. Raymond
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).