[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250402161158.444ca614@gandalf.local.home>
Date: Wed, 2 Apr 2025 16:11:58 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Sean Christopherson <seanjc@...gle.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>, Andy Shevchenko
<andy.shevchenko@...il.com>, Petr Mladek <pmladek@...e.com>, Sergey
Senozhatsky <senozhatsky@...omium.org>, John Ogness
<john.ogness@...utronix.de>, Andy Shevchenko
<andriy.shevchenko@...ux.intel.com>, Rasmus Villemoes
<linux@...musvillemoes.dk>, Peter Zijlstra <peterz@...radead.org>,
linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] more printk for 6.15
On Wed, 2 Apr 2025 13:00:20 -0700
Sean Christopherson <seanjc@...gle.com> wrote:
> "just Google it" does work most of the time, but search engines won't help all
> that much if the maintainer massaged the shortlog and/or changelog, especially
> if the surgery done when applying is significant.
Actually that's a good point. There's several times I get a patch with an
incoherent subject line, and I will change it without requesting for an
update. And usually in these cases I tend to rewrite the change log as the
submitter isn't a native English speaker and I reword it to make it have
proper grammar and such.
The Link: tag in this case is the only evidence that the commit came from
that email. The patch itself can sometimes be modified if there's a small
conflict with the current code. If it's anything more than "oh there's an
added line just before the code that this patch touches" I'll ask the
submitter to rebase, but for the case the code around the patch changed,
that's enough to make the commit not 100% what was submitted.
-- Steve
Powered by blists - more mailing lists