code-of-conduct: Remove explicit list of discrimination factors
Subsystems (6)
PATCH v3 1/1 code-of-conduct: Remove explicit list of discrimination factors
Providing an explicit list of discrimination factors may give the false impression that discrimination based on other unlisted factors would be allowed.
Furthermore, this list is already overly long, polarizing, politically-laden, and reinstating the concept of human races. None of these is related to the goals of the Linux kernel project.
Avoid any ambiguity or political undertone by removing the list, to ensure "a harassment-free experience for everyone", period.
---
v3:
- Add 2 Acked-bys,
- Add more rationale to the patch description.
v2:
- Add 3 Acked-bys.
--- Documentation/process/code-of-conduct.rst | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-)
Documentation/process/code-of-conduct.rst +1 -4
@@ -8,10 +8,7 @@ Our Pledge 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. +our community a harassment-free experience for everyone. Our Standards =============
Signature · 1 line
2.17.1
Quoted 10 lines · Geert Uytterhoeven
Providing an explicit list of discrimination factors may give the false impression that discrimination based on other unlisted factors would be allowed.
Furthermore, this list is already overly long, polarizing, politically-laden, and reinstating the concept of human races. None of these is related to the goals of the Linux kernel project.
Avoid any ambiguity or political undertone by removing the list, to ensure "a harassment-free experience for everyone", period.
I think this is a very important change as well.
Quoted 37 lines
Fixes 8a104f8b5867c682 ("Code of Conduct: Let's revamp it.")Signed-off-by Geert Uytterhoeven <[email protected]>Acked-by Frank Rowand <[email protected]>Acked-by Tomi Valkeinen <[email protected]>Acked-by Bart Van Assche <[email protected]>Acked-by Pavel Machek <[email protected]>---
v3:
- Add 2 Acked-bys,
- Add more rationale to the patch description.v2:
- Add 3 Acked-bys.--- Documentation/process/code-of-conduct.rst | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-)Documentation/process/code-of-conduct.rst +1
-4@@ -8,10 +8,7 @@ Our Pledge 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. +our community a harassment-free experience for everyone. Our Standards =============Signature · 1 line
2.17.1
Signature · 2 lines
Cheers, Joey Pabalinas
Quoted 11 lines · Geert Uytterhoeven
Providing an explicit list of discrimination factors may give the false impression that discrimination based on other unlisted factors would be allowed.
Furthermore, this list is already overly long, polarizing, politically-laden, and reinstating the concept of human races. None of these is related to the goals of the Linux kernel project.
Avoid any ambiguity or political undertone by removing the list, to ensure "a harassment-free experience for everyone", period.
Quoted 7 lines
Fixes 8a104f8b5867c682 ("Code of Conduct: Let's revamp it.")Signed-off-by Geert Uytterhoeven <[email protected]>Acked-by Frank Rowand <[email protected]>Acked-by Tomi Valkeinen <[email protected]>Acked-by Bart Van Assche <[email protected]>Acked-by Pavel Machek <[email protected]>
Quoted 30 lines
---
v3:
- Add 2 Acked-bys,
- Add more rationale to the patch description.v2:
- Add 3 Acked-bys.--- Documentation/process/code-of-conduct.rst | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-)Documentation/process/code-of-conduct.rst +1
-4@@ -8,10 +8,7 @@ Our Pledge 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. +our community a harassment-free experience for everyone. Our Standards =============Signature · 1 line
2.17.1
Signature · 2 lines
Sincerely yours, Mike.
Greg Kroah-Hartman
maintainerQuoted 10 lines · Geert Uytterhoeven
Providing an explicit list of discrimination factors may give the false impression that discrimination based on other unlisted factors would be allowed.
Furthermore, this list is already overly long, polarizing, politically-laden, and reinstating the concept of human races. None of these is related to the goals of the Linux kernel project.
Avoid any ambiguity or political undertone by removing the list, to ensure "a harassment-free experience for everyone", period.
I understand the reason you and others are proposing this change, however for now, let us stick with the text that we have. As Linus and I said just over a month ago, let's sit with the text we have until something comes up that requires a change to happen.
Also, I recommend you work with the upstream developers of this text to see if they agree with your changes here. If they do, and update their version, I will be glad to revisit this text at that time.
But everyone, please note that there are very specific reasons for listing things like this. You might not agree with those reasons, but many other people do so each "camp" can not be happy in the end. As we did have 3 years without such a list of factors, perhaps it is time to have 3 years with the list to provide a fair balance. :)
So I'm not going to accept this patch at this point in time, sorry.
thanks,
greg k-h
Hi Greg,
Quoted 12 lines · Greg Kroah-Hartman
Quoted 10 lines · Geert Uytterhoeven
Providing an explicit list of discrimination factors may give the false impression that discrimination based on other unlisted factors would be allowed.
Furthermore, this list is already overly long, polarizing, politically-laden, and reinstating the concept of human races. None of these is related to the goals of the Linux kernel project.
Avoid any ambiguity or political undertone by removing the list, to ensure "a harassment-free experience for everyone", period.
Quoted 8 lines
I understand the reason you and others are proposing this change, however for now, let us stick with the text that we have. As Linus and I said just over a month ago, let's sit with the text we have until something comes up that requires a change to happen.
Also, I recommend you work with the upstream developers of this text to see if they agree with your changes here. If they do, and update their version, I will be glad to revisit this text at that time.
I did, cfr. https://github.com/ContributorCovenant/contributor_covenant/issues/610
The official response was:
"I'm not going to make this change to the Contributor Covenant itself,
since I believe that explicitly listing examples of protected classes is important. However, any adopting project is free to modify the document according to the license."
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
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
Greg KH
maintainerQuoted 25 lines · Geert Uytterhoeven
Hi Greg,
Quoted 12 lines · Greg Kroah-Hartman
Quoted 10 lines · Geert Uytterhoeven
Providing an explicit list of discrimination factors may give the false impression that discrimination based on other unlisted factors would be allowed.
Furthermore, this list is already overly long, polarizing, politically-laden, and reinstating the concept of human races. None of these is related to the goals of the Linux kernel project.
Avoid any ambiguity or political undertone by removing the list, to ensure "a harassment-free experience for everyone", period.
Quoted 8 lines
I understand the reason you and others are proposing this change, however for now, let us stick with the text that we have. As Linus and I said just over a month ago, let's sit with the text we have until something comes up that requires a change to happen.
Also, I recommend you work with the upstream developers of this text to see if they agree with your changes here. If they do, and update their version, I will be glad to revisit this text at that time.
Quoted 8 lines
I did, cfr. https://github.com/ContributorCovenant/contributor_covenant/issues/610
The official response was:
"I'm not going to make this change to the Contributor Covenant itself,
since I believe that explicitly listing examples of protected classes is important. However, any adopting project is free to modify the document according to the license."
I figured. As I said, some people feel that the list is good to have, if not essential. So let's stick with it for now.
thanks,
greg k-h
Quoted 17 lines · Greg Kroah-Hartman
Quoted 10 lines · Geert Uytterhoeven
Providing an explicit list of discrimination factors may give the false impression that discrimination based on other unlisted factors would be allowed.
Furthermore, this list is already overly long, polarizing, politically-laden, and reinstating the concept of human races. None of these is related to the goals of the Linux kernel project.
Avoid any ambiguity or political undertone by removing the list, to ensure "a harassment-free experience for everyone", period.
I understand the reason you and others are proposing this change, however for now, let us stick with the text that we have. As Linus and I said just over a month ago, let's sit with the text we have until something comes up that requires a change to happen.
Quoted 6 lines
Also, I recommend you work with the upstream developers of this text to see if they agree with your changes here. If they do, and update their version, I will be glad to revisit this text at that time.
But everyone, please note that there are very specific reasons for listing things like this. You might not agree with those reasons,
So what are the reasons?
You marked yourself as a maintainer (and I do not think community agreement exists that you should be maintaining this), yet you refuse to take changes, pointing that there's "upstream".
Quoted 3 lines
many other people do so each "camp" can not be happy in the end. As we did have 3 years without such a list of factors, perhaps it is time to have 3 years with the list to provide a fair balance. :)
What kind of argumentation faul is this?
Aha. https://en.wikipedia.org/wiki/Argument_to_moderation
Quoted 1 line
So I'm not going to accept this patch at this point in time, sorry.
Linus, I don't think Greg is doing good job maintaining this. Can you take the patch? (Or explain what is going on here, because I don't think public has full story).
Thanks,
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Quoted 4 lines · Pavel Machek
Linus, I don't think Greg is doing good job maintaining this. Can you take the patch? (Or explain what is going on here, because I don't think public has full story).
I think Greg is doing a fine job, and I personally will not take patches to the CoC without *much* stronger reasons than just some random opinion.
This is an area where everybody has opinions, and there is no inherent technical agreement (ie no "look, numbers: this makes code 5% faster"), so my policy wrt the CoC is that changes to it have to have very concrete reasons for them. IOW, actual problems caused by real issues, not "in my opinion".
Honestly, the list of discrimination factors looks fine to me, and if it is shown to be insufficient or problematic, there's the documented link to the Code of Conduct Committee. That sounds to me like the right way to bring up problematic behavior - and if the review then shows that "yes, the CoC should cover this too", then at that point we have a real and present example and reason to modify the CoC.
Linus
Quoted 12 lines · Linus Torvalds
Quoted 5 lines · Pavel Machek
Linus, I don't think Greg is doing good job maintaining this. Can you take the patch?
(Or explain what is going on here, because I don't
think public has full story).I think Greg is doing a fine job, and I personally will not take patches to the CoC without *much* stronger reasons than just some random opinion.
Oh wow, see this is why I was 50/50 split on if I should still spend my time working on Linux anymore, glad that's now settled.
I think Greg is doing a fine job dodging questions by saying, "it's fine, just wait and see if something happens". Who are the $(people) that choose to put this document into the kernel repo, and most importantly, WHY? Was it You, Greg, Someone else too? What opinions lead $(people) to choose the exact wording in this document, are they not also "random" opinions on a non-technical issue that should be equally disregarded?
Quoted 5 lines
This is an area where everybody has opinions, and there is no inherent technical agreement ...
... actual problems caused by real
issues ...
What a nice *professional* reply, you wear your best suit and tie for sending emails now? We have reached canary status, IM{NR,R}O. Not that you people care, but FWIW: I'm officially done with upstream Linux as a bare metal kernel. I won't criticize any awkward patches people are proposing, or propose any of my own because I've lost trust in upstream to manage and defend the project adequately from it's competitors so this is all starting to feel like a waste of my free time now.
OK, I can't leave you all without letting you the one thing that angered me nearly every time I updated to a new "stable" kernel over the last 3-4 years. The phrase "we don't break userspace" is misleading at best, unless you assume all userspaces are running up to date .so's published by the kernel maintainers. All of my code interfaces directly with the kernel and not some .so layer that hides API breakage from it's users. Though my opinion is just some random and absolutely not professional or corporate sponsored opinion and thus in this newest age of Linux development, must be worthless!
Linux kernel dev's should now have to repeat this mantra "there is no breakage, your userland just needs updates!" (obviously /s). I was actually getting nervous about having to update from 4.14 soon and learning about the fun new undocumented behaviors (sadly not /s).
Sorry if this wording is too harsh, I mean no disrespect just genuinely DONE with this corporate bullhug[1] AND false sense of stability. AND the fact that you feel there are no real problems caused by horribly worded governance related documents with glaringly obvious and probably exploitable flaws. A document that AFAICT nobody likes except You, Greg, and a few people getting their paycheck from $(multi-billion-dollar corporation with questionable motives and history).
[1]: In order to comply with the CoC, replace **** with a hug.
--- drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c | 2 +- drivers/gpu/drm/nouveau/nvkm/subdev/pmu/fuc/macros.fuc | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
(quoted diff) +0 -0
b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c
index 9cc10e438b3d..55a0060881ea 100644
drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c +1 -1
@@ -446,7 +446,7 @@ init_ram_restrict(struct nvbios_init *init) {/* This appears to be the behaviour of the VBIOS parser, and *is* * important to cache the NV_PEXTDEV_BOOT0 on later chipsets to -* avoid fucking up the memory controller (somehow) by reading it +* avoid hugging up the memory controller (somehow) by reading it * on every INIT_RAM_RESTRICT_ZM_GROUP opcode. * * Preserving the non-caching behaviour on earlier chipsets just
(quoted diff) +0 -0
b/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/fuc/macros.fuc index 3737bd27f74e..ee364c71cc2e 100644
drivers/gpu/drm/nouveau/nvkm/subdev/pmu/fuc/macros.fuc +1 -1
@@ -46,7 +46,7 @@ #define NV_PPWR_INTR_EN_SET_SUBINTR 0x00000800 #define NV_PPWR_INTR_EN_SET_WATCHDOG 0x00000002 #define NV_PPWR_INTR_EN_CLR 0x0014 -#define NV_PPWR_INTR_EN_CLR_MASK /* fuck i hate envyas */ -1 +#define NV_PPWR_INTR_EN_CLR_MASK /* hug i hate envyas */ -1 #define NV_PPWR_INTR_ROUTE 0x001c #define NV_PPWR_TIMER_LOW 0x002c #define NV_PPWR_WATCHDOG_TIME 0x0034