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.
Fixes: 8a104f8b5867c682 ("Code of Conduct: Let's revamp it.")
Signed-off-by: Geert Uytterhoeven <[email protected]>
Acked-by: Frank Rowand <[email protected]>
Acked-by: Arnaldo Carvalho de Melo <[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(-)
diff --git a/Documentation/process/code-of-conduct.rst b/Documentation/process/code-of-conduct.rst
index be50294aebd5db37..4379cce85faa804d 100644
--- a/Documentation/process/code-of-conduct.rst
+++ b/Documentation/process/code-of-conduct.rst
@@ -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
=============
--
2.17.1
On Sun, Dec 02, 2018 at 10:32:57AM +0100, Geert Uytterhoeven wrote:
> 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.
Acked-by: Joey Pabalinas <[email protected]>
> Fixes: 8a104f8b5867c682 ("Code of Conduct: Let's revamp it.")
> Signed-off-by: Geert Uytterhoeven <[email protected]>
> Acked-by: Frank Rowand <[email protected]>
> Acked-by: Arnaldo Carvalho de Melo <[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(-)
>
> diff --git a/Documentation/process/code-of-conduct.rst b/Documentation/process/code-of-conduct.rst
> index be50294aebd5db37..4379cce85faa804d 100644
> --- a/Documentation/process/code-of-conduct.rst
> +++ b/Documentation/process/code-of-conduct.rst
> @@ -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
> =============
> --
> 2.17.1
>
--
Cheers,
Joey Pabalinas
On Sun, Dec 02, 2018 at 10:32:57AM +0100, Geert Uytterhoeven wrote:
> 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.
>
> Fixes: 8a104f8b5867c682 ("Code of Conduct: Let's revamp it.")
> Signed-off-by: Geert Uytterhoeven <[email protected]>
> Acked-by: Frank Rowand <[email protected]>
> Acked-by: Arnaldo Carvalho de Melo <[email protected]>
> Acked-by: Tomi Valkeinen <[email protected]>
> Acked-by: Bart Van Assche <[email protected]>
> Acked-by: Pavel Machek <[email protected]>
Acked-by: Mike Rapoport <[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(-)
>
> diff --git a/Documentation/process/code-of-conduct.rst b/Documentation/process/code-of-conduct.rst
> index be50294aebd5db37..4379cce85faa804d 100644
> --- a/Documentation/process/code-of-conduct.rst
> +++ b/Documentation/process/code-of-conduct.rst
> @@ -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
> =============
> --
> 2.17.1
>
--
Sincerely yours,
Mike.
On Sun, Dec 02, 2018 at 10:32:57AM +0100, Geert Uytterhoeven wrote:
> 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,
On Mon, Dec 3, 2018 at 12:05 PM Greg Kroah-Hartman
<[email protected]> wrote:
> On Sun, Dec 02, 2018 at 10:32:57AM +0100, Geert Uytterhoeven wrote:
> > 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.
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
On Mon 2018-12-03 12:05:06, Greg Kroah-Hartman wrote:
> On Sun, Dec 02, 2018 at 10:32:57AM +0100, Geert Uytterhoeven wrote:
> > 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,
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".
> 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
> 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
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Mon, Dec 03, 2018 at 12:53:00PM +0100, Geert Uytterhoeven wrote:
> Hi Greg,
>
> On Mon, Dec 3, 2018 at 12:05 PM Greg Kroah-Hartman
> <[email protected]> wrote:
> > On Sun, Dec 02, 2018 at 10:32:57AM +0100, Geert Uytterhoeven wrote:
> > > 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.
>
> 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
On Mon, Dec 3, 2018 at 4:15 AM Pavel Machek <[email protected]> wrote:
>
> Linus, I don't think Greg is doing good job maintaining this. Can you
> take the patch? (Or explain what is going on here, because I don't
> think public has full story).
I think Greg is doing a fine job, and I personally will not take
patches to the CoC without *much* stronger reasons than just some
random opinion.
This is an area where everybody has opinions, and there is no inherent
technical agreement (ie no "look, numbers: this makes code 5%
faster"), so my policy wrt the CoC is that changes to it have to have
very concrete reasons for them. IOW, actual problems caused by real
issues, not "in my opinion".
Honestly, the list of discrimination factors looks fine to me, and if
it is shown to be insufficient or problematic, there's the documented
link to the Code of Conduct Committee. That sounds to me like the
right way to bring up problematic behavior - and if the review then
shows that "yes, the CoC should cover this too", then at that point we
have a real and present example and reason to modify the CoC.
Linus
On Mon, Dec 3, 2018 at 4:52 PM Linus Torvalds
<[email protected]> wrote:
>
> On Mon, Dec 3, 2018 at 4:15 AM Pavel Machek <[email protected]> wrote:
> >
> > Linus, I don't think Greg is doing good job maintaining this. Can you
> > take the patch?
> > (Or explain what is going on here, because I don't
> > think public has full story).
>
> I think Greg is doing a fine job, and I personally will not take
> patches to the CoC without *much* stronger reasons than just some
> random opinion.
>
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?
> 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(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c
index 9cc10e438b3d..55a0060881ea 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c
@@ -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
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/fuc/macros.fuc
b/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/fuc/macros.fuc
index 3737bd27f74e..ee364c71cc2e 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/fuc/macros.fuc
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/fuc/macros.fuc
@@ -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