Re: [GIT PULL] LEDs for v7.4

[Linus Torvalds]

On Mon, 26 Oct 2026 at 05:20, Lee Jones <lee@xxxxxxxxxx> wrote:
>
> Good afternoon Linus,

Lee,
 your pull requests are already fairly unreadable because they aren't
exactly summaries, they are long lists of details.

But darn it to heck, that is *not* made better by then repeating the
same long list of details *twice* for no apparent reason.

> LEDs for v7.4
>
> - New Support & Features
>   - Core: Add `led_trigger_notify_hw_control_changed()` to allow drivers to notify the
>     core of autonomous hardware control transitions
>   - Core: Add the `hw_offloaded()` trigger callback and [...]
[...]
> - New Support & Features
>   - Core: Add `led_trigger_notify_hw_control_changed()` to allow drivers to notify the
>     core of autonomous hardware control transitions
>   - Core: Add the `hw_offloaded()` trigger callback and [...]

Please try to make your pull requests more readable. Make them
explanations of what the pull brings in - highlighting important parts
but at the same time *summarizing* thg contents, not just listign
every single detail. Much less twice.

The goal of the pull request message should be to explain why I should
pull it, but also act as documentation for what has been going on.

The *details* are in the individual commits. Nobody wants the details
repeated, people want the highlevel "what's up, what's interesting,
what is this bringing to the kernel".

And the merge message is there as documentation for others to read, to
get an overview of what is going on - both if things work well, but
also if some merge ends up causing problems. That's when people look
at merge messages - for people do a "git bisect --first-parent" to do
a rough "which merge caused this problem", but also for people who
aren't experts on some particular subsystem but still want to get an
idea of what has happened.

A suggestion I've given other maintainers is to treat the pull request
not just as a "let Linus know", but also think of it as the thing that
sites like linuxnewbies and phoronix woudl be able to use to then let
people know about what is going on in new kernel versions. So yes, the
email is for me to know what I'm merging, but it's *also* for those
kinds of third parties (the third parties may be kernel developers
too, who just are working on other parts of the kernel but want to see
what is going on elsewhere - again, not interested in individual
commits, but in the "big picture")

And yes, when an already not very easily readable version then shows
up twice, that is just annoying.

                Linus