From: Peter Zijlstra <peterz@infradead.org>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Steven Rostedt <rostedt@goodmis.org>,
James Bottomley <James.Bottomley@hansenpartnership.com>,
Mark Brown <broonie@kernel.org>,
Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Linus Torvalds <torvalds@linuxfoundation.org>,
"Michael S. Tsirkin" <mst@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Konstantin Ryabitsev <konstantin@linuxfoundation.org>,
users@kernel.org, tools@linux.kernel.org
Subject: Re: [workflows]Re: In defense of Link (was Re: [b4] initial "b4 dig" to supplant Link: trailers)
Date: Thu, 16 Oct 2025 09:32:32 +0200 [thread overview]
Message-ID: <20251016073232.GF3419281@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <20251015184043.GB30747@pendragon.ideasonboard.com>
On Wed, Oct 15, 2025 at 09:40:43PM +0300, Laurent Pinchart wrote:
> I've been similarly annoyed at partial series in the past, but that was
> because I wasn't CC'ed on some important patches, not because I didn't
> receive the whole series.
>
> When doing tree-wide or subsystem-wide refactoring, it's typical for the
> first patches to rework/improve/extend some APIs, and then for the
> remaining of the series to address drivers one at a time. The cover
> letter should explain the rationale. I've been CC'ed multiple times just
> on a patch that touches a driver I maintain, without being CC'ed on the
> first patches in the series that show what's going on. That's annoying,
> even if I'm CC'ed on the cover letter.
This, very much this. How are you supposed to judge the new API usage if
you've not seen the implementation.
But I've also had more involved cases where people were trying to solve
a 'problem' and me then only seeing a very small part of it and going
WTF. By going back and looking at the whole thing you can maybe suggest
an alternative approach, which isn't at all possible if you've just been
given a very small piece of the puzzle.
> On the other hand, being CC'ed on 50 patches touching lots of drivers
> in very similar way causes lots of noise.
>
> In such cases I try to adopt a middle ground, CC'ing everybody on the
> cover letter and the core patches, and CC'ing only relevant people to
> the driver patches. Is this something you would find annoying, would you
> prefer always being CC'ed on a full 50+ patch series ?
So I'm in the simple rules and overkill camp. Send me everything, that
way I'm sure you're not forgetting something.
The moment you start to make 'maybe' rules and people need to think
(like the Link thing seems to be now), things become subjective and
blergh.
So yeah, I would be okay with the core patches and the patches touching
'my' subsystems, but the moment we have a different view of what
constitutes that core, or someone fat-fingers it, I'd much rather have
been on everything. Everything is simpler, simple is good.
And I don't mind the 50+ patch series -- provided I can indeed really
ignore most of it. I'm very good at not reading email -- job requirement
for maintainers at this point :-(
next prev parent reply other threads:[~2025-10-16 7:33 UTC|newest]
Thread overview: 81+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-11 5:59 In defense of Link (was Re: [b4] initial "b4 dig" to supplant Link: trailers) Paolo Bonzini
2025-10-11 6:13 ` Willy Tarreau
2025-10-11 6:33 ` Paolo Bonzini
2025-10-15 8:56 ` Geert Uytterhoeven
2025-10-11 6:39 ` Jiri Slaby
2025-10-11 10:33 ` Mark Brown
2025-10-12 23:27 ` Jason Gunthorpe
2025-10-13 8:18 ` Vlastimil Babka (SUSE)
2025-10-13 8:27 ` Paolo Bonzini
2025-10-13 8:42 ` Willy Tarreau
2025-10-13 8:48 ` Jiri Slaby
2025-10-13 8:56 ` Willy Tarreau
2025-10-13 11:21 ` Laurent Pinchart
2025-10-13 14:26 ` [workflows]Re: " Steven Rostedt
2025-10-13 14:39 ` Laurent Pinchart
2025-10-13 14:59 ` Steven Rostedt
2025-10-13 15:04 ` Laurent Pinchart
2025-10-13 15:44 ` Steven Rostedt
2025-10-13 11:03 ` Mark Brown
2025-10-13 11:49 ` James Bottomley
2025-10-13 12:15 ` Mark Brown
2025-10-13 12:29 ` Paolo Bonzini
2025-10-13 12:47 ` James Bottomley
2025-10-13 13:02 ` Jürgen Groß
2025-10-15 18:05 ` Jeff Johnson
2025-10-16 16:47 ` Linus Torvalds
2025-10-13 12:21 ` Michael S. Tsirkin
2025-10-13 17:00 ` Linus Torvalds
2025-10-13 18:14 ` Paolo Bonzini
2025-10-13 18:53 ` Linus Torvalds
2025-10-13 20:12 ` Junio C Hamano
2025-10-13 21:44 ` Linus Torvalds
2025-10-13 23:22 ` Sasha Levin
2025-10-14 1:29 ` Linus Torvalds
2025-10-14 3:39 ` Willy Tarreau
2025-10-16 14:52 ` Geert Uytterhoeven
2025-10-16 15:08 ` Jason Gunthorpe
2025-10-16 15:33 ` Geert Uytterhoeven
2025-10-13 22:31 ` Paolo Bonzini
2025-10-14 6:47 ` Jiri Slaby
2025-10-13 21:59 ` Theodore Ts'o
2025-10-13 23:09 ` Michael S. Tsirkin
2025-10-14 1:23 ` Linus Torvalds
2025-10-14 10:38 ` Michael S. Tsirkin
2025-10-14 16:56 ` Linus Torvalds
2025-10-14 18:05 ` Luck, Tony
2025-10-14 18:41 ` Linus Torvalds
2025-10-14 19:09 ` Paolo Bonzini
2025-10-14 21:10 ` Jason Gunthorpe
2025-10-15 7:37 ` Geert Uytterhoeven
2025-10-15 7:33 ` Geert Uytterhoeven
2025-10-15 9:38 ` Miguel Ojeda
2025-10-15 12:11 ` Mark Brown
2025-10-15 13:50 ` James Bottomley
2025-10-15 13:59 ` Jürgen Groß
2025-10-15 15:08 ` Mark Brown
2025-10-15 15:14 ` Peter Zijlstra
2025-10-15 15:18 ` [workflows]Re: " Steven Rostedt
2025-10-15 15:53 ` Peter Zijlstra
2025-10-15 15:59 ` Steven Rostedt
2025-10-15 16:06 ` Peter Zijlstra
2025-10-15 16:15 ` Steven Rostedt
2025-10-15 16:43 ` Mark Brown
2025-10-15 16:15 ` Vlastimil Babka (SUSE)
2025-10-15 16:44 ` Steven Rostedt
2025-10-15 16:58 ` Konstantin Ryabitsev
2025-10-16 9:28 ` Matthieu Baerts
2025-10-15 17:01 ` Miguel Ojeda
2025-10-15 18:40 ` Laurent Pinchart
2025-10-16 7:32 ` Peter Zijlstra [this message]
2025-10-16 8:20 ` Vlastimil Babka (SUSE)
2025-10-16 13:58 ` Steven Rostedt
2025-10-15 14:37 ` Miguel Ojeda
2025-10-15 14:50 ` [workflows]Re: " Steven Rostedt
2025-10-15 13:51 ` Martin K. Petersen
2025-10-15 14:16 ` Konstantin Ryabitsev
2025-10-15 14:42 ` Miguel Ojeda
2025-10-15 15:03 ` Jason Gunthorpe
2025-10-15 14:55 ` [workflows]Re: " Steven Rostedt
2025-10-15 17:34 ` Martin K. Petersen
2025-10-15 14:51 ` Geert Uytterhoeven
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=20251016073232.GF3419281@noisy.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=James.Bottomley@hansenpartnership.com \
--cc=broonie@kernel.org \
--cc=geert@linux-m68k.org \
--cc=konstantin@linuxfoundation.org \
--cc=laurent.pinchart@ideasonboard.com \
--cc=miguel.ojeda.sandonis@gmail.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=rostedt@goodmis.org \
--cc=tools@linux.kernel.org \
--cc=torvalds@linuxfoundation.org \
--cc=users@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.