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: <4ca02ad4e0c73f1ba2cbfd007f0d63421eaf5ba0.camel@redhat.com>
Date:   Fri, 27 Sep 2019 15:52:47 -0400
From:   Doug Ledford <dledford@...hat.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Zhang Rui <rui.zhang@...el.com>,
        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 12:41 -0700, Linus Torvalds wrote:
> On Fri, Sep 27, 2019 at 12:29 PM Doug Ledford <dledford@...hat.com>
> wrote:
> > 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.
> 
> Well, at least these days it's also very clearly spelled out in the
> Documentation directory.

Yeah, but let's be fair.  How many people read the documentation fully? 
Or even if some new maintainer read it, did it really sink in?  Or will
they rebase a year later not thinking about it?

> And the "don't rebase" does get posted on the mailing lists each time,
> and I've mentioned it over the years in my release notes too.

Lots of people here and there miss those things.  You never know who
caught what.

> Besides, I actually only work with about a hundred top-level
> maintainers, not thousands. Yes, we have thousands of developers, but
> doing the stats over the 5.0 releases, there have been "only" 131
> people sending me pull requests. Sure, more than a couple, but at the
> same time it's not like this is a "every developer" kind of thing,
> this is literally subsystem maintainers. We've got a fair number of
> them, but it's definitely not about thousands.
> 
> I feel like I've sent that email out way more than a hundred times
> over the last 15+ years.

I'm sure you probably have.  I think I got it two or three times before
I got all the nuances of which rebases were OK and which weren't :-).

> .. and I don't think having git warn is right, since rebasing is
> perfectly fine as you are doing development.
> 
> It's really just that maintainers shouldn't do it for bad reasons and
> at bad times.
> 
> And "there was a conflict" and "yesterday" is really one of the
> absolute worst reasons/times around.

I think you send it out a lot because it doesn't get driven home in
people's heads until they get yelled at.  And there's more to the
badness of a rebase than just annoying you when you want to see the
conflicts to judge things for yourself.  There are legitimate issues
such as a rebase wipes out history.  Or if you rebase a public tree it
blows up everyone that is tracking that branch.  These things apply even
to when you are doing your own development.  Or rebases might wipe out
merge commits from other trees, depending on options.

A git warning solely for you might not truly be appropriate, but I'm not
at all convinced that a git warning with a more general "Here are the
pros and cons of rebases, with a list of dos and donts if you are going
to do a rebase" document is a bad idea, and might actually help you out
too.

-- 
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)