linux-kernel - Re: [GIT PULL] Thermal management updates for v5.4-rc1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <64d13484950cab570e5f2691d7cdeca292882d95.camel@redhat.com>
Date:   Fri, 27 Sep 2019 15:29:47 -0400
From:   Doug Ledford <dledford@...hat.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Zhang Rui <rui.zhang@...el.com>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Linux PM list <linux-pm@...r.kernel.org>
Subject: Re: [GIT PULL] Thermal management updates for v5.4-rc1

On Fri, 2019-09-27 at 11:34 -0700, Linus Torvalds wrote:
> On Fri, Sep 27, 2019 at 6:08 AM Zhang Rui <rui.zhang@...el.com> wrote:
> > One thing to mention is that, all the patches have been tested in
> > linux-next for weeks, but there is a conflict detected, because
> > upstream has took commit eaf7b46083a7e34 ("docs: thermal: add it to
> > the
> > driver API") from jc-docs tree while I'm keeping a wrong version of
> > the
> > patch, so I just rebased my tree to fix this.
> 
> Why do I have to say this EVERY single release?

Because there are literally thousands of developers working on kernel
bits here and there, and you're swatting this particular fly one
developer at a time.

I might suggest that you need to speak with the git people and politely
ask them to add a warning to the rebase command itself so that it prints
out something like:

----

If you are doing linux kernel development, and you are doing a rebase,
please read Documentation/When_Not_To_Rebase.rst before rebasing your
code and sending it to Linus.  You've been warned.

Acknowledge receipt of warning and proceed with rebase? (y/N)

----

You would have free reign to put one of your more monumental yet funny
rants in place in the documentation.

You could also have a global git config to turn off the "Don't annoy
Linus with rebases" warning.  But only mention that global config at the
end of the kernel documentation so you know people have read it before
they turn the warning off.

Maybe that would help.

> A conflict is not a reason to rebase. Conflicts happen. They happen a
> lot. I deal with them, and it's usually trivial.
> 
> If you feel it's not trivial, just describe what the resolution is,
> rather than rebasing. Really.
> 
> Rebasing for a random conflict (particularly in documentation, for
> chrissake!) is like using an atomic bomb to swat a fly.  You have all
> those downsides, and there are basically _no_ upsides. It only makes
> for more work for me because I have to re-write this email for the
> millionth time, and that takes longer and is more aggravating than the
> conflict would have taken to just sort out.
> 
>                    Linus
-- 
Doug Ledford <dledford@...hat.com>
    GPG KeyID: B826A3330E572FDD
    Fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD

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