mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Doug Ledford <dledford@redhat.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Zhang Rui <rui.zhang@intel.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Linux PM list <linux-pm@vger.kernel.org>
Subject: Re: [GIT PULL] Thermal management updates for v5.4-rc1
Date: Fri, 27 Sep 2019 15:52:47 -0400	[thread overview]
Message-ID: <4ca02ad4e0c73f1ba2cbfd007f0d63421eaf5ba0.camel@redhat.com> (raw)
In-Reply-To: <CAHk-=whwYbKX1AqnOvcdT7T2GofRQqnb6xEJJ6+==ZZN1eEYQA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2881 bytes --]

On Fri, 2019-09-27 at 12:41 -0700, Linus Torvalds wrote:
> On Fri, Sep 27, 2019 at 12:29 PM Doug Ledford <dledford@redhat.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@redhat.com>
    GPG KeyID: B826A3330E572FDD
    Fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2019-09-27 19:52 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-27 13:08 Zhang Rui
2019-09-27 18:34 ` Linus Torvalds
2019-09-27 19:29   ` Doug Ledford
2019-09-27 19:41     ` Linus Torvalds
2019-09-27 19:52       ` Doug Ledford [this message]
2019-09-27 19:52     ` Richard Weinberger
2019-09-27 19:57       ` Doug Ledford
2019-09-30 13:09     ` Jonathan Corbet
2019-09-30 13:09       ` Jonathan Corbet
2019-09-28 14:00   ` Zhang Rui

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4ca02ad4e0c73f1ba2cbfd007f0d63421eaf5ba0.camel@redhat.com \
    --to=dledford@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=rui.zhang@intel.com \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®