On Thu, 10 Sep 2026 10:58:05 +0200 "David Hildenbrand (Arm)" <[email protected]> wrote:
> On 7/23/26 05:25, Gregory Price wrote: > > On Wed, Jul 22, 2026 at 05:19:42PM -0700, SJ Park wrote: > >> On Wed, 22 Jul 2026 08:16:56 -0400 Gregory Price <[email protected]> wrote: > >> > >>> > >>> See the damon changes in: > >>> > >>> https://lore.kernel.org/linux-mm/al-pkvmgIxGu3LzM@gourry-fedora-PF4VCD3F/T/#mfb99303c85dd9d4c3f58832dc28fc55583a7217a > >> > >> Summarizing what you want to say, quoting something from the patch, or at > >> least > >> calling it "26th patch of this series" would have made reviewing much > >> easier. > >> Cc-ing damon@ for only patches that toucing DAMON source files and the > >> cover > >> letter of the series could also be helpful. Please consider doing some of > >> these for future replies. > >> > > > > I have been very much discouraged from this kind of trimming because it > > removes the context of the series from the individual patches - making it > > even more confusing. > > Yes, 99% of upstream maintainers will scream at you if you CC them only on > individual patches :) I agree that not everyone would like selective Cc-ing, like I also replied. But the number might be changed after we got modern mailing archives and tools like lore (public-inbox)? At least for me, selective Cc-ing works better as long as the cover letter is Cc-ing all recipients of all patches. I can understand the high level picture from the cover letter and directly jump to the specific patch that require my attention. Of course the sender might failed at figuring out to which mails I really need to pay attention. If the cover letter doesn't tell me some details or I feel the sender might not Cc-ed me on all the patches that require my attention, I can fetch the entire thread from lore (public-inbox). Meanwhile, my private inbox have limited space and suboptimal UI. Hence I use my private inbox as just an alarm and usually work on only public-inbox with a CLI tool. Hence keeping noise in private inbox lower is more important to my specific workflow. Again, my workflow may be very different from others. Thanks, SJ [...]
