Re: [GIT PULL] LEDs for v7.4

[Lee Jones]

On Mon, 26 Oct 2026, Linus Torvalds wrote:

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

Sorry Linus, this was a <copy>-<paste>-<paste> error during tagging.

Also, noted on the verbosity.  I'll summarise more in the future.

-- 
Lee Jones