On Sat, Jun 01, 2024 at 12:33:31PM +0100, Mark Brown wrote: > On Mon, May 20, 2024 at 12:10:31PM -0400, James Bottomley wrote: > > On Sun, 2024-05-19 at 23:52 -0400, Kent Overstreet wrote: > > > > I also do (try to) post patches to the list that are doing something > > > interesting and worth discussion; the vast majority this cycle has > > > been boring syzbot crap... > > > you still don't say what problem not posting most patches solves? You > > imply it would slow you down, but getting git-send-email to post to a > > mailing list can actually be automated through a pre-push commit hook > > with no slowdown in the awesome rate at which you apply patches to your > > own tree. > > > Linux kernel process exists because it's been found to work over time. > > That's not to say it can't be changed, but it usually requires at least > > some stab at a reason before that happens. > > Even if no meaningful review ever happens on the actual posts there's > still utility in having the patches on a list and findable in lore, > since everything is normally on the list people end up with workflows > that assume that they'll be able to find things there. For example it's > common for test people who identify which patch introduces an issue to > grab the patch from lore in order to review any discussion of the patch, > then report by replying to the patch to help with context for their > report and get some help with figuring out a CC list. Posting costs > very little and makes people's lives easier. Exactly. This is the standard workflow that everyone depends on. So, for example, for my -next trees, I only ever add patches to them via "b4 am lore-url-here...". If I've got patches to add to -next from some devel tree, I don't cherry-pick them to my -next tree: I send them to lore, and then pull them back down. But the point is: send your stuff to lore. :) -- Kees Cook